Is there any way to retrieve a UIImage object with imageWithContentsOfFile: if the image is stored in an xcasset Bundle (Xcode 5 Image Catalog)?
It's easy to access it with the imageNamed: method, but imageWithContentsOfFile: has a slightly different behavior, so what do I pass in the path parameter?
I've tried to use a variety of formats, but they all return a nil value:
ImageName#2x.png
ImageName#2x
ImageName
NSBundle File Path to Image
Apple's documentation doesn't specify a format for this. Any ideas?
You can't load an image from xcasset via imageWithContentsOfFile:, because every entry in xcasset is compiled into a single binary file Assets.car. The format of this file is not documented and yet not reverse-engeneered well afaik (see "What you should know if you want to try reverse-engineering this stuff." section for explanations).
This is done for performance and low memory consume reasons, that's why imageNamed: is a good solution.
Related
When you drag an image from the desktop into the asset catalog in Xcode, you can access that image in a project using:
UIImage(named: "somePNG")
But how do you access that image using UIImage(contentsOfFile:)?
if let path = Bundle.main.path(forResource: "somePNG", ofType: "png") {
someImageView.image = UIImage(contentsOfFile: path)
}
The above code doesn't work. The image in the file inspector is added to the target. What am I missing?
Why would you want to use UIImage(contentsOfFile:) instead of UIImage(named:)? The reason is probably that you are wishing you could load your image from the asset catalog without automatically caching it. You can't. (I regard this as a major bug in the way asset catalogs work.) You will have to store the image at the root level of your app bundle instead, just as we used to do before asset catalogs existed.
If you name your resolution-dependent files according to the naming convention, e.g. myFile.png, myFile#2x.png, myFile#3x.png, then the right thing will happen when you use the code you've shown along with the name "myFile.png".
You can't access the image through contentsOfFile if it exists in xcassets , you need to add it to the project files , with copy option enabled
I've localized my images via Xcode, and all the images are in the proper lproj folder.
However, when I use imageNamed I don't get the correct image, but I keep getting the default image even if I change language.
_myImageView.image = [UIImage imageNamed:#"image_name"];
This kind of issue made me waste some time, but then I realized it was a false issue and I hope to save you precious time.
If you switch language and the images are not in the new language, that's because of cached images. The documentation is straightforward:
This method looks in the system caches for an image object with the specified name and returns that object if it exists
Hence, when you switch language, and you ask for the same name to the cache, you'll get the old image! That's it. :)
Instead of:
_myImageView.image = [UIImage imageNamed:#"image_name"];
use:
NSString *imageName = NSLocalizedString(#"image_name", #"image_name");
_myImageView.image = [UIImage imageNamed:imageName];
and localize your image names using the Localizable.strings files like any other resource in your project.
Are there any negative implications of excluding the file extension when using [UIImage imageWithContentsOfFile:] or is it best to include the file type in the path?
The Apple Docs state that initWithContentsOfFile: requires the following path as its parameter:
The path to the file. This path should include the filename extension that identifies the type of the image data.
However, the path for [UIImage imageWithContentsOfFile:] just states:
The full or partial path to the file.
I was just wondering if it's still best practice to include the file extension or to not even worry about it. Thanks!
You should include the file extension for all file requests. The only instance I can think of where you would not is using the
NSBundle pathForResource:ofType:
method. That method you specify the file extension outside of the file name. I'm relatively certain the "partial path" refers to relative paths. You can ask for a file in the root of your bundle by just the file name as it's path relative to your bundle is in the root, in other words just the file name.
The best way is to use NSBundle pathForResource:ofType:
If you have those images:
"myImage.png" (iPhone)
"myImage#2x.png" (iPhone Retina)
And you want to load it to an UIImage, you will use this code:
UIImage *myImage;
myImage = [UIImage imageWithContentsOfFile:[NSBundle pathForResource:#"myImage" ofType:#"png"]];
This code will also load the "myImage#2x.png" in iPhone Retina with no need to add the #2x to the code.
Be sure to write the exact file name. "myimage" might not work on device since the original file name has a Uppercase "I" ("myImage.png").
We have a constants file and want to be able to whitelabel our app.
Part of the white labelling is defining images that can be swapped by our clients.
What overhead would defining all these images be?
e.g. #define kMPNavigationBarBackgroundImage [UIImage imageNamed:#"nav_bar"]
Would it be worth defining NSString constants for the image names? Or will this be ok?
Bear in mind there will be hundreds of these images, are they all going to load into memory at this point? Or is the #define just a palceholder for lines of code which won't get run until they are called?
Thanks
"#define" is preprocessed by the compiler, before the compilation takes on all your kMPNavigationBarBackgroundImages will be replaced by your definition. It doesn't have anything to do with runtime.
http://www.cplusplus.com/doc/tutorial/preprocessor/
When you use #define to define some sort of constant it is just a preprocessor directive to tell it to replace the defined text in the code.
So if you use:
#define image [UIImage imageNamed:#"name"];
UIImage *myImage = image;
Then before compilation it will get changed to:
UIImage *myImage = [UIImage imageNamed:#"name"];
It just gets replaced everywhere that you use it.
Hope that helps!
:)
Well in short, your last statement is correct; the code which forms part of the #define won't be evaluated until it's referenced in the code.
Perhaps a better approach to the issue would be to put all these Assets into a dictionary that can be optionally swapped out by "the client" if they wish. The dictionary would map the well known name to the asset filename.
The issue with using #defines is that it relies on the customer putting the right code in the definition, which is tedious and error prone, for example:
// (Missing end quote)
#define kMPNavigationBarBackgroundImage [UIImage imageNamed:#"nav_bar]
Will cause a non-obvious compilation warning.
A more elegant approach would be to provide a method (somewhere) where you simply supply the well known name:
- (UIImage *)imageWithWellKnownName:(NSString *)wellKnownName;
Which looks-up the asset filename and loads it, throwing an exception if the file could not be loaded.
In my App for the iPad I'm trying to load an image file programmatically. The file is NOT part of my project, hence it is not referenced in XCode. There is no entry for the file in XCode's Groups and Files column.
The image has to be loaded at runtime instead, it name being read from a Property List.
I'm trying to load the file like this:
NSString* pathToImageFile = [[NSBundle mainBundle] pathForResource:#"MyImage" ofType:#"png" inDirectory:#"MyDirectory"];
UIImage* retVal = [UIImage imageWithContentsOfFile:pathToImageFile];
In this case, mydirectory lives in the main bundle like this:
MyAmazingApp.app/MyDirectory/MyImage.png
Unfortunately, the Image will not load. I can't add the image file to my project, as its name is to be determined at runtime and cannot be known in advance. The file name is read from a config file (a Property List) at runtime instead.
What am I doing wrong? Your help will be very much appreciated.
You can use NSFileManager to get the contents of a directory, or several directories. You obviously have to know something about the file you want to load so that you can identify it, but you could for example use NSFileManager to help you generate a list of images in your app bundle and in your app's Documents directory.