I'm building an app that retrieves a JSON dataset from a PHP server. The app has a view that displays a "feed" of several different newly added or updated items from the web server.
The app loads 20 of the newest items to start with, and the user can subsequently load 20 more older items, and 20 more, and so on. I want this data to persist between subsequent view changes, and quitting/launching the app.
So far I have a PHP webservice handling the JSON response by accepting a last_updated timestamp, which is sent by the iphone client with the webservice query. The server then returns any items it finds that are newer than the last_updated time.
On the iPhone side I have the connection to the webservice returning results to the iphone and displaying them in custom UITableViewCell cells. However as of right now the app will request the data from the webservice every single time.
I'm a little confused as to what's a good way to cache this data. Do I store the actual cells themselves, or create an object for each feed item type and store that? Or something else? Do I use core storage, sqlite, or some other custom method?
Thanks for any insight.
You never store data of any kind in a table view cell. Cells are intended to be reused to create the illusion of an arbitrarily long table. If you keep creating and retaining the cells as a data store you will eat all your memory very quickly.
It sounds like you do want to create a Core Data store although a plist and SQL are inferior options. The learning curve for Core Data is relatively steep but once you learn it it makes everything easier.
Related
I'm making an app where the user can take a picture and add a title and description. But now I need to store the picture and the titles. I’ve tried making an object that contains title, description and image properties.
When it’s done I save an array of custom objects with the information on it with UserDefaults. My idea is showing in another view a table view with all the content and pictures the user has taken on the cells. I tried getting back the information with user defaults. It was working well until the user saves too many pictures. When the viewController with the tableview loads, then my app gets slower, and eventually it crashes.
I suppose the problem is when I load all the array with all custom objects, all the pictures are loaded into memory although they aren’t used and displayed for users. So I think it isn’t the best way to make what I want to make.
Is there any way better to make what I’m making or store data more efficiently and use it in tableview without using all the memory of the device?
I’m making the app from 0 again.
Can you show me how to store data and images efficiently?
There are several options for permanently storing user data on the device such that it will survive app and phone restarts. NSUserDefaults typically is for small amounts of data, such as user preferences.
When it comes time to store a lot of data, in particular big binary objects like photos, you need to decide which design you want to use. One option:
store all the photos in one directory in your apps documents and then use some simple lookup store (perhaps Core Data, or SQLite, or even a flat file) to index the photos and their metadata. Or if you don't care about indexing you can read the list of file names from the directory and sort them by time.
The other problem you are maybe having is that you are trying to load all of the photos at once for the user. As you have discovered, once you have more than a handful of photos this system falls apart. You need some mechanism to load only a few photos at a time, preferably only the ones the user needs to be displayed at that moment.
So, for example, if you are displaying the photos in a tableview, you want to only load the 10-15 photos that are visible in the table at any given time.
When storing this kind of data, you have 2 options (In fact you have more than 3 options, but saving image to the disk is IMHO complicated for this.) -
UserDefaults
Database like CoreData/Realm/FireBase...
The first one is recommended when there is not much data to save... For operating with more data, I would use database - CoreData...
For you operation you can use CoreData and NSFetchedResultsController (which is designed especially for fetching objects from the database)...
you can read the FetchedResultsController doc here... and core data basics here
Wish you best luck!
I come to iPhone programming from a web development paradigm and am having a bit of a problem understanding how to design my iPhone application.
The crux of my question is: How much data do you load into your model and when do you load it with data from the database?
In the web apps I've created, the objects on the server-side are filled by the database based off form values supplied by each request. Take the example of a simple list. You click a list value, the id for the list is sent to the server (query string), the server loads an object for just that list item, server-side code uses the object, and then destroys it before the page is returned to the user.
With iPhone apps (or I guess any app where objects persist), you could load all the list item objects into a singleton dictionary from the database before the user ever interacts with them. Then you never have to go back to the database when the user clicks on a link. You just load the object from the dictionary.
Alternatively, you could design it like a web app and just go back to the database each time and fill the object with the data requested.
Can you give me any guidance on when to use one way over the other? When do I load the data? I'm tempted to just load a bunch of data when the application starts up so that I never have to go back to the database. But this feels dirty.
For static data that isn't too large, loading it all at startup works.
In one of our products, we do this for simplicity on one of the tables (we don't expect more than a few thousand rows) and load the other table lazily (high-res images). This is a reasonable option if you don't have background threads also accessing the database.
Core Data does batched lazy loading (i.e. it will load a batch of result rows at once).
Sidenote: Writes using Core Data and an SQLite store seem exceptionally slow, to the extent that we moved processing to a background thread to avoid blocking the UI (and this is for not very much data at all) and gained some annoying concurrency issues as a result. Sigh.
I have a iPhone app which loads json from my webservice.
I think its a good idea to store the data with Core Data but how should I sync the data with my webservice?
For example, say that I show a UITableView with the information stored in Core Data, and then I would like to update the object.
Are there any design patterns or ideas for this?
Each time your app loads it should try to load info from the web service. If it can't connect, use the local data. You should timestamp your data on the server and in the app so that you can track when the information was last updated. You can also offer a button to manually refresh the data. (Like the Mail app.)
EDIT:
To make asynchronous requests, you can see the ASIHTTPRequest library.
I'm developing an iPhone app that relies heavily on calling ASP.NET Webservices to transfer data to and fro between a database in one of our servers and the phone.
There are multiple items that the user works on. And to work on each item, a typical usecase requires 5-6 webservice calls. Depending on 3G signal strengths, the amount of data that's being downloaded and the number of items each day, it takes any where between 5-6 minutes of time just to keep the user looking at the spinning wheel.
This is simply not acceptable, so, basically I want to be able to asynchronously keep both the app and the database on the server side in sync.
How would I go about doing this? (I'm currently not using CoreData at all, but I'm guessing I probably need to use it now).
Thanks,
Teja
You will need to code the glue beteeen core data and your restful web service. Try and design your data model to match the data coming back from the web service and that will make the glue easier to manage. If you can get the data in JSON then the glue will be even less.
Core Data is an object hierarchy and you will need to approach it like that when you design your caching and syncing code.
Update
The tableview has nothing to do with the data. When you are working with Objective-C and iOS you need to think in terms of MVC. So you need to be thinking about watching delta changes in your Model (the UI or view portion of MVC is irrelevant). Core Data easily lets you do this during a save operation and you can take those deltas and push them back up to the server. The tricky issue is how to get notifications from the server of changes server side. That is something that is dependent on the server design.
Processing changes from the server should be done on a background thread (with a separate NSManagedObjectContext connected to the same NSPersistentStoreCoordinator) and the main thread should be watching for save notifications from that background thread so that it can update the UI as needed.
This is a non-trivial design and the complexity means that you can and will run into issues but those issues are dependent on your application and server design. There is no silver bullet other than the fact that using Core Data makes all of this a lot easier.
I needed some advice on how to get the data from the database(sqlite). I am having a navigation based application. The db i have, contains a CONTACTS table.For each row in CONTACT, another table CONTACT_DETAILS contains around 50 rows.
The data from CONTACTS i have to load at application startup as i have to show them on the first page of application. Now about the CONTACT_DETAILS, here i am a little confused about how to load the data from the database.
Shall i load all at once on application load? Or
Shall i load this data only on selection of a particular contact?
Short answer: use CoreData and you wouldn't have to worry about it.
Slightly longer answer: it depends (ok, that was shorter). If your database is small and you aren't going to update it, you might just as well load it at launch; but if you are updating or it is larger, load the details when you call the view controller from the master - typically in the viewDidLoad (or viewWillAppear, again, depending).