top | android | coffee | dealing_with_companies | dev_blog | experiments | food | fun | io15 | politics | products | random | security | startups | tech_events | thoughts | wearables |

16 Dec 2015, 11:53

Suggestions for Wearables and Automation

google glass

I’ve been thinking a lot about automation recently. One of the big questions that I ask myself over and over is, what can I stop spending so much time on? What are things that I’m not great at that could get better through automation?

I have a list of general things that I think would be fun to try automating (which I’ll write about later), but of the list of tools, I think that wearables present an interesting opportunity for automation. The problem is, that I am having trouble thinking of what I could do there.

So, I figured that I would ask what people think about this? I’m sure that there are lots of people out there with Glass or Android Wear who dreamed of what they could do with those devices. If those dreams involved automating something, what were they?

16 Nov 2014, 00:26

Some Thoughts on Smart Wearables

Some Thoughts on Smart Wearables

People said similar things about mobile internet devices (Smartphones, old Windows Phones, PDAs, Nokia Internet Tablets) to what some are now saying about Glass. Back before the iPhone, and really for several years after Android’s introduction, people kept asking why they needed to be able to check their email when they were away from their desk, as if that’s all a smartphone was good for. There was a niche market for this that BlackBerry did a great job of serving. This viewpoint is incredibly myopic, and I am of the opinion that it is a similarly myopic view of smart wearable devices. For smartphones, there was a game changer (actually probably a few, but I’ll focus on one) that came into play that took the smartphone from a ‘nice to have’ to a necessity, and that was real time navigation.

Real time navigation was a very clear example of a use case that strongly favored the smartphone over existing technology, and it was something that more and more people were becoming interested in. More and more people were starting to buy dedicated GPS devices at price-points between $200-$500. This device did one, and only one thing, and it did it in a relatively fixed and frustrating way. Android came out with Google Maps, as well as several other low-cost real time navigation apps with different feature sets, at a price-point of under $200, and it did a lot of other really great stuff. What’s more, the navigation experience was sure to improve over time, whereas the dedicated unit would require expensive map updates, and eventual replacement. There were also features that were very difficult for the dedicated units to do, like real-time traffic updates.

Other killer smartphone features are over-the-top calling and messaging, which can provide a much better experience than those provided by the phone companies. At this point, it’s a low-cost full-fledged computing platform. You can even write Android apps from your Android phone (not that I have any idea why someone would want to do that). Email on the go is nice, as is checking the web. And, there are tons of other really incredible mobile experiences that don’t make sense on PCs or other platforms.

Now, back to wearables. Is it possible that it’s just a bit too early to be discounting several totally novel ways of interacting with smart devices? Is it possible that there may be some applications that once released would be market drivers, and really sell the notion of smart wearables to the masses? Do you think that there’s a possibility that whoever figures out what that product is will become a huge player, worth billions of dollars? Do you still want to ignore this still untapped market? I know that I don’t want to miss what’s next. And, to be sure, I think that’s going to come from some currently unknown (or barely known) developer, who really hits it out of the park.

So yes, it may be early in the game, even too early for some, but if you want to get a head start, now’s the time to start running.

03 Nov 2014, 16:57

Going from Google Glass Mirror API Quick Start to Product

Going from Google Glass Mirror API Quick Start to Product

At this point, you should have either the Java or the Python Mirror API Quick Start up and running. If you do not, please check out this post, and this post (apologies that I don’t have one for Python, just Java). This post is going to discuss how to use the quick start projects to begin making progress on your product.

I’m going to talk about this in the context of a service that I’m working on building up, Hearty.io. I think that it’s important to understand the product, and the goals of the product when approaching development. I also think that it is especially important with wearables to understand your product, and how that’s going to work with wearables.

Hearty.io

Let’s get started by taking a look at what we have for a service, understanding it, and thinking about how we can use the Mirror API to extend it and offer something useful to our users. One note, Hearty.io is currently very rough and is missing quite a bit. What we will do here, is to define a current, fictional set of functionality, things that we can assume are already working. Again, to be clear, the following is a fictionalized description fo the service, that we will use for our purposes.

Hearty.io is a fitness service with several components. There is an Android component, an Android Wear component, and Glassware. There is also a backend service that keeps all of the data synchronized.

Android

