I have a REST service running on top of my application, which returns data to my iPad app. This app is built using RestKit to sync data in and out of the iPad. I have however a webapp running as well, which allows the users to delete some data.
The current problem that I have right now, is that whenever a user logs in into the iPad app, I run a query to get the data that was last_modified/added since his last login. This allows me to have faster/shorter queries. The only problem, is that if for example an object was deleted from the DB between his last two logins, the user will still see it in his iPad.
What strategy should I adopt to have this data in Core Data deleted as well? Should I just not delete object from my DB and have instead a BOOL that says "deleted" or not, and whenever I get the last_modified data via REST, this item will appear and I will just filter it out in the iPad?
I know RestKit has a way to delete orphans objects, but since I am syncing the "last_modified" data, I don't think it can be applied here.
From your comment question:
I created a list of objects that needs to be deleted from CoreData. So for I example, I return an array of IDS that corresponds to the Users I need to delete in CoreData. How can I do such mapping with RestKit?!
You should create a mapping to NSMutableArray. If your source data is a JSON array of strings then you will need to use a nil key path mapping in order to get the strings extracted into your destination array. See this link.
As Wain suggested, I will have a list of deleted objects in the Database with a "deleted_date" field. Whenever I will fetch the latest objects, I will also fetch the latest deleted objects back.
Related
Is there a way to update existing core data on the app from mysql instead of deleting the objects and then adding them again?
The usual approach is to fetch the existing objects and update their values with new data from your server. To do that, you need to have a unique ID that's included in the server call and that you save in Core Data. Then you do something like this, for each entry:
Get the unique ID returned by your server.
Fetch the managed object from Core Data that has the same unique ID.
Update the managed object properties from the incoming server data.
Save changes.
I have an app where a UITableView is used to represent a friends list. Now, this table is updated by values stored in core data, and I'm downloading friend values to core data via Parse. Instead of accessing Parse to update the tableView directly, I decided to update Core Data and then the tableView because I need the friend information in other parts of the app, and thought it would be more efficient to use Core Data than to have calls to Parse again and again. Everything works fine!
However, my app has a log in system before users can use the app. And when I created another dummy user to test it, I found that the friend values stored in Core Data by my actual account were being used to update the friend list tableView! When actually the tableView should be empty (new user).
I don't know exactly how Core Data works but I figure it uses some segment of the device's memory to store entities. My question is this, is it possible to use Core Data to store private information related to a particular user that can't be accessed by other users that log into the same device? Or should I continue to make calls to Parse whenever I need information?
Hope you guys understood my question, thanks!
iOS is not a multi-user system. Your app stores its files in a sandboxed folder structure and this sandbox is independent of any user logins you have implemented in your app.
When a new user logs in (or, if you prefer, when a user logs out) it is up to you to remove any data you have stored in Core Data that you don't want another user to have access to.
Parse can save data offline by Local Storage or cache the request by Cache Policy
They are much faster than creating your own database (by CoreData).
I currently have an api call that gives me an array of featured series for a video streaming app. If one of these series gets deleted it seems realm won't delete the object if it is gone from the JSON REST response. Core Data does it so is there something I am missing with realm?
When you check your REST API you will need to delete any objects that no longer exist. A way to do this is to check what is in Realm against the primary keys you get from your REST api. If it doesn't exist, delete that object.
This isn't something that Realm does automatically since it has no way of knowing what has been deleted on your server.
I have a problem.
I have iOS client app that has to allow multiple users to log in and store their data locally.
Data is synchronized with RESTful service, and the latest snapshot along with user's changes should be stored locally for all users.
Previously this app was implemented with SQLlite as data storage engine.
Now I would like to migrate to CoreData.
What do I have:
server returns me entities for current user. User ID is not sent, as the user authorizes and gets their session;
I know who is logged in an should store all data for this particular user. In order to do that I need to say CoreData to store the object for the user with ID=12345.
The problem is:
I have to tell CoreData to store the particular object associated with particular user's ID.
I need a way to somehow alter the object mapped with RESTkit - setting proper ID field for it.
This task was straight and simple with SQLlite but looks problematic with CoreData.
I am still thinking that I don't know something about CoreData asking you to help me with clarifications or useful links.
There isn't a good way to do it.
Hacky, you could add the id as a parameter in the request so you can map it back again (requires RestKit dev branch at time of writing).
Non-hacky is to update and re-save the objects returned in the mapping result.
Alternatively you could use one operation to download the JSON, then mutate it, then run another operation to map it.
First, Thank you for any help provided.
I have an iOS leveraging CoreData to retain various presentations, this data comes from a sqlite file and there is no server connection.
I will have to be able to provide App updates (via appstore), this update may add more data to the database.
The tricky part is that it can not simply overwrite the current database, there are a few user tables that I will not like touched.
Please provide any information I should consider when accomplishing this or any links are greatly appreciated.
Thank you.
Given your app has no server connection, you will have to rely on shipping data within the updated application itself. I would recommend using a plist file or define your own xml or json structure. You can then read this data to create/update core data nsmanagedobjects.
It looks like someone in the past was using plist->coredata on SO
Would you have relationships between user created data and shipped data?
If not, you might go the route of connecting two stored to the persistent store coordinator. The shipped store would be read-only. The store with user created data would be read-write. You can use this approach, too, if you have relationships between shipped and user-created objects, but it's a lot more complicated, since CoreData doesn't manage cross-store relationships for you, and you'll need to write your own logic (doable, but not straight forward).
If you need to have relationships between shipped and user-created objects, you can still ship a CoreData store. When the app launches for the first time (no user-created objects), you copy the store to the Documents folder and user this store to create your CoreData stack. User created objects will be added to this store. Once you have new 'shipped' objects (i.e. a new store in the app-bundle), you'll have to manually migrate that stores data into the store that the user has changed. You'll have to be able to find
(1) objects that need to be deleted
(2) objects that need to be updated (changed)
(3) objects that need to be added
If you mark your shipped objects with a special flag such that you can tell if it's a user created object or a shipped one, that would be doable. You also have to have some sort of ID to be able to tell which objects in the new store correspond to which ones in the existing (old) store.
You do not need to go the route of using plists. In fact, I'd recommend against it. You can easily open two stores at the same time. Either to use both stored, or just to migrate objects from one store to the other store.