We have a Universal iOS app. We use JSON to download content into the app during the first launch.
The size of content being downloaded on iPad (due to large image sizes) is about 100MB and on iPhone (smaller images) 80MB.
It takes about 4-7 minutes to download all content over WiFi. On 3G it takes 7-10 minutes.
Images are large in size, text content is not so much.
Is there any way we could reduce the download time? I'm aware of JSON compression but not sure if it will help with images?
Any ideas?
Tx
Some of this information has been mentioned in various comments, but it's what I would have suggested anyway and I figured having an answer written up would be more useful, so here goes:
Instead of storing the location of each image in the JSON file and downloading them one at a time, store the images in zip files and download those. Any amount of compression you get from this is an improvement in your download time, and you can simply unzip the images once you've downloaded the zip files.
Store a reasonable amount of the images in the main bundle along with the app. In your case you clearly can't store them all there; you don't want to have a huge app, and since it's a recipe app I presume you'll be adding more recipes as you go along. It makes a lot more sense to be able to update and download recipes via the JSON than to have to push a new version of the app to the app store with each change. But there are some items that can be bundled with the app; ex. large background images, design elements that are constant and unlikely to change. Any image which won't be likely to need updating should be bundled with the main app; any savings on download time is an improvement.
Have some kind of interesting loading screen. This is very important since you're talking about 4-10 minute download times. That is a long time for a user. When engaging with an application, 30 seconds can even seem like a long time. You're going to be hard pressed to make me willing to sit there and wait for 10 minutes for the app to begin if nothing is happening during that time. Have creative vegetable characters move across the screen, include a little interactive puzzle or ingredients on the loading screen, something. Just give the user something to look at (or preferably something interactive to do) while they're waiting. Otherwise you're probably going to lose a lot of users during this download.
If you can make this work, it really is a good idea to only download items when necessary. For example if your recipe app is broken into "Salads", "Fish", "Chicken", "Desserts", etc., you could prompt the user to download the recipe information for each category the first time they click on it. The great thing about this is that it breaks up the time the user has to spend waiting on the download; let's say you have 10 recipe categories, now the time the user has to wait all at once has been decreased from 4-10 minutes to 30 seconds-1 minute. That is a huge difference. I'll wait 1 minute for the Dessert recipes (still give them something to do!) much more readily than I'll wait 10 minutes for the whole app.
4b. You mentioned not being able to access new content while offline, which is a valid concern. To address this you could have a prompt the first time the app loads: This application contains hundreds of exciting recipes and delicious images. It can take several minutes to download all this yummy information. You can download all the content now, or proceed to the app and download recipes by category when you wish to view them. Please note that this will require an internet connection. And the buttons could say something like Download Now and Proceed to App. Obviously you can play with the wording to your heart's content, but the idea is sound. You've informed the user that there might be a significant download time, so at least they're forewarned, and they can make their own decision about how to use your app.
However you decide to proceed, break up the content you download into logical categories for the zip files. For example, "Desserts.zip", "Salads.zip", etc. That way even if you don't decide to let the user download on-demand now, you've set up a structure that is open to change later on.
Related
Scenario:
As a user I am able to take (an unlimited amount of) photos and videos which are stored in the apps documents folder. Each of these media files gets a record within a Sqlite database with additional information (for exeample a caption). All this is possible to do completely offline.
Back online I get a dialog with a list of all the videos and photos I took and a button which starts an upload process.
Each file is uploaded after the other together with its metadata by making a multipart POST request to the server. The response of the server is stored together with the metadata in the Sqlite database (so there is no fire and forget).
Reliable solutions?
If I am reading and understanding this chart correctly, the most simple solution would be to wrap each of these uploads within a Task. Side effect: after 10 minutes every task would be cancelled, which becomes a problem by having a slow connection or very large files (for example a very long video).
The recommended way would be to use NSUrlSession/Background transfer service.
Which leads me to my question:
Is it possible to wrap multipart POSTs in NSURLSessionDataTasks and would this be reliable, even if the task is running longer than 10 minutes or the user is suspending the app?
As I am a Xamarin/C# guy I would really appreciate some sample snippets for a working multipart upload, even if it's in Objective-C ;-).
Almost and... yes.
Background Transfer service works with NSUrlSessionDownloadTasks and NSUrlSessionUploadTasks only. Not NSUrlSessionDataTasks, as described here.
Other than this "basic" limitation, it's safe to use background transfer service with upload tasks.
The 10-minute-freepass-in-the-background no longer applies on iOS 7 (basically, it's there, but different), however, with NSURLSession and background transfer service you do not need it.
I've a blog post here for background transfer service, based on download tasks.
An important thing to note is that, starting a task basically means that it will actually start sometime and actually finish some other time. This depends on whether the device is on cellular or Wi-Fi and other factors which are (probably) only known to iOS (and Apple).
I'm making an app. Part of the app is to choose from 5 preset images.
These will be available at install and so need to be bundled with the app.
However, there is also potential to "add" more images through in app purchases.
I'm looking for the "best" way to store these images on the device with the potential to add/unlock more images.
My thoughts are that "CoreData" is too heavy for this. I could do some sort of plist thing to reference the initial five images. But then how do I add more through IAP?
With IAP, do I download the additional images upon purchase? Or should they also be bundled into the app at install and then unlocked when purchased?
Never done IAP stuff before and my previous apps all used Core-Data as they were very data heavy.
There are two things to consider -
Do you want to add more images after you've shipped?
Are the images small enough that they can be download quickly on demand?
If the answer to either is yes, I would recommend going the hosted content route. Apple even allows you to host content on their servers.
Otherwise, just bundle everything in your app and unlock as required.
Small note on security: I would not worry about piracy at all since there is no way you can stop people from pirating content/apps. Besides, the number of people who JB is quite small (23m / 90% * 500m ~ 5%) and the number of people who pirate is even smaller.
I am working on an app where I need to download lots of images locally (so that they are available offline). The number of images can be 100 - 10,000. Each image may vary from 100K- 250K
I can do this via a NSOperationQueue and I have the code to make this work already but this question is more of a conceptual nature. I am not sure what is the best approach to take here.
1) Do I download all images as soon as the user logs in for the first time ? Based on the number of images, this could take a long time and what if the user closes the app meanwhile. I understand there is a limit on the time that can be spent by a background process in this case? Honestly, I dont want to do anything in the background (ie when app is closed)
2) Do I download images when a particular category is selected by the user? If a category has 800 images, then what happens if the user selects another category before all of those 800 images are finished downloading? I can always start threaded downloaded but will the thread keep on running if the user selects another category ?
3) Put something in "Settings" to let the user decide this themselves. Something like "Total Images: 8000" Images Available : 2000 and a button to say "Download All" which would display a UIProgressView of what's going on....so the user will probably wait till it's all done.
Or some other approach?
Thoughts?
As far as I understand from your description, including comments, I think that the best approach would be downloading all of your images in a thread and make the download process resumable. In this way, you are going to mirror a remote database of images for offline use.
What this entails is:
you keep track of which images you have downloaded;
each time the app starts/resumes, you start the downloading thread exactly from where you left;
you should also provide a mechanism so that the user is suitably informed when he is trying to access an image which has not been downloaded yet, but I think this should be no problem (you might also provide a progress indicator somewhere).
I would only download the image when the user actually needs to do something with the image. Your users will hate you if you download all the images upfront. :)
I have an issue I'm hoping someone can help with. I have an application that, for all intents and purposes, is working great. It's basically a picture viewer type of application - for something very specific. What it is is about 500 pictures.
I have all pictures set as Content and I load/unload one at a time. For the 500 pictures, I have a class that is used as data about each picture. So things like "place taken" , "index", "short description", etc. I never need to insert or delete from this list, but I may need to make some changes to each individual one, like "user viewed this picture on..." (date) or "favorite = true" (boolean where user marks a picture as a favorite picture).
When I deploy the app, this "picture metadata" is in xml file. It is then deserialized and saved to IsoStorage upon first run. A copy of it is maintained in memory and that is what is used to run my whole app. I have 3 different pages that all use that data, which is set as a static property in app.xaml.cs. Upon Deactivate/Closing the data is serialized back to xml - upon relaunching it is deserialized. Everything works fine and fast - everywhere. Including tombstoning.
The problem is resuming from Deactivation where the app is not tombstoned. It can take up to 10-15 seconds and definitely is returning from e.IsApplicationInstancePreserved in Application_Activated (i.e. it's not tombstoned).
Activating from brand new it takes about 3-4 seconds for the app to start. Returning from tombstoning it also takes about 3 seconds.
What I'm not understanding is why returning from e.IsApplicationInstancePreserved = true; is taking so long (and it won't allow me to pass certification). I've tested and found that if it is about 10 items in the List its incredibly snappy for FAS. If there are about 50 items in the List then it's not immediate. If there are 100 items, it's the first time you can see "Resuming..." (yep, that word coming from FAS, not tombstone). Where I have it, at 500 in the List, it is painfully slow to watch FAS, which is SAS.
It's interesting that in the emulator, FAS works perfectly fine, even with 1000 objects in memory. It's on an actual device where it is incredibly slow (Samsung Focus) in both debug and release mode.
Now I know the easy answer may be something like "why maintain a class with a list of 500 objects all the time?", but my whole architecture and user experience is based on having data about the pictures available on all three pages all the time. Linq is heavily used to report data everywhere.
Any thoughts or guidance on this situation?
Great to hear you found the problem.
"sounds a serialization/deserialization issue to me. Are you storing the list in a State 'variable' ? were the framework will serialize when leaving the app and deserialize it when you return"
Remember, your PC + Emulator is MUCH faster and more powerful than your phone's 1GHz single core ARM processor with 500MB RAM!
When your app is activated with e.IsApplicationInstancePreserved == true, then you shouldn't need to restore any state and you should be able to pick up where the user left off.
If you're saying that when your list catalogs 500 items, the performance is horribly slow when resuming the app, I wonder whether you're also keeping the 500 images in memory and your phone is having to swap all that data into your app's memory space. This will be further compounded if your app has multiple pages each containing copies of your 500 images!
I strongly encourage you to profile your app to measure its memory footprint and to see where the big memory, storage, IO and perf issues are.
I'm an apprentice junior programmer and have been given a project at work, its a simple app in which images are flashed on the screen for a short period of time (starting at 2 seconds) the user has to play for 3 minutes 70% of the images must be clicked / tapped and 30% must be ignored, at the end it displays how many "fails" and how many "halftimes" you got (fails being how many times you clicked an image you WASNT meant to or didnt click an image you WAS meant to and halftimes being how many images you was meant to click that you clicked in half the allotted time i.e at first, if you clicked within 1 second that would count as a halftime click) anyway, all of this works fine, the problem i have is that: i wish to read a value from an XML file (at first the value being 2000 so i can use it as a variable for when i initiate my image timer) which i have achieved, at the END of the game, if the number of fails is 1 or less, i would like to decrease that value by 50 (0.05 seconds) and if the fails is 2 or more i would like to increase the value by 100 (0.1 seconds) and i dont have a clue how i can modify the XML file to change this value, as i said im a junior programmer and dont have much knowledge of AS3 with XML so any help is welcome and appreciated.
Thank you for your time.
I can't explain all the ins and outs but I can give you some direction. If you're publishing a swf for the web, you will need a server-side script (something like PHP or ASP.net) which can write the change to either a database or an xml file.
If you're publishing a swf or projector for desktop playback, you can combine the ByteArray and FileReference classes to save a file, but a "save as.." dialog will open for the user.
If you're publishing as an AIR application, you can use the File class to modify the xml file.
Hope this helps..