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

Android Wear Module #58

Open
wants to merge 22 commits into
base: master
Choose a base branch
from
Open

Conversation

Querschlag
Copy link
Contributor

Related discussion: #57

To share relevant code between the watch and the handset app I had to restructure the project.
Base classes like Tick and Track are now located in the tickmatelib module along with some assets the watch app uses.
I also bumped the target-sdk to 23 (Android M) and implemented the required permission requests when accessing external storage (DB-Backup).

@lordi
Copy link
Owner

lordi commented Dec 6, 2015

Please update .travis.yml to reflect the usage of sdk version 23, so that the tests will run properly on travis.

@lordi
Copy link
Owner

lordi commented Dec 8, 2015

Thanks alot for the PR. I still have a few questions.
Whats your rationale for moving some classes to the "tickmatedata" package? I guess you wanted to use the models in the wear app as well. Can't the wear app use the classes from the tickmate package?

@Querschlag
Copy link
Contributor Author

I guess you could refrence classes and assets from the tickmate package, but it seemed to be more structured that way.
Refrencing the tickmate package as dependency for the wear package is a bit too much, as the wear app doesn't need the whole package.

@lordi
Copy link
Owner

lordi commented Dec 31, 2015

So I tried to run both apps with two paired emulators. Pairing with the Android Wear app works, but running Tickmate on the watch emulator only shows a loading animation and the following entry in the log files:

Caught a RuntimeException from the binder stub implementation.
java.lang.SecurityException: Neither user 10025 nor current process has android.permission.WAKE_LOCK.
at android.os.Parcel.readException(Parcel.java:1620)
at android.os.Parcel.readException(Parcel.java:1573)
at android.os.IPowerManager$Stub$Proxy.acquireWakeLock(IPowerManager.java:357)
at android.os.PowerManager$WakeLock.acquireLocked(PowerManager.java:1111)
at android.os.PowerManager$WakeLock.acquire(PowerManager.java:1079)
at com.google.android.wearable.compat.WearableActivityController.postEnterAmbient(WearableActivityController.java:250)
at com.google.android.wearable.compat.WearableActivityController.-wrap4(WearableActivityController.java)
at com.google.android.wearable.compat.WearableActivityController$AmbientActivityCallbacksStub.enterAmbient(WearableActivityController.java:563)
at com.google.android.wearable.ambient.activity.IAmbientActivityCallbacks$Stub.onTransact(IAmbientActivityCallbacks.java:61)
at android.os.Binder.execTransact(Binder.java:453)

Any hint? Oh, and have a great new years eve :-)

@Querschlag
Copy link
Contributor Author

As for the warning: Normally this shouldn't be a concern, but adding the wake lock permission to the Manifest of the wear module should clear the warning.

Running with a handset(emulator) and watch(emulator) setup won't work. You need the Android Wear app from Google Play as well as the Google Play Services and those aren't available on an emulator.
Install the handset app on a physical device and pair the watch emulator in the Wear app.

@lordi
Copy link
Owner

lordi commented Jan 1, 2016

Okay, I got it to work with WAKE_LOCK permission.
It does work with two emulators, if you use the "Google APIs" base image and install the Android Wear APK via adb install.

I like the navigation of the wear app. One question that comes to mind: There seams to be no "sync" between the phone app and the wear app while both are running. Would such a thing be feasible?

@Querschlag
Copy link
Contributor Author

Shouldn't be a problem to trigger an UI update on the phone when receiving a message from the wearable. Updating data changes on the watch should be handled more conservatively as real devices are way slower than the emulator.

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

Successfully merging this pull request may close these issues.

2 participants