The Android app does automatic activity recognition, and tracking. It uses Google Play Services to determine what the user’s current activity is, and then automatically tracks times when the user is active. The Android app posts a notification during times that it is tracking with the current activity, and the length of time tracked.

The Android app also syncs with the server, and displays data from all three sources.

Android Wear

The Wear app does step counting, and syncs directly to Android using the Android Wear Data APIs. The Android notifications for Activity tracking show up on the watch, and there is a Wearable action that would allow the user to ‘ignore’ the current activity.

Glass

The Hearty.io Glassware uses the GDK and talks to a Bluetooth Heart Rate Monitor. The user launches the Glassware by saying 'Ok Glass, show my heart rate’. When Hearty launches, if there is no device paired, it redirects into a pairing UI. Once paired, Hearty.io inserts a LiveCard that displays the users’s current heart rate. The Glassware syncs the user’s heart rate directly with the server.

Server

The server just keeps track of three things for each user, each day’s step count, number of active minutes, and average heart rate.

New Mirror functionality

The most obvious thing that I can think to do with Mirror here is to send the daily summary to the user on a daily basis. We also want to display that data in a dashboard for the user.

There are a few things to consider here, beyond simply what we want to build. The primary consideration should be if it’s something that makes sense, and would be a good experience on Glass. Mirror can be used to do things that don’t result in a good experience. For example, news content is tricky to consume on Glass. Reading lots of text on a screen, or spending up to a minute listening is not ideal. WinkFeed does a great job of providing a good experience for news, mainly because of its Pocket integration. Sometimes, a clever feature can help your Glassware to go from a mediocre experience to a great one. Take a look at the Glass Design Principles and think about whether what you’re doing is in line with those principles.

What we are going to build

Let’s build the following, a web service that uses a fake database, displays the dummy data to the user on a web app, and then allows the user to send that data to Glass.

Wiring this up to our real service should be something that we know how to do, so we are not going to cover that here. We are also not going to do the work of automating this to run on a daily basis, that should be fairly straightforward.

I’ll cover Java first, if you’re more interested in Python, feel free to skip down to that section.

Java

I’m going to assume that you’ve already been introduced to the quick start code, and so I’m going to skip the overview here. What we need to know is where we need to go in and what to modify.

JSP

The index.jsp file is what is used to generate the main web view. We are going to start by adding a section at the top with some dummy, hardcoded data. Place this above where the timeline cards are shown.

<div class="span4">
  <br>
  <table class="table">
      <tbody>
      <tr>
          <th>Heart Rate</th>
          <td>
            77
          </td>
          <th>Steps</th>
          <td>
              17,311
          </td>
          <th>Active Minutes</th>
          <td>
              89
          </td>
          <td>
          </td>
      </tr>
      </tbody>
  </table>

</div>

That will give us a table, without any actual data. Let’s add a button at the top that uses the same sort of paradigm that all of the other buttons do on this page.

<form action="<%= WebUtil.buildUrl(request, "/") %>" method="post">
    <input type="hidden" name="operation" value="insertHeartyData">
    <button class="btn btn-block" type="submit">
        Insert a bundle with Hearty Data</button>
</form>

Pretty easy, right? Notice that the value of the input is insertHeartyData, that’s going to be important when we go to the servlet.

Now, let’s make a quick side-trip, and add our dummy database.

FakeDatabase:

public class FakeDatabase {
    private static final ConcurrentHashMap<String, HeartyData> heartyData = new ConcurrentHashMap<String, HeartyData>();

    private static Random rand = new Random(System.currentTimeMillis());

    public static void generateFakeUserData(String userId) {
        HeartyData data = new HeartyData();
        data.activeMinutes = rand.nextInt(110);
        data.stepCount = rand.nextInt(25000);
        data.heartRate = rand.nextInt(50) + 50;
        heartyData.put(userId, data);
    }

    public static HeartyData getUserData(String userId) {
        return heartyData.get(userId);
    }

    private FakeDatabase(){ // not allowed to instantiate }
}

Ok, now that we have our database, we have to get data in there, so what we’ll do for that is to add the following to the NewUserBootstrap:

public static void bootstrapNewUser(HttpServletRequest req, String userId) throws IOException {
    // snip ...

    FakeDatabase.generateFakeUserData(userId);

    // snip ...
}

Back to the jsp, let’s use our “real” data there:

