-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OneBusAway Glassware - native GDK version #116
Comments
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. |
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. |
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. |
@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. |
@paulpv Thanks! :) I assume you're talking about Gradle build flavors? |
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. |
@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 Per Android Gradle plugin docs:
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. |
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. |
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". |
@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: 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 |
@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. |
Mockup of possible menu structure: Google Doc drawing is here. Feedback is appreciated. |
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? |
@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 |
There is now an official library for progress bars on Glass: We should switch to this and ditch the current 3rd party library being used. |
Opened a WIP PR for this Glass GDK work so it doesn't get lost - #219. |
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:
gradlew installDebug
from root of project using command-lineOBA 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 aListActivity
instead ofListFragment
). 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.
The text was updated successfully, but these errors were encountered: