目前 Google Glass 上有两种开发 Glassware（应用，特指为 Glass 定制的应用）的方式：一是通过 Mirror API 从云端进行开发，另一种是使用 GDK 进行本地开发。
"Mirror API or GDK?"
Mirror API 是一套 RESTful 接口，通过 OAuth 2.0 授权协议让 Glassware 与用户资料建立关系。它的背后是一个神奇的机制。Mirror API 云端储存了某个 Glassware 产生的、用户向某个 Glassware 分享的内容的完整副本。当 Glassware 向 Mirror
API 更改了内容，或者用户在 Glass 上产生了更改，这些更改都会在恰当的时候被同步（背后是 Google Messaging Service 推送等等技术的支持），并且这个同步过程是由系统统一管理的，共享资源，因此也达到了节电的目的。同时，如果有必要，Mirror API 也会向你的 Glassware 反馈用户的更改（比如地理位置变更、分享了一张照片），因此在对实时性要求不是特别高的情况下，Mirror API 是一个不错的选择。
而 GDK 则是基于 Android SDK (API 15) 的一套 SDK，用来开发直接运行在 Glass 本地的应用（众所周知 Glass 是基于 Android 4.0.3 的）。GDK 相对于 Mirror API 的优势是，可以直接访问各种底层传感器（比如陀螺仪、指南针、摄像头等等），并且因为是本地执行，因此更适合实时应用。
GDK 和 Mirror API 的对比
Mirror API
前面已经提到，使用 Mirror API 开发的 Glassware，并不需要直接接触用户的 Glass，而是与 Mirror API 打交道，由 Mirror API 负责将内容反映到 Glass 上。其关系大致上如下图所示。
Mirror API 关系结构
Mirror API 的三个特点：
- 轻量级 - 资源共享，由系统统一调配，不会使 Glass 产生额外的开销
- On-The-Cloud - Glassware 本体在云端运行，开发者无需了解具体的 Android
开发知识，只需要具备基本的 HTTP 基础 - OAuth 2.0 - 用户通过 OAuth 2.0 向 Glassware 授予权限，Glassware 只能读写属于自己的数据
Mirror API 使用示例
通过 Mirror API 开发需要了解 Glass 的几个基本交互元素，下面将一一介绍。
Timeline
Timeline
Timeline（时间轴）是 Glass 上最最基本的交互元素，每一张卡片都代表一个信息。用户可以通过 Glass 的眼镜腿前后翻阅每一张卡片。
Timeline 结构
整个 Timeline 大致上是这么分布的：用户首先看到的是一个时钟主屏幕，所有操作都从这里开始；左边是正在发生的事情，比如正在运行的 GDK 应用，比如用户固定了的卡片；右边是过去的事情，类似一个瀑布流，旧的消息会被一直往后推，直到消失不见。
卡片组
而对于具有相关性的卡片，比如一组电子邮件会话，则会展示为一个卡片组。用户可以展开它看到这个邮件主题的对话历史。
关于卡片的设计，谷歌官方对此给出了四点规范：
Don't get in the way · 不碍事
在你需要的时候，它就在那里；在你不需要的时候，你不会留意到它存在。Glassware 做的应当是你的个人助手，而不是掌控你的行为。
Keep it relevant · 说重点
Glassware 提供的信息应当是尽量简洁的，不需要用户过多注意力去提取信息。所以，说重点，不要一大堆废话。
Build for people · 以人为本
所谓以人为本，就是你只需要很少的交互，就可以达到目的。一个最典型的例子是，有妹纸发来短信，你只需要「ok glass, reply」，当你说完你的回复内容后，Glass 自动帮你将信息发送出去。整个过程甚至不需要动手，不需要点来点去各种菜单操作。
Avoid the Unexpected · 别作死
深夜某个时候，哐当一声。。。嗯，某些公司的癖好，大家懂的。
Menu Items
Menu Items
另一个重要的交互元素是 Menu（菜单）。每一张卡片都可以带有一个或多个菜单项，用户翻到这张卡片时，点击眼镜腿，就会看到这张卡片的操作菜单，每一个菜单项都代表着特定的功能。开发者可以自己定义每张卡片应当出现什么菜单项。几个常用的菜单项有：
- Share - 分享
- Reply - 回复信息
- Read aloud - 通过语音读出卡片内容
- Call - 打电话
除此之外 Glass 本身还支持很多菜单指令，甚至还能由开发者自己定义菜单项，或者改变原有菜单项的显示文字。
Subscription
前面提到，使用 Mirror API 开发的应用并不能直接访问 Glass 设备本身，因此如果需要对用户的操作作出回应，就需要用到 Subscription 机制。
Subscription 机制的原理是，Glassware 向 Mirror API 注册一个 HTTPS 回调地址；当用户产生了特定动作（比如，向你的 Glassware 分享照片），Mirror API 就会向你的 HTTPS 地址发出一个 POST 请求；Glassware 接收到这个 POST 请求后，就可以从请求体中提取出必要的信息。
Voice Command
Glass 的所有操作都通过主屏幕开始。用户可以通过点击触摸板，或者使用「ok glass...」语音指令启动主菜单看到这些指令。
除了 Glass 本身提供的「Take a picture」、「Record a video」等等系统指令外，Glass 还向 Glassware 提供了不下 19 种语音指令，比如「Post an update」、「Take a note」等等。当然，还有 17 条指令直到目前还没出现在官方开发文档中，我就不说啦（没去
GDG 现场的朋友吃亏啦哈哈哈）。
Contacts
Share to somebody
Contacts 在 Glass 上是一个比较开放的概念。它既可以是一个真实的人，也可以是一个虚构的概念。它的存在是作为一个接受指令的东西：
- 用来作为拨打电话的目标
- 接受分享
- 回应语音指令
Location
Glass 同时也是一款很适合 LBS 的设备。然而 Glass 本身并不自带 GPS 模块，而是需要依赖所配对的手机的 GPS 进行定位。通过将 GPS、蜂窝数据等耗电模块转嫁给手机，也是 Glass 达到节电、轻便设计的一个手段。
Glass 与手机配对后，Mirror API 便会使用手机的地理位置信息（众所周知，只要你的 Android 手机开放了相关的权限，便会定时向 Google 上报地理位置）。通过相应的接口，Glassware 可以获取到 Glass 最近一次上报的地理位置。此外，通过 Subscription 机制，Glassware
也可以及时得知用户的地理位置变更，从而作出相应的回应。
"So, what about GDK?"
新鲜滚热辣，上个星期刚刚发布的 GDK。这次 GDG 聚会我也顺便简单介绍了一下。
Android SDK and GDK
GDK 本身基于 Android SDK (API 15)，并在此基础上加入了一些 Glass 才有的特性。相较于 Mirror API，使用 GDK 开发的 Glassware 是一个 APK 格式的 Android 应用，运行在 Glass 本地，并且能够访问 Glass 本身的一些底层传感器（比如指南针、陀螺仪等）。
这里主要介绍一些 Glass 特有的概念。
Live Card
Live Card
使用 GDK 开发的 Glassware 可以向 Timeline 主屏幕插入一条语音指令作为启动触发器；当用户触发这个指令时，Glass 将会通知 Glassware 的服务；此时 Glassware 可以创建一组 Live Card 向用户展示运行状态。
所谓的 Live Card，实际上就是 Timeline 主屏幕左侧的卡片，表示正在进行的事情。Glassware 通过 Android 四大组件之一的 Service 可以在后台更新这张 Live Card。同时，用户也可以点击这张 Live Card 调出 Glassware 的菜单，进行一些操作或者退出 Glassware。
目前 Google Glass 开发团队在 GitHub 上提供了几个 GDK Live Card 的示例，有兴趣的朋友可以参考一下：
- Stopwatch - 秒表，主要演示了实时绘制 Live Card 界面
- Compass - 指南针，主要演示了指南针传感器的调用
- Timer - 倒计时器，主要演示了菜单
下期预告：极镜论坛-谷歌眼镜开发教程GDK版一
搭建开发环境