Google Glass: GDK vs Mirror API
In the development community there are always debates that fire up when a new technology takes the stage: .NET vs Java, SOAP vs REST, iOS vs Android, Hybrid vs Native, and with Google Glass there is not going to be any exception. A new toy for developers has been created by the brilliant minds at Google and so developers begin to think - “Well what can I do with this new toy?” On one corner we have Google Glass Mirror API, a RESTful based API that can be developed using any of the supported languages: Go, Java, Python, PHP, .NET and Python. In the other corner, we will have the Glass Development Kit (GDK), which we do not know enough about yet, only that we will have access to the hardware on the device. So which one will deliver the best glass experience?
Lets start off by highlighting the Glass specs (Reported by Tom's Hardware).
- Runs Android 4.0.4 ICS
- OMAP4430 45-nm SoC from Texas Instrument
- IVA 3 Hardware accelerator
- ABE processor
- 682 MB of RAM
- 5 MP Camera
- 720 p videos
- Bone conduction transducer for audio
- Wireless 802.11 b/g
- Bluetooth Connectivity
- 12 GB of usable memory, synced with Google cloud storage. 16 GB Flash total.
So why are the specs relevant to this argument? Well lets take a look at what Mirror API allows you to do, so that we can revisit these specs.
WHAT MIRROR API CAN DO:
- A developer can develop a webapp that sends notification to one or more glasses via the Google App Engine to create Timeline items or cards. These can be in the form of a menu or an individual card. Timeline cards are the way the user interacts with glass. They are very simplistic cards that appear on the Glass screen which the user can tap, swipe left or right.
- The content can vary from images, html pages (subset tags supported) or videos. The API provides the capability to insert, update, read, and delete timeline items from a timeline.
- The API allows for subscriptions to be made by the web application, so that it can receive notifications for when the glass user interacts with a timeline created or their location is updated.
- The API allows to render maps using timeline cards.
- The API allows to share content with contacts or glassware.
So in a nutshell it is a very sophisticated content delivery system. So this is really great, and we can probably imagine several applications that would use this API for delivering content for news, blogs, location based content, etc. However, although it is a pretty exciting new way to deliver content there are several things developers can not do with Glass Mirror API.
WHAT MIRROR API CAN NOT DO:
It cannot access any of the hardware or sensors that come with google glass as specified in the specs.
It is a cloud based API, so Glassware built using Mirror API can only be used while the user is connected.
It cannot launch a native application on glass or on the device.
It doesn’t provide access to any graphical API such as OpenGL for gaming.
It doesn’t allow to run an applications that launch at boot-up.
It doesn’t provide access to persistent storage
It is unclear what the GDK will look like once it is officially released by Google. However, Google has already encouraged the development community to use the Android SDK for building native applications. This gives developers access to the NDK, OpenGL, and basically all the native features available on Android, with exception that users will interact with the application differently.
Some developers are concerned on how the GDK will impact the Glass experience. In the Glass Framework Throwdown moderated by Jason Salas, some comments were made on how the GDK will impact the Glass experience negatively. Some of the concerns included: creating applications that will eat up the battery, losing the simplicity of Glass with access to APIs like openGL, and inviting poorly written native applications into Glass that will slow down the device. But, considering the hardware specs of the Glass, I believe it should go without saying that a GDK is very much needed. However, what restrictions will the Glass Team apply to avoid developers to get carried away?
At Google I/O in the Fireside Chat with the Glass Team, Charles Mendis, Glass Software Engineering Director, indicated how the Glass team is looking on to the development community to help shape what the GDK will look like. This makes this debate all the more important because the development feedback will help create the GDK.
In conclusion, which framework should developers bank on in order to provide the best Glass experience? I do not believe there is a silver bullet. I believe these APIs will be intended to solve different types of problems and should be look at as such. Each developer will just have to make sure to follow the design principles of Glass irrespective of what API they use.