Google glass from a developer’s point of view

Recently, I got access to the long-awaited Google Glass glasses and started writing my own application for them.
All I knew about Glass was that it was an Android device, which I needed to connect through the Android Debug Bridge and run my programs.

It turned out wrong!

There are already enough reviews of the points themselves and their fillings, I want to tell you a little what the glasses are from the programmer's point of view, and how the correct program should work for them.

Of course, the Android program will work, well, it's better not to write it (at least in the near future), and this is why ...
')
Everyone knows that the glasses mate with the user's phone via Bluetooth and receive Internet and GPS from him, and also that through glasses you can answer calls and send SMS.
It may seem that the glasses are something like a SmartWatch, a kind of addition to the phone, but this is an independent device that only needs the phone as an external control device and a 3G modem.

What are not the glasses, and what they can not?

- Glasses do not complement the phone and almost do not know anything about it, in fact they implement the BT headset profile and take the call just like any other headset, the glasses do not even know how to show the contact name (unless of course this is the contact of the glasses themselves, but this later). By the way, the headset of the glasses turned out not the best, everyone notes the "echo" in the handset and the low volume of the speaker through the glasses.
- Points do not take any (almost) data from the phone, even if you put on them the proprietary program MyGlass (available only in the USA).
- On glasses you can not run the usual android programs, except through ADB. That is, there is no way to say “ok glass let's play doom” and get the game.

What can points?

- They can show the tape (timeline) of the cards. The tape “infinitely” is a thing of the past and contains all actions performed (made a call, photo or note) and notifications in chronological order.
- They may have "contacts." Contact in the understanding of points is either a person (phone number / email) or an application (glassware) to which you can share regular cards. As soon as the user selects the Share action on the card, he is shown a list of available contacts that can be scrolled one by one. Apparently, that is why glasses do not store a full contact sheet, it would be impossible to navigate through it.

How to work with it?

Formally, you can write a standard android application, fill it with glasses via ADB and post cards using the Timeline API directly, but the user will have no control over such a program. The correct option in the understanding of Google is the Mirror API (https://developers.google.com/glass/v1/reference/).
You create a web application that requests access to points through OAuth, from now on you are allowed to post cards in the timeline of the user and create contacts. In addition, if there is a return address (that is why we need a web application), you can subscribe to notifications from points (more on that later).

What can cards?

- The card can be plain text or provide advanced content (html, pictures, video, maps). The content can be long and paginated, or even bundled, then you simply group several similar cards into one, and the first one is a cover. You can attach your layers with the route or interesting points to the maps, the API will overlay the layers and show the finished picture with glasses. Here are examples of cards:



Card with a map and an additional layer of the route


- The card may have an action menu. By default, nothing can be done with the card, it cannot even be deleted. But the creator of the card (your application) may allow you to perform a series of operations on it. There is a standard set of Reply, Delete, Share, Read aloud, Voice call, Navigate, Pin, Open URI, Play Video. In addition, you can create any of your menu items. Here the menu will already generate notifications for your application.

Share menu over card

What notifications are available?

- Notifications about actions on the card: when the user does something (selects any menu item), you will receive a notification with a unique card identifier and a description of the action. Notifications arrive at the specified Respond URL, in the form of a POST request, which must be answered with code 200.
- Notifications about moving points: if you subscribe to Location updates, then once in 10 minutes you will receive a notification about the last known location of the points (or rather the connected phone, because your GPS does not have glasses).

In addition, the glasses are equipped with a number of sensors: a touch panel, a camera button, turn sensors, accelerations and a compass, all of which can be accessed from native apk applications. The touch panel does not give coordinates, but tells the program about gestures: svayp, tach, svayp and tach with two fingers. On these gestures and on the signals from the sensors, you can build interaction in the native application, for example, the integrated points browser can navigate the page, following the tilt of the head.
If there is a desire to post something from the phone to the glasses, then the best way is to log in via OAuth, without specifying the callback URL and simply create cards via the API (the application on the phone cannot receive notifications for want of its own URL). This option is suitable for programs that do not imply a special reaction to user actions (reminders, news, etc.)
The IPA of points is developing rapidly, and probably there will soon be an easier way to interact with glasses, but the cards are good because they don’t load idle glasses (the battery is not the most powerful in them) using a single communication channel. All processing also falls on the server part, additionally unloading the power of the device. In general, in the current form, glasses are, first of all, a means of obtaining important information in real time, and not a platform for games or complex applications.

So, even if you do not have points yet, you can already think about what the existing interface could be useful for your program.
P.S. For those who want to learn about the glasses themselves, it’s better to start from the official page , and for those who are eager to try writing a smartphone application you should start from here (just remember to sign it with the correct key and register in the Google console ).
P.P.S. Thanks to Weezlabs for the new device.