I have to load a lot of data onto an iOS device with 128GB storage, for use by my app. The data is around 2,000 files of around 40Mb each, total is around 80GB - 100Gb.
I control the iOS device and the load machine/program and the local network they're on, and time is not critically important (if it takes a week to load, that's OK). I can format the data as required to facilitate the load.
I've done some iOS programming, but I'm not sure where to start looking for a solution to this. If you can outline the broad approach to use and which iOS docs to read up on, that's all I need.
Hoping for a solution where I can format the data and write the program, plug the iPad in to the Mac and say 'start loading' and come back when it's done.
We discovered that it is possible to load data one device at a time using iTunes, but that isn't a good answer for us.
We added a 'load data' button into the application. When triggered it loads a configuration file from a hard coded local network address, then retrieves all the data files listed in the configuration file using REST GETs from the local server, storing them into the application /Documents directory.
This is a good approach for us; it is secure, allows multiple devices to load data at the same time, and doesn't need any manual file loading : start the app, press 'load', and wait for it to finish.
Related
here is a question from a total beginner in mobile app development :)
I am building a React Native application for iOS platform first. I am stuck with decision on how to deliver icons to the application. Imagine:
I have a reference data set with eg travelling options (bike, motorbike, etc).
The actual set is much bigger though - I am expecting rather 100-200 items with one icon each for the UI.
These should be cached in the application.
Most of them wont change, new ones might come to the set periodically, but not even every week.
Now to the options I was thinking of:
Deliver a sqlite database with images as BLOB and update the database when new icons arrive
Deliver a sqlite database with image URLs for S3 bucket items and update the database when new icons arrive
Deliver the app with initial sqlite bundled with BLOB or URLs(?) and update over the air when new icons arrive
Do not use sqlite database at all and deliver all with REST API call on startup with image URLs. Load images when needed and cache them. Update database with new icon URLs when new icons arrive.
I think I tend to be using Option 4 because it seems least heavy on the client - he can always download the icon whenever he needs one. But it also has a latency because of downloading the icon for the first time from private s3 bucket.
However I am missing real-world experience in mobile apps and probably missing important details. Hoping for some insight from experts. Thanks for any pro and con you can deliver on this options!
You are right, no database needed at all.
So basically you have to load those icons only once and cache them inside the app. You can you something like react-native-fast-image or do caching by yourself.
If URL of icon was changed - the new image will be cached.
So on real-world apps, you usually have the image placeholders (example below) or loaders (more rare).
If you have multiple types of vehicle, you can create multiple placeholders and show them unless the original image is loading/not available.
Using react native firebase storage and firestore is a good option. The images can be loaded remotely and the caching is done automatically
We're using Parse in our iOS app and we've discovered that our app is using an enormous amount of space -around 2.3GB in some devices- in storage. After downloading app data to my Mac, I've realized almost all of that data is the cached images in a folder called PFFileStaging, it contains highest resolution PNGs of all the PFFiles that the user has viewed in our app, ever. How can we disable this behavior, at least limit it? Is that the intended behavior? I heavily doubt using GBs of space is the intended behavior. Is this a bug?
Unfortunately this is not cache related (as per Parse's engineers: "this is used to ensure that no concurrent modification happens to the file after you request uploading").
They're planning to implement automatic trimming of PFFileStaging folder on every app start (as per road plan this should appear in next version 1.8.2).
See the the whole thread on GitHub.
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).
Newbie question.
I will need to have a data base from about 200 UIImages (single of them less than 500kb size) for iPad app. Customer want to have possibility to change set of this images from time to time without releasing new version of app in appstore and app must work without connection to the web (local data base on a device). I don't see how this can be done simultaneously, I see only one common option here:
Image data base would be stored on a server, what app customer will be able to change anytime. User will need to have web connection and every time he will start the application - existing data base will load into the app.
Main questions here:
is it possible to update data base on user's device without releasing new version of app and what data base managing system is more proper to this situation(SQLite, MySQL etc...)?
Q : is it possible to update data base on user's device without releasing new version of app?
A : Yes. It is possible.
SQLite will be perfect for you.
The photographs reside on the web server.
A number of start-off photographs may reside within the boundle so that the app is not really empty at start.
However, when downloading the app, the user must be online. In most cases he would still be online directly afterwards when he launches the app for the first time.
The server provides two services:
A quick one that just provides a version number of the
photo-database content and/or the date of the last change to the
photographs on the server.
The app frequently (not more than daily I would say) checks wether there are new images on the server or not.
If they are then the user is asked, whether he wants to download them.
If the user says YES then the app sends the version number and/or last date and/or IDs of all local photographs to the server and the
server provides the information about which photographs have been
added and where to download that very photograph and which have to
be deleted.
Then you add or delete or update the photographs from the download source given by the server. (That may well be an URL to the
very same server of course.)
For 200 data sets I would strongly suggest core data with SQLite - the standard stuff.
You may then think of holding the image data in the file system or in NSData properties within the database.
I have a lot of data present in the database present in my webserver. Each time I starts the ipad application after downloadiding, I want all these data to be copied into the sqlite database present in my application. Then using this data, the application should work.
We are now using xml's and sometimes on 3g it takes about 20minutes which is completely unacceptable. After the 1st time it syncs using time log and all. And it works without any problem.
Is there any other way I could get all the data and make it populated into my sqlite db?
If it is a large database it might be worth doingin the background. And even better if it was just over wifi (otherwise you'll be eating up your users data)
What I usually do is have a local copy of the database shipping with the app, so the user can use that, and update it in the background. It might be worth creating some pages where you just present the updated content, download that, then update your database accordingly. Rather than downloading everything all the time.
This would depend entirely on your implementation however.
On initial app launch you could download just enough data to make the app functional. Then download the rest of the data in the background.
This is a common strategy used by Sync Frameworks and works pretty well. I have personally tried with with synchronizing more than a thousand objects using OpenMobster's sync service.
Now what data to download initially is to be decided by the requirements of the App
Thanks