prepopulated static data, to ship in my iOS app - ios

I have an app that shows static data and images, it will never update or change its content ( client's request ), The client will provide all the data, I am exploring possible ways of doing this, I've read articles close to what I am trying to accomplish that do this by
prepopulating a sqlite DB, and using coredata to load it.
Is this the best approach? This app never has to connect online to get new data or updates, just show whatever it contains locally.
Thanks.

That should work. Use core data, build the app in the simulator. Then go into the simulator folder, copy the sqlite into the app and link to it in the app delegate. At that point it will ship with the app.
For images you should store in your app's folder as opposed to putting in core data, then put the url to the image or document in your entity (if you need it). Use NSFileManager to store docs and images in your app's folder.

Related

What is the safest directory in iOS which can be used to download images/pdfs? [duplicate]

Currently i was saving my application data (Media) to the CacheDirectory i.e
/var/mobile/Applications/BEAFC76C-C450-4A3A-9765-A0385A9580F3/Library/Caches
and things were going fine. But recently i got a bug report that the application data has been deleted. When i searched over it, i got this Apple Doc. According to it, DocumentsDirectory should be the ideal place to store the User/Application data.
Put user data in the /Documents/. User data is any
data that cannot be recreated by your app, such as user documents and
other user-generated content.
And Cache should not be used to store the User Data that could not be reproduced by the application.
Put data cache files in the /Library/Caches
directory. Examples of files you should put in this directory include
(but are not limited to) database cache files and downloadable
content, such as that used by magazine, newspaper, and map apps. Your
app should be able to gracefully handle situations where cached data
is deleted by the system to free up disk space.
What should be the ideal place to store it.
EDIT:
I have an application that allows user to store Videos and Photos in the application. For that i used CacheDirectory. But i am getting bug reports that the Data (Videos/Photos) is getting deleted. What conclusion i draw is that the data is being getting delete by the Device itself in order to provide space.
Secondly i also wanna give the iTunes sharing function. So only the particular files has to be stored in the DocumentsDirectory. Some files can never be exposed and some has has to be shared. What should be the ideal way to store the files.
Use Documents (NSDocumentDirectory) for files you wish to share via iTunes.
Use Application Support (NSApplicationSupportDirectory) for files you wish to hide from the user but still be backed up and never deleted by the OS.
Starting iOS 5, Apple says that it's no longer a good thing to save all kind of files in Documents Directory - if you do that, your app will be rejected for sure because this folder is backed up to iTunes & iCloud, unless otherwise specified.
It says that we should save files into Caches or Tmp Directory - these won't be backed up, but it's not a good thing to do because files from these directories can disappear if low memory happens.
So I think the best think to do is to save the important files that you need all the time in your app into Documents Directory and mark them not to be backed up, like this.
Library/Application Support Folder is the folder you should be using.
This directory doesn't always exist, and thus you may need to create it.
You can enable or disable whether you want to backup this data with iTunes or not.
This data is not accessible even if you enable file sharing. Only data that you put in Document directory would be shared with iTunes sharing, so you can still protect your data and get it backed up as well. Apple's documentation

Copying Sqlite database file content in CoreData

I'm working for an iOS app that was earlier developed using phone gap. It is having a sqlite database for storing data. But now while developing the same app in native, I'm using core data for storing the data.
Now when the new native app replaces the old phone gap app on user's device, I want to copy data from already existing sqlite file into core data.
So when I run the application on device with phone gap build pre installed my app(native) replaces the old build as I'm using same bundle ID but I'm not able to find out the path to that sqlite file. Does sqlite file still exists in documents directory?
If you have an example old database file still installed on one of your devices you could try downloading the App off the device using the Device manager in Xcode.
Then you open up the bundle and search for your file. Then if you know its location / name you can simply access it, read it using some SQLite library and load the data into your CoreData backing store. Keep in mind you either want to mark it in NSUserDefaults or delete the old DB all together so your app does not keep on migrating ( And then maybe accidentally deleting new data from a user. ) I would choose for keeping the old one around for at least a version or 2 so you can verify that your migration works without bugs / deleting user data in the process.
Tip: It is probably a good idea depending on how big your database is to show the user some kind of progress or "migrating / optimizing db" while you're doing this. So you don't end up with the user adding more data to the database before you're done migrating.

My IOS App has been rejected- Data Storage Guidelines (2.23) I have 2 possible suspects

my app has been rejected due to iCloud Storage Restrictions. (2.23).
There are lots of questions for this situation, but i am still not sure why my app has been rejected.. Here are my suspects:
1- My app downloads pdf files and images for letting users see on "offline" mode when a user selects a row from a tableview. I've set my download folder as "Documents/privateDownloads" and set the folder (and files inside) url flags as "do not backup"
2- My app also has a 2Mb. "preload.json" file, which my app reads the file at first launch and preloads into the database only at first launch (with a progress hud showing the progress of importing data). I haven't set the "preload.json" file as "do not backup".I just drag dropped the file into "Supporting Files" group in Xcode.
My guess is the problem lies in the 2nd suspect, but i've also read that i should move the "privateDownloads" folder into "Application Support" Folder instead of Documents folder.
i always stored my offline files on nsurl cache for a very long time (technically forever), but this time i've decided to do like this.
thanks for reading and helping.
Edit: there is a note from app store for rejection reason:
"In particular, we found that on launch and/or content download, your
app stores 3.6MB"
When i control this issue, this is happening after my application "preloads" the data. But what i really don't get it is, i am storing this preloaded data in core data. So yes, i want this data to be backed up in iCloud?!
To solve the issue of your seed data being too large, you might split your Core Data stack in two separate stores - one which stores the user data and is backed up to iCloud. And a second one which stores the seeded data imported from your JSON. This store could then be excluded from iCloud backup via the "do not backup"-flags.
Another recommended way would be to ship a pre-populated store like described in this article on objc.io. Since you mentioned your preload.json is several MB, this would be even more desirable to pre-generate the store once than on every device on initial app startup. And you could apply the required file attributes for not backing it up more easily.
The issue won't have anything to do with your preload.json file. If that's included in your app distribution, it is part of the app and you don't need to do anything different with it.
I would suspect that the reviewer didn't notice you were setting the 'do not backup' flag on files you've added to the Documents/privateDownloads folder, or that you have a bug and the flag isn't being set at all. It is safer, if you're able, to store those kinds of files in a /Library/Caches sub directory. Then you don't need to worry about the flag.

Automatically update iPhone app database without making user do anything

I have a pretty strong background in C++ and am making the switch to Objective-C to try to make an iPhone app. A main component of my app will be a database.
1) Is there a way to update the database of the app without requiring users to update to a new version from the App Store?
2) If there is, where & how do you pull the data into your app? Do you have to pull it from a website?
2a) Is there a way to make a master copy of the app that I can make data changes in and then have that copy update all other versions of the app?
If my database contains info that is only updated by me, do I need to store each piece of data as an object?
Ex: One "object" may have a name, a type, a number, and a picture
names, and types will overlap but numbers and pictures will be unique
Thanks again.
Yes, copy the datdabase (SQLite) from the application bundle to the documents folder. For an update, download over top the old one. Also, you can use something simpler than a database like an NSDictionary stored in a .plist file.
Yes, from a web server. NSDictionary has methods that let you download directly from a URL (dictionaryWithContentsOfURL). So does NSData.
Why not use third party tools to edit data? You can store a NSDictionary in a .plist file and edit it there, then upload it to the web server.

