I have a question on using the AssetLibrary with iOS. It it possible to store a pointer to an image in your app rather than the actual image? Let's say I want to create a playlist, but I don't want to store the actual image.
The reason I am asking, is that I find when I use the image picker, I can save an image to the devices documents directory, but once I get to 25 or so, it starts to slow down the device (iPad 1). I scale down the images if they are very large, I ran through the leaks instrument many times, and there are no leaks. I am just at a loss as to where to turn next, so I wanted to investigate alternatives. As I see nowhere where I can free up memory.
That's where I am at now, I'm curious if the AssetLibrary might be a option since I won't be storing physical images. I know it has some dis-advantages (requires users location, can be a bit slow when looping through images)
Any thoughts on this would be greatly appreciated.
Storing 25 images to the documents directory shouldn't slow down the device, unless you're trying to load all 25 extremely large images into memory at the same time.
You can't permanently store a pointer to the assets library asset, but you can store the URL you retrieve from the ALAssetRepresentation's url property and then use ALAssetsLibrary's assetForURL:resultBlock:failureBlock: to get back the corresponding ALAsset later. Do note that it is possible for the user to delete the asset from outside your program, even when your app is in the background, so if you are hanging on to an ALAsset you must listen for ALAssetsLibraryChangedNotification to know when to reload the assets.
Related
Whats the most effective way of dealing with different image resolutions in Parse for the different ios devices?
For instance
Would it be better to have 1 image in parse at the highest res and download for every device? (slower download speeds for lower res devices)
Have 1x 2x and 3x versions of the image in Parse and download for relevant device. (takes up more storage space on Parse)
Run cloud code on Parse to resize the images to their correct resolution as they are downloaded to the devices. (possible slower download speed for all devices?)
Any other options anyone can think of would be welcome.
Al
I would say this strongly depends on the usage case. For example, if you have a profile picture, I would recommend uploading it in 2-3 versions, as those pictures may be downloaded very often (for example in a social networking app where you have profile pictures in posts, user profiles, messages, etc.). When the picture is downloaded a high amount of times, you would rather download a smaller one to minimise download time and save parse data transfer resources.
On the other hand, for pictures that aren't downloaded as often as other ones, I'd recommend storing them in a high-res format, and scaling them down (if necessary) as they are downloaded. Take for example again a social networking app. A post contains a profile picture (which is downloaded quite often) and the actual post (a photo in this case). The actual post photo is only downloaded a single time (ideally), so there should be no reason to worry about the download speed.
Basically (and that's the way I handle this), you should always try to cache every image. Images that can be cached easily and don't have to be retrieved very often can be stored in a single high-res format (saving data space on parse). Images that cannot be cached easily or have to be refreshed quite often, should be stored in different sizes, which will, in the end, save you data transfer. The small amount of extra storage does not have that much impact, to be honest, especially if you store them in scaled down sizes.
Need your suggestions/advice on a scenario I am stuck into. I am developing an iPhone Application which has 12-15 videos. User can download any video and then play it on his iPhone. The problem is that I am writing the videos to the documents directory. It works well for small videos(~50 mb) but when the bigger ones are choosen(~250 mb) the app crashes, due to low memory warnings.
I know that the app is crashing due to increase in memory footprint. Is there any alternate way to download large files more efficiently(in chunks) with less memory utilization? Otherwise I am thinking to give download option only for small videos and only streaming option for large size videos.
1) Use an asynchronous NSUrlConnection object to download the video.
2) create a file to save the video beforehand, get the file descriptor, and set the F_NOCACHE flag on the open file so as to not consume memory in the disk cache.
3) as you get small chunks of data as NSData objects in the delegate call, append them to the open file.
4) when the download completes, close the file.
You may want to verify that the device has enough space to accept the download; there are posts here on how to do that.
I am making a some complex app, in which every detail is imp. i have some questions
1. how much storage limit we have, if we plan to save big files on core data/cache.
2. Whats the RAM limit on iphone? Actually searching for some table that can give detailed info about IOS devices on this. Because i need to handle memory warnings and defend App crashes.
3. Its better to save images in cache or core data, assume you have a lot of images approx. 200-250.
Thanks
1) I am not aware of any storage limit. Obviously, you will never get 64GB or more - since no device is larger ;-). My wife's facebook app consumes >5GB at the moment... I suppose they did something wrong. The only important point is to fail gracefully (show a dialog, clean some space, ...) if the storage is full.
2) The RAM limit varies depending on the iPhone model and the currently running applications. Also there are some iPods with less memory in market. 30MB should be pretty safe. Total physical memory of the device can be retrieved as described here while retrival of the available RAM can be derived from that question.
3) Maybe this is a good starting point. I would always write image data to the file system and just store the file name inside the database, as suggested here.
I'm facing the iOS app size issue that the app size over 50 MB cannot be downloaded over 3G/4G connection. My iOS app is heavy because of large amount of images (.png). I have already tried some solutions but it's not enough.
Separate between iPhone and iPad.
Use Compressing PNGs Technique but this just reduce my app size little.
Use zip archiving like SSZipArchive.
I saw an app with download size less than 50 MB but after downloading and installing the usage size is more than 100 MB. How this can be done?
I think they may download some resources later in some way but I do not know how. Any one please give me some suggestions. Thank you.
EDIT:
The texture package sprite-sheet of format such .pvr.ccz also be used. This can be handle the same way as .png.
If your app is heavy on PNGs, you could apply something similar to #2, but with better results. I have used the ImageOptim + ImageAlpha combo with great results.
Here is a interesting case study about this method.
Yes most apps do this. Since you are talking about .png they already go through 2-stage compression. So I dont think further compressing or zip is going to help you.
Lets say you have several heavy images which bloat up your app size. So you remove those heavy images from app packaging and when the user downloads the app for the first time, at that time fetch those images as static files using usual http. You could either do this in a separate setup step (showing progress bar et al.) or you could download these images at runtime based on what the user does in your app.
Once you fetch them you can keep these images locally in your app documents folder or any other folder & serve them up locally from next time onwards (see SDWebCache). or you could keep it simple at make it pure http calls (no locally storing) but this might impact your users experience.
How to Store Large size Images into iPhone Application?
Images are taken from UIImagePickerController but saving into Database and retrieving from
Database crash the application.
If your images are large enough, then you should NOT store them inside Sqlite. Instead, you should simply store in the database the pathname where you actually save the image in the filesystem (say for example the Documents directory of your application).
Now, it is up to you to decide what is large enough. To me, binary data greater than 1 megabyte is large enough to decide not to store the data inside the database. The threshold is dictaed by practical consideration related to the speed of both Sqlite and the filesystem.