This may sound like a bit of a silly question- but do any of you have any "preferred" methods of keeping a large iPhone/iPad project organized? More specifically, any type of strict directory/layout structures?
I know this question has been asked before in the context of something like an Xcode project- but what I'm wondering is what would be the best way to organize and keep an -entire- project clean and tidy. This includes other assets that are not directly used by Xcode, but otherwise exist as they are used to generate the assets that get included in Xcode (ie, Logic Pro tracks, Cinema 4D scenes, meshes modelled up in Modo, PSD and AI source files, etc...).
Some of our larger projects are getting a bit disorganized and difficult to make sense of, which is why I'm asking. I want to implement some sort of strict directory structure that everything will eventually adhere to (apart from the things already sitting in source control). We deal with multiple programs for the various assets that get used by Xcode to produce the final game- so it isn't unfortunately as simple as just tossing everything in the Xcode project folder and calling it quits.
Cheers,
-CMPX
I like to follow a Rails inspired layout:
App (AppDelegate and stuff)
Controllers (All the controllers)
Views (All your XIB's)
Models (All your models)
Libraries (all Apple and 3rd party stuff)
Images (static images)
HTML (for local webviews and stuff)
...
Works for me :)
For me, I keep two separate folders 1 for the Xcode project with all the final assets. The other folder external to the Xcode project folder is the art asset folder where I create all the graphics and later import them into my Xcode project.
In the Xcode project, I create separate folders for different types of assets such as classes and images, audio files, textures and so on.
We found that separation as Apple suggests by default on models / views/ controllers (in different folders) is not sufficient. We are trying to keep structure workflow / functionality oriented but flattening the structure of a project to keep all layers of an app visible for further code reuse. All XIB files usually kept in the same place with code files to make it simple to modify solution. All resources are divided by types at the top level and by workflows / functionality underneath.
Related
Is there a way to know what is of all my GO, textures, sounds, etc, are not in use in all scenes, to delete it?
When i tested my game, I have inserted some textures, sounds, GO etc and some of them are not in use.
I'm using Unity 5.1.1.
2018 ..
The modern solution is simply ..
Click on your scene(s) and select "Select Dependencies".
It will show you what is used; the rest is unused. Really it's that easy.
As with many things in Unity pipeline, it is very common to use an asset, virtually every project uses a few well known assets. "A+ Assets Explorer" (link) is very common.
When Unity builds the executable, it does so only with required assets. Anything else that might exist in your scenes or projects is simply ignored.
This answer over on Unity Answers has more info.
There are also options available in the Asset Store, such as this one.
Asset Hunter is a tool that analyzes your buildlog and gives you an easily understandable overview over unused assets in your project folder.
The results are grouped into folders and file types, making it easy to start cleaning up your project.
I'm developing an iPhone app that can edit images. Ultimately, I want to have a small version that allows the user to simply edit their images, and a large version that allows social networking of the images. Then I'd like to develop a version of each for the iPad.
Being that this is my first foray into commercial mobile development, I'm confused about how to organize all these versions in Xcode. Obviously, there will be file reuse shared between each version. I guess my question is, how do I go about organizing these separate projects in the most efficient way so that they share files and so when I edit a particular file that is shared, the changes are made to each version of the application? Is there some kind of construct to follow in XCode?
Are there any links or literature on how to go about doing this? (was not sure the correct term to search for it).
Remember: If you find yourself repeating/duplicating something, suspect that you're doing it wrong.
Your Xcode project will have 4 targets in this scenario. The basic target layout for this setup looks like this:
A Static Library (for your shared source files)
A Resource Bundle (for your shared resources)
App-Full (Universal)
App-Lite (Universal)
The apps link to the shared static library, and copy the resource bundle.
Naturally, apps will have sources/libraries/dependencies which differ -- those go in the app target (or some other dependency).
Given your background: Plan on it taking a good amount of time (initially and as you go) and patience to figure out how these dependencies should be composed, used, and maintained.
I would suggest keeping the "lite" and "full" projects separate but within the same workspace. That way you can keep the shared files in one project and simply use a shared reference to them in the other. All changes made to the shared files from either project will affect both.
As far as iPhone/iPad versions, I would also suggest that you keep these apps completely separate but within the same workspace (so that they can share code) as well. If you look around about the suggestions for managing both apps in a single project (aka, universal app), the only real benefit is that customers can buy one app and can download it on either device and some may get upset if that isn't available to them. If your app is free, don't worry about it.
Lastly, a caveat about workspaces, you need to uniquely name your files across all projects. For example if you're working with a project that uses a MainViewController.h subclass and another project that uses a MainViewController.h subclass, you could assign or edit the wrong one by accident regardless of what project you're in, so be wary. If using unique file names is a problem, you can bypass using workspaces by simply creating an empty project to dump all of your shared code into and then add references to your standalone apps from there.
If you choose to keep various copies of your project for different functionality, it will be eventually confusing, as there are places when XCode offers you one thing instead of another. One such place is - when you open a project from location X, it will also show you your copy from location Y since you opened it last time. As a result, you are likely to commit more mistakes. Organizer is one more such place where you can make mistakes.
XCode is self-contained enough to maintain both iPhone and iPad versions. You will have two separate storyboards which can be made part of one project if you chose universal as the type of app.
As for various features, you shouldn't be maintaining separate copies of your project. Instead, recommended way is to keep all features within single project, and have app logic provide access to various features.
XCode keeps version of your build under Targets section when you click project. To maintain multiple versions through your dev cycle, use source code repository (git or svn).
Are there any best practices for how to organise one's solution in xcode
This is mine at the moment from the root:
A folder for each 3rd party framework e.g. KissXML
A folder for my unit tests
A folder for frameworks, products and resources
A folder for MyApp which has sub folders for model, view, controller, database, supporting files and domain.
Mine is:
Main application
Model
Singletons
Helper+managers
Controllers // I keep nibs with their respective class files
View
Resources
images
plists
// ... groups from other types of resources if needed
Supporting files
Unit tests
Frameworks
For reusable code on iOS I use static libraries and add these as separate projects in the Xcode workspace. Even for third-party code, if there is not a static library target, I create one. That way, I treat third-party code the same way as I treat my own library code. Further, then I don't have to worry about versioning of third-party code.
I've found it important to have Xcode mirror the file system organization of the code, at least up to some level. I adopted this practice after reading this blog post. I don't do this below the levels I've listed above, though. This helps when you share code on github, for example. Rather than have downloaders or contributors have to dig through all of your source dumped into a single directory, it is organized into functional buckets. I've seen some projects where the Xcode organization is OK, but every single source file in the file system is dumped into a single directory.
Although no particular method can be devoid of disadvantages, here is what we use
Folder for Application core or Model. This includes sub-folders for
any third party libraries used and folders for specialized model
classes. For example there would be folder for web service handling.
Folder for one major module which would include sub-folders for each
screen containing class files, nibs and resources (this may include
more sub-folders according to the need).
Folder for second major module and so on..
This model serves us one major purpose. Our application core contains stuff like logging, data encryption/decryption etc. So it is very unlikely to be changed for many applications that we develop. Similarly there would be some applications which would need functionality of major module one and add some other things. Therefore these three folder groups are maintained as separate repositories on the subversion.
Now when we start a new project, we create a new repository for the project and link it with the application core repository and other major module repositories according to the need. So any changes made in application core by one project team, is reflected in other projects as well. Same with other major modules. This also helps us to achieve complete modularity.
Of course there would be disadvantages to this scheme, but this scheme has suited us well for many years now :)
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 realise that the view/controller stuff will be different between Mac and IPhone apps but the model code may well be similar/the same. So whats the best way to organise a project(s) so that the model code is/can be shared?
Copy/paste - just duplicate it and manually keep it in sync
Have 2 xcode projects point at the same workarea - one for Mac and one for IPhone and share the code.
Common library - presumably you can't do this (or can you)
Thanks for any tips.
There are a few ways to do this. The first thing you can do is is create a project that builds as a framework on Mac OS X. Since you cannot use frameworks on iPhone, you can make static library target that contains the same code files. That basically works, but the header paths will be different. If you want the header paths to be the the same (i.e. <Myframework/MyFramework.h>) you will need to modify the the install path of the static library headers so that they are copied into "$SDK_ROOT/usr/local/include/MyFramework", and make sure /usr/local/include is an included header search path. You will then need to install the library and headers into each SDK_ROOT.
I started out doing the above, but I found it to be a royal pain. So I ended up doing something that is a variant of #2. Basically, I get the header paths to be equivalent by making a directory named "Externals" in my iPhone project root, then a directory named with the appropriate name ("MyFramework") in the externals folder. That is the folder I copy I drag the framework files into.Findally I add the Externals folder as a system header path (which is admittedly sort of a gross hack). You need to manually add new files to the iPhone project, but I have found that to be less of a pain the installing static libs into my build root.
I'm not sure if the suggestion from the previous answer would work. If you look at my previous question, you'll see that I've failed to load a custom framework on the iPhone even though the framework works fine on Mac.
I would go with method 2.
You could develop your application in JavaScript, CSS, and HTML. You would use the WebView and UIWebView objects on the Mac and the iPhone respectively. You can do pretty much anything you want in the WebView objects, even make calls down to Objective-C.
The QuickConnectiPhone installer, found here https://sourceforge.net/projects/quickconnect/, installs QuickConnectMac and QuickConnectiPhone templates into Xcode.
This way you can quickly create an application in one environment and then migrate the view to the other. In fact the QuickConnect framework is highly modular.
If you don't want to develop in JavaScript the same modular framework is found on the Objective-C side of the templates installed.
It should make it much easier for you to do what you are attempting.