Overview of the Mirror API - Develop - Designing and Developing for Google Glass (2015)

Designing and Developing for Google Glass (2015)

Part III. Develop

In this final part, we examine the steps necessary to put working Glassware together, both as a cloud-based service with the Mirror API and as an installed application with the Glass Development Kit. For Mirror Glassware, the chapters walk you through the sequence of decisions to be made for setting up a new project, obtaining authorization credentials, establishing communications with Google, working with menus, managing subscriptions, and sharing resources with entities. We conclude with some thoughts on how the Glass community and industry at large is already applying Glass technology in real-world scenarios.

Chapter 7. Overview of the Mirror API

This is the chapter in which we start to detail how Glassware works with the Mirror API and how to build it. This is an process that has several moving parts and a few different technologies, and requires several decisions to be made in a particular sequence, so we use this discussion to introduce the mechanics of the Mirror API framework and how you make it work for you to architect cloud-based services for Glass. So welcome!

Again, we emphasize that we’re taking things a step further as part of our dedication to teaching you how to Think for Glass: we don’t merely want to show you how to write Glassware, we want to show you how to write great Glassware. And as we’ve demonstrated thus far, such a talent for maximizing the platform involves amassing deep knowledge and embracing pragmatism.

So, as this is the first scene in the third act of our three-act play on Thinking for Glass, let’s wax pessimistic for a moment and get some housecleaning duties out of the way first.

This isn’t going to be an exhaustive dissection of the Mirror API’s various method signatures and expected parameters. The online documentation does a fantastic job of that already, and like Glass, is changing all the time. Our goal is to arm you with a weapon that has far more shelf life and help you understand the documentation and the Glass environment. And appropriately, this is the level of abstraction that the Mirror API provides you with that you’re going to need to embrace.

Let’s say that again because it bears repeating (and we’ll repeat it again): we want you to understand what the Mirror API and Google’s documentation is talking about, not just provide you some cookie-cutter code fragments. This isn’t a read-and-rip section—it’s a lot more.

Life on the Server Side

With its development model based on client-server web programing, the Mirror API lets us use tried-and-true coding techniques that provide several advantages over native development:

Incredibly flexible and very easy to get started with

You can use practically any programming language, developmental framework, and hosting environment you wish. The usual suspects pop into mind, so you can use the Java, PHP, Python, Ruby, Perl, Go, Dart, C#, VB.NET, Node.js, or even Cold Fusion know-how that you’ve accrued over the years, along with their respective frameworks for desktop, console, web, and mobile platforms—anything that speaks HTTP. You can even change them later as your Glassware evolves! If it can run on a web server and if it can issue web requests, you can use it for your Glassware. That’s just about every programming language these days. There are some requirements you’ll need to follow (such as having a public HTTPS URL), but they’re not onerous requirements. Although we’ll be talking about Google App Engine later, this isn’t required, and if you’re familiar with Tomcat or IIS with .NET (or any other web application environment), you should be able to use them with ease. Play to your strengths and use what you know!

Rapid application development

The compile-debug cycle is shortened because you don’t need to load the app onto an emulator or device.

Rapid application deployment

Unlike native apps, you won’t need to push an entirely new version of your Mirror API Glassware and have users download/install it. Being web server–based, you need only save the changes, which then become effective the very next time the system automatically syncs. It is highly test-friendly—Glassware is heavily event-based (which we’ll discuss shortly), and each event naturally translates into unit and regression tests.

Easy debugging

Tests are a good start, but sometimes you need to debug what is going on. The Mirror API provides ways to query for the state of every event your application has access to. We can do at least some design, testing, and debugging using our own HTTPS commands with our own JSON and HTML content. We can either send test events to Google’s servers, to see what it may look like on Glass, or we can mock up events to send to our own web hooks.

Measurement

Web analytics have become highly evolved over the years. We can leverage these tools for our Glassware.

Battery-safe/processor-friendly programming

Because information is delivered in quick cards, there’s very little, if anything, you can do with the Mirror API that will cause the device’s battery to rapidly discharge or the processor to work so excessively the headset heats up.

While the Mirror API will handle a tremendous number of use cases, it can’t do everything. So keep in mind some of the following pitfalls about the Mirror API:

Real-time data delivery

The whole concept of “real time” can be a misnomer these days. Glassware that uses the Mirror API operates as a low-latency vehicle, which is to say it distributes its payload to its intended target on the order of a few seconds, but there is going to be some network lag. If your project mandates immediate notification, you’ll need the GDK.

Connectivity is required

One of the big selling points for native Glass development is the ability to handle offline situations. Glass will queue sync operations for when the network returns and you don’t have to worry about it, but the Mirror API expects most of the heavy lifting to be handled off-device.

No sensor or hardware access

The full range of sensor APIs are programmatically available only through the GDK for things like light detection, motion, and velocity. Access to the camera, microphone, and GPS are more passive with the Mirror API and usually rely on the user taking an explicit action.

Purely event-response driven

There are just some things you can’t do when you’re talking about discrete events. Streaming video (either sending it from Glass or watching it on Glass) just can’t be done frame by frame, for example.

But fear not. Most of these issues are addressed with native development and the GDK, although we’ll see it has its own set of pitfalls. And don’t dismiss developing with Mirror out of hand—there is still lots you can do with it that is far easier than with the GDK.

Mirror API development, as we noted, is incredibly liberating in the sense that any server-side language can be used to write a Glass service and tap the RESTful endpoints that the Google Mirror API provides. This means you can easily build a server in a web document, a desktop application, for a mobile OS, or even one that runs at the command line or via SMS. You can do whatever is most comfortable to you to build, most convenient to use, and most appropriate to satisfy the use case. Client libraries in a rapidly expanding array of languages are available for download at the Google Developers Glass site.

SERVERS VERSUS APPS

We’re starting our look at developing for Glass with a thorough look at the Mirror API, which provides a network-service perspective toward writing Glassware. Those of you already familiar with Android may feel left out or want to skip ahead. Native development with the GDK will be covered in a few chapters. GDK programs are more like traditional apps—running on Glass itself instead of sending all the events to a remote service.

We strongly suggest, however, that you read through and become familiar with the Mirror API as well. Many tasks, particularly those that will send things over the network, are particularly well suited for the Mirror API, and understanding how it works will help you write better GDK apps.

And here’s a little tip—the Mirror API and GDK can even work together. (We’ll look at how later.) This makes a case where the result is truly greater than the sum of its parts.

But what may not be so evident is that this also means you’re free to use other frameworks like Google Apps Script and integrate with the Glass backend to communicate across platforms for things like writing to and reading from files in Google Drive.

A FUNNY THING HAPPENED ON THE WAY TO THE HACKATHON…

Allen based his hackathon project built at the New York City Glass Foundry on the concept of building Glassware with two technologies that at the time didn’t have much documentation or examples relative to Glassware programming (and largely still don’t)—coding up a to-do service using Google Apps Script (GAS) that would interface with Google Drive, an early version of what would ultimately become Vodo. This allowed items to viewed and marked as completed, and be stored in a spreadsheet, or would track changes to word processing documents. Worksheets represent individual lists, which could be shared with others. To facilitate communication between GAS and the Google Mirror API, Allen wrote a simple proxy handler in Java. He says, “The key thing to understand is that each interface was designed for the environment. I didn’t try to duplicate a spreadsheet on Glass—but I was able to get Glass to show a good representation of a list.”

He explains his idea in full detail in a YouTube video.

If you choose to develop with the Mirror API, you also have your choice of IDEs to work with—whether you enjoy the rapid coding atmosphere of the Google Developers Console (formerly the API Console) with Chrome’s Developer Tools or the visualization for timeline cards in theMirror API Playground; or if you favor a full-blown editing and debugging environment of something along the lines of Eclipse or Visual Studio; or if you’re a vi, Emacs, Notepad++, TextMate user or have Sublime Text savvy; or if you prefer web-based coding with something like Cloud9 or ShiftEdit, or like to go old school and just use good old Notepad. It’s completely up to you.

