My first app for Glass is “Glass HUD” – an application that displays readouts from sensors onboard Glass and your phone. With a little trickery, I managed to get this data to display on a pinned card on Glasses native timeline. You will need to use Launchy or some other Native App Launcher to launch the application but once it is up and running interfacing with it should be purely native.
Here is a video of the app working:
In order to get more than just the compass and accelerometer sensors I packaged with the Glass version, you will need to load a companion app on your phone. This app, which I will release on the Android Market in the coming months as “Applied Companion” will service not just this app, but all of my Glass apps that interface with your smartphone.
You can view the source code and build the app for yourself now:
Here are some notes on the code:
The main functionality of the app is encapsulated in a service, specifically GlassHUDService. This service aggregates sensor data, packages it into HTML viewable on the timeline, and pushes updates to the timeline. For the Android developers reading this, really the only code that might be new to you will be found at the bottom of GlassHUDService.java. It’s here you will find the TimelineUpdater class that is responsible for writing to the timeline.
I think I will be re-using this service-based model a lot with Glass Development. Accessing native apps, even with Launchy (see +Mike DiGiovanni ) is kind of a pain since you completely remove yourself from the Glass ecosystem and cannot do anything but access your app. By keeping your UI in a card with a backing Service that updates it and communicates with it, you are able to still use Glass as it was intended while your app runs.
It turns out you can update timeline items continuously and the results will show up pretty quickly in the main UI. I am seeing about a 2Hz update rate – not good enough for an animated GIF, but good enough for a lot of other things .
One issue I ran into early on was if your app does not record and re-use the TimelineItems it creates early on, you will end up with a glass timeline cluttered with cards from your app, which is definitely not desirable. I got around this by recording the ID of the first card I push in a SharedPreferences structure then fetching that card every time the app is launched from then on. I also put the card in a “disabled state” when the app is not running so it is not confusing to the user. Another option would be to delete the card after you use it.
The main activity for this app provides the users with some switches via classic android buttons. Classic android UI’s are still relatively navigable with Glass so this works fine. This was necessary for this app since the service consumes considerable CPU time when it is running (constantly polling bluetooth/sensors) so I needed a way to disable it. I can see other apps registering themselves to startup when Glass is powered on and run completely in the background so third party launchers like Launchy are not even necessary.