Deployed Google Glass Quick Start Project Demo on App Engine

by Mike Levin SEO & Datamaster, 09/19/2013

Wow, so I haven’t really done any meaningful coding yet on Google Glass, but I’m the bloodhound on the scent now. Following the scent led me through a distracting but necessary OAuth 2 practical refresher. I now understand OAuth 2, which is so important. Refresh tokens never expire. When combined with the client secret, they are very valuable. When refresh token and client secret combine, you get a new access token. When you’re using the client library, token refreshing is automatic. OAuth 2 authentication, while it appears reasonable by hand, is probably better accomplished with the OAuth 2 client library.

Once you have the access token, you use an authorization HTTP Header:

GET [/task/v1/lists/@default/tasks] HTTP1.1 Host: www.googleapis.com Authorization: Bearer [blahblah3]

It can also be passed in the URL with:

GET [/task/v1/lists/@default/tasks]?access_token=[blahblah3] Host: www.googleapis.com

This is plain text, but it gets wrapped in SSL for security.

You can use multiple scopes with a space-delimited list.

Okay, I feel I got what I need. It’s 2:15 PM. I’m going to have to take a sanity-walk now. But you have MOST of what you need in your mind right now… but not all. Having a server holding an access token able to make calls to the Mirror API is… what? Like half the puzzle? We’re going to need access to a gmail account too! And that’s likely to be a different user… but that can be hard-coded! We don’t need OAuth2 for the server’s ability to perform email tasks.

I would like for a Google Glass app (card in the timeline?) to have access to the camera, but it seems that the “Add a cat to that” example shows a different philosophy that puts the user very much in control of the camera, and what happens to pictures. Sending pictures to a “Contact” which is really an app seems to be the suggested workflow, especially since sending a picture can trigger a notification within the Mirror API, so your email-aware server app doesn’t have to do mail-check polling. Apparently, sending a pic to a content could trigger an event so that you don’t have to wait for mail polling. Hmmm.

https://developers.google.com/glass/stories#add_a_cat_to_that

A plan forms.

Thu Sep 19 16:51:18 EDT 2013 Okay, my Google Glass Hello World success has greatly improved. Instead of using the Quick Start Project Demo located at:

https://glass-java-starter-demo.appspot.com/

…I’m using the one located at:

https://[myappspot].appspot.com/

It’s the SAME THING, but I pulled the code from github at:

https://github.com/googleglass/mirror-quickstart-python

Once I pulled the project, I did the steps outlined on:

https://developers.google.com/glass/quickstart/python

…in order to get the OAuth 2 registration all lined up with with an actual app deployed on the Google App Engine. I feel some level of success, but this is still all kinds of funky. I had to do a deploy actually from the GoogleAppEngineLauncher, and not the command-line way, because that’s the only way it would prompt me for my Google login, which is necessary to deploy an app. Hmmmm. Where does this leave me? How tied to the GAE is this really? What files are in there?

Michaels-MacBook-Air:mikelevinux miklevin$ ls -la total 96 drwxr-xr-x 19 miklevin staff 646 Sep 19 16:40 . drwxr-xr-x+ 30 miklevin staff 1020 Sep 19 16:40 .. -rwxr-xr-x@ 1 miklevin staff 2563 Aug 30 08:44 CONTRIBUTING.md -rwxr-xr-x@ 1 miklevin staff 862 Aug 30 08:44 LICENSE -rwxr-xr-x@ 1 miklevin staff 238 Aug 30 08:44 README.md -rwxr-xr-x@ 1 miklevin staff 641 Sep 19 16:39 app.yaml drwxr-xr-x@ 4 miklevin staff 136 Aug 30 08:44 attachmentproxy -rwxr-xr-x@ 1 miklevin staff 281 Sep 19 16:33 client_secrets.json drwxr-xr-x@ 10 miklevin staff 340 Sep 19 16:25 lib -rwxr-xr-x@ 1 miklevin staff 1141 Aug 30 08:44 main.py -rwxr-xr-x@ 1 miklevin staff 8618 Aug 30 08:44 main_handler.py -rwxr-xr-x@ 1 miklevin staff 1062 Aug 30 08:44 model.py drwxr-xr-x@ 4 miklevin staff 136 Aug 30 08:44 notify drwxr-xr-x@ 4 miklevin staff 136 Aug 30 08:44 oauth -rw-r–r– 1 miklevin staff 65 Sep 19 16:33 session.secret drwxr-xr-x@ 4 miklevin staff 136 Aug 30 08:44 signout drwxr-xr-x@ 6 miklevin staff 204 Sep 19 16:25 static drwxr-xr-x@ 3 miklevin staff 102 Aug 30 08:44 templates -rwxr-xr-x@ 1 miklevin staff 3259 Aug 30 08:44 util.py

Okay, this looks like 7 folders with 96 files total. Is this overkill complexity? Clearly main.py is the equivalent of the index.html (the program that gets run when you hit the app URL). I did my non-Glass Hello World experiments with the GAE on main.py. Looking inside that file, we see that GAE’s equivalent of web.py or bottle.py is webapp2. It’s a WSGI web framework. GAE would support pretty much any Python WSGI-speaking framework, but they include webapp2 by default.

I am peeling away the layers here between here and being an effective Google Glass developer. Methinks I feel a lot of unnecessary overhead. Methinks there’s a bit of mystery and perhaps obfuscation here by starting with a full project pulled down from github that’s keyed top GAE and webapp2. Methinks it just may be time for a new version of Levinux very much keyed for exactly what I need to do here.

That’s not over-complicating it, right? It makes it interesting, and lets me understand things in a bottoms-up sort of way. And the daily work journal entry documenting that process WILL BE AWESOME!