How can I ship my app with a pre-populated Core Data database?

My app uses Core Data and I want some default entries to be inside.
What's best practices of how to do that?
If you're already loading the pre-load data via a temporary routine for testing in your current code there's no reason you can't use the sqlite file it creates in the simulator's directory (no need to write a separate Mac app).
If you're not already filling that db you can still write an iOS app that does it. Odds are you've already written the methods for adding data to your store so you can use them to import the pre-load data as well.
Either way you'd grab the sqlite file from the simulator's directory and add it to your app's bundle; on first launch you'll copy it into the appropriate place in the app's directory before pointing Core Data to it. If it's really large the downside is that there will be a copy in the bundle and another on disk, but there's not much you can do about that other than grabbing the data over the network.
As others have suggested, if the amount of data is small you can just import it at first launch, using the methods you've already written for adding data as part of the normal app's workflow.
See the CoreDataBooks example, which has sample code for copying a database at first launch.
EDIT: I've created a Core Data framework (read about it here: http://bikepress.org/?p=1120) that includes this feature.
I would just create a database and put add it to my target so that Xcode copies it into the app bundle. At the first launch just copy it from the app bundle to eg. the documents directory or wherever your app expects the database.
There is Core Data Editor at the app store. Alternatively you could build your own simple mac app just for this particular DB and manage it from there. If the amount of default entries is small, then you're better off storing it in a plist or something and loading it into DB after the first launch.
In iOS 5, my app was rejected if I put a database file into resource bundle. So, I have to download the database from internet instead.

Resources