Profile cover photo
Profile photo
Laurence Moroney
181 followers
181 followers
About
Posts

Post has shared content
Thanks to everyone for all of the thoughtful and constructive comments, questions and feedback. We're reading them all, and we'll respond as quickly as we can (while we catch our breath after the excitement of the launch and #io16). In the meantime, we encourage you to use the following channels for information and to share your comments:

* firebase.google.com/support - includes links to a variety of Google and community-sourced support options, including Stack Overflow and one-one-one technical support via email
* firebase.google.com/support/contact/bugs-features - file a bug or request a feature with this form
* twitter.com/firebase - follow us on Twitter for the latest announcements, updates and resources

#firebase
Add a comment...

Post has attachment
Following on from my #Android  tip from the other day, here's another:


Multiple Accounts:
If your app supports multiple account connections simultaneously (like the Gmail user interface shown below), you are calling setAccountName on the GoogleApiClient.Builder when constructing GoogleApiClients. This requires you to store the account name as well as the Google Account ID within your app. However, the account name you’ve stored will be different if the user changes their primary email address. The easiest way to deal with this is to prompt the user to re-login. Then, update the account name when onConnected is called after login. Any time a login occurs you, can use code such as this to compare Account IDs and update the email address stored locally for the Account ID.  

[Google Play Services 6.1+]
String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
String accountID = GoogleAuthUtil.getAccountId(accountName);
// isExistingLocalAccount(), createLocalAccount(), 
// getLocalDataAccountName(), and updateLocalAccountName() 
// are all specific to the app's local storage strategy.
boolean existingLocalAccountData = isExistingLocalAccount(accountID);
if (!existingLocalAccountData) {
    // New Login.
    createLocalAccount(accountID, accountName);
} else {
    // Existing local data for this Google Account.
    String cachedAccountName = getLocalDataAccountName(accountID);    
    if (!cachedAccountName.equals(accountName)) {
        updateLocalAccountName(accountID, accountName);
    }
}

This scenario reinforces the importance of using the Account ID to store data all data in your app. 
Photo

We've had a few questions come in recently regarding Google Accounts on Android, so we're putting some tips together to show you some of our best practices. The first one today is around Unique Identifiers for your signed in users:

A common confusion happens when developers use the account name (a.k.a. email address) as the primary key to a Google Account.  For instance, when using GoogleApiClient to sign in a user, a developer might use the following code inside of the onConnected callback for a registered GoogleApiClient.ConnectedCallbacks listener:

[Error prone pseudocode]
String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
// createLocalAccount() is specific to the app's local storage strategy.
createLocalAccount(accountName);

While it is OK to store the email address for display or caching purposes, it is possible for users to change the primary email address on a Google Account. This can happen with various types of accounts, but these changes happen most often with Google Apps For Work accounts.

So what's a developer to do? Use the Google Account ID (as opposed to the Account name) to key any data for your app that is associated to a Google Account. For most apps, this simply means storing the Account ID and comparing the value each time the onConnected callback is invoked to ensure the data locally matches the currently logged in user. The API provides methods that allow you to get the Account ID from the Account Name. Here is an example snippet you might use:

[Google Play Services 6.1+]
String accountName = Plus.AccountApi.getAccountName(mGoogleApiClient);
String accountID = GoogleAuthUtil.getAccountId(accountName);
createLocalAccount(accountID);

[Earlier Versions of Google Play Services (please upgrade your client)]
Person currentUser = Plus.PeopleApi.getCurrentPerson(mGoogleApiClient);
String accountID = currentUser.getID();
createLocalAccount(accountID);

This will key the local data against a Google Account ID, which is unique and stable for the user even after changing an email address. 

So, in the above scenario, if your data was keyed on an ID, you wouldn’t have to worry if your users change their email address. When they sign back in, they’ll still get the same ID, and you won’t need to do anything with your data.

My book 'The Fourth World' now available on the Play Store!

https://play.google.com/store/books/details?id=k5N_BAAAQBAJ
Add a comment...

Post has attachment
Building a Cloud-Powered Android Wear application -- full walkthrough, source code and more at https://ljpmblog.appspot.com/?p=99

Post has attachment
Part 3 of my series on learning how to build cloud apps with App Engine and Python. 

Enjoy!

https://ljpmblog.appspot.com/?p=41

Post has attachment
Part Two of my series on Learning Python through building a CRUD app on App Engine. Enjoy.

https://ljpmblog.appspot.com/?p=31

Post has attachment
Hi Everyone -- just wanted to introduce myself. I'm Laurence, a developer advocate here at Google, working on the cloud platform. Right now I'm working on a series of tutorials for folks who want to get started in building Python apps on App Engine, by stepping, in detail, through a simple CRUD application. 

First post is here: 
https://ljpmblog.appspot.com/?page_id=51

Would love comments and feedback. Or if there are any subjects you would like covered, please let me know! :)
Wait while more posts are being loaded