I'm using an asset catalog with Xcode 5.1 and making an app for iOS 7 and above. The idea behind an asset catalog is that you can call the images whatever you want and the catalog associates the image with the correct device and orientation. In the background, Xcode apparently renames the files along the scheme mentioned here. However, it appears that there is a steady supply of problems accessing the files programmatically (here, here or especially here) without running into memory problems (e.g. here).
So I have the assets in my catalog and the launch images are called correctly. But I also want to use the launch images as background images, so I need to call those programmatically. In principle all that I should need to do, if I understand the asset catalog concept correctly, is something along these lines:
- (void) selectBackgroundImage {
self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:#"LaunchImage"]];
}
And the OS should pick the correct launch image from the xcassets launch image set. However, this apparently only works if one uses the conventional names for the images, e.g. Default-Portrait#2x~iPad.png which defeats one claimed advantage of the asset catalog (any name you like) and may run into the aforementioned memory problems.
At this point, a few months after the referenced posts, are there better solutions? I know I can get rid of the asset catalog and access the files directly, or add a lot of work around code, or use the catalog along with the official file names, but none of these 'solutions' are in the spirit of what the asset catalog is supposed to do.
Related
It's come up recently at my job that the SEO guys for our customer are unhappy with the src attribute values being generated in our img tags on their CQ/AEM-based website. I know next-to-nothing about SEO, so I won't pretend to understand, but it seems they have a point. We're not using the out-of-the-box image component per se, but the behavior is the same.
The src attribute of the img tags gets the path of the image node, with the img selector and some other stuff appended to it. This of course causes the request to go through the image servlet, which is then responsible for drawing the image. If I understand correctly, it's done this way to support things like the crop/resize/etc tools available in the html5smartimage widget. The servlet applies these edits to the image and renders the altered image.
The complaint is that the actual file name for the images are nowhere to be seen in that src attribute. I'm operating on the assumption that this is a valid complaint, but I really don't know if it is. I'm likely going to be asked to jump through hoops to change this behavior so the src attribute references the image by its direct path in the DAM.
Are these valid complaints? If the complaints are valid, why would the image component work this way? Should the title/alt values be considered sufficient for SEO purposes? If my customer is not using the extra features from html5smartimage, is there any other reason why I should not just address the images by their explicit DAM path? I've already worked out what I think is the best solution, but I'd like to be armed with more information before taking that plunge.
image component as it is allows you to have server side modified layouts of the same image (with usual transformations like cropping, rotation, ...) customised for each usage of it, that is different content for each usage (with one original image, and different settings in each component).
This has the drawback as you mention to locate the src of the image in a rather unfriendly URL in terms of SEO (i.e. where the component content is)
If you only want ONE version of one image, you'd surely should refer directly to the DAM image (or whatever image hosting you use).
I'm trying to create live tiles in my app by using BitmapRender (in Windows 8.1) to create an image from a user control, which I then want to add as my live tile image.
Creating the image works perfectly, and I store it in the app's roaming folder. However, I can't get the image to add to the live tile when created this way. The odd thing is that if I copy my generated file into the project and then try to attach it to the live tile it works (so the image must be correctly formatted/size, etc.); and if I copy a random image into my roaming folder and set that as the live tile image it also works (meaning I am able to use a file in the roaming folder to set the tile image)...so that means I am referencing the file location correctly, and the image itself is capable of being used on a live tile...so why doesn't it work?
I have created a sample project (link below) that illustrates that my live tile creating code works (with an image stored in the project), and also that I can successfully create an image from a UI control and store it in the roaming folder (FWIW I've tried using different folders with no change in behaviour).
Is there something I'm missing? Any insight or help would be greatly appreciated.
Project is in VB.net, but I can figure out answers in C# if that's easier.
Sample project to illustrate the issue
The trouble is that you're attempting to use an absolute file path to reference the image, which is not supported. If you look in the tile schema, specifically at the page for the element, you'll see that the src must be an URI using http[s]://, ms-appx:///, or ms-appdata:///local for Windows Store apps. The fact that you can use a relative in-package path of /livetile.png is a bit of a fluke, as that's defaulting to ms-appx:///livetile.png.
What you need to do, then, is just use this for a filepath:
filepath = "ms-appdata:///local/livetile.png"
I tried this in your sample and it worked fine. Do note that only the local folder is supported here, not roaming. This is primarily because roaming appdata is limited to 100K to begin with, and dropping tile images in there would often quickly fill your quota. You'll want to then generate the image locally on each device (which would make sense also because you can then take the current scaling into account).
i have 2 issues.
my app has a high quality images, and i enabled the retina display(using cocos2d), so every png has the hd : image-hd.png .
my first question is, if want it to fit also iphones under 4 (3gs) i must have all my images again in the 320x480 without the -hd ?
i have sooo many images, and this way seems strange to me, cause it doubles the app size!
another thing. my app size on disk is BIG, but i have discovered that there is a folder init that called: build, which is 136Mb ! it has simulator and debug files that are not mine.
how would i get ride of this folder that is so big ?? my app is 30mb only !
thanks a lot
i must have all my images again in the 320x480 without the -hd ?
Yes. If you want your game to work with non-Retina devices, then for each xxxx-hd.png you must provide a corresponding xxxx.png file.
this way seems strange to me, cause it doubles the app size!
It doesn't double it. It depends a little on the type of files (PNG, JPG) and how well the images can be compressed. Uncompressed, an SD image is a quarter of the size of an HD image. So you're more likely looking at an increase of app size by 25%. If your HD assets weigh in at 100 MB, your SD assets will add roughly around 25 MB to the app size.
my app size on disk is BIG, but i have discovered that there is a
folder init that called: build, which is 136Mb ! it has simulator and
debug files that are not mine.
These are temporary build files created by Xcode. Don't delete them because Xcode will recreate the files anyway.
The size of your .app is the only file size you should be considering. Furthermore, you should ignore the size of your .app in debug builds, which is what you've been looking at. The only app size from which you can determine (or guesstimate) the final app size on the App Store is the app created by an Archive build.
Run Product -> Archive with a iOS device selected as your current configuration (otherwise Archive is grayed out). When it's done, the Xcode Organizer will open and highlight the newly created archive. Right click it and select "Show in Finder". There may be several .xcarchive files in this folder, select the latest one and right click it, then select "Show Package Contents". Navigate to Product/Applications which will show your .app and its size. This is the only size of your app you should ever give any consideration.
However, this is not the final size of your app on the App Store, since the .app bundle will be compressed (making it smaller) and at the same time the executable will be crypted (making it impossible to compress). I once wrote an article about how to determine your app's final App Store size that I think still holds true today. In essence, you copy the .app bundle, remove the executable from the bundle, compress the bundle, then add the size of the compressed bundle and the size of the executable and the result is a good approximation of your app's size on the App Store.
You need to give a name for HD image with prefix #2x, for example image#2x.png. Leave normal name for images in order to support lower versions of iOS - image.png. In code or Interface Builder you have to use only normal named images (all another things will be executed automatically).
The short answer to the 'images' part of the question is YES , you should include the normal sized files. The artwork is probably different with the two resolutions (I am not a graphics expert, but i suspect there is a lot more to it than resizing the image). The whole point of implementing the "-hd" suffix was to have the ability to deploy a single bundle that works seamlessly for Retina and non Retina displays. I just had a requirements change to go from SD to SD+HD on one of my products ... errr ... now both the artists and the softies are in a mad rush to do just that : create the artwork and make certain all is well (ie no missing resources). Best of luck with your own requirements change.
How to create custom templates in iOS app having uiimageview ,uitextview,and many other views so that user can select any one template and starts editing it.
There is a famous library thats floating around for this kind of usage - iOS BoilerPlate
It is intended to provide a base of code to start with
It is not intended to be a framework
It is intended to be modified and extended by the developer to fit their needs
It includes solid third-party libraries if needed to not reinvent the wheel
What it includes -
HTTP requests and an image cache (both in-memory and disk-based)
UITableViews and UITableViewCells: fast scrolling, async images, pull-down-to-refresh, swipeable cells,...
A built-in browser so your users don't leave your application when they browse to a certain URL
Maps and locations: directions between two points, autocomplete a location, etc.
I am working on an app for iPad where I want to have lets say 100 jpg's in a folder.
They could be named like 01.jpg, 02.jpg etc.
In my app I like to browse those images and when clicking on one of them I need the name of the image to be able to send some data over the network (the data part works fine).
I tried to use UIImagePicker but I found out there are no name connected to the actual image.
Then I made another approach where I have a number of pages where I have buttons and here I load in the images which works fine as long the are a part of the recourse of the project...
But here comes the real problem.
The user of the app should be able to change those images over time without recompiling the app.
So I do look for a way to have a folder where the user can place/replace images with the names 01.jpg etc and the app to use those updated images.
Ideas are very welcome.
Wiljan
I am not sure that I understand what you mean, but You can save images in your application documents folder. You can find more details at:
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/StandardBehaviors/StandardBehaviors.html#//apple_ref/doc/uid/TP40007072-CH4-SW6
You can also use NSFileManager to copy files.
what I suggest to do is :
put default images on project resources.
At first start, copy files to documents folder.
always use images from documents folder.