  <div class="span4">
    <form action="<%= WebUtil.buildUrl(request, "/") %>" method="post">
        <input type="hidden" name="operation" value="insertHeartyData">
        <button class="btn btn-block" type="submit">
            Insert a bundle with Hearty Data</button>
    </form>
    <br>
    <table class="table">
        <tbody>
        <tr>
            <th>Heart Rate</th>
            <td>
              <%= FakeDatabase.getUserData(userId).heartRate %>
            </td>
            <th>Steps</th>
            <td>
                <%= FakeDatabase.getUserData(userId).stepCount %>
            </td>
            <th>Active Minutes</th>
            <td>
                <%= FakeDatabase.getUserData(userId).activeMinutes %>
            </td>
            <td>
            </td>
        </tr>
        </tbody>
    </table>
</div>

That about does it for the viewing side, let’s try to make this do something.

Servlets

The quick start uses a Servlet for handling all of the POST requests from the web page, as well as all of the subsequent Mirror requests. We can copy one of the other insert methods, and modify it a bit for our purposes.

if (req.getParameter("operation").equals("insertHeartyData")) {
    LOG.fine("Inserting Hearty Timeline Item");

    String bundleId = String.valueOf(System.currentTimeMillis());

    TimelineItem timelineItem = new TimelineItem();
    Attachment bundleCover = new Attachment();

    String imgLoc = WebUtil.buildUrl(req, "/static/images/hearty_640x360.png");

    URL url = new URL(imgLoc);
    bundleCover.setContentType("image/png");

    timelineItem.setText("Hearty.io");
    timelineItem.setBundleId(bundleId);
    timelineItem.setIsBundleCover(true);

    TimelineItem timelineItemHeart = new TimelineItem();
    timelineItemHeart.setText("Heart Rate: " + FakeDatabase.getUserData(userId).heartRate);
    timelineItemHeart.setBundleId(bundleId);

    TimelineItem timelineItemSteps = new TimelineItem();
    timelineItemSteps.setText("Steps: " + FakeDatabase.getUserData(userId).stepCount);
    timelineItemSteps.setBundleId(bundleId);


    TimelineItem timelineItemActivity = new TimelineItem();
    timelineItemActivity.setText("Active minutes: "  + FakeDatabase.getUserData(userId).activeMinutes);
    timelineItemActivity.setBundleId(bundleId);

    // Triggers an audible tone when the timeline item is received
    timelineItem.setNotification(new NotificationConfig().setLevel("DEFAULT"));

    MirrorClient.insertTimelineItem(credential, timelineItem, "image/png", url.openStream());
    MirrorClient.insertTimelineItem(credential, timelineItemHeart);
    MirrorClient.insertTimelineItem(credential, timelineItemSteps);
    MirrorClient.insertTimelineItem(credential, timelineItemActivity);

    message = "A timeline item has been inserted.";
}

That’s a big chunk of code, but there are lots of repeated bits in there. Let’s break it apart and look at it piece by piece.

There is a repeated pattern, that I’m going to show here:

TimelineItem timelineItemHeart = new TimelineItem();
timelineItemHeart.setText("Heart Rate: " + FakeDatabase.getUserData(userId).heartRate);
timelineItemHeart.setBundleId(bundleId);

MirrorClient.insertTimelineItem(credential, timelineItemHeart);

The above is the basics for inserting an item into the timeline. Notice that the bundleId is set as well, that allows this Card to be bundled with other Cards with the same bundleId.

You’ll notice that the full block of code that was posted just repeats that pattern a few times to create four cards, a cover and three children.

Wrapping up with Java

From here, what I did was to move the Hearty.io pieces out of MainServlet and into both its own Servlet, and its own jsp file. When you do this, you’ll need to modify web.xml to map the new path to the correct servlet. You can see the final version of the code here.

Python

As with Java, I’m going to assume that you’ve already been introduced to the quick start code, and so I’m going to skip the overview here. What we need to know is where we need to go in and what to modify.

As a note, this is going to be very similar to the Java portion. Partly because it does the same thing, partly because the quick start code structures are fairly similar, and mostly because I’m lazy.

HTML Template

The index.html file is what is used to generate the main web view. We are going to start by adding a section at the top with some dummy, hardcoded data. Place this above where the timeline cards are shown.

<div class="span4">
  <br>
  <table class="table">
      <tbody>
      <tr>
          <th>Heart Rate</th>
          <td>
            77
          </td>
          <th>Steps</th>
          <td>
              17,311
          </td>
          <th>Active Minutes</th>
          <td>
              89
          </td>
          <td>
          </td>
      </tr>
      </tbody>
  </table>

</div>

That will give us a table, without any actual data. Let’s add a button at the top that uses the same sort of paradigm that all of the other buttons do on this page.

<form action="/hearty" method="post">
    <input type="hidden" name="operation" value="insertHeartyData">
    <input type="hidden" name="heart_rate" value="77">
    <input type="hidden" name="step_count" value="17,311">
    <input type="hidden" name="active_minutes" value="89">
    <button class="btn btn-block" type="submit">
        Insert a bundle with Hearty Data</button>
</form>

Pretty easy, right? Notice that the value of the input is insertHeartyData, that’s going to be important when we go to the handler. Also notice that I’ve got several input values, these are for passing values from the web frontend to the backend. There’s probably a way to attach this to a session, but I don’t know Python that well, and again, lazy.

Now, let’s make a quick side-trip, and add some sort of data generator.

Hearty:

class Hearty(object):
  def __init__(self):
    self.heart_rate = random.randrange(40,135,1)
    self.step_count = random.randrange(2000,28000,1)
    self.active_minutes = random.randrange(17,132,1)

Ok, now that we have our data, we have to get data in there, so what we’ll do for that is to add the following in the get method:

@util.auth_required
def get(self):
  # snip ...
  self.hearty = Hearty()
  self._render_template(message)

And our render template method:

def _render_template(self, message=None):
  """Render the main page template."""
  template_values = {'userId': self.userid,
                     'hearty': self.hearty }
  # snip ...

This means that every time we refresh the page, we will see new values.

Back to the template, let’s use our “real” data there:

<div class="span4">
    <form action="/hearty" method="post">
        <input type="hidden" name="operation" value="insertHeartyData">
        <input type="hidden" name="heart_rate" value="{{ hearty.heart_rate }}">
        <input type="hidden" name="step_count" value="{{ hearty.step_count }}">
        <input type="hidden" name="active_minutes" value="{{ hearty.active_minutes }}">
        <button class="btn btn-block" type="submit">
            Insert a bundle with Hearty Data</button>
    </form>
    <br>
    <table class="table">
        <tbody>
        <tr>
            <th>Heart Rate</th>
            <td>
                {{ hearty.heart_rate }}
            </td>
            <th>Steps</th>
            <td>
                {{ hearty.step_count }}
            </td>
            <th>Active Minutes</th>
            <td>
                {{ hearty.active_minutes }}
            </td>
            <td>
            </td>
        </tr>
        </tbody>
    </table>

</div>

That about does it for the viewing side, let’s try to make this do something.

Handlers

The quick start uses a handler for handling all of the POST requests from the web page, as well as all of the subsequent Mirror requests. We can copy one of the other insert methods, and modify it a bit for our purposes.

