I am developing an iOS app with objective-C. With my 'GET' request am getting a large chunk of json data in below format.
[ { #"value": #1,#"day":#2,#"hour":#1} , {#"value": #1,#"day":#1,#"hour":#1 }....]
Note, This array always contain 168 fixed number objects.
Inside my app I have different UI controls which suppose to show different chunks of the obtained data. For example clicking 'Button1' suppose to show ob1---obj10 and so on.
In theory its all working, but I am not happy with my design approach.
Because for each button press I am calling the api to get the entire data set again and extracting the required data.
Ideally what I think should happen is I should store the data locally upon first 'GET' request and different classes within my app should be able to extract required information.
Same method should apply to my 'POST' requests. I am confused with what options I have, and what is best practice in this situation. I can think of following
Store data in an Array ?
Store the data in adatabase like sqlite ?
Finally plists ?
Using core data is bit of an overkill ?
168 records where each is roughly 40 bytes gives about 7 Kb of data, which is probably reduced down to something like 2 Kb if your API server supports gzip compression. This is nothing according to modern web standards.
You could download it completely, parse and save to a variable in your view controller. I recommend creating a "model" class (as in MVC) to wrap your data nicely and factor out the rows selection logic.
CoreData (or SQLite) is definitely an overkill for this amount of data.
You can use something like a plist or NSKeyedArchiver to cache the data to disk if you need offline support, i.e. you want to have an app working without an internet connection.
Related
I have to download thousands or millions of hotposts from a web service and store them locally in core data. The json response or file is about 20 or 30 MB, so download will take time. I guess mapping and store it in core data will also take time time.
Can I do it in restkit? or has been designed just for reasonable size responses?
I see I can track progress when downloading a large file, even I see I can know when mapping starts or finishes: http://restkit.org/api/latest/Protocols/RKMapperOperationDelegate.html
Probably I can also encapsulate the core data operation to avoid blocking the UI.
What do you think? Do you think is this feasible? Or should I select a more manual approach? I would like to know your opinion. Thanks in advance.
Your problem is not encapsulation or threading, it's memory usage.
For a start, thousands or millions of 'hot posts' are likely to cause you issues on a mobile device. You should usually be using a web service that allows you to obtain a filtered set of content. If you don't have that already, consider creating it (possibly by uploading the data to a service like Parse.com).
RestKit isn't designed to use a streaming parser, so the full JSON will need to be deserialised into memory before it can be processed. You can try it, but I suspect the mobile device will be unhappy if the JSON is 20 / 30 MB.
So, create a nice web service or use a streaming parser and process the results yourself (which, could technically be done using RestKit mapping operations).
I'm creating an iOS app that draws graphs. What's the easiest way of storing the data for drawing these graphs? I'm using GET requests to retrieve data from a server. The data is updated roughly every 15 mins. I need to be able to add the new data every 15 mins to the old data.
I've looked at using Core Data but not sure how to proceed as it appears there are multiple routes I can choose.
Some general pointers would be helpful.
If you need the data to be persisted across runs of the app and have "unlimited" amount then you will want to use Core Data. If you just need a little data during 1 run of the app you can use things like an NSArray of NSDictionary's.
The very very simplest way to save your data is as a plist. NSArray and NSDictionary both provide -writeToFile:atomically: and -initWithContentsOfFile:.
For any complicated retrieval or searching, you'll want to learn about and use Core Data. But for simply dumping the entire array out and getting it back, these methods suffice. You'll encounter memory pressure for large datasets, which is why Core Data has been suggested.
When you receive graph data from server, do you receive delta change or complete set again?
In case its delta change, you should use NSMutableArray or NSMutableDictionary. Keep appending more records.
In case you receive full set, you should clear all objects in NSArray/NSDictionary and re populate with data received on server.
Core data is for persistent storage in file system. Based on your requirement it doesn't look like you need one.
Design question:
My app talks to a server. Json data being sent/received.
Data on server is always changing, and I want users to see most current data, not stored/cached data. So I require a user to be logged in order to use the app, and care not to persist data in the app.
Should I still use CoreData and map it to Json's.?
Or can I just create custom model classes and map Json's to it's properties, and have nsarray properties, which point to its child objects, etc. ?
Which is better?
Thanks
If you dont want to persist data, I personally think core data would be overkill for this application
Core Data is really for local persistance. If the data was not changing so often and you didnt want them to have to get an updated data everytime the user visited the page, then you would load the JSON and store it locally using CoreData.
Use plain old objective-c objects for now. It's not hard to switch to Core Data in future, but once you've done so it gets a lot harder to change your schema.
That depends on what your needs are.
If you need the app to work offline, you need to store your information somehow in the client.
In order to save on network usage, you could store locally, then query the server to see if it had an updated answer -- you could do this by sending a time stamp to the server and return a 304 Not Modified if the entity hasn't changed.
Generally, it depends on how much time you have to put into the app and what your specific requirements are, but as a general rule I would optimise for as low bandwidth usage as possible, as that not only reduces potential data costs, but also means the answers will be more quickly available to your users (when online and they have not changed) and also available offline.
If you do not wish to store data locally at all,
I'm making a catalog where the cells in my collection view will be either an image with a label or a pdf. There will be many collections and they themselves will be static. I want the user to be able to save the cells he likes and view them in his own custom view.
1) I could to store the image as data in Core Data.
2) I could just include the image in my App Bundle and load the image from there every time my app starts.
I've got it into to my head that reading data from a Core Data Store would give me more options when building my app as well as offer some boost in performance as opposed to reading it from the app bundle. Is that true? Keeping in mind of course that most of the data is static.
It seems inefficient to have images both serialized images in my app bundle and the pure data as well.
I think I'd rather have it all in the store but they have to be loaded from the bundle at some point in code right?
I'd love to know how other developers do it.
Now in Core Data there is an "allows external storage" option for binary data, which basically means if your file is bigger than 1 MB it will be stored automatically outside of your database, and you have to do nothing differently. In my opinion that's the way to get the best of both worlds, increased performance + automatization + fast queries (although they are slower than usual when you allow external storage, but still faster than doing it yourself)
I am currently creating an iOS app, which connects to a database and asynchronously downloads a JSON object of data to display in a table view.
As it currently stands, this is an ok way to do it. However, when the database starts getting much larger, this will cause a massive inconvenience. I'm reasonably proficient in Objective-C but not so much in the database side of things. What would be the best way to get this data from the server, and keep it in the app? At the moment, I have a custom class object storing the data for each of the 'objects' in the JSON object. There will however be many other aspects of the app that the database will handle, such as invites, logins and user details.
Would core data be the way to go? I.e duplicating the database (to a certain extent) and storing it locally, then accessing from there. As I said, i'm not really sure which route to take here, so any advice would be real appreciated.
Core location is for handling location (satellite (and wifi) positionning).
I guess you mean Core Data. Core Data is a graph object model which allows you to manipulate data as objects. You don't dig directly into the database, you ask for objects instanciation through predicates (kind of where clause in SQL) and the manipulate the objects.
This stated, it all depends on what is a "big" database. If it's really big you could consider copying locally a part of it and ask for what's remaining from the server through your webservice.
Another question that you could ask yourself is the quantity of data that never change and if your website database and your app database needs to get synchronized (if your website database is always changing then it would be dumb to copy it in your app totally and always synced your app..).
Links :
Introduction to Core Data
Difference between Core Data and a Database (Cocoa With Love)
edit :
A question you can ask yourself is where your data needs to be saved ?
if your app is just for printing 20 cells out of a total of 200 cells then i would go for a total download of your 200 cells. The load of the other cells will be with no delay after first download, especially appreciated if you're using table view cells with reusable cells
is a delay of some seconds acceptable between the 20 first cells and the 20 following ? I think there is no real "good" answer to your question, it depends on many factors (purpose of your app, acceptable time between loads, does the info needs to be modified and saved back to server or locally, what kind of customers, what your app will do with the cells, if you have a database locally will it be totally independant from "mother" database (if no, what kind of synchronization), etc.)
Trying to sum up things according to what I've understood of your needs, I would say that webservices is good if you just need to retrieve info and exploiting it after without saving it back (even if you can do it actually having services allowing you to do it), having a database locally is good if you need your app to be independant from your server in some ways.
Only you has the key to answer all this and take a decision according to your needs and your knowledge of your application and your customers.
Something like JSON or SOAP is the way to go with getting structured data from a web service into objects in your iPhone app.
Storing relational data on the iPhone itself is easy with SQLite. Here's a decent looking tutorial.
Make things easy for yourself by writing a data layer, abstracting away calls to the database, to avoid dotting SQL queries all over your code in places it shouldn't be, like the UI.