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).
Related
In my case I have 50 Folders where each of it has subfolders and images. I could drag them into the apps main bundle but there are many duplicate filenames and it would be more practical to access them in the structured way.
Your wording "it would be more practical to access them in the structured way" seems to suggest that you think the Resources folder cannot contain a folder tree of files, it can. However if you let Xcode itself copy your resource files into the bundle it will flatten the tree without any option to preserve it (for reasons unknown). To address this you can copy the files into the bundle using a build script.
In outline, you need to fill in the gaps with some reading:
First add your files and folders into your project. Use one group per folder, in Xcode 9 creating a group creates a corresponding folder in the project directory but in prior versions you must create the group and then associate it with a folder – check the documentation of whatever Xcode version you are using.
Mark all the folders and files added in this way as not part of your build target. This prevents Xcode copying the files automatically into the bundle, and flattening your folder tree in the process.
Now in the target settings go to the "Build Phases" tab and add a new build script phase. Add a shell script which uses something like ditto to copy the folder tree into the bundle. Various environment variables are set which reference the project and the bundle, check your Xcode documentation or just run a dummy script and dump them out (it is an option, or use printenv). You can use these environment variables to determine the source and destination for your copy.
In your app itself you can locate the root folder of your tree using standard bundle methods. From there you can use whatever method you choose to traverse it/reference items with in it, in exactly the same way you would if the folder tree was not inside the bundle.
HTH
When I'm creating a new framework, the Xcode automatically create two files: one header file, and one plist file. For example:
I know what is header and plist. But, this files are important when my framework is a Swift pod for CocoaPod/Carthage/SPM? When this files are important?
Anatomy of Framework Bundles
Framework Bundle Structure
Framework bundles use a bundle structure different from the bundle
structure used by applications. The structure for frameworks is based
on an earlier bundle format, and allows for multiple versions of the
framework code and header files to be stored inside the bundle. This
type of bundle is known as a versioned bundle. Supporting multiple
versions of a framework allows older applications to continue running
even as the framework binary continues to evolve.
The system identifies a framework by the .framework extension on its
directory name and by the Resources directory at the top level of the
framework bundle. Inside the Resources directory is the Info.plist
file that contains the bundle’s identifying information. The actual
Resources directory does not have to reside physically at the
top-level of the bundle. In fact, the system frameworks that come with
OS X have a symbolic link to the framework’s Resources directory in
this location. The link points to the most current version of the
Resources directory, buried somewhere inside the bundle.
The contents of the Resources directory are similar to those for
application bundles. (See “Anatomy of a Modern Bundle” in Bundle
Programming Guide for more information.) Localized resources are put
in language-specific subdirectories that end with the .lproj
extension. These subdirectories hold strings, images, sounds, and
interface definitions localized to the language and region represented
by the directory. Nonlocalized resources reside at the top level of
the Resources directory.
Headers
Contains any public headers you want to make available to external
developers.
For more information Apple Documentation page.
Cocoapods
If you'll publish your framework with cocoapods for example, maybe better to start from cocoapods's lib create guide instead of using XCode's scenario.
You can use this command to start (like guide says):
pod lib create MyLibrary
when you finnish framework create wizard you'll have directory tree like this :
I am curently converting my app source from an entirely different tool to Swift tarrgeting ios7 and newer. I now have an xcode project setup for multiple targets (some source, multiple apps) where each app has its own ".xcassets* file like this:
customerapp1_AppIcon
customerapp1_LaunchImage
And then also:
customerapp1_DataSet (.xml data files and some images)
customerapp1_DataSet_Folder1 (images)
customerapp1_DataSet_Folder2 (images)
The idea is hat the app at startup will use these files (if it finds newer ones online, it will download them to cache and use those instead)
However, researching this further, I now have some doubts:
1) Is this an incorrect use of xcassets if my goals is to have a way to include different files depending on target?
2) How do I load files found in "customerapp1_Data_Folder1" (and what if I e.g. have an image file with the same filename in two folders?)
3) If above is incorrect use - would a solution be to zip all my own data + image files + foldes into a single .zip file. Store that single file in "customerapp1_Data" and then unzip into cache directory at first startup? (That way, my own data structure would also be kept)
The correct thing is to:
Select app project root in acode - build phaes - copy bundle resources
Add folder using "add folder references"
Select the appropriate target for the bundle files
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
I am having trouble with xamarin folders. Currently I'm writing xamarin iOS project. In Xcode I used directories for grouping images, there could be several levels of nested folders, but when I was building project for device or iOS simulator, these resources where simply being copied to main bundle, without any folder structure. I can't reach the same behaviour in xamarin studio. Whenever I create folders in my project and put pictures or other resources in them, this folder structure is recreated on the actual device, and thus, I struggle against different paths, when loading images. How can I make xamarin studio simply copy the files in the folders to main bundle, instead of recreating folder structure?
Thanks for help.
My first suggestion is to change the BuildAction property of your images to BundleResource.
Once you do that, there are multiple ways of achieving your goal:
The first option is to specify a LogicalName to be whatever you want the name to be inside of the compiled app bundle. Currently there's no way to set the Resource ID (UI name for the LogicalName property) for anything other than EmbeddedResource files (I'll work on fixing that momentarily), but you can edit the *.csproj like so:
<BundleResource Include="Icons\icon.png">
<LogicalName>icon.png</LogicalName>
</BundleResource>
Normally, that Icons\icon.png file would be copied into the iOS app bundle as Icons/icon.png, however, the LogicalName property overrides the relative path name. In this case it would be copied over as simply icon.png.
As another example, you can also do this:
<BundleResource Include="Icons\iOS\icon.png">
<LogicalName>AppIcon.png</LogicalName>
</BundleResource>
This will copy the Icons\iOS\icon.png file into the root of the iOS app bundle and also rename it to AppIcon.png.
A second option is to simply move your image file(s) into the Resources folder. The Resources folder is special directory that get stripped out of the default path names when copied over to the iOS app bundle. In other words, Resources\icon.png would be copied over into the root of the iOS app bundle as icon.png rather than Resources\icon.png as is the case with normal project directories.
A third option is to simply register other "Resource" directories of your own (and they can exist within other directories, including the default Resources directory).
For example, you could have the structure in your project:
Resources/
Icons/
icon.png
icon#2x.png
And in your *.csproj file, edit the following tag:
<IPhoneResourcePrefix>Resources</IPhoneResourcePrefix>
and replace it with:
<IPhoneResourcePrefix>Resources;Resources\Icons</IPhoneResourcePrefix>
This will ensure that the icon.png and icon#2x.png files are installed in the root of the iOS app bundle.
Xamarin has two ways to setup files you want present in the iOS bundle:
Put them in any folder, and mark the "Build Action" as "Content". Whatever directory structure you have in your project will be present in the main bundle.
Put them in the "Resources" folder, with a "Build Action" as "BundleResource", this does the same as #1, but removes the "Resources" folder from the path present in the bundle. This is a nice place to put all images you want in the root of your bundle but would clutter up your project.