Beginnigs of a Wear app #3
Conversation
You'll still need to manually copy the Android support library from holoeverywhere into drag-sort-listview to make it build. This support library is NOT the one from Google, but is built with extra features needed by holoeverywhere.
To be built with Gradle, Android Studio.
This is just rudimentary and invents entirely new logic on the wearable to format the timestamp, etc. The wearable does not share any Departure logic with the phone application, so this is currently no better than just launching a static notification from the handheld.
WearableDeparture mocks the Departure class on the main handheld app, but it only functions as a remote for the updates that come from the handheld.
This also adds an action button to cancel the notification.
This blinks the icon in the notification, though :(
I'm not the only one who can't figure this out. StackOverflow has a thread wherein: A: "Just do this." B: "It doesn't work." A: "It works on $DEVICE." B: "It doesn't work on $SAME_DEVICE." A: "Here, compile this from Github." B: "Yeah, it still doesn't work." Url: http://stackoverflow.com/questions/25499834/android-wear-timer-like-notification-card-on-wear-device
This uses a GoogleApiClient instance variable that is co-opted to mean "if mGac is not null, then this is the boarded departure". It updates the wearable whenever mergeEstimate() is called. The Wear API update moves to the Departure object, so it can get called by the BART API network handler threads.
|
Nice! Thanks for putting this together, and I admit I'm a little embarrassed that I didn't get a chance to clean up the whole build process and forcing you to go through that slog. I'll try to get through this code as soon as I can (the app is sorely in need of an update, anyway). I'm actually thinking of dropping < 4.x support to keep things simple, so hopefully HoloEverywhere and ABS won't be necessary in any case. |
|
A couple more days of hands-on commute testing reminds me that this is still definitely a work in progress... to add to the above list of known issues: I've managed to get the Wear app side of it in a state wherein the cancel button does nothing, so I have to pull out my phone to make the ongoing-notification disappear. Hopefully I'll get a chance to update the pull request with fixes to these things this week or next. About < 4.x support: with the current releases of HoloEverywhere, it worked fine for me to target API 8 as you already do. I don't really see an immediate need to kill off support for devices, since Google's v7-appcompat library replaced the need for ActionBarSherlock with only minor changes. |
|
Hey guys, I thought I could help out to get this polished up a bit. I managed to get the pull request download but I'm not sure what I need to do to build and push it to my emulator. Can either of you point me in the right direction for this? Thanks! - Shawn |
|
It's been a while since I've touched this, but I just had a coworker ask me about the state of the project too :) For the handset application half: that still builds with Eclipse, and it requires a couple of dependencies -- all of which also need to be imported into Eclipse. You should be able to get them with a "git submodule update", but it looks like I did have one local change for If I recall correctly, the support-v4 JAR I used was the upstream from Google, as the one in the git repo was customized. The Wear application half is much easier, since it's an AndroidStudio project. You should be able to import it directly. I also have local changes to change the APK package name of both applications so I can have it installed alongside Doug's official Play Store release. The package name of the Wear and handset applications must match in order for the Wear API to work. As far as known bugs go, the worst one that annoys me has been the action attached to the notification often doesn't actually receive events (and thus I can't cancel the notification from the wearable). Still haven't managed to track that one down -- once it hits, the intent doesn't even seem to fire and so there's nothing to even catch in the debugger. My best guess right now is the Wear device low-power states, perhaps. |
|
Thanks to FuegoFro, we're now using Gradle for building and the whole project is Android Studio compatible. If you're still up for it, I'd love to have this project revived. |
|
Awesome news. I'll try to rebase on top of that and get the Wear app at least to the state I had it in. |
3 participants
This is very much still a work-in-progress, and you probably shouldn't merge it as-is. I would like to get reviews for it in the meantime, but I am fixing a couple things as I go along.
Known issues with this changeset:
I did have to upgrade holoeverywhere to get it to build (for reasons I can't quite remember, but maybe for the support library JAR that needs to be copied around), which had a trickle-down effect of needing to get rid of ActionBarSherlock too.
You should be able to build the wearable project by simply "Importing"
wearable/build.gradlein Android Studio.