OneBusAway Glassware - native GDK version

[barbeau]

I've been working on a GDK (native) version of OBA Glassware lately, and I now have a working alpha version to share. I'm opening this issue so we can track implementation for the GDK version separately from the Mirror API version (OneBusAway/onebusaway-application-modules#60).

Code for this is now available via a WIP PR - #219.

Options to install:

1. Download the current APK here, and follow these directions to install it on Glass, or...
2. If you have the Android dev environment setup w/ GDK installed - run gradlew installDebug from root of project using command-line

OBA Glassware is activated by using voice commands "ok glass", then "show me transit times" (note: this was changed from the original voice command per direction of Glass Review Team):

It will figure out your region (Puget Sound, Tampa, Atlanta, Washington DC, or York Canada):

...find the closest bus stop to your real-time location, and then show you the arrival times for that stop:

Times are refreshed every minute until you dismiss the Activity by swiping down. You can scroll up/down the list of arrival times by tilting your head up and down. You can pause/resume scrolling the list by long pressing with two fingers on the touch pad. Tapping with two fingers will automatically scroll to the top of the list. The arrow points towards your stop from your current position and orientation (so in the example above, you'd turn to your right a little over 90 degrees to face your stop).

Long-term goal is to get the GDK version of OBA Android merged back into the main project, hopefully using Gradle build flavors. Main differences between the two projects is that Glass does not support the Google APIs add-on (including maps and GeoPoint object) or Google Play Services, and apparently has poor support for Fragments (hence use of a ListActivity instead of ListFragment). Most of the internal infrastructure for API calls and various utilities are the same, though, and could be shared between projects.

I'd like to get feedback from others for what features they'd like to see, so please let me know what features you think would be useful.

[paulcwatts]

Is this how you see other Glass projects working, by sharing codebases? Seems like it's a big hit to testing, considering most of us don't have Glass and couldn't test the codebase on all platforms.

If the differences between Android and Glass are well called out in the code that might work -- for instance, separating platform-specific code into separate packages. And limiting the common code's exposure to the Google APIs would make sense for other reasons. I just am not quite seeing how it would work in practice.

[barbeau]

I think it depends on the project. For OBA Android it makes sense to me, since there is a lot of shared code - the major additions specific to Glass are the UI, and a re-arranging of some of the other business logic (called from within the new UI component). REST API calls, data persistence, in-memory representation, etc. are all the same implementation. With Gradle build flavors we should be able to cleanly separate out OBA Android proper from OBA Glassware, so platform-specific code is separated in different classes and folders/packages. An alternate approach is a separate shared library for the common classes, but my understanding is that Gradle build flavors are intended to replace this design paradigm (though, granted, I currently have very little hands-on experience with build flavors).

The GDK needed to build Glass apps is easily installed via the normal Android SDK Manager (now under the API 19 Kitkat - "Glass Development Kit Preview" checkbox), so build-time errors could be easily checked by anyone without Glass. Gradle build flavors can be compiled separately, so one criteria for accepting new PRs would be at least checking that Glass flavor builds. We may be able to set up Travis CI to check this as well.

We're short on unit test coverage right now, so the main danger I see would be some change in app logic where the project builds, but existing methods behave differently than currently assumed. So far I haven't seen any potential pitfalls, where we are making major assumptions on Glass that wouldn't hold true on any other Android device - it seems any changes made to the common code would be needed for both OBA Android and Glass. Additional unit tests would of course help shore this up.

We'll see how it works. If it doesn't, we can always maintain it as a separate project.

[paulcwatts]

That makes sense, and if Gradle build flavors are the New Way Forward(tm), then we should go with that. Maintaining separate projects has its own costs attached.

[paulpv]

@barbeau SPECTACULAR! I have been meaning to do this for OBA myself. I was initially looking in to doing the same for ZXing's BarcodeReader, and was going to move on to OBA next.
This is exactly the technique required to maintain reusable code across the inevitable multiple "platforms" that we will be seeing in the future: Watch, Wear, Glass, Tab, Phone, ...next (Coin, Fit, Bit, ...).
The more convincing perspective should be that this forces better design and higher quality code.
We do this at the company I work at (twistpair.com, now motorolasolutions.com), and in one day we were able to get a fully functioning Glass Live Card Immersion running our PTT app. We are well positioned to write a Watch based app, and we can also choose to release our individual libraries to 3rd parties that can use our PTT library to enable PTT in their own specialized app (that we never would have had the time/domain-knowledge to write).

[barbeau]

@paulpv Thanks! :) I assume you're talking about Gradle build flavors?

[paulpv]

Not really, and I take back a bit of what I said; I hadn't fully reviewed @barbeau's code, and was under the impression from this issue's comments that has was making a common library to be shared between the Glass and non-Glass app.
@barbeau is committing to the existing onebusaway-android project folder, which would break the existing app and never be able to be merged to the upstream master.
For this to ever get merged upstream there would need to a separate "onebusaway-glass" project folder and a "onebusaway-common" library that is used by both the Glass and non-Glass app.
I'd be glad to help make this possible and get it merged back upstream.

[barbeau]

@paulpv Agreed, the branch I'm working on currently is in no condition to be merged upstream - its currently my scratchpad that represents the shortest path to a working prototype Glass app as well as my learning curve on Glass. Final version to be merged would take a much different shape. I appreciate offer to help - let me polish things up a bit first though.

Have you used gradle build flavors at all? Seems like we could treat Glass as a flavor of Android project instead of completely new application w/ library project (though I do agree that certain classes, like oba.elements.*, would be useful as library in general for other Java clients, e.g., Mirror API web app).

Per Android Gradle plugin docs:

Product flavors

A product flavor defines a customized version of the application build by the project. A single project can have different flavors which change the generated application.

This new concept is designed to help when the differences are very minimum. If the answer to “Is this the same application?” is yes, then this is probably the way to go over Library Projects.

IMO, the answer to "is this the same application?" is "yes", so I'd like to explore build flavors before going down the library route, unless we have a good reason not to.

[barbeau]

I heard back from the Google Glass Review Team that reviews voice command submissions, and they are suggesting a change in voice command to "Show me transit times" (with an assumption that this will be the official command for this type of content going forward). So, I've changed the voice command in the current version of the app and updated the original post above (including screenshot) with the changes.

[paulpv]

I'm skeptical that this is "the same application" as onebusaway-android (for legacy reasons, "com.joulespersecond.seattlebusbot"). The manifest's would be quite a bit different, and I would not expect it to be the same package name in the store (maybe that isn't a requirement to be "the same application"). Basically, the Glass app would be semantically no more the same as the Android app than the iOS app is. Sure, they do the same net thing, but they are intended to be run on different "platforms". I would expect the Glass app package name to be something like "com.joulespersecond.onebusaway-glass".

[paulpv]

@barbeau I cannot open issues on your fork, so I am piggy-backing here. Have you noticed that your ListActivity no longer scrolls up/down with left/right swipes? Here are some SO links that may help to solve the problem:
http://stackoverflow.com/questions/23097555/how-to-enable-scrolling-on-a-simpleadapter-on-google-glasss-firmware-x16/23146305#23146305

Here is my app's issue, specifically related to PreferenceFragment: http://stackoverflow.com/questions/23160084/preferencefragment-cannot-scroll-up-down-on-xe16-worked-fine-on-xe12

[barbeau]

@paulpv Thanks for letting me know! Hadn't noticed that. I'm guessing this is another thing that XE16 broke. Thanks for the SO links, I'll check them out! I just added the issue feature on my fork to track specific Glass problems, and added an issue about it there. Please also feel free to open transient Glass-specific issues there in the future.

[barbeau]

Mockup of possible menu structure:

Google Doc drawing is here.

Feedback is appreciated.

[dakini3]

Hey there Sean - I am trying to get One Bus Away sideloaded. I have the ADB installed and can run terminal and have downloaded the One Bus Away APK but I am not certain where the APK needs to reside on a Mac for the ADB to access it. Are there any Mac people around that can assist me with sideloading?

[barbeau]

@dakini3 Unfortunately I'm not going to be much help on Mac, but this article looks fairly complete. Sounds like you're near the end, where you need to set up your path so you can execute adb commands from any directory (including the directory you downloaded the OBA Glass APK to). Sideloading a Glass APK is the same as any Android APK, so any general Android/Mac tutorial should help.

[barbeau]

There is now an official library for progress bars on Glass:
https://developers.google.com/glass/develop/gdk/slider

We should switch to this and ditch the current 3rd party library being used.

[barbeau]

Opened a WIP PR for this Glass GDK work so it doesn't get lost - #219.