> I was considering a solution similar to yours, but I wasn't going to force a password - I really hate being forced into creating a new
account wherever I go. The sooner the world gives over to ubiquitous OpenId the better. I keep hovering around adopting OpenId, but I have usability concerns about how neatly one can mesh web based auth into an android app. I'm also not aware of any effective protection against spammers creating mock providers to flood apps with fake accounts, at least none that aren't burdensome to the users. Though these concerns may simply be the result of ignorance on my part. I was planning on either using the IMEI or a randomly generated number (or a combo of both) as the unique identifier. I'm simply using a number generated from a SecureRandom and persisted in a private SharedPreferences. If the user installs the app, then uninstalls it and reinstalls it, that will look like two devices in the system I'm developing. I'm not really interested in the phone's identity across installs since I only use this to tie authentication tokens to the device. The anonymous account is allocated a separate randomly generated username (that the user never sees) until the user chooses to provide one. Tom,. when a user installs your app a new device, how do you plan on linking their new anonymous account with their existing account? That's a good question. When the application first runs the user is given three choices: Login, Register and "Later". Hopefully registered users will choose Login, some users may have already decided that they want to use the app and will register immediately, most I expect will skip it until later, some of whom may already have accounts. Hopefully, an existing user will log into their account before a new anonymous account is created for them on the new device, or at least before the anonymous account has accrued any 'valuable' data. To cope with the situation where this does occur, all the local app data that needs to be shared with the remote server gets tagged with the server account that 'owns it' (ie. which account the user was logged in under when they created the item) and users will have the option of basically pooling all the data on the device into one account (though I'm not sure whether to invest effort into making this intelligible to the user - I may just make it available discreetly and guide users to it if they encounter problems). As I said, it's a fair bit of work, but I think its worth it in my case since (a) I'll be using this system across a number of applications and (b) I actually have a fair bit of user generated content that my applications will need to synchronize with the server, not just highscores. Tom. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
