The Problem with Mirror

So, two days after being published and posted to the XE community, I’m forced to take Glass Feeds offline. Why?

Google is intentionally limiting the audience of non-native Glass developers by putting a cap on the amount of timeline cards they can push. Any Glass Explorer only has the permissions to push a maximum of 1,000 cards per day, to any account. This applies for all applications from a developer; so if I were to max out my account by offering Glass Feeds to a select few users, I would be unable to develop any further applications.

Why is Google doing this? Well they are keeping that part of it a little quiet. Representatives on glass-community.com have stated that the caps are in place because Glass Apps are currently not meant to be distributed outside of the developer’s immediate network. I think this notion is ridiculous. What they have essentially done is made an art gallery under the promise to showcase all of the local talent, but then proceeded to only put up the paintings of established artists. What is the point of all that Google is doing to try and get developers in on the Glass program if they are just going to turn around and shun all their work?

If this bothers you (and it should, if you dropped $1,500 for a pair of Glasses an expected to see anything other than the core apps offered by Google), I’d suggest you make posts on glass-community or contact a Glass guide about your concerns. I have no doubt that Google will come around and remove the limitations in the coming months, especially when they figure out how the Glass App Store is going to work. The problem is, that isn’t soon enough. This is a critical moment for Glass. It’s out there, there are developers tinkering with them and spending time building applications for them. Fostering this community, not squashing it, is imperative.

As for Glass Feeds, it will be back. I will continue working on it and using it in the background until Google lifts it’s restrictions. Thanks to those who supported it during it’s brief life thus far..

Glass HUD

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:
https://github.com/neonglass/GlassHUD

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.

Proudly powered by WordPress
Theme: Esquire by Matthew Buchanan.