React Native + Expo + Google APIs (Rant)

...What a blasted racket! 😵 So, bouncing off the last time I tackled actually writing to a Google Sheets spreadsheet, I did some research, and according to Stack Overflow answers this and this, just having an API key won't work if I actually want to write data to the spreadsheet. The documentation for the Google APIs sure misled me, and apparently a few others, by giving the impression that OAuth 2.0 and an API key were two equally usable methods of authorizing with the Google APIs. This could have been avoided, probably, if the Reading and Writing Values page had a link, right at the top, pointing to Authorizing Requests page! So, now it's time to get an OAuth client ID for my app, which for clarity, is using the Expo SDK, but will be a standalone Android App, one I can submit to the Google Play Store.

When figuring out how to do something in React Native, I've learned to check, in order, the React Native docs and Components, then the Expo SDK Docs, then the rest of the Internet, including the NPM package repository. Turns out, the Expo SDK provided a Google api, expressly meant to get an OAuth access token, which I can then use in my HTTP operations to actually add and update rows to a spreadsheet.

There are plenty of instructions spread across multiple different projects, so I won't repeat information likely to be outdated in a few years, but as like a hierarchy of the things I needed to do to get where I am now, I give you this dependency list below:

  • accessToken (to actually modify spreadsheet data)
    • scopes (what the token wants to do, just ["https://www.googleapis.com/auth/spreadsheets"])
    • androidStandaloneAppClientId (a parameter to Google Expo SDK)
      • A Google APIs OAuth 2.0 client ID (Love how Expo apologizes for these requirements 😄)
        • A new Google APIs Project
        • ...with the Sheets API enabled...
        • ...and a standalone app package name
      • An Android OAuth Client ID (yeah, this is NOT the standalone setup I want - this would still be running through Expo and opening a web browser to ask for permissions, but this is required before getting the standalone client ID)
        • Some admittedly straight-forward steps
        • Setup the OAuth 2.0 consent screen
          • A Google group, so I don't reveal my personal email. Even gave it a good name! Figured out from StackOverflow
          • (Eventually, when I publish the App) A Privacy Policy??? Required?? Do you know how basic this app is?
        • GOT IT! AHAHAH.. Ahem, sorry, just some emotional payoff
        • Implement usage of it in the app to make sure it works
          • Ask for consent when the app starts up
          • Pass the accessToken correctly in the Authorization header - Google Docs Page here
          • Get a new API Key because my old one is from a different project 😖
          • ... At long last, the spreadsheet receives a new row from the app!
      • Info for a standalone Android app, documented here
        • The exp tool for building the standalone app using the Expo SDK
          • An Expo account registration
          • The project "slug" name of the published app
            • ...from create-react-native-app documentation, exp publish
        • ...

... At this point, I think I'll put this post on hold until I actually finish the final stage. I have, at this point, achieved part of my objective to actually modify spreadsheet data, so testing and development can continue, with this obstacle out of the way. I feel confident enough that a path does exist to get this working in a standalone app that doesn't require the Expo app installed on users' devices.

The Wikipedia article for OAuth has a controversy section indicating that at least one of the original authors for the OAuth 2.0 standard removed themselves from the project because they believed that the standard was essentially adding too much complexity for not enough benefits besides more consultation service sale opportunities. Whether this is actually the case or not is beyond my current knowledge of the (truthfully) complicated problem of securing access to a Google-like service's user data. What I do know is that in my experiences of learning HTTP APIs (which I have spent multiple years doing), the Google Spreadsheets API OApth 2 authentication setup process was one of the most complicated HTTP API setup processes that I've done so far. Mission accomplished, but just for writing data to a Google spreadsheet... Wow. I'm hoping things become more simple in the future, though to be honest, not very optimistically.