I ran into a small chunk of free time, and I would like to do a significant but hopefully minor refactor job for my app, Baby Pool. Unfortunately the change involves syncing, and when I originally designed the app I did not have the syncing perfected. The adding of guesses to pools involves spagetti logic, which needs to be completely rewritten.
One other change I would like to make involves the removal of guess sync category, “PENDING” unless there are no more guesses left. This is a significant customer request, and I know it was over-thinking the security and control aspect of these guesses. Admittedly so, it’s a lazy feature implementation, but hey! We all make mistakes! This will simplify the UI a bit, but be a small refactoring of the business logic…
So I have two options at refactoring the first problem of the guess sync mechanism.
1) Stick with the creation date, and determinate uniqueness off that date and an additional field like the pool key. I will have to query for a guess of the same creation date, and update it if it exists or add it if its not there. I believe I attempted to do this the first time around, but instead of updating if it exists, I skip it.
2) Go with a more “industry standard” approach of inserting UUIDs for objects in all my tables. Then I would have to track a syncdate that is off the UTFC. And pass around objects from the last successful syncdate. Those objects would all follow the same scheme of the creationDate, but it’s guaranteed unique, and it’s more geared for Core Data and mysql queries: If UUID exists, update, if not, add it.
Either way, I definitely need to track the syncdate using UTC time, I believe originally I set it to the local time. If I add a sync date on the first sync that the server passes down as a UTC time, I will always query off that last sync time and send back all changes. I would much rather be tracking for duplicates off a UUID. So I’ll go ahead and make that change as well.
First thing to do take out the PENDING if the account has enough guesses remaining. From now on, whenever a person makes a guess, it goes straight to Added state unless the guesses remaining hits 0. I will need to keep a balance of guesses, and when there is a negative amount of guesses, I’ll only add the guesses as pending if the user needs to purchase additional guesses. The whole in app purchase strategy may have been a mistake, it’s good that I tried it out, but at this point, it’s probably ok to just remove it completely!
On IOS, creating a UUID is pretty straight forward:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
+ (NSString *)CreateUUID { CFUUIDRef theUUID = CFUUIDCreate(NULL); CFStringRef string = CFUUIDCreateString(NULL, theUUID); CFRelease(theUUID); NSMutableString *retStr = [NSMutableString stringWithString:(__bridge NSString *)(string)]; // If I need to format the UUID to remove that last dash // NSRange lastDash = [retStr rangeOfString:@"-" options:NSBackwardsSearch]; // NSString *retStr = [retStr stringByReplacingCharactersInRange:lastDash withString:@""]; return retStr; } |
