I'm building an application where I want to provide the user with a few dozen templates that will internally take the form of property lists. I would also want to group them in categories, which would conveniently be achieved using folders.
While I have contemplated shipping these files as simple resources in my application, I don't like the idea of this single location containing dozens and dozens of files, and besides it doesn't seem to be possible to group them in folders.
I can see that many applications have installed such resources in their application support directory (~/Library/Application Support//...), but I can't seem to find any documentation resource on how to achieve this.
I don't like the idea of this single location containing dozens and dozens of files, and besides it doesn't seem to be possible to group them in folders.
It is. Put them in folders in your project directory, then add the top-level folder(s) to your project. Make sure you add it/them as folder reference(s) and not group(s) (see? that sheet does have a purpose!).
Then, add the folder reference(s) to your Copy Bundle Resources or Copy Files phase.
One word of warning: When you change one of the files in the folder, you may need to “touch” the folder to get Xcode to re-copy it. You can do this in Xcode or from the terminal.
You can group items in sub-folders of your app bundle's Resources directory. Unless you want users to edit these plists, keeping them in your app bundle allows users to drag-n-drop install your app, rather than having to use an installer package (a big win).
You can group them into folders in your application bundle by adding a "New Copy Files Build Phase" to your project as described in this forum post:
http://forums.macrumors.com/showthread.php?t=458594
Related
In Xcode, what is the difference between a folder and a group? Are these interchangeable terms or is there a subtle difference?
Groups
With groups, Xcode stores in the project a reference to each individual file.
Folders
Folder references are simpler. You can spot a folder reference because it shows up in blue instead of yellow.
There are two types of folders in Xcode: groups and folder references.
You can use groups to organize files in your project without affecting
their structure on the actual file system. This is great for code,
because you’re only going to be working with your code in Xcode. On
the other hand, groups aren’t very good for resource files.
On any reasonably complicated project, you’ll usually be dealing with
dozens – if not hundreds – of asset files, and those assets will need
to be modified and manipulated from outside of Xcode, either by you or
a designer. Putting all of your resource files in one flat folder is a
recipe for disaster. This is where folder references come in. They
allow you to organize your files into folders on your file system and
keep that same folder structure in Xcode.
Reference
A folder in Xcode represents a folder in the file system.
A group in Xcode is a "fake" folder which does NOT represent a folder in the file system.
It is common to use a combination of groups and folders for a given Xcode project.
Xcode behavior (starting with v9) has changed and groups are now actual folders on-disk.
I found that Xcode 9.2 has two versions of group when you create a group. One is group the other is group without folder. The first one also creates folder in your file system, the second one doesn't.
I was following a tutorial and it had me drag a nested folder with a number of autogenerated Swift files with public classes and structs. I missed that I was supposed to click the "Create groups" and not "Create folder references". When I added the folders/paths using the incorrect 'folder ref', my other scripts did not see these public objects. When I did it the right way, added them using 'groups', then they were recognized in other scripts. I think this is in keeping with TheNitram's comment, that 'group' adds to the root ...
My application stores logs in /Users/username/Library/Logs/appname and preferences in /Users/username/Library/Preferences/appname but where I should store the reports it creates.
Originally they were in Logs, but they are not really logs. I then thought about putting them in /Users/username/Library/Reports/appname but the Reports folder does not exist under Library and it seems bad practise to create additional folders at this level.
What is the correct mac-friendly way to do things ?
A good candidate would be your app's folder in ~/Library/Application Support/
You may need to create it, and you should really use the bundle identifier for your app as the folder name.
~/Library/Application Support/com.bundleIdentifier.something/
In there you can create whatever you need to to support your app.
File System Programming Guide
Important: The files in the user’s Documents and Desktop directories
should reflect only the documents that the user created and works with
directly. Similarly, the media directories should contain only the
user’s media files. Those directories must never be used to store data
files that your app creates and manages automatically. If you need a
place to store automatically generated files, use the Library
directory, which is designated specifically for that purpose. For
information on where to put files in the Library directory, see “The
Library Directory Stores App-Specific Files.”
Application Support Use this directory to store all app data files except those associated with the user’s documents. For example, you
might use this directory to store app-created data files,
configuration files, templates, or other fixed or modifiable resources
that are managed by the app. An app might use this directory to store
a modifiable copy of resources contained initially in the app’s
bundle. A game might use this directory to store new levels purchased
by the user and downloaded from a server. All content in this
directory should be placed in a custom subdirectory whose name is that
of your app’s bundle identifier or your company. In iOS, the contents
of this directory are backed up by iTunes.
As far as I figured, those are reports that are the end result of the app itself and are something the user needs to have access to.
Even more so, the reports are HTML (so a valid recognizable format)?
I think that constitutes them as documents.
I would put a folder in documents named after the app and put the reports there.
A lot of apps do that (Office comes to mind at the moment).
I involved with the development of an application that is intended to deploy on multiple desktop system including the Macintosh.
Our team decided we would like to a drag and drop installation for the Macintosh. However, the application is intended to ship with other content besides the application itself such as example files.
Originally these files were placed in the application bundle, however this was discovered to be problematic as the cross platform libraries used for the user interface will not allow someone to access the contents in the bundle. Also force users to have to dive into a bundle to find content does not offer a great user experience.
To that end, we decided to pull these examples file and what not out of the bundle and place them in a separated folder that lived along side the application bundle. To make sure everything including the examples and the application were copied together during the drag and drop installation, a new top level folder was created that contained everything to be copied.
The problem that now exists is that whereby when originally just the application bundle was copied over to the system, the copying of this top level folder does not cause file associations for the application to occur automatically.
What can be done to associate an application with certain files when someone installs by dragging a folder contain the application bundle?
I suggest you to deliver it separately in one dmg. So your dmg structure will look like next:
MyApp -> Applications
MyApp Examples -> Application Support
Simple, user-friendly, no problems with association.
Actually it looks like the file association is working after all. Someone reported a defect against the installation not making the associations. However, I just tested the installation on a clean system and copying over the folder does seem to make the associations.
Whenever I am adding some files to my project by dragging and dropping in Xcode, a popup message is shown "Copy items into destination's group folder (if needed)".
I noticed that when we are using most of the third party library's we DON'T tick the checkbox and instead specify the library path in "Header Search Path/Library search Path". But for smaller resource files like images, we tick the checkbox.
Which specific scenarios do I have to tick and what difference will it make?
It all depends on how you want to organize you project. It's far more common to store 3rd party frameworks somewhere on your machine that is independent of any project that may use that framework, thus allowing multiple projects to reference the same shared framework project from a standard directory. In that case, you don't want the 3rd party framework copied into your own project, and so you don't check that box.
Images and other resource files are typically owned on a project-by-project basis, so it makes the most sense to store those in the directory of the project itself. To pull that off, you check that box to make sure a copy is made in the project's directory if one doesn't already exist.
Neither of those rules are absolute, you could copy an entire framework into your project's directory if you want, and you could reference media assets from some standard location. It's all up to you to implement good project organization.
Typically, your project is saved to a project folder. If you drag stuff from outside the folder into your project without copying, only references to the added files are stored. You will have to be careful not to delete them, or your project will break.
Also, if you are using version control, such as the built-in git, files not in the main folder will not get added to your version tree.
I got into the habit of copying everything I need into the main folder and then drag-add without copying. This is working well for me and has so far avoided any errors.
what is copy items into destination group's folder (if needed)
is this a good option? If I dont choose it will it just make a reference to my files?
Also if I have two images with the same name like /images/home.gif, /public/home.gif
but they are in different groups how does the compile know which image to use? is this even possible?
I'll have a crack at this :-)
1 & 2 - Used when adding files to a project. If selected, the file you are adding is copied into the projects directory from wherever it originally was. Note it is copied. If not selected, the project can still use it, it just has a reference to the original source file. Which means that if something happens to the original file, the project will not longer have a copy it can use. Personally for files such as images I copy them into the project so they stay with the project. For other things such as external apis, I don't because I don't want multiple copies everywhere.
3 - If you have two images with the same name you won't be able to copy them in without renaming one. XCode may do this for you, I've never tried. I'd suggest renaming one so you control it's name.
4 - Don't get confused by groups. They are logical groupings of files within XCode and do not refer to the underlying file system. Having said that you can actually assign a directory to a group so if you really wanted to you can match the two. I tend to do it a little. In my projects I generally have a src and test directory. I setup two groups and assign them to refer to these directories. Then when I create a new source code file I can create it in the src or test group and it will be created in the sub-directory instead of the project root directory. Often below src and test I will use other groups, but they do not map to any sub directories. The result is that the root directory of the project is free of source code files and the source code also has source and test code separated.