I am working on a new wear application with a companion mobile app.
It will rarely be necessary to transfer information from the mobile to the watch via Bluetooth connection.
The main wear app is standalone, so transferring data from the mobile phone is a luxury because it will be a more convenient way to set up user preferences than doing it on the watch (Although the settings menu will also exist on the watch).
So I have a dilemma between two options:
Listen to messages coming through the Bluetooth connection only when the app is open on the watch.
The advantage here is resource savings and efficiency (but the question is how much).
The disadvantage is a lesser user experience.
Set up a WearableListenerService that will always listen to messages coming from the mobile phone.
The advantage here is a high user experience since the user will not have to open the app on the watch in order to transfer the data.
The disadvantage here is a waste of resources (and again the question of how much).
What should I do?
How expensive is WearableListenerService in terms of system resources and battery life in particular?
As per the WearableListenerService docs:
The life-cycle of this service is managed by Android Wear. This service will be bound to and events delivered as a result of various Android Wear events, including data, messages and events indicating a device has connected or disconnected from the Android Wear network.
This means that the service is only created when Wear has data, messages, etc. to deliver to your app - when there isn't anything to deliver, the service is destroyed and takes up no resources whatsoever.
If you have any case where you want to receive callbacks while your process is not already open, then implementing a WearableListenerService is exactly what you should be doing.