OpenUDID Persistence
thanatos0801 opened this issue · comments
I've been looking at the history of this project and it strikes me that the device Keychain is not being used at all in the current version. This confuses me. While the keychain CANNOT be used to SHARE the OpenUDID across other apps (that's why the UIPasteboard implementation was used), it CAN be used to guarantee persistence across installations when only one OpenUDID enabled app has been installed. Using the keychain as a back-off persistence mechanism removes PART of the "UDID Reset" issue when all OpenUDID apps on a particular device have been removed. If the user then reinstalls any of the previously installed OpenUDID apps, then they get the same UDID back. If they install a DIFFERENT app first, then a new UDID would still be generated, and the code would have to account for that... but this may provide some small additional persistence where there is currently none?
That's a very good point Josh.
Initially Keychain was naively thought to help share across apps; but indeed, that was limited to apps within the same publisher namespace. So the entire logic was rewritten around UIPasteboard.
Now, are you sure that if you delete all apps of a given namespace, the corresponding keychain entries remain???
If so, you are right, that would add even greater stability.
Care to improve the code?? ;-)
I'm positive that the keychain entries will persist across installations, as I've already experienced that with several of my own apps.
Another possibility would be to use a cookie and a hidden UIWebView that's not in actual displayed view tree. This would provide some cross-app persistence that would stick around in the OS independent of the application, although the cookie could eventually be yanked by the user.
I'd probably recommend starting with the UIPasteboard, backing off to the cookie, and then finally checking the keychain. This would provide quite a bit more "extended stability" than just relying on the pasteboard alone.
I wouldn't actually want to impose creating a UIWebView as the overhead is probably too great.
But point taken on the Keychain - great idea indeed.
Will think of adding this time permitting, unless someone volunteers to help out.
The only downside with the Keychain is that you have to link with another framework - but nothing too complicated for most I hope ;-)
Perhaps make the UIWebView an option via a compiler switch... the benefit of using a cookie is that if someone installs a NEW OpenUDID enabled app before reinstalling the last removed OLD one, they still keep the same UDID value rather than generating a new one. I might be able to find a way to access the cookie store without using a full up UIWebView. I may look into it.
Okay... did a little research. Cookies are sandboxed as well, so that won't work as a back-off. I've added the keychain support though, and have sent you a pull request. If you feel so inclined, would LOVE to see attribution to Vora Labs (http://voralabs.com)... but glad to contribute to a much-needed replacement UDID mechanism!
Josh, I'll review asap and will surely merge. At first sight, it looks solid.
It would be nice if it’s totally incorporated in OpenUDID.h/m and not with an added separate file too.
I thought about that... I could probably strip down the KeyChainWrapper class to what I actually used and include it in-line. The extra files didn't bother ME all that much... But I'll work on it.
Sent from my iPad
On Mar 28, 2012, at 8:35 PM, Erik Lindberg reply@reply.github.com wrote:
It would be nice if it’s totally incorporated in OpenUDID.h/m and not with an added separate file too.
Reply to this email directly or view it on GitHub:
#7 (comment)
Okay.. updated the pull request to all be in the OpenUDID.h/.m source files. Really just merged the KeychainItemWrapper into the source of OpenUDID.m... worked quite nicely.