Skip to content
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

Add Android Wear support #181

Open
barbeau opened this issue Oct 6, 2014 · 12 comments
Open

Add Android Wear support #181

barbeau opened this issue Oct 6, 2014 · 12 comments
Milestone

Comments

@barbeau
Copy link
Member

barbeau commented Oct 6, 2014

Requested by a user.

For adding support for existing notifications, see:
https://developer.android.com/training/wearables/notifications/index.html

@barbeau
Copy link
Member Author

barbeau commented Oct 6, 2014

To clarify user's request:

I was more curious about an actual android wear app option where I could check times on my watch via voice commands

I believe this falls into the category of wearable apps:
https://developer.android.com/training/wearables/apps/voice.html

@pohh
Copy link

pohh commented Nov 21, 2014

@barbeau I would like to take a stab at this.

Is there a process to begin work, or can I fork and submit the pull when it's ready for review?

@barbeau
Copy link
Member Author

barbeau commented Nov 21, 2014

@pohh Sure, that would be great!

For contributing guidelines, please check out this readme, which includes code style guidelines, ICLA, etc.

As far as logistics, I haven't done any Wear stuff myself other than to check out some of the docs, but at this point I would think it would probably be easiest to fork the CUTR-at-USF fork of the OBA Android project, and start a new branch off my current UI-redesign branch, and then submit a new Pull Request against that branch. The UI-redesign branch already contains the updates to the newest SDK, build tools (including material design for Android 5.0), and support libraries (not to mention some core refactoring of the package names) so I think this will be the easiest path forward for you (assuming that all Wear features can be developed against the newest SDK and build tools), and will also avoid a lot of conflict resolution later. As I mentioned in the other thread, we should be able to keep support for Android 2.3 in the UI-redesign, so we don't lose anything in terms of backwards compatibility by focusing new feature work on that branch.

Please take a look at this and let me know if you have any questions. Also feel free to open a PR as a work-in-progress (just be sure to label it as such) so we can take a look at your work along the way. Ideally this work would include an update to the current notifications, but let us know what you think when you're further into this.

Thanks for giving this a shot!

@pohh
Copy link

pohh commented Nov 21, 2014

Sounds good.

From the user request it sounded like voice recognition support for the app was the use case to implement.

Should the first iteration of wear support be scoped for:

  1. notification features. Stacked notifications, interacting with notifications
  2. voice control of specific use cases

@barbeau
Copy link
Member Author

barbeau commented Nov 21, 2014

I would vote for 1), as I think this is basically an overall of the
existing notification feature that includes a push to Wear devices. I
think this should be fairly straightforward to implement, and easily
mergeable.

From my (very basic) understanding of Wear, I think 2) may get more into a
separate APK that runs on the Wear device. This would obviously be more
difficult to implement/manage, and may not easily be mergeable back into
the core project (at least without using something like Gradle build
flavors). The Glass APK that I did had similar limitations.

I'm not exactly sure where the feature line is between using the existing
app and having to package a separate Wear APK, so it would be good to know
that after you dig in a bit.

For either, I would suggest posting a very simple UI mockup before full
implementation just so others can give feedback along the way.

Either way, I'm excited to see what you come up with! :)
On Nov 21, 2014 3:39 PM, "p oh" notifications@github.com wrote:

Sounds good.

From the user request it sounded like voice recognition support for the
app was the use case to implement.

Should the first iteration of wear support be scoped for:

  1. notification features. Stacked notifications, interacting with
    notifications
  2. voice control of specific use cases


Reply to this email directly or view it on GitHub
#181 (comment)
.

@pohh
Copy link

pohh commented Nov 21, 2014

Fair enough. Updating notifications to support wear formatting looks fairly straightforward. I'll move forward by taking some time getting familiar with the current notification cases. Once I get a handle on that I'll put out a UI design that leverages wear functionality where it makes sense.

I think you are correct in your assumptions about a separate wear APK, and it does add some lift to the build and deployment pipeline.

@barbeau
Copy link
Member Author

barbeau commented Nov 22, 2014

Sounds good! IIRC, the only notification in OBA currently is the reminder
for when your bus is going to arrive. Should be in the "tripservice"
package.
On Nov 21, 2014 4:09 PM, "p oh" notifications@github.com wrote:

Fair enough. Updating notifications to support wear formatting looks
fairly straightforward. I'll move forward by taking some time getting
familiar with the current notification cases. Once I get a handle on that
I'll put out a UI design that leverages wear functionality where it makes
sense.

I think you are correct in your assumptions about a separate wear APK, and
it does add some lift to the build and deployment pipeline.


Reply to this email directly or view it on GitHub
#181 (comment)
.

@pohh
Copy link

pohh commented Nov 25, 2014

@barbeau
Copy link
Member Author

barbeau commented Dec 3, 2014

@pohh When you're working on Notifications for Wear, it would be great if you're able to eliminate the call to Notification.setLatestEventInfo(). There's a nasty bug in current Android versions (5.0 and earlier) where apps aren't notified of a user dismissing the notification if this method is called, which can result in the notification being displayed again later. See #104 for how this affected OBA Android. I implemented a workaround for this for OBA Android in #150, but in the AOSP issue I filed Google has made it clear that we should be using only Notification.Builder, and not call the deprecated Notification.setLatestEventInfo() method.

@brendandburns
Copy link

Was any work done on this? If not I'd love to pick it up as something to explore.

Any pointers you may have would be welcome.

Thanks!
--brendan

@barbeau
Copy link
Member Author

barbeau commented Oct 14, 2016

That would be great! @pohh got a proof of concept working - see #198, and #197 stubs out a breakdown of the project into modules to help support this . The PRs were closed during the merge process of some of the unrelated UI redesign work for v2.0 back to the master branch, so the first order of business would probably be seeing how far this work has diverged from current master branch and possibly rebasing.

@pohh if you have any wisdom based on your work feel free to chime in.

@pohh
Copy link

pohh commented Oct 26, 2016

The wear app was functional but after looking at the resulting wear app i believe it was overkill.

Implementing voice search intents and rich notifications should get you a lot of oba functionality on the wear device without needing a wear app. The previous attempt was a littlw heavyweight. Id consider rich notifications and voice search intents first.

Ive been meaning to get back to this but started a new job shortly after conpleting first slice of the pull request and havent had a chance to finish up. Glad someone else is interested in finishing this up! Im out of country at the moment but if you have any other qs i can do my best to help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants