Developing for Android Wear — A Noob’s perspective
Disclaimer: Familiarity with Android Development is required to understand this post in its entirety. Links are provided to terms the author considers fairly new. I will follow this post up with a tutorial to explain the development process in detail.
Students of the Android Developer Nanodegree by Udacity have to work on a couple of compulsory technical projects, optional non-technical career-building projects and a final technical project which is split into two stages in order to earn a certificate. The last compulsory technical project is on Ubiquitous computing, where a watchface that displays the current date, time and weather based on an already existing Android Application will be developed.
For some reason, I think it was assumed that the students would already be familiar with Android wear devices. Before this project I had never built any app for a Wear device. I didn’t even own one. Of course I had seen wear devices around, but I didn’t understand how it worked. I know, I’m two years late on this one :(
Anyway, I watched the necessary videos that usually precede each project that contained explanations on how to develop this wear application. I had thought I was going to breeze through this project because the requirements were so few and move on quickly to the final project. Alas, I was wrong.
Connecting the mobile device to an Android wear
My problems started with not fully understanding how an Android wear device works. Android wear devices have to be connected to an Android mobile device (phone/phablet/tablet) via a custom Android Wear app developed by Google. Apps built for wear devices are then packaged into the .apk file of the phone application during development and get installed on the wearable device automatically so far it is still connected to the mobile device. This means that to debug an Android Wear app, you must first connect either a real wear device or a virtual wear device (an emulator) to your mobile device whose sdk version must not be less than 19.
I had borrowed a watch to test my app initially. The watch was already paired up with another mobile device. I ignorantly tried instantiating another connection to my mobile phone with the same device, which of course did not go through. Running just the wear application on the device worked although that meant that the wear device did not receive updates from the mobile application.
Connecting the mobile device to an Android wear emulator
After I tried and gave up on the real device, I decided to set up a virtual wear device on the emulator instead. I discovered that to establish a connection between a physical device and a wear emulator, you have to first start up the emulator, navigate to your SDK path via the command line and into the platform-tools folder like so ~/Library/Android/sdk/platform-tools (This is the default path on Mac OS) and type ./adb -d forward tcp:5601 tcp:5601 to establish a connection on port 5601. The -d tells the debug tool to select just one device if you have more than one connected to the computer, real or virtual. Then connect your mobile device via USB to your computer and then start the Android Wear App created by Google and in the top right corner, you’ll locate the switch that toggles the emulator off and on.
Testing the wear application
The next headache was to figure out how to test the wear application. This was an issue because the wear application was built to listen to data changes in the mobile application. It took me a while to figure out that this was supposed to work the same way installing normal wear apps work. It took me even longer to realize that both the mobile and wear apps were supposed to be signed in release mode with the same key before that could work. What I finally settled for was to run the mobile app normally on Android Studio (since it had been said that the wear app would automatically be installed on the wear device).
Listening to data changes on the mobile application via the wear application
So the app was now installed on the wear emulator via my mobile device. The next problem was that it wasn’t registering any changes (if it was, I didn’t see the data change). I had to re-think my previous strategy. What I finally resolved to was to run only the wear application (since nothing was really changing in the mobile app) which got installed on the emulator each time. Lucky for me, there was provision to manually change some settings in the mobile app which triggered a fresh data reload. Between that and debugging with log statements, I was able to get the wear device to display updated data.
Transferring and receiving Assets
I thought I had finally overcome all the challenges until I decided to transfer an Asset to the wear device. This was the weather icon indicating the state of the weather. My first port of call was the developer docs which had sample (supposedly working) blocks of code for transferring and receiving assets. I successfully implemented a transfer from the mobile device to the wear device following their example which I confirmed by logging the callback functions. The next battle was with receiving the assets. I followed the code on the developer docs as usual and then I got the “Unfortunately, Sunshine has stopped” alert on the wear device. I read the Logcat and saw that the .blockingConnect() and .await() methods in loadBitmapFromAsset() were not supposed to be called on the UI thread (I wonder if it was put there on purpose just to test us. You never know.)
AsyncTask came to the rescue as I quickly created one to run all the erring functions.
In the end, I was able to submit the project and meet expectations. Woohoo!
It’s time to take on the final Capstone projects. I can’t wait to see what challenges lie in store for me.
Thought this was great? Please don’t forget to “Recommend” so that others can read it too.
