I have some Json Data I am getting from an API, I want to store it for later use, in case the user has no Internet connection. But I am not sure what my best option is to save it.
I was thinking about using sqflite, but in my use case I will need to fully replace all entries, so I would have to delete and rewrite about 300 columns, split between 5 tables, pretty regularly and I am not sure if that is ideal.
I also considered just saving the Json file to device storage or even using shared preferences.
Do any of you have experience/ideas on what my best option would be? Will sqflite be slow if I use it? Thank you
I think using sqflite would be the best option when it comes to persisting data if you want to create an offline cache for the user.
Using shared preferences would be slower as NSUserDefaults and its Android counterpart are not designed for high performance read/write operations therefore any insert, update and query operations would be slower in general if you handle big amounts of data.
Saving the Json file to device storage would be in my opinion the lest performant option if you have to query it afterwards as you would have to serialise/deserialise whereas if you use the database you'll be able to quickly query data and instantiate your on model objects etc. I'd recommend you to follow a layered approach if possible (using a Repository to feed your View Models or Blocs etc and a separate DB Manager/Service etc.
Related
I'm trying to figure out how my new app should handle data.
In previous projects i've avoided core data due to the learning curve and I've ended up using arrays.
However, this project is a little more complicated.
There's a remote server which provides json content.
I've already got the custom authentication written.
The server will aggregate the data.
I'm worried about performance, having to access the server each time I want to get any data.
However, my main question is, can i use coredata as a kind of wrapper rather than having a local database / datastore ?
CoreData can have as backing store: XML, SQLite, Binary and Memory.. So you can use an in-memory store... if this is your question...
I'm worried about performance, having to access the server each time I
want to get any data.
Of course if you request some data from server, it takes more time and you need to be connected. So if it is critical consider storing some already received data on device.
CoreData is not very useful as a "wrapper".
When you receive JSON results from server most natural way is parse them into native collection of NSDictionarie's and NSArray's with lib like JSONKit, then you can simply use this results. To fill coredata storage you anyway need to parse data and them assign CD-managed objects from parsing results.
But if you want to store results either on disk for future use or in memory just to organize them into your custom classes then CoreData is a good choise.
thanks for you help.
I'm attempting to add core data to my project and I'm stuck at where and how to add the actual data into the persistent store (I'm assuming this is the place for the raw data).
I will have 1000 < objects so I don't want to use a plist approach. From my searches, there seems to be xml and csv approaches. Is there a way I can use SQL for input?
The data will not be changed by the user and the data file will be typed in by hand, so I won't need to update these files during runtime, and at this point I am not limited in any type of file - the lightest on syntax is preferred.
Thanks again for any help.
You could load your data from an xml/csv/json file and create the DB on the first lunch of your application (if the DB is not there, then read the data and create it).
A better/faster approach might be to ship your sqllite DB within your application. You can parse the file in any format you want on the simulator, create a DB with all your entities, then take it from the ApplicationData and just add it to your app as a resource.
Although I'm sure there are lighter file types that could be used, I would include a JSON file into the app bundle from which you import the initial dataset.
Update: some folks are recommending XML. NSXMLParser is almost as fast as JSONKit (but much faster than most other parsers), but the XML syntax is heavier than JSON. So an XML bundled file that holds the initial dataset would weight more than if it was in JSON.
Considering Apple considers the format of its persistent stores implementation details, shipping a prefabricated SQLite database is not a very good idea. I.e. the names of fields and tables may change between iOS versions/phones/whatever hidden variable you can think of. You should, in general, not concern yourself with how this serialization of your data is formatted.
There's a brief article about importing data on Apple's developer site: Efficiently Importing Data
You should ship initial data in whatever format you're comfortable with (XML allows you to do incremental parsing efficiently, which reduces memory footprint) and write an import routine to run if you need to import data.
Edit: With EliBud's comment in mind, I still consider the approach a bit "iffy"... The format of the SQLite database used by Core Data is not something you'd want to generate by yourself (it's weird, simply put, and still not something you should really rely on).
So you'd want to use a mock app running on the Simulator and use Core Data to create the database (as per EliBud's answer). But you'd still have to import the data into that mock-app! And while it might make sense to do this once on a "real" computer instead of a lot of times on a mobile device (i.e. copying a file is easy, importing data is hard), you're essentially using the Simulator as an administration tool.
But hey, if it works...
I need to keep track of some variables and to save them very frequently. I don't need complex search and sort, just simple read/write.
What is the difference in read/write performance between plist and sqlite ?
Besides the above two methods, should I use core data ?
Please give me some hints.
Thanks.
In SQlite you can perform all functions related SQL like create,delete..and also store large amount of data.But in Plist its you jst store .
Plist and SQLite have different use as below..
PList is a file format used to store a small amount of structural data (less than a few hundred kilobytes), typically a dictionary. PList doesn't have sorting capabilities in and of itself, although code can easily be written to sort it.
A property list is probably the easiest to maintain, but it will be loaded into memory all at once. This could eat up a lot of the device's memory
SQLite is a full-fledged database. File sizes (on an iphone) are essentially unlimited. Sorting capabilities are built in. Querying and relational table designs are possible. Performance should be as good as any sorting algorithm you might come up with.
An sqlite database, on the other hand, will load only the data you request. I'm not sure how your data is structured, but you could quite easily create key-value pairs with a single database table. (A single table with a key column and a value column) Then, if it were me, I'd write an Objective-C class to wrap the database queries so I can write easy statements like:
NSString *welcomeText = [[MyData sharedData] dataWithKey:#"WelcomeText"];
Getting the data into the database in the first place doesn't have to be difficult. You can use the command line sqlite3 utility to bulk load your data. There's a command called .import that will import your data from a text file.
From the answer provided by #Robert Harvey in this previous SO question plist or sqlite
PList is a file format used to store a
small amount of structural data (less
than a few hundred kilobytes),
typically a dictionary. PList doesn't
have sorting capabilities in and of
itself, although code can easily be
written to sort it.A property list is
probably the easiest to maintain, but
it will be loaded into memory all at
once. This could eat up a lot of the
device's memory.
SQLite is a full-fledged database.
File sizes (on an iphone) are
essentially unlimited. Sorting
capabilities are built in. Querying
and relational table designs are
possible. Performance should be as
good as any sorting algorithm you
might come up with.An sqlite database,
on the other hand, will load only the
data you request. I'm not sure how
your data is structured, but you could
quite easily create key-value pairs
with a single database table.
If you are storing "huge data" then
you will benefit from sqlite.
Especially if you are going to be
performing complex queries,
extraction, searching and sorting
etc..
If you are going to do operations like search, sort you have to use sqlite. In sqlite we can able to store large amount of data but it is not possible in plist.I dont know about the performace between this.
I'm creating an iPhone app, which fetches information from a server every time it is started. However, i'm planning on using the fetched data of the last month/few months/year to calculate some averages.
I had been thinking about saving them to NSUserDefaults using dictionaries (associating a date with a value), but i just remembered there also exists something like core data. Seeing that i do not have any experience with core data, i don't know if it's better. If it wouldn't, i could save the
time i'd use learning it otherwise.
The data comes in in XML format, and i get several sets of the same response each time (for different locations on a map). The amount of sets can change, as the user can add more locations. I currently only save the raw data to the disk to load if the load fails next time it starts. However, i also want to save some specific values from that XML in a way that i can easily access it. What would be the best way to do this?
Edit: I actually also need to know how fast/efficient core data is. I'm currently passing around NSArrays with NSDictionaries for the sets of data during that session. For saving the data that last longer than the session core data is ideal, i found out that much (just need to find a nice way to associate an entity with a date), i just need some advice on the efficiency.
If you're going to be working with larger amounts of data, it's probably anyway better to give Core Data a try, it's after all not that complicated and there's a plenty of good tutorials where you can learn it. There are different settings for the storage type, you can either use a sqlite database or an xml file.
According to the guys from Apple, it should be fast and memory effective to use Core Data in contrast to self-made solutions, so it's a preferred way to go.
Core data would be easier to manipulate the data and query the data using predicates. Core Data supports dates so you can even find items in date ranges.
Is Core Data still a good option to use for the iOS even if they data will only be quite temporary. i.e – data being sent up to a server in the cloud once within range of a network, and then never needed again on the mobile device.
You don't have to use Core Data to persist data.
If you don't want to persist the data at all, you can define an in-memory store which never writes to disk.
Core Data's true function is the management of an object graph i.e. it handles the relationships between objects. It's real advantage is the ability to automatically handle complexity.
That complexity can arise from the data objects themselves or from their needed relationships to controller or view objects. Either way, Core Data makes it easy to tie all the objects together without great gobs of custom code. Where the objects end up being persisted or even persisted at all, is really secondary.
Yes, if there could ever be a large number of records (e.g. user is overseas, doesn't have a data connection), use Core Data. The point of the Core Data abstraction is just this - if you only have 10 records max, ever, it may just use a flat file of data, or maybe a Sqlite database if more than that -- by "handing the problem" over to Core Data, you make storage decisions Apple's problem, and for free you'll get all the optimizations that Apple'll throw into the Core Data framework in the coming years.
Core Data is complex when you first look at it. Apple's API docs aren't bad, but there are a few "gotchas". If you've worked with anything like the Entity ORM framework, etc, it's really easy to pick up.
Alternatively, if you're reasonably certain that you're only going to get 5-10 records, and the data is anything that conforms to NSCoder, you could just archive it and save it, and then unarchive it when you launch the app. Also, if it's array data, a plist is pretty nice.
The approach I take is to insert entities into a NIL context and provide a base class for insertion into a valid context when I wish to persist them. Code can be found here... Temporary Core Data