  def _insert_hearty_item(self):
    """Insert a Hearty.io timeline item."""
    logging.info('Inserting hearty timeline item')

    bundle_id = `random.random()`

    body = {
        'notification': {'level': 'DEFAULT'},
        'text': 'Hearty.io python',
        'isBundleCover': True,
        'bundleId': bundle_id
    }
    heart_rate = self.request.get('heart_rate')
    step_count = self.request.get('step_count')
    active_minutes = self.request.get('active_minutes')

    body_a = {
        'text': 'Heart Rate: ' + heart_rate,
        'bundleId': bundle_id
    }
    body_b = {
        'text': 'Steps: ' + step_count,
        'bundleId': bundle_id
    }
    body_c = {
        'text': 'Active Minutes: ' + active_minutes,
        'bundleId': bundle_id
    }

    media_link = util.get_full_url(self, "/static/images/hearty_640x360.png")
    resp = urlfetch.fetch(media_link, deadline=20)
    media = MediaIoBaseUpload(
        io.BytesIO(resp.content), mimetype='image/png', resumable=True)

    # self.mirror_service is initialized in util.auth_required.
    self.mirror_service.timeline().insert(body=body, media_body=media).execute()
    self.mirror_service.timeline().insert(body=body_a).execute()
    self.mirror_service.timeline().insert(body=body_b).execute()
    self.mirror_service.timeline().insert(body=body_c).execute()
    return  'A timeline item has been inserted.'

That’s a big chunk of code, but there are lots of repeated bits in there. Let’s break it apart and look at it piece by piece.

There is a repeated pattern, that I’m going to show here:

heart_rate = self.request.get('heart_rate')
body_a = {
    'text': 'Heart Rate: ' + heart_rate,
    'bundleId': bundle_id
}
self.mirror_service.timeline().insert(body=body_a).execute()

The above is the basics for inserting an item into the timeline. Notice that the bundleId is set as well, that allows this Card to be bundled with other Cards with the same bundleId.

You’ll notice that the full block of code that was posted just repeats that pattern a few times to create four cards, a cover and three children.

The only other thing going on here is adding the image to the bundle cover:

media_link = util.get_full_url(self, "/static/images/hearty_640x360.png")
resp = urlfetch.fetch(media_link, deadline=20)
media = MediaIoBaseUpload(
    io.BytesIO(resp.content), mimetype='image/png', resumable=True)

# insert the cover body with the media into the timeline
self.mirror_service.timeline().insert(body=body, media_body=media).execute()

Wrapping up with Python

From here, what I did was to move the Hearty.io pieces out of main_handler and into both its own handler, and its own template html file. When you do this, you’ll need to modify main to map the new routes to the correct handler. You can see the final version of the code here.

Moving forward

This post should have given you some idea of how to take the Mirror API Quick Start and start taking steps towards morphing it into your own project. You will obviously want to have your own service, with your own data, and a real database. The idea here was to start turning knobs and seeing what happens when we change things. Really, the same approach can be taken with most sample code, where you start with what’s given, and poke at it, while reading the documentation, to figure out how to do what you want to do.

04 Aug 2014, 23:18

Android Wear UX

Android Wear UX

Android Wear UX

I saw the news today about WhatsApp releasing a beta version of their app with Android Wear support. It got me thinking about what makes for a good experience, especially on wearables. This is something that I do think about quite a bit, but I haven’t written a lot about.

One thing that popped into my head was that my co-worker and I had solved some of the same problems on our app, Talkray, that WhatsApp is trying to address. While I don’t have much insight into WhatsApp’s design process, I can talk a bit about what we looked at when we were working on Talkray’s Android Wear support. I actually presented on this last week, here’s a video of that.

Design Principles

The Android Wear design documentation provides some guidelines on how to create a great experience on Wear:

