5

In my application i have to maintain a local persistent store in sync with cloud kit private database. So I just wanted to know how can I handle account changes that may happen.

Confusion I have is as below: say a set of records belong to user A now if user B log's in to the same phone I can do the following of the 2 things:

  1. Ignore user and let data sync to B account too but that way A's data will get sync to B's private account too. Here the record change tag and all get a bit mess up since am saving CKRecord encoded fields to database.

  2. I can maintain a user table and link each record to the user that is logged in that way user data will get separated. So should I maintain a user field along with all records ?

How can this be best handled even apart from above 2 things.

user3519594
  • 387
  • 1
  • 11

1 Answers1

2

Of course in your local persistence store you could add the userID to personalize all records. An other mechanism is to remove all local data and fetch the users data when a change is detected. If you want to keep the users data on the device you could also create separate data stores for each user.

You can detect a changed login by adding the following code in your app delegate or root view controller:

NSNotificationCenter.defaultCenter().addObserverForName(NSUbiquityIdentityDidChangeNotification, object: nil, queue: nil) { _ in
     /// remove local data and fetch user data
}

You should also refresh all user related data in memory and refresh the loaded views.

Andriy
  • 2,767
  • 2
  • 21
  • 29
Edwin Vermeer
  • 13,017
  • 2
  • 34
  • 58
  • 1
    Thanks edwin, In my application user may have unsaved data to cloud since we provide him with an option to turn on/off cloud syncing so if we remove all data when account switching occurs then their are chances that user may lose some data. For the other 2 options i.e maintaining userID in persistent store and making separate persistent store which one is more preferable ? – user3519594 Oct 07 '15 at 11:47
  • A separate persistent store is easier maintainable. You only have to switch stores' You don't have to alter your data or your queries. It would only be more difficult to query for data for multiple users at once. – Edwin Vermeer Oct 07 '15 at 11:51
  • And suppose even if we go for different persistent store how do we handle version migration for multiple persistent store. Then we would have to migrate every store that is created. – user3519594 Oct 07 '15 at 11:52
  • yes, the moment you are activating a store you should check for version – Edwin Vermeer Oct 07 '15 at 11:54
  • hm.. am quite new to core data migration so lets say it happens that user A has a persistent store with version 1.0, user B with version 1.2 and user c with version 2.0 and current version is say 3.0 then could core data migrate each store to a proper version ?. we allow him to take backup of his data to other services and restore from previous backup. – user3519594 Oct 07 '15 at 11:59
  • Well, on app startup you could start a migration of all persistent stores. But thinking of these scenarios... Maybe it's easier to just put all data in one store. Then you only need to add a recordID of the user to each record and you must be really careful what queries you use. Always filter for recordID – Edwin Vermeer Oct 07 '15 at 13:19
  • Yes that is what i was thinking too. But then say another senario arises where no user is logged in to a cloud account so by default our application would start with local so in this records i will have to put say default user ID, now say a user logs in and enable cloud then i will have to update the default values to belong to that user ID i.e quite a big number of update may occur. Or is their any other possible way – user3519594 Oct 07 '15 at 15:37
  • The idea to have a separate datastores is attractive, but there are at least two problems when it is very uncertain to achieve: 1. Fetching the user ID is an asynchronous operation, so before picking the right datastore, we have to wait for the response. In case when the connection is weak or not available, we can't achieve a great user experience. 2. There's a situation when the user uses the app without being signed in to iCloud and then signs back in. In the worst-case scenario, there can be data in both the local datastore and on the server that should be merged. – Andriy Oct 18 '19 at 13:16
  • Considering my previous comment, did anyone come up with an approach to have the best implementation and user experience possible? – Andriy Oct 18 '19 at 13:17