You’re also free to move around with hosting, with the cloud model being completely platform-agnostic. You can use affordable commercial web hosts, or enterprise-level scalable providers like Google App Engine, Amazon Web Services, and Windows Azure, or even host services yourself out of your room on a commodity machine. (We don’t recommend the latter, however, and we’ll explain why shortly.)

Events: The Building Blocks of the Glass Timeline

We have mentioned and will continue to mention events throughout this book, especially in the Development section. If you’re a seasoned programmer, you might have figured out what we’re talking about, but you might be a bit surprised. One of the things we realized as we began working with Glass is that it shows us things that have happened, will happen, or are happening. Similarly, most Glassware either notifies the wearer of things that are occurring, or receives messages from Glass about things that are taking place.

In this chapter, we’ll explore a little bit more about what we mean by an event and how these events get between your Glassware and Glass (and vice versa). Since privacy and security of events are important, we’ll look into this a bit in Chapter 8 and discuss what role OAuth plays. We go into (a lot!) more details about sending events to the wearer in Chapter 9, as we discuss the timeline and the timeline cards that represent our events. The tables are turned in Chapter 11 and Chapter 12 as we hear how our users can generate events of their own by replying to cards or generating their own cards with powerful built-in tools the Mirror API provides like subscriptions and sharing. We round out the Mirror API in Chapter 12 as we discuss a special type of event, the Location event, and how it ties into other events as well.

We feel using events is a great way to think about what goes on with Glass, but the notion is a little different from what you might be used to. Don’t worry—it may take some time for the concept to sink in, but once you have that “A-ha!” moment, you’ll see how everything works based on this simple premise.

So let’s dive in and take a look at how Google handles these events, where your Glassware will fit into the picture, and why you should care in the first place.

The High-Level View

We’ve talked about Glassware, and we’ve talked about Glass itself, but how do the two actually talk to each other? If you’ve done any web development at some point in the past 15 years (and probably if you’ve done any other Internet-based programming in about that time), you’ll findFigure 7-1 somewhat familiar. It represents a device, working through a proxy, communicating with a server. In this case, Glass is the device, Google acts as a proxy for Glass, and the proxy is communicating with your server that runs Glassware.

The Mirror API builds on this legacy in many ways. The communication channel between Google’s server and you is HTTP (actually HTTPS, but we’ll discuss that more in a bit). You will use standard REST HTTP commands such as GET and POST to update the events sent to Glass. The contents of the HTTP payload are JSON objects. Unlike normal HTTP, however, the communication is bidirectional—your Glassware will register a web hook with the proxy, and Google will use HTTP to send events to you via these interfaces. We’ll look at what these messages look like in just a moment.

The flow of information between Glassware, Google’s cloud, and Glass

Figure 7-1. The Mirror API architecture (image courtesy of Google)

What about that part on the right of the diagram labeled “Glass sync”? How does Glass communicate with the mothership? Magic. Well, no, not really…you can see the upcoming sidebar for more about how the synchronization component of the ecosystem works, but this is an aspect that we generally don’t need to concern ourselves with when we’re working with the Mirror API, and this is a good thing. Technically speaking, as far as how information flows between users, your Glassware, and Google, wearers never talk directly to your server.

When users invoke commands through voice, gestures, and menu items, when they share a resource with your Glassware, send data to it, or when they subscribe to receive notifications from your program, they send these requests to Google, which then sends the messages in expected data structures in JSON to your server for processing. Any confirmation messages flow back in reverse from your server to Google, and then to Glass clients. The converse applies, too, for situations where your Glassware has new data to push. Any subscription information is sent to Google, which then delivers the messages to clients efficiently. Your Mirror API–driven Glassware never talks directly to any Glass headset, no matter the scale.

