I have a requirement in which locally created events have to be synced with sever synchroniously. To explain this briefly lets consider this scenario, there were two events occurred in the offline app called A and B here A > B. In this case B should sync only when A is completed its sync.
To fix this I must have an extra attribute in my entity to identify which is created earlier. This attribute can maintain either created time or any incremental number.
Here only i am facing some clarifications
Solution :1 Based on created time
If I maintain created time in that attribute, Will it be proper for below scenario
Lets say I created on event “A” today then I changed my device’s date to previous day’s date and then I am coming back to my app and creating an another event “B”. Here which one will be earlier? if app says “B” is most recently inserted object then there is no issue I can stick with this solution itself otherwise I need to move to some other solution. Is there any optimised solution to find inserted order by maintaining created time?
Solution :2 Based on incremental number
I believe core data does not provide any auto-incremental id so we need to maintain it manually. If so what would be the better approach to maintain the maximum assigned value? Will it be good if I store the maximum assigned value in NSUserDefaults? Whenever app creates an event the value will be fetched from NSUserDefaults and +1 will be added and then I will assign final value to the event. Is this approach proper one? or else please guide me if you know any better solution
There is no auto-incrementing number built into Core Data as that is more a business logic specific item. However, it is not difficult to implement.
You can store the last number used in the metadata of the persistent store. During your insert, simply increment that number, add it to each entity as you go. When you are done inserting, update the number in the metadata.
That is how Core Data updates its own insert numbers for the objectID.
The app I'm writing will let people store several photos, and associate them with a single object.
I thought I would use CloudKit, to store these images, as CKAssets.
In CloudKit, besides the other property-list types, I can create a CKAsset, and attach a file to it (in my case, a JPEG). I can also attach an NSArray of any of these types, including a CKAsset.
My users might send up 5 images per object, or it may be 30... who knows.
Just wondering if someone has come across a situation like this, and seen drawbacks to this approach. (vs, say, creating separate CKRecords for each image, and adding a reference to another CKRecord, for instance).
Fetching a CKRecord with multiple CKAssets could take considerable time to download. You would not have any control over it. If you store each assets in it's own CKRecord with a CKReference to it's parent record, then you could query those and you would be able to see them coming in one by one. Besides that, are you sure that you always need all the CKAssets when accessing the main record? If not, then it would be a waste of bandwidth. I would advice a separate record for each asset. Then you could also add an assetType field so that you could distinguish the assets if you need to.
My app has it's own sql database with let's say 2000 rows.
I know that in future I will add some new and delete some old. Each row got prioritet parameter that changes in order of user interaction.
I want to store all prioritets locally so my future app updates would not erase them.
So the question is what is the best way of doing that? Remember that I will need fast access to those prioritets in future and they must be easily mutable.
I have records that are added, updated. Then sync them with server.
According to server response, if one of them fail to update, I would like to have that NSManagedObject to previous value. As I research, UndoManager works as stack, so I can't find any record with Id and undo that record, am I right?
And finally, what would you suggest for this issue?
You could track your objects by introducing your own ID attribute and syncing that with the server. I think this is a solid and robust design - I have used it many times without problems.
Apple does provide an objectID with each managed object, but this is really meant to ensure consistency of data across different managed object contexts. I would not recommend "abusing" this ID for external systems.
Your server could provide the old values (along with the message that it was not updated) and you could write that back into your Core Data store, finding the record using your ID attribute. For more granular change and update management, you could even use a time stamp attribute.
thank you for taking the time and interest reading this and hopefully helping me out.
I need an unique user identifier for IOS, and what I mean with unique user identifier is a unique string that Apple provides that is unique for user not device, meaning that it will stay the same across devices. I thought about the Apple ID or something like that, but it´s not possible, because Apple does not provide it(at least not that I know of), but I want something similar to that.
It cannot be the UDID, because(besides being deprecated) it´s not persistent across devices. I want this in order to authenticate a user, without the user having to login, or signup. It is possible to do so, because some apps do so. I didn not log in or anything with another device, but it authenticated me. I had thought it was with the Apple ID, but that´s not possible to do.
I checked this answer: iOS unique user identifier. And it seems that it might be the solution, but I don't quite get it, as I don't see how it would be unique to every new user(being able to distinguish between multiple users, and the same user, but on different device).
I really appreciate people reading this and trying to help.
Thank you
PD: I use Titanium´s Appcelerator, not Apple´s IOS SDK or anything like that. But it´s not that important, I just want to get the process to be able to do it with Titanium's Appcelerator
PS: NOTE:
Thank you for answering and so fast!. I have read it many times and I just don't get it. Could you guys help me understand it a little bit better?
The way I understand it is this.
1.-Create an UUID(changes with every installation)
2.-Store it to the Keychain(As far as I know, the values saved on the keychain are local to the device) with a default service(I think Ill put it with the application's id-com.bla.bla-), and also a default account, I think Ill leave it as "users".
This will all be local, so every single installation will do this, with a different UUID for each installation(not necessary every user)
3.-Save the UUID to the NSUserDefaults.
4.-Save the UUID to the Cloud's public data store.(The UUID in the Cloud´s Data Store, Keychain and NSUserDefaults should be the same)
So, if 5 installations are run, the Cloud´s Public Data Store should be like this
An Array of 5 values:
[
XXXX-EEEEE-FFFFF,
SFSDFFWE-WERW-SDFS,
XXXX-XXXXX-XXXXX,
ZZZZZ-ZZZZ-ZZZZX,
XZXZZX-ZXZXZXS-ADADS
]
5.-All this will be executed every time you run the application, checking first if there is a value stored on the public cloud store. Here´s where I am confused, how will a different device know which UUID is yours? I mean, there are 5 different UUIDS to chose. Maybe it´s not supposed to be saved on the public data store, but on the private data store, but for that you would need to also identify each user. This is where I get so confused.
If there is no UUID set, execute the last 4 steps.
So, I get confused on the 5th step, most people understand that solution, without any more explanation, so I must be ignorant in the way something works, maybe the cloud services? I think the problem is that maybe I'm not understanding how the iCloud works, and how it stores it´s values. I just don't get how the 5th(random number, it might be the 2nd or 2000th) device of X running the app, will know that the UUID XXX... is the UUID of user X, and not the UUID of user Z.
Thank you again for answering so fast, I thought maybe I would have to wait a couple of days, not a couple of minutes. Forgive me for my ignorance, I'm kind of a noob on this matter, but I would like to learn. Been stuck on this problem for days
The answer you referred to is the correct way to identify your users. The solution is to save the value of that identification called a UUID (Unique User ID) - as opposed to a UDID (Unique Device ID).
The only down side to this of course for you as a developer is that the user could delete and install the app again and have a different ID.
As Daniel said, the UUID is the correct way to identify your users. I just want to add on this; you said that
I dont see how it would be unique to every new user
Well, accordint to this Wikipedia article:
Randomly generated UUIDs have 122 random bits...only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs.
So you can be pretty sure that the UUID will be unique to each user.
Additionally, the MAC address is based off of the MAC address of your ethernet card, the timestamp, and some other miscellaneous information. This adds to the uniqueness of the UUID as according to this question on Superuser:
[MAC addresses] are reasonably unique.
The first 3 octets define the manufacturer.
The last 3 octets are usually generated at the time of PROM burning. It's up to the manufacturer how they do this.
That obviously gives 16,777,215 possible unique MAC addresses per manufacturer. That's quite alot, so the manufacturer shouldn't re-use one.
So basically, the UUID adds an additional degree of uniqueness to the MAC address.
In summation, for your intents and purposes, the UUID would be perfect.
Hope this helps!