The process of building apps for Glass through a set of RESTful services (the Mirror API) sounds amazing, but many of us still want more. While many developers have been looking forward to the Glass Developers Kit (GDK), where more robust native apps can be created, some of us have been dreaming of what Glass would be like with the full Web.
I spoke with Glass Explorer Adam Singer about his ideas. Adam is a software engineer who embraces the free and open source world of Dart programming. He is originally from Las Vegas and his professional life has been geared towards development of casino games, systems, and inventions. Currently, while living in San Francisco, his personal interests are highly focused on Dart development and the open source community surrounding it. Adam performed a full investigation into the Glass Browser that was added back in XE7:
Adam: “The Primary goal for me (in terms of Glass) is to explore how Dart can play a role in rapid prototyping and development on Google Glass. At first I thought it was the Android Browser cause the user agent is [Mozilla/5.0 (Linux; U; Android 4.0.4; en-us; Glass 1 Build/IMM76L; XE8) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30]. After digging into it more I can’t say for sure its the Android Browser but it shares some similarities. I’d take a good guess that it has some common Android WebKit code. After taking some time to review the Android code base I’m guessing that “WebView*” related Java and cpp files probably play a role in the GlassBrowser.apk. When inspecting Glass from the Android Debug Monitor one can see that “HtmlItemView” objects are used for the Timeline cards.
The GlassBrowser is stripped down and not much is exposed to the user. A large amount of HTML5 and general Android Browser APIs are not available. My background in Android development is limited so most of my research and investigation comes from Android Debug Monitor, log files, and other random ways of poking around on Android systems. When it comes to Dart the quickest way to figure out if something works is by writing a small sample; if it works then it might be supported. If the sample does not work I drop it quickly and move on mainly because Google has not mentioned supporting the browser, its API, or HTML5. Since I enjoy hacking on Dart I just go with the flow and hope enough requests for built-in browser support happen. The Java class that implements the view for the browser is called “WebBrowserWebViewImpl”; I could not find any reference to it in the core Android code base. I’m guessing it extends one of the “WebView” classes that do exist in the Android code base.
Ryan Weaving and I have been hacking at dart for some time now. Since the Breaking Glass Hackathon Ryan has been doing some amazing work towards creating a motion library https://github.com/dartglass/glass_motion in Dart that works on the GlassBrowser. We keep tossing ideas around on use cases and creating samples.”
So, what would Chrome provide that Glass currently doesn’t have?
Adam: “A fair amount, IMO. I’m not on the Glass team, I know little about the internals, all I can do is imagine that Chrome and HTML5 could be an amazing platform to develop against on Glass. It would probably require some additional APIs to be exposed from native interfaces or providers. The downside is we all know Chrome is fast but did not arrive to mobile devices until recently. So full support on something like Glass might just be a research project or not practical from Google’s point of view. There are a lot of good Web technologies that GlassBrowser could benefit from such as:
- Offline cache – Think about pinning an application that is semi cached or can run on Glass offline.
- WebGL – High speed rendering (with a few layers in-between) to the graphics card (or System on Chip in this case).
- Geolocation – geolocation goes hand and hand with anything Glass related.
- WebSockets – bi-directional communications mixed in, this would be a total hit.
- Web Audio API – better processing of audio on device.
I think a case could be made for a lot of these technologies, its hard to cover each one in a short period of time. The downside of Chrome is it might consume more resources than a more native application such as GlassBrowser. The huge upside is UI/UX might evolve much faster if its possible to have quick edit/refresh cycles.”
I’d love to hear from other Glass Explorers in the comments… would you like to see Chrome on Glass or are you happy with the MirrorAPI/GDK options?