  • Focus on not stopping the user and all else will follow (5 second rule)
  • Design for big gestures
  • Think about stream cards first
  • Do one thing, really fast
  • Design for the corner of the eye
  • Don’t be a constant shoulder tapper

Talkray on Android Wear

If you haven’t heard of us before, Talkray is a calling and messaging app. Talkray has had Android Wear support since Wear launched. There were two basic things that we wanted to be able to do from the watch. First, was to be able to answer incoming calls. The other thing was to be able to quickly respond to incoming messages. We came up with two basic ways of responding to messages, a canned auto reply and a voice reply.

Considerations

We took into account a few basic considerations when designing the UX for our wearable app. First and foremost, we wanted to have very, very quick interactions, as short and simple as possible. There’s a 5-second rule that shows up in Google’s documentation for Android Wear, and that is that if you force the user to interact with you on a watch for more than five seconds, they might as well have pulled out their phone.

There were several other things that we thought about too, like the fact that Wear is going to be a small screen, with limited interaction capabilities. We didn’t want to make the user read or think, as much as possible. We also wanted to make it safer to use while driving, since we know that people do text and drive, even though they shouldn’t. I realize that it’s a bit controversial to say that, but I felt that if we could cut down the interaction enough, we could give people something that would allow them to quickly and easily respond to messages without pulling their attention away from the task at hand.

Auto Reply

The first thing that we give users is a button to send a canned response to a message. This is actually a bit interesting in that it uses Activity Recognition to figure out what you’re doing and respond intelligently. E.g., if you’re driving, it will say that you’re driving and can’t talk right now.

We considered giving multiple choices for canned responses, but felt that doing so would require too much interaction, and would defeat the purpose. There’s literally only one thing to do here if you want to send a canned response. No thinking, just hit the button and you’re done.

Voice Reply

For anything beyond the canned response, we figured that people should be able to say what they want. However, after a year of using Glass, I know that when I see the speech to text running, it distracts me from just saying what I want to say, and I start thinking about what I’m reading. This is really bad for two reasons, first, it pulls my attention into the watch. Second, it distracts me from delivering the information that I want to get across.

Providing a voice-only message, that records the actual audio and sends that, means that I don’t need to think about what the machine thinks that I’m saying, the other person should be able to hear it and figure out what I’m saying based on the audio.

The one big down-side to this is that the current crop of watches don’t have speakers. This means that while we are encouraging people to send audio messages, they won’t be able to receive them. While not ideal, we felt that this was acceptable, though there may be room for improvement here.

30 Jul 2014, 15:40

Android Wear SDK - UX and Data Syncing

Android Wear SDK - UX and Data Syncing

Last, night, I gave a talk on the Android Wear SDK at Hacker Dojo. It was listed in a couple meetup groups, and we had about a hundred people show up for the event! The large event room in the Dojo was packed! The main focus of the talk was on UX and data syncing between the phone and the watch.

Video

Slides

Hearty.io

I also announced a little project that I’ve been working on, Hearty.io. I’ll write more about this later, but here’s how you can check it out:

git clone --recursive https://github.com/emil10001/Hearty.io.git

Thanks for all those who came out, it was a lot of fun!

Here’s a bonus photo that I found on the meetup page. Thanks to whoever posted it!

19 May 2014, 15:53

LowFreqLiveCard - Example of a low frequency LiveCard using GDK for Google Glass

LowFreqLiveCard - Example of a low frequency LiveCard using GDK for Google Glass

I wrote an example of a low frequency LiveCard using GDK for Google Glass. The master branch uses Gradle, the legacy branch is able to be imported into Eclipse.

This code is heavily based on the Live Card documentation on the GDK section of the Glass developer docs. The reason that I wanted to do this was that I wanted something that required as little code as possible to run.

Code

Here’s the entire source for the Service that creates and publishes the LiveCard. It’s very similar to what you see in the documentation.

Notes

A couple of notes, it uses a custom voice command, launch with:

'Ok Glass, start my awesome app'

This displays random data, it is not correct, and Glass does not have a built in HRM that I’m aware of. It will display a new value every 3 seconds, and will stop updating after 10 values have been generated.

Importing

Instructions for importing legacy version into Eclipse.

Instructions for importing into Android Studio.

Instructions for importing into IntelliJ. A note on this one, you’ll actually import this as a Gradle project, not ‘from existing sources’. Everything should be configured correctly to allow it to be imported as a Gradle project.

Source

Full source available on GitHub.

02 May 2014, 15:59

Are Wearables Doomed?

Are Wearables Doomed?

A number of articles have appeared in the last week, asking if wearables have already peaked. I think that the answer is a solid no. I’m going to break this down into a few parts, tracking devices, health and smart wearables (Glass, smart watches, etc.).

Tracking

While, I do think that the fitness tracking space is limited, I think that has to do with the appeal of these devices. No matter how many features fitness trackers offer, they will only appeal to a certain segment of the market. However, I think that there are three important aspects that have been unexplored so far.

First, is the feature set, most of the tracking devices are simply motion tracking, they do step counting and possibly sleep tracking. There are some people that primarily care about these two things. However, it misses out on other potential exercising, like cycling, or weight lifting. There are some tracking devices designed to do better activity tracking, like Basis, but we aren’t quite there yet, and those devices don’t seem to have penetrated the market in the same way that FitBit and its competitors have. Adding more sensors, and providing a more complete activity tracking picture will entice more people.

Second is health. I’ll discuss this more below, but there is an overlap with tracking devices.

Third, tracking devices may be used in conjunction with smart devices. This allows them to be possibly more discreet and less expensive, connecting through Bluetooth Smart (BLE). Perhaps I’ll have a step counter on my hip, a heart rate monitor chest strap, and a temperature sensor on my arm, all talking to Glass. What this does is allows those other devices to cut down on their BOMs, for example, they would not need a display at all if connected to a smart watch or to Glass, because they would already have access to a glance-able display.

Health

This isn’t as much a consumer space, but I think that there is a ton of potential here. We are just now starting to see devices that can start addressing health issues showing up. What’s more, there is some overlap with the tracking devices, for people with lifestyle conditions that would be improved by exercise.

I have started seeing reports of wearable patches being developed that could run on body heat and measure blood pressure. Imagine if there was an easier way to do blood glucose readings with a non-invasive wearable? Or, a potential application for Glass which might assist patients in taking their pills, using computer vision to verify the correct pill, and motion tracking to verify that it was taken, then reporting to the physician. There are lots of potential applications in this space.

Smart Wearables

This is what is going to tie everything together. I’m not sure that people will be still walking around with phones in a few years or not. Either way, smart wearables will enable other categories of wearables, as well as providing their own value. We are starting to see some useful Glassware show up, things like LynxFit and DriveSafe, that really couldn’t be done without Glass or at least not as well.

Conclusion

Wearables are not doomed, and they have not peaked, but we aren’t there yet either. If we still aren’t there in a couple of years, I’ll have to re-think some things, but for now, I’m optimistic.

28 Apr 2014, 16:37

IDE Imports Part 9 - GDK with Eclipse

IDE Imports Part 9 - GDK with Eclipse

This is the ninth of a series of posts discussing how to get Google Glass Mirror (Java) and GDK projects set up in various IDEs.

One of the most common questions that I get from people during workshops is how to get set up either the Mirror quick start, or the GDK project into Eclipse, Android Studio or IntelliJ.

This post will cover importing a GDK project into Eclipse.

0. Clone from GitHub

See previous post.

1. Import Project

File -> Import Project -> Android -> Existing Android Code Into Workspace

2. Select the directory with your project

Make sure that all your source is selected. Then ‘Finish’ and you’ll be done with that.

3. Edit Project Properties

Right click the project, select Properties.

4. Set the SDK as GDK 19

In Project Properties, go to Android, then select the correct SDK.

5. Finished!

You’re all done!

28 Apr 2014, 16:25

IDE Imports Part 8 - Java Mirror with Eclipse

IDE Imports Part 8 - Java Mirror with Eclipse

This is the eighth of a series of posts discussing how to get Google Glass Mirror (Java) and GDK projects set up in various IDEs.

One of the most common questions that I get from people during workshops is how to get set up either the Mirror quick start, or the GDK project into Eclipse, Android Studio or IntelliJ.

This post will cover importing the Java Mirror Quick Start project into Eclipse.

0. Clone from GitHub

See previous post.

1. Install m2e plugin in Eclipse