As Figure 7-2 shows, Google is the ultimate middleman, a friendly intermediary that keeps everything having to do with messaging in line. Google handles all the complex situations of batching multiple events into a single job and queueing them up to make sure they are delivered over a network that cannot always be relied upon. Glass sync ensures that once we hand an event off to Google for delivery, it will eventually be delivered to the correct Glass device; once an event takes place on Glass, it will eventually be delivered to us as well.

How data flows between Glass, Google, and your Glassware

Figure 7-2. Data flow in the Mirror API

UNDER THE HOOD OF GLASS SYNC

The Glass sync component is the phase in which Google manages all of the messaging operations for delivering the messages and synchronizing them with their intended headsets, such as queueing, batching, and optimization, as well as handling situations where the user’s headset may be out of range of connectivity or isn’t powered up at all. At the time of this writing, this part of the system runs on a modified build of Google Cloud Messaging for Android (formerly known as Android Cloud to Device Messaging), which is the same system that runs Google Play’s over-the-air install feature for mobile apps. This infrastructure is subject to change at any point, and access to it is prohibited to external developers anyway.

While we as third-party software developers don’t have to worry about the intricacies of this side of the Mirror API framework, it means we also don’t have the ability to configure several cool aspects of GCM. We hope that someday we’ll be able to tweak some settings in that regard for more direct control of messaging because there are some neato flags we’d like to enable.

How Your Server Talks with Google

Returning our focus to the lefthand side of Figure 7-1, what does the Mirror API look like? As noted, our Glassware will be making HTTPS calls to Google’s API server. Each request will contain an authentication header that has resulted from a user authenticating themselves using OAuth2. As with all HTTP-based requests, we will be issuing REST-like commands against a URL that represents the object we will be working with (usually an event). If we need to specify values (and what is the point if we’re not specifying values at some point?) we’ll use either values in the URL, URL parameters, or JSON objects in the HTTP body. If we are sending media, such as a picture or video, we will send them using a multipart body, part of the HTTP standard. The text displayed on our user’s screen on Glass can be formatted using a simplified HTML markup, with some predefined CSS classes and other CSS styles we can define.

Data comes back to us in one of two forms. If we are issuing a query to Google, for events that meet a particular criteria for example, then the HTTP connection will contain the response, usually in the form of a JSON object. But for events that take place on Glass, we shouldn’t need to open up a connection to Google just to see if there is anything new. Instead, we will register a callback as our aforementioned web hook, which is a URL on our server that Google can contact when there is something to tell us. We’ll get an HTTPS connection to our server from Google, delivering a JSON object containing the event information. In either case, media is delivered to us in the form of a URL to fetch, instead of the full chunk of data.

If you’re not familiar with REST, you can generally think of it as a way to reference certain atomic database operations on objects. So if we are talking about events, we would be interested in doing tasks such as adding a new event to Glass, searching for events that meet specific criteria, fetching an event by a unique identifier, deleting an event, sending all new data about an event, or updating just some fields in an event. (But this is a spoiler…for Chapter 9.)

If you’ve used JavaScript, you’re probably at least vaguely familiar with JavaScript Object Notation. (JSON, get it? Totally unrelated to one of this book’s authors.) This is a simplified, yet easy-to-read, way of distributing a data object, composed of attributes and values, where the values may be numbers, strings, Booleans, other objects, or an array of any of these. If you’re new to JSON or have only worked with formatting content in HTML, an extremely helpful post is available on O’Reilly Answers giving details, but here is a quick taste so you get the idea:

{

“question”: “string value”,

“numeric_example”: 42,

“is_this_the_answer”: true,

“nested_object”: {

“nested_attribute”: “totally exciting”,

“nested_boolean”: false

},

“possible_questions”: [

“How many roads must a man walk down?”,

“What does our amp go to?”,

40

]

}

