Miscellaneous (part 6)

Being at the last step of our Android Wear journey suggests us to make some assumptions and considerations on how to take advantage of this new platform in real scenarios. Beside this, we are going to have a brief look at some of the missing elements that we did not touch before, focusing our attention on answering the questions those might have risen in the mind of the readers while going through the entire path.

During the development of our Books application, we realised that a wearable device has usually a different number of limitations those can be masked pairing it with a handheld one. If we want for example to provide price suggestions or places indications about a book offer while the user is moving, we have to take into account that the wearable device might not have a GPS module installed on it and it might not be currently connected with the handheld device. Because of this, even if we can take advantage of the Wearable Api to sync and exchange data, some of the functionalities should not be available on the wearable device if they cannot be satisfied or they cannot be gracefully handled: we should try to inform the users that if they want to use a particular feature in the wearable app, both devices must be paired.

One real example of this is the case when we want to detect the user location. In order to do this we can take advantage of the GooglePlayServices those offer us a way to abstract the location lookups just using the FusedLocationProviderApi. This option makes the most power-efficient decision using the handheld device as first source for the updates if connected and the wearable device as the last resort if not. In this way, in the best case, the location updates happen transparently to us and the price that the wearable device is paying in terms of battery consumption is the one for the communication between the two nodes. As said before, if the two devices are not connected and the wearable has not installed a GPS module, then we cannot detect the user location and we have to notify the user of the problem if disrupting an ongoing action.

Being just a the beginning of the Wearable Era might raise some concerns and doubts about the effectiveness of implementing solutions for Android Wear. If you have followed the entire path of our journey, you should be able to understand that you are not enforced to provide any Android Wear version of your handheld app, especially if there is no reason to do it. On the other side, if you think that your service, taking advantage of the wearable technologies, can offer cool, powerful and useful functionalities to the user, you should start to think about enabling these. At the moment, it is really hard to say if it worths or not to invest days or weeks of development in your company time just to do that. At the same time, being one of the first services landing on wearable devices might give visibility at your app through channels like the GooglePlay (e.g.: GetTaxi, Runkeeper, Endomondo, The Guardian, Duolingo,…), social networks and/or blogs. In order to tackle this problem, we might start to offer at the beginning some ad-hoc notifications for wearables using the WearableExtender class while trying to grab informations about our users. The latter part can be easily achieved tracking the source of the user interaction and providing maybe a light background WearableListenerService that tracks when peers join and leave the wearable network. Doing so allow us to have a better understanding of the World outside and to detect how many customers could possibly be affected by adding functionalities directly on a wearable device. Even if the numbers might be against a wearable(or whatever platform) integration, we should still think about investing a bit of time to provide a better wearable experience at least in the notifications.

Our journey does not take into account Watch Faces but this does not mean that you should not have a look at them.

Thanks everybody for your attention 🙂

Simone

Advertisements

About alchemiasoft

Android Developer at Bloomberg LP. Algorithms and performance passionate. Curious. Eager to learn.

Posted on April 3, 2015, in Android, Development and tagged , , , , , , , , , , , , . Bookmark the permalink. 2 Comments.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: