I'm about to write a simple iPhone app that uses Core Data to store local copy of remote data that is fetched via RESTful web service. The data changes (new records being added) quite often. I came across RestKit and I'm wondering if it can do what I need. And what I need is to load all records in the beginning and then periodically download ONLY records that were added since previous check. Obviously there is no mystery about how that can be accomplished even by simply using NSURLConnection, but I hoped RestKit (probably in combination with a proper web service) would do that without me having to write all the synchronization logic. Again the key for me is that only new/changed data is fetched from the server.
I agree - RestKit can do this, we've recently used it to do something similar in a recent project. We used a last-modified-date request header to indicate the last successful 'sync' time, which the server can use to return only the records modified since that date. A http 304 'not modified' status code was used to indicate no change when appropriate.
RestKit also includes a seeding facility, so you know up front the initial data set - you can seed it as the initial database easily, and fetch the updates, even upon first use of the application.
Some information I found useful regarding RestKit & CoreData mapping - https://github.com/RestKit/RestKit/blob/master/Docs/Object%20Mapping.md, and the Google group is a good source as well - https://groups.google.com/group/restkit. Hope this all helps.
First of all: YES
RestKit handles CoreData very well. All you need to do is to provide mapping of your entities and it does the work for you.
For the second thing about selective sync, I really recommend checking StorageRoomApp it is a great, and not so expensive service that does exactly what you need.
They have a very good API that extends RestKit, it is very easy to use and their support is great. Take a look.
Related
I am going to display list of cities and countries. I have to get it from server using web service. but city and country are not changed every time. so we don't need to call that web service every time. so we can store all the information locally. what is the best way to handle this situation?
Yes you are right we don't need to call web service every time. You can use coredata in this situation. Using coredata you can manage all data locally and retrive back from coredata.
Core Data is the best one to use for non-trivial data storage. It can reduce the memory overhead of your app, increase responsiveness, and save you from writing a lot of boilerplate code.
Refer this link : http://www.raywenderlich.com/934/core-data-tutorial-for-ios-getting-started
You can do this in several ways
you can use nsurl session caching
store data in local db (coredata or sqlite) http://www.raywenderlich.com/934/core-data-tutorial-for-ios-getting-started
For simple data you should use NSUserDefaults
use plist file http://www.theappcodeblog.com/?tag=ios-saving-data-to-plist-tutorial
http://code.tutsplus.com/tutorials/ios-sdk-working-with-nsuserdefaults--mobile-6039
please check the following also
storing data locally on the iphone
Store data locally IOS
There is some more option to locally
1. Using LocalDB - its little bit pain but not bad that much
2. Using XML file - you should have the method to retrieve the data.Its pretty easy
3. Using Plist - This is also very easy can done through few lines.
4. NSUserDefaults - This can be use only as few cases like User information, store tokens.
Got it!
I would like to sync a core data app with a user with a different iCloud ID and I am trying to figure out the most graceful way to do this. I do not want the data to sync with all users, but want to be able to sync among family members for instance. From the research I have done, I do not think I can do that using iCloud Core Data sync because it only syncs between devices with the same iCloud ID. I have looked at this stackoverflow answer and read a little bit about Ensembles, Parcelkit and TICoreDataSync, Parse etc., but it is not clear to me if any of those options will allow me to sync with multiple users. Does anyone have a good method for syncing a Core Data app with multiple users?
Ensembles and TiCoreDataSync might work. They can use Dropbox file syncing, so in principle they should work with Dropbox shared folders. I don't think these are the main intended uses, so I suggest contacting the developers and/or doing some good testing yourself before assuming this would actually work.
You'll need to think about the user experience, though. At a minimum, your users would both need Dropbox accounts and would have to set up a shared folder before beginning to sync data this way.
Parcelkit probably won't work. It uses Dropbox's data store API which, unlike other Dropbox services, doesn't appear to support shared data.
Services that do support this kind of sharing exist-- for example, Parse and Firebase-- but make sure to review their pricing carefully before using them. Also of course, there have been any number of projects that have their own custom server back end, but that obviously requires having someone on the team who can do that kind of work.
You need to think about other device types (Android at least) if you want your application to be reaching more users.
I'm doing the same now by the following way:
Setup an online database with proper web services (careful with implementation for security matters - DB should NEVER be exposed by anything other than the web services).
Create a Class for your communication with the server (using Class methods with security handling like authentication and authorisation).
Use the class in your app to communicate with the server (SQL operations are done on the server).
To integrate with CoreData you need to create the model in your app similar to the structure in the backend database. Then you need to create a similar class for the app that deals with only local CoreData.
A higher level class might be required if you want to make sure that operations done on both server and local data storage.
Besides, you have to implement a lot of conditions to make sure that data written in local ONLY after making sure that it is stored online (or create an engine for differed operations to run later).
Another Way if you are familiar with notifications:
Use structured notifications between devices for data operations in order to keep everything in sync with other users. The problem with this is the "Autonomy" of the operations. If two operations were done in approximately the same time, you have to find a way to make sure the order of the operations is done properly (maybe timestamp or something).
I'm looking into the same thing for my app and I 'think' you can do a fairly unsecured version of what you are after using using the public folder in cloud kit as mentioned in this question (no accepted answer at time of posting) : Private data sharing using CloudKit
You would need to find a way to differentiate between data that is truly public and those shared among the users you need and some level of authentication.
I'm going to try exporting a permission file with access permission in it to whomever I want to share with combined with a unique identifier located in that permission file.
Keep in mind, as mentioned in the comments of the linked answer, my implementation will be security by obscurity (thanks for that phrase) unless you find a way of adding proper validation to it but my data is relatively insensitive.
Hope this, or any ridicule in the comments, points you in the right direction : )
I've worked on several iOS apps, some of them utilize Core Data, and some of them don't. While I consider myself having a basic to somewhat good understanding of Core Data, there's always something that makes me doubt the usefulness of it. I've done a lot of reading on the subject, and the general consensus seems to be the advantages of using it outweighs the disadvantages. I recently submitted an app without using Core Data, and always planned on going back to update the project to utilize it when I have the time for some optimization work. Now's the time, but I wonder if it makes sense for the app I'm working on, and maybe I am not using it correctly all along. Please advise and point out what I am missing.
The project I am working on is a social networking app, which also has a front-end site. We have standard features like a newsfeed, event listing, the ability to follow/unfollow someone, and a map with POIs at user's location. Currently, we're using pagination whenever needed when requesting data from server.
My understanding of why Core Data is great:
Easier to manage data with complicated relationship
Easier to access data without having to pass them around
Easier to manipulate, fetch, and sort your data
Better memory utilization
Improve perceived performance by preloading data stored locally until latest data's received
The problem I am having is, since I am using pagination when requesting for data instead of requesting for all at once. The data stored locally is only a subset of the current state in the database. Let's use newsfeed as an example. If I do the following, it will cause some problems:
User manually refresh the newsfeed -> Controller notifies model that it needs the latest 20 items -> Model requests for the latest 20 items in the newsfeed and save them as NSManagedObject -> Model notifies controller that data is ready -> Fetch the latest 20 items to show in UITableView
If user A refreshes the newsfeed, background the app, and then user B deletes his post in the newsfeed (let's say it was 10th item) before user A foregrounds the app again to refresh the newsfeed. In user A's newsfeed, B's post will still be up there because according to the createdAt attribute, it's indeed one of the latest 20 items.
To fix this problem, I can think of a few solutions:
Add a flag to the item to indicate it's removed
Always discard local data when new data arrives
Disable pagination
Instead of using the workflow described above, always present the requested data only instead of fetching the latest
Solution 1 means custom code is required to deal with different clients since browser doesn't need deleted items but iOS client does. However, even though it can work, it can potentially mess up the pagination mechanism and can cause weird behaviours in the client. For example, if a large amount of items gets removed, the latest 20 items will contain only a few items that will actually show up in the newsfeed on the client when user refreshes it. As user follows more people, more stories will be inserted in his newsfeed as well. This solution won't work very well in this situation.
Solution 2 totally defeats the purpose of using Core Data in the first place unless I am missing something.
Solution 3 means the client always needs to request for all data. This is nearly impossible to do because as you get more data, the time to retrieve and process them will make the app slow and unresponsive. It also doesn't make sense from technical and UX point of view.
Solution 4 also kinda defeats the purpose of using Core Data because it's the same workflow when we only store data in memory. You can still fetch and find objects but they might be invalid on the server already at the time of access.
Am I missing something? How is Core Data supposed to be used in this scenario? How do you ensure data consistency when the client doesn't have all the data? Thanks you in advance.
I have an application that talks to a remote API using RestKit with an SQLite store for Core Data. When I got to the point of adding server-side searching, I was faced with having to find a way to efficiently display search results. To accomplish this, I used an NSFetchedResultsController that is tied to another in-memory store of the same schema as the SQLite store, and also backed by RestKit. When RestKit searches against the API's search endpoint, it maps the responses back to the in-memory store.
This works really well for what I need, but has now caused another issue. When I get these "transient" objects back from the server, and the user selects one, it needs to be copied into the persistent store at that point (various interactions beyond that point will load additional objects from the server and attempt to tie them back to the original object - which will fail if they're in two different object contexts).
tl;dr
Does anyone have any suggestions on how to copy an entire object (entity and relations) from one core data store to another? Or, is that even necessary? Is there an easier way to accomplish this same task using RestKit?
Would I be better served by changing my search instead, to not use an in-memory store? If so, how should I store these objects?
I wouldn't use the in-memory store. I'd just put the search results into the main store and bypass the issues with copying. I'd then have a purge that ran to clean out the old search results that aren't required any more. You might want to tag search results that need to be kept around for some reason. And you can get RestKit to do the purge automatically when each new search is performed (see "Fetch Request Blocks and Deleting Orphaned Objects" in these docs)
For your other question, about tagging. When you make the search request, the search term is in the URL. If you use RKObjectManager and routing then you can access the metadata that is provided to the mapping to get the search term and store it into the returned objects. Something like:
#"#metadata.routing.parameters.searchTerm": #"searchTerm",
See the metadata docs here.
I need help understanding how to manage the API for an iPhone application that persists remote objects using CoreData. From my understanding, when the iOS app fetches the remote objects, it loads all the objects at the resource path.
For subsequent requests, I want to reduce overhead by having the web server return only objects that have been updated since the last update time. I perform this by returning objects where updated_at is newer than the last_update time of the request.
RestKit then parses and maps the modified objects to CoreData. Is this implementation the proper way of performing synchronization using RestKit and CoreData or am I missing a layer somewhere in between?
Thanks!
Typically RESTful interfaces should try and head "back to the basics". In your case I recommend using the HTTP Header If-Modified-Since. It is slightly cleaner than passing another parameter because RestKit will handle the HTTP status responses without you doing anything.
Otherwise, your method seems normal. Server synchronization is an enormous problem and there is a lot of literature and methods dealing with it. If you want to do something more complex then a quick web search will turn up a handful of methods, but your approach is what I usually end up doing.
If a user can edit data on your app, then there is the problem of synchronizing modifications made on the device. For this you typically set a object scope "modified" flag and only upload an object if it is modified.