In the preceding code example, we see a very basic, yet illustrative, object represented in JSON. The whole thing is surrounded in curly braces, indicating it is an object, and the nested object attribute uses this brace notation as well. Arrays of values are similarly marked by square brackets, and can contain mixes of types. Attributes of the object are surrounded by double quotes, to the left of a colon. Values are to the right of the colon. Attribute/value pairs are separated from each other by a comma. All values are constants—you can’t call functions or do math formulas to compute a value.

If we were documenting this (and this is how Google documents it), we might describe the resource something like so:

{

“sample_string”: {string},

“numeric_example”: {integer},

“is_this_the_answer”: {boolean},

“nested_object”: {

“nested_attribute”: {string},

“nested_boolean”: {boolean}

},

“possible_questions”: [

{string or integer}

]

}

And then document it in table form as in Table 7-1.

Table 7-1. Object model for a JSON resource

Property name

Value

Description

sample_string

string

A sample string, representing the ultimate answer.

numeric_example

integer

A possible numeric answer to the question.

is_this_the_answer

boolean

Is this the answer or not?

nested_object

nested object

An object representing a nested resource.

nested_object.nested_attribute

string

The attribute for this nested resource.

nested_object.nested_boolean

boolean

Random Boolean for the nested resource that was included.

possible_questions

list

A list of possible questions for this answer. May be string or numeric.

We’ve stressed one of the advantages of the Mirror API being your ability to program Glassware in whatever language you choose, so why are we going into so much detail about HTTPS, REST, and JSON? Because we need a lingua franca that everyone can understand to illustrate the concepts behind how the Mirror API works and this is in line with how Google’s documentation reads as well. Whether you’re just starting out with Glassware development or are new to programming entirely, it’s helpful to have a consistent lexicon. The fact that the technologies are also open standards means that everyone else using them will refer to them consistently.

Don’t fret, however—Google’s documentation also talks about many common languages, and the wrappers they use to translate these concepts into ones you are probably more familiar with in your specific language. We’ll be pointing you at those language-specific references when the time comes, but we will be talking about the concepts more than the syntax.

Components of the Mirror API

Speaking of concepts, this seems like a good time to introduce you to the components of the Mirror API itself. We’ll be going into details over the next few chapters, but you’ve been such great readers so far that you deserve a little bit of a preview. In a nutshell, whenever your Glassware communicates with the Mirror API, it does so in terms of the collections that the API supports. This is the common grammar used by the JSON messages you’ll send to and receive from Google, essentially Mirror’s object model.

There are five collections you’ll be using, with each having its own distinct set of properties and expected values:

§ Timeline

§ Timeline.attachments

§ Subscriptions

§ Contacts

§ Locations

The easiest and most basic thing you’ll be working with are events related to the timeline. You’ll be inserting, deleting, and updating cards there by sending these commands to Google’s servers. There are a lot of properties to set on a timeline item—ranging from the text to display on a card to menu items attached to each one. And speaking of attachments, you can also attach images or video to be shown along with each card. We’ll go into all of the options (and there are a lot of them), how to use them, and what commands you’ll be sending to the server in Chapter 9.

As we can see from Figure 7-1, however, our communication with Google is a two-way street. So in Chapter 10 we’ll learn a bit about the menu items that we can attach to a timeline item and how we get notified when someone selects one. To do this, we’re going to have to provide a callback URL to a subscription that we send to Google, and we’ll learn about how to manage our Subscriptions and what it looks like when we get the callback event. We’ll also learn about what we might do with our timeline item once a menu on it has been called.

A special type of event occurs when someone shares a timeline item with us. We will need to create one or more contacts, register them with Google, and these may show up in the list of people or things that people can share a card to. We’ll get the callback via the same Subscription method, but Chapter 10 will go into details about what additional information we can provide with a contact, what it looks like when something gets sent to one of our contacts, how to get the timeline item that was created just for us, and what we should do with it.

