Can I access an xcassets directory on the filesystem? - ios

I would like to dynamically load all images in an xcassets directory. The files are named StockPhoto# where # is the number in the list. If I can access my StockPhotos.xcassets at runtime to count all the files in the directory, I won't have to manually load the files each time I add new stock photos.
If there are other solutions to this problem, I'm open to that but I'm also just very curious how xcassets are handled by the file system- whether they're just reference to a set of files, or actually their own directory. Information on this is sparse.

If there are other solutions to this problem, I'm open to that
The problem is that there is no introspection at runtime into an asset catalog: it isn't a "thing" you can "see" as far as Objective-C and Cocoa Touch are concerned.
The usual solution to this kind of problem is to drag a folder full of images into your project at the outset, and when you do, choose "Create folder references for any added folders" in the dialog - not "Create groups for any added folders". The result is that the folder is copied into your app bundle, and now you can use ordinary file system methods to say "every file in this folder".

Upon compilation of your iOS project, xcassets are compiled to produce either image files, or a proprietary .car file. In that latter case images won't be stored in a directory you can browse.
If your "Deployment Target" is less that iOS7 (meaning that your app would still be able to run on iOS6)
It will produces the same set of image files that you would have had to produce without using Assets Catalog, namely <YourImageName>.png, <YourImageName>#2x.png, <YourImageName>~ipad.png, <YourImageName>~ipad#2x.png and so on, for each image set of your xcassets.
If your "Deployment Target" is iOS7 or greater (meaning that your app would only be able to run on iOS7+)
It will produce a single big .car file in the final bundle (I don't really looked up if this file was actually an sqlite3 datatbase or some proprietary format or whatnot, but who cares, you are not supposed to manipulate it anyway). This big .car file contains all the images, with all their provided variants, and even with slicing info (if you did slice some of them for tiling or to use them as 9-patch images using the tool provided for that in the Assets Catalog editor)
Whatever the produced result you shouldn't / are not supposed to dig into internal details of your bundle like that. The format of the .car file may even change from one iOS version to another (who knows? that's internal details after all which we shouldn't have to deal with) so don't base your logic on it.
[EDIT]: If you need to be sure to have a directory with your set of images at the end of the compilation, you could instead use a folder reference (referencing a real folder in the Finder, as opposed to an Xcode "group" as only group files in Xcode's Project Navigator) then use code to browse it. But then you will have to deal with other details, like only browse files that match the current device (iPhone vs. iPad, non-retina vs. retina…), so this would only shift the problem further in your case; you really should use a constant somewhere to declare the number of images (or put this in some PLIST file for example) and iterate thru them.
As the files you provide at compile time will be in your Bundle — which cannot be altered once compiled as it is digitally signed — the number of images will never changed once the app is compiled anyway. (That's not like if you used the Documents directory and enabled iTunes File Sharing or whatever, letting the user add images himself ;-))

If you're targeting iOS 7+ then no. Xcode will package the files into a proprietary format (.car) that you can't access directly.
Either use imageNamed: methods, or don't use Image Catalogs for the files you need to access directly.

as #AliSoftware suggests you can store all assets images to plist and access them later for more details see here

Related

Using XCAssets Properly (adding assets)

I had two people discuss two different approaches with me on how to add assets such as images to a project in Swift.
Person 1: "You should create a new folder within your actual project workspace and then add all of your assets to it directly (so it's within the project). Then drag & drop the assets from this project folder to XCAssets, to actually create the icons you will use."
Person 2: "Just download your images from wherever, and drag and drop them directly. They can be from different locations. When you deploy to ITunesConnect it will copy the images."
Now I'm confused - when I drag and drop an image (let's say from my Downloads folder) doesn't Xcode copy the image locally into its own private location? Once I drag it into XCAssets, does it need that source location anymore? I thought maybe approach #1 would end up forcing Xcode to store duplicate images/assets and take up more size on the app.
What is the "correct" approach to adding assets?
Thanks!
Both actually can work (drag and drop/use asset folder). But the latest method introduced by Apple by xcasset folder. XCAsset folder is superior in the way that you can see a list of assets nicely one by one, even you have multiple sizes on it (.png #2x.png #3x.png etc). Easier to manage and see which size you are missing etc.

swift ios and geing final grip on copy bundle resources

I am currenly converting an iOS project built in another tool to xcode/swift.
I currently have an xcode swift ios project with multiple targets defined (one for each customer)
For each customer I have a folder "customerxyzassets" that I have added to "target > build phases > copy bundle resources" using the process described here Include a resource directory hierarchy into app bundle
This folder "customerxyzassets" contains subfolders with images and data files which the app is born with.
I would like to grab a path to this folder upon startup, so I can access load datafiles, images etc. from it.
However, the code I have found, e.g. NSBundle.mainBundle, seems to require speciel access to the files through the above. I would rather have raw file access to it. Am i missing something obvious?
It's not clear what you mean here by "special access" or "raw access." NSBundle just returns you paths or URLs so you can directly access the files using normal file APIs.
If you've created a directory structure, then you would generally use pathForResource(_:ofType:inDirectory:) to fetch the path to your specific file. Alternately, you can build a path using NSBundle.resourcePath and append your relative path using stringByAppendingPathComponent. The advantage of the pathForResource methods is that they handle localization for you, and this is preferred unless the resource should never be localized (which is rare).

Some files are located outside of "MyApp" directory in my iOS app - why?

I'm now developing my first iOS app, and I found that two of my classes (hence, four files) are located outside of my MyApp/.
So in my filesystem, here's the current situation:
My App
- ClassA.h
- ClassA.m
- ClassB.h
- ClassB.m
MyApp/
MyApp.xcodeproj/
MyAppTests/
Other than the two classes, all of my class files are located in MyApp subdirectory. The other resources, such as Core Data model file or images are saved in the same directory.
However, why are the two classes, and only the two classes, located in the outside of MyApp subdirectory? When I move those files to the supposedly correct location, those files are no more "valid" in Xcode with the color of the file name is converted to red.
So here's my question:
Why are those two files located there?
Do they have any issues if they remain to be located there?
Should I fix this issue and save it correctly? I think I haven't had any issues so far with the Simulator and the actual iPhone...
I use iOS 7 and Xcode 5.
•Why are those two files located there?
A: When you have created these files or imported from external directory, you may have not taken care of the group/folder these files are getting created/imported into. Hence they are inside the main app folder in the file system.
•Do they have any issues if they remain to be located there?
A: No, this is certainly not an issue in the correct functioning of your app, but it is always good to manage your files under groups/folders for better file structure and it is easier to find files when they become large in number.
•Should I fix this issue and save it correctly? I think I haven't had any issues so far with the Simulator and the actual iPhone...
A : This depends on you. If you like to keep your files in folders and like everythin arranged in some pattern, then yes you can divide the app into different folders. When you move the files in a folder, the reference of those in XCODE should change as well, and thats why you see those files in red in XCode. No worries. Just delete the files and add them again. Make sure you uncheck the option "Copy files under detsination group's folder".
Now, you may seem the option of creating New Groups inside XCode. But it is good to be aware that these groups do not create separate folders inside file system. These are just for Xcode refernce. So, a neat way is to create folders outside of XCode, and then import these folders(can be empty) in Xcode. Now when you add any file in these imported folders, even from XCode, it will go inside the correct folder in file system.
I am sorry I am not on my MAC right now, so cannot paste actual images, showing how to do it. Feel free to comment, if I have instead of solving the issue, have rather confused you more:D
You can put your source files wherever you want, as long as Xcode knows where to find them. You can leave them here, or organize it in another way, as you seem to be willing to do.
So, if you want to move these files in your Myapp/ subfolder, just move them there, and when Xcode complains it can't find them, highlight all those files in red in the navigator, and in the "File inspector" pane (right hand side of the window), click on the little Folder icon to browse to the new location. If you selected all files you don't need to do that 4 times, Xcode will find it out by itself.

How to add large number of static files to MonoTouch bundle?

I have (quite a bit of) static files that I need to deploy with my application that is built on top of a legacy .NET library. These include several XML and config files, and a read-only database in the 10's of Megabytes.
Most forums I have seen indicate that the best way to accomplish this is to reference the needed files in a project, and set them to Content and "Copy to Output Directory".
I have two issues/questions dealing with this:
Adding these files, and setting them to "Content" seems to not only copy the files over, but embed them into the .dll as well. In other words, I have 40 MB worth of files, and a 40MB dll (this project's only goal is to import these files, there is no substantial code).
How can I prevent this extremely large dll from being made?
Is there an alternative way to get files into the App bundle? I would love to use a custom build command, and although I can copy files into the target directory ${AppDirectory}, but this does not result in these files ending up in the app bundle. Is this approach possible?
Any help is appreciated in advance.
You need to include your files from the main .exe project. You do this by using MonoDevelop's Build Action to Content on each file. They should be copied to the .app without being included inside an .dll (or the .exe).
An alternative (for development) is to use iTunes sharing to copy once your files to your device. This allows you much faster deployment times while developing.
Of course you can't submit such build to the app store (unless the files are not required to make the application work, unlikely). What I do (for my nearly 80MB read-only database) is to use this hack (loading from /Documents) inside #if DEBUG. The release build load the files from the normal location.
I have not automated the process (still debugging the app ;-) but it should be possible to script this so modifying the project options (for each file) is not required when switching from Debug and Release builds.

What is the best way for packing 6000+ sound files in a iOS Application

I'm working on a iOS application that will contain around ~6000 mp3 of sounds files.
Each one is around 1 second (2 max) long and rather low quality (24K bitrate) weighting in at around 2-3KB each. (Please do not comment on the quality, it's as it should be)
Since this is a large amount of files I was wondering what we be the best approach for packing these into the bundle? Should I just throw them together in a group? Is there someway of storing them in a single "package" file then reading them out separately as needed?
Also, what would be the best place to place them: Library/ ? Documents/?
As I'm rather new to iOS development and kick in the right direction will be greatly appreciated.
Thanks in advance,
Ken.
You can create a bundle which will contain all your mp3 files. Your files will be in the ressources of your application, no need to store them in the Documents or Library path of your application sandbox.
The way to create and access a bundle is illustrated here.
Hope this helps
There is no package type that were meant for resource files. There are ones for static and dynamic libraries, custom frameworks and so on, but purely for resources I know of none.
Instead of adding them in bulk into a Group in Xcode's project hierarchy, you should add the containing folder as a folder reference to the project. (Appears in the file navigator in blue.) This way any external modifications you make to the contents of the folder, like adding/removing files will automatically be picked up when you next compile your project.
You can do this by dragging the folder from within Finder to the project browser in Xcode and when asked choose "Create folder references for any added folders".

Resources