  • Visit the m2e project site
  • Go to the Downloads section
  • Copy the latest m2e release URL
  • In Eclipse, go to Help -> Install Software
  • Paste the m2e link into the bar, hit ‘enter’ and give it a name, like m2e
  • Select the packages that come up when it loads
  • Install the m2e packages
  • Accept the license
  • Restart Eclipse

2. Import Project

File -> Import Project -> Maven -> Existing Maven Project

3. Hit 'Next’ a few times

Then 'Finish’ and you’ll be done with that.

4. Update the oauth.properties file

I previously made a video with instructions on this. Google has also posted instructions for getting OAuth set up.

5. Fire up a terminal

Run the following from the root of the project:

$ mvn install
$ mvn jetty:run

6. Finished!

You’re all done!

28 Apr 2014, 16:15

IDE Imports Part 7 - Legacy GDK with Android Studio

IDE Imports Part 7 - Legacy GDK with Android Studio

This is the seventh of a series of posts discussing how to get Google Glass Mirror (Java) and GDK projects set up in various IDEs.

One of the most common questions that I get from people during workshops is how to get set up either the Mirror quick start, or the GDK project into Eclipse, Android Studio or IntelliJ.

This post will cover importing a Legacy GDK project into Android Studio.

0. Clone from GitHub

See previous post.

1. Import Project

2. Hit ‘Next’ a few times

Until the project is imported.

The project will automatically be converted into a Gradle project.

3. Add compileSdkVersion to build.gradle

The correct value is:

compileSdkVersion "Google Inc.:Glass Development Kit Preview:19"

4. Fix the AndroidManifest.xml

Need to have one Activity that is considered the launch Activity, otherwise IntelliJ (Android Studio) won’t let you run.

5. Finished!

You’re all done!