Finally, Google will send us a specific event notification if we subscribe to location changes. Chapter 12 will show us a bit about location information that may be attached to Timeline events, how to create maps for our cards, and how we can get user location to help keep our events timely. (You remember that was a Noble Truth, don’t you? If not, reread Chapter 5.)

Preparing Your Project

With this high-level view of what happens on the left side of the diagram, and a quick overview of what messages are exchanged between our Glassware and Google, it is time to start zooming in on what you actually need to do to use the Mirror API. You probably have an idea for a project. Maybe even more than one. We’re not quite at the point of building it, but we’re getting ready to set it up. To do so, you’re going to need to have a few things ready.

First, you’re going to need a server. Easy, no? Well, there’s more to it. Don’t forget you’ll need a web server on it, and you’ll probably want a data store of some sort, as well (i.e., a database, XML file, spreadsheet, flat file, etc.). Google will need to contact your server, so it has to have apublic IP address—the machine in your house probably isn’t enough. Since Google will be contacting your server via HTTPS, you’re going to need an SSL certificate. And, with all your hard work, your Glassware is going to be a big success so you’ll have to be prepared to scale this up. Is this sounding like a lot of work yet?

Would you like somebody to do all of that work for you? Fortunately for you, somebody is. If you’ll be developing in Python, Java Platform Enterprise Edition, Go, or PHP, you can use Google App Engine (GAE) to host your project. GAE takes care of providing the hardware, a working web server that supports HTTPS, the necessary SSL certificate, and even a hostname that you can use for your Glassware. It is free to set up a basic GAE instance, so you can get familiar with it and begin developing your idea, and you can transparently add more instances as your needs increase. You can find out more about GAE and the rest of Google’s Cloud Platform at http://cloud.google.com.

Once you have a server set up, it’s time to set up a project with Google. If you’re using GAE, or any of the other Google Cloud Servers that we just covered, you’ll already be familiar with the Google Developers Console. If you’re not, we’ll be using the Developers Console to set up access to the Mirror API. The console allows us to do several things: create a project, indicate that it will be using the Mirror API (and any other APIs we may need), and get a Client Key and Client Secret that we will use as part of the authentication and authorization process. You’ll also use it to find out helpful trends about your quota usage, such as what time(s) of day your API calls are being made most. (We’ll talk about the quota in a moment.)

API CONSOLE VERSUS DEVELOPERS CONSOLE

If you’ve used Google’s API Console in the past, you may be wondering what this Developers Console thing is, and why we’re pointing you at it instead of the tried-and-true API Console. Google appears to be shifting all its future efforts to the Developers Console, and although it isn’t fully functional yet, it seems destined to replace the API Console in the (relatively near) future. Now’s the time to start getting used to it and sending in feedback about the up-and-coming hotness.

Oh, and why call it “Developers Console” if it does more than control access to Google’s Cloud Services? Your guess is as good as ours.

We’re going to create a new project that we’ll use for the next couple of chapters to get us started with the Mirror API. Our journey begins at http://cloud.google.com/console where we will either log in to our Google account or create a new one if we’ve somehow managed to avoid this before. If we’ve never set up a project, we’re greeted with a welcome message, as shown in Figure 7-3.

If you have created a project in the past, you’ll be greeted with the list of your projects and the same red Create Project button.

As you might have guessed, we’ll be clicking that button to create a new project. A window will pop up prompting us to enter some basic information. The Project name should be set to Glass Playground for reasons that will someday become clear. You can keep the Project ID to one that they suggest, or come up with something clever on your own—but it has to be unique across everyone’s projects, so you might want to just accept what they suggest or incorporate something with your name (Figure 7-4). Finally, you’ll check the box saying you’ve read and accepted the Terms of Service (you have, haven’t you?) and click the Create button.

Creating a new project in Developers Console

Figure 7-3. A new Developers Console project

