The CommonsBlog

No Unnecessary Accounts, Please

The iosched sample app is a fine bit of engineering and a useful source for mining various Android development techniques. However, first and foremost, it is a production app for the Google I|O conference. That limits its appropriateness as a template for other apps, even apps for other conferences.

Notably, when you run the app, you are immediately required to supply a Google account, and if you do not do so, you cannot enter the main portion of the app.

This is a regrettable decision by the authors of iosched. There are many features of a conference app that should not require a Google account, such as viewing the list of sessions and viewing details of a given session. Associating a Google account with the app should be optional, not mandatory, even for Google I|O.

That being said, you needed a Google account to attend Google I|O in the first place. Hence, while forcing you to supply an account to iosched is regrettable, it is at least somewhat understandable… for Google I|O.

It is not understandable for conferences run by other groups.

And, for the vast majority of Android applications, forcing the user to supply unrelated account credentials to use the app would be an exceptionally bad idea.

Note the use of the word “unrelated”. It makes perfect sense for the Evernote app to require an Evernote account. It makes perfect sense for the Remember the Milk app to require a Remember the Milk account. In those cases, the apps are dedicated mobile front-ends to what, at its core, is a Web app. And, the accounts in question are highly relevant to the apps.

You are welcome to prompt the user to supply an unrelated account on first run of your app. But please provide a “Skip” option, with the ability to supply (or replace) the account information later on from elsewhere in the app, such as from a PreferenceActivity. If the user elects not to provide the account, simply hide or disable UI options that require the account (e.g., drop the +1 button if they do not provide a Google account), or perhaps just lead the user back to the “provide the account” screen at that point before continuing.

More importantly, when repurposing somebody else’s code, do not just blindly adopt it en masse. Instead, think about the app’s behavior, decide whether or not that behavior is appropriate for your user base, and change things as needed.

Stuck on an Android problem? Subscribers have access to live office hours chats with Mark Murphy, to help you work through your challenges!