I am porting an existing project from Flash Pro to Flash Builder.
The code is almost completely portable between Web/Android/Projector/AIR, and I simply change a few constants for each target device before hitting publish...
However- in Flash Builder, it asks me when creating a project whether it will be mobile or web.
What's the best-practices way to target multiple devices from a single project in Flash Builder?
OR, in Flash Builder, must they each be their own project? If they must each be their own project- is there a multi-project organization method which works well, keeping in mind that in this context each project is really just a different build of the almost-identical codebase (On one foot- I thought of having a "common" project which would hold most classes, and then each build-project instantiates a Main class from there...)?
Thanks!
You can create a mobile project with one codebase and select multiple devices (android, ios, blackberry playbook). If you also want a web version, you should be able to specify that codebase in the build path for your web version. You do that by going to Properties --> Actionscript Build Path. Click Source Path and then browse to the folder that contains those files. So yes, you can create a different Main.as, if you need to, for each project. Although in Actionscript the entrypoint class generally has the same name as the Project itself.
You'll then be able to modify one set of files, but the modifications will apply both to the original project and to any project which references those files in this way.
Related
I want to build two apps, one optimized for iphone and one for ipad.
both of these applications invoke server API calls and would share the same code for model objects, so I would like to share this code between my iphone and ipad projects.
I am using xCode 4, with a concept of workspace (which is supposed to allow sharing of code between projects) but I was wondering if I need to create another project for just the shared code.
Has anyone done this and care to share the best practices?
I prefer to share code across projects, be it for iPhone/iPad reuse or any other sharing scenario by leveraging a Static Library Project to house shared code, and used as a Target Dependency in all projects that consume it. In a bit more detail...
You can create a new Xcode Project with a Cocoa Touch Static Library template. This project can house all of the shared code between projects. Then, in any app in which you want to use the static library, you can add a project reference to the static library project by dragging the static lib project into the client project. In this client project, it's a good idea to add the static library as a Target Dependency build phase of the client project. This forces the shared library to be re-built anytime the client project is built. Then, you'll add the static library product to the "Link Binary With Libraries" build phase of the client project.
And, as one final caveat, you also need to tell the client project where the headers for the static library live. This is a result of static libs not containing their own headers like a Cocoa Framework on the Mac does. To do so, just find the "Header Search Path" build setting in the client project, and add the path to the static library headers. I've found it most useful to reference the ones produced by Xcode and placed in Derived Data (if you have Xcode configured to do so).
If you are going to build two separate applications, then you need to create one workspace with two iOS application projects and one static library project. The static library should contain all of your shared code, and the library should be included by both of your iOS application projects.
I have an iPhone/iPad app that I want to port to MacOSX. Most of my objective C classes should work just fine as long as they do not contain UIKit stuff. Obviously the interface will be different.
What is the best way to do this in Xcode? Start a completely new project? Add a new target? How can I keep the different platforms in sync? Should I just use git with multiple branches?
I've had difficulty setting up a unified project with different targets for the two OS types, so I generally split this into two projects that share source files.
For an application that will be targeted Mac and iOS, I tend to create one directory for the application. I place the two projects within this, and set up one directory for shared source files, one for iOS-specific stuff, and a third for Mac-specific stuff. This way, you might have different projects, but shared files will update between them as they are changed. The only time you manually have to sync the two is when a new shared file is added to the application and must be added to both projects independently.
You should be able to restructure your existing project to support this without much trouble.
You can also simply add the files from one project as references to the other one. Simply drag them from the source project (where the actual files reside) into the other project. The dialog will ask you whether you want to copy the files. Choose no. This will make the second project point to the files in the first project. Edits go into both projects.
Be careful with this, though, as there are a few differences between APIs in iOS and MacOS, even if they are called the same.
I've build a static library working nice in a Cocoa Touch environment. Now I'd like to compile it also for Cocoa.. Can I have a single XCode project with different sdk targets? Is there some resource out there able to give hints about best the practices in this (and other) sense?
This last two months I have been working on exactly this task ( cross compiling static library for iPhone/Android/Mac OS/Linux/Windows...
It is certainly possible, a nice way, is adding an external xcode project as a target to your first xcode project. So you create a new "Active Configuration" for Mac OS X, iPhone and other platforms that you want to support.
Here, you can find a good tutorial about how to use a secondary Xcode project as a target of your main project to build a static library. It's a cool way because if you debug for example you still have all the symbols of the library, etc.
It can be done but it requires some manual tweaking of the build.
Start with the Xcode Build System Guide.
As an informal way of accomplishing this, you can create two separate projects and add references for exact same set of library source files to each project. Set one project to compile for Cocoa-Touch and the other for Cocoa. If both projects reference the same files, changes made in one project will be automatically reflected in the other. (If you have both projects open, Xcode will complain that the file has been changed by another app but otherwise it won't notice.)
I have a utility class that I continually dump new methods in. I add it to every project and just park methods as I need it. The new methods show up in old projects because the source files are shared across all the projects.
I have an iPhone app, and I'm taking a few features of the app and creating a new app.
What's the appropriate way to build two apps from a common code base?
One more option nobody seems to have mentioned yet - you can create a new target in the original project file. I do this for "free" and "paid" versions of the same app, but it'd be useful for any two apps that share most of the same code.
I got this from an Xcode expert:
Xcode has two affordances to do the right thing here:
1) For files outside your project tree that your project requires, set up a source tree. Xcode > Preferences > Source Trees, define a symbolic path (e.g. EXTRA_SOURCES) with the actual path on your disk to where they're checked out. Then when you add those files to your project, add them Relative to Source Tree to that source tree.
(N.B. Quit and restart Xcode after defining the source tree in Prefs.)
2) In Xcode 3.2, define the Project Roots to include the Source Tree. Project > Edit Project Settings > General tab, "Configure Roots & SCM" button. Add the source tree to the Project Roots and set up its repository, which can be a separate repository from your main project files.
That's it. You have one file tree, from one repository, but many projects can share it, and if you perform an SCM operation on the source in one project it's reflected in others.
Ideally you would be able to make a dynamically linked shared library (or "framework" in Apple parlance) from the common code, but the iPhone platform does not support this. In addition to the approaches already suggested here, you can link against your own static libraries.
Building static libraries with the iPhone SDK
Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References
Keep the common code in a common repository. Then you can easily use it in as many projects as you want.
I am developing an iPhone app and have to parse xml files in order to put them into a database. I will also be using those same xml parsers in my app so users can import their own data. I was wondering how I can extract those xml parsers into a bundle or a library so I can use them both in my iPhone app and in a command line app where I just populate a sqlite3 database.
Thanks in advance!
Create a static library project, then use the interproject dependency feature of Xcode to build them in the correct order and link the app with the static library. You'll need to have a common build directory set for all the projects for this to work correctly (at least you did around Xcode 3.0, didn't check if this is still a problem with 3.1).
You can set the build directory from the target or project's build settings (in the Get Info pane). To create an interpoject dependency:
Drag the library project into the application project's Files & Groups pane.
Set up target dependency in the application target's Get Info pane. Make it dependent on the library's target.
Drag the library product in the application target's Link With Libraries step. You can find the library product by expanding the library project within the app project's Files & Groups (click the arrow).
Sounds more complicated than it is. It isn't much.
(Small extras: yes, you need a common build folder as indicated in the Xcode Project Management Guide, and the Xcode Build System Guide can help you "get" Xcode's build system, which -- at the cost of starting a religion war -- I think is one of the most flexible and simple build systems out there.)