It may take a few moments, but once the system has created the project for you, it will place you on the overview screen for your Glass Playground project. You can explore some of this, if you wish, but we’ll be going straight for setting it up so we can use the Mirror API. If you select the APIs & auth menu item on the left, it will open up the API submenu and show you a (long) list of Google APIs that you can enable. Some of them may already be turned on—you can safely turn them off since we’re not interested in any of the cloud APIs right now. Turn them off by clicking the green ON button, then scroll down until you see the entry for Google Mirror API (they’re arranged alphabetically) and click the OFF button to turn it on, as shown in Figure 7-5. Intuitive, right? You’ll be prompted to acknowledge the terms of service. Once you have, the API will be turned on and moved to the top of the list.

Naming your project and being assigned a Project ID

Figure 7-4. Name your project

Enable the Mirror API, and you’re on your way!

Figure 7-5. Flip the switch on the Mirror API

We’re all set! Well, not quite.

The Glass Ceiling—Your Project’s Quota

The console also gives you access to some basic analytic information. We can see how many calls we’ve made to each API we’ve authorized, as well as how many calls per day we’re permitted to make. Waitaminnit…we’re limited in how many calls we can make? Yup—Google limits how much we can use each API to prevent abuse, particularly while developing new applications with it.

Initially, you’re allowed 1,000 calls for your project each day. This resets at midnight Pacific Time (and sorry—no rollover minutes). You can see your quota, current, and historic usage for your use of the Mirror API by clicking from the APIs & auth menu page and then clicking the Google Mirror API link. Links for quota and reports are available at the top.

A thousand calls per day is a pretty good level for initial development—it lets you get your feet wet while you learn, and it prompts you to think a little bit about making sure you’re making the most efficient use of the Mirror API. (We’ll share some efficiency tips as we go along, but don’t stress too much about it.) It should even be enough for a few test users to help you get going before you’re public. As you widen the program, you can request more quota from Google, as long as you justify the increased usage. Once you go live, of course, you can ask for an even bigger quota—but we’ll be covering that later.

We’re getting ahead of ourselves a little bit, but what counts against your quota? Every action that you take for each user by calling the API counts as one call. Batching calls won’t help—a batch of 10 API calls, all sent at one time, still counts as 10 calls. If we look at Figure 7-1, the arrow from your Glassware to the Google Cloud indicates what counts against the quota. The arrow from the Google Cloud to your Glassware, however, doesn’t. Similarly, actions taken with just the GDK don’t count against the quota.

METRICS ON WEARABLES

It is important to make sure we know how our users are actually using our apps, and modern toolkits like Google Analytics, comScore, and WebTrends generate powerful reports about users browsing your website in real time. They can also be applied to native application tracking (like with the Google Analytics SDK for Android) to gauge which screens users are viewing, the length of their sessions, the effectiveness of integrated marketing campaigns, response to tweets with embedded links, devices and user agents, error logs, crash reports, and API calls. It makes sense to want all of this for our Glassware too, right?

At the moment, we’ve got solid metrics available in Developers Console that analyze how many calls we make to Google’s API servers. But since the Mirror API is a server-side technology, we can’t implement the frontend JavaScript libraries like we can with Google Analytics. We can, however, track messages being passed to and from the server in response to the various Glass events like menu item selection and data sent across the wire. The Google Analytics API lets you define interactions that can be tracked by adding events when you get a callback or when your Glassware inserts or updates a card on the timeline.

Over time, you should keep an eye on the console to make sure you’re not reaching your quota limit.

The Even Bigger Picture

This is good for starters. But a real project will involve much more. If you’re using Google App Engine to run your projects, you’ll be using the console to control your instances and to manage the project and its financing.

Most Mirror API projects will be making use of other Google APIs. At the very least, you may want the Google+ API so you can get information about the users when they log in. You may wish to use Drive, Cloud SQL, or Cloud Storage to store configuration information for your users. If you’ll be using any of Google’s other services, this will be the place (and time) to enable them. But we won’t need to for the Glass Playground.

What we will need, however, is to set up the security credentials. We’ll also be doing this using the console—but we’ll explore why and how in the next chapter.