[Feature request] Allow applications to temporarily override the watchface

[dodoradio]

There are certain usecases (such as a sports tracker) where the user will want to see something other than the watchface as the first thing when turning on their watch.
There are several proposed solutions to this:

• Android Wear sports trackers generally persist on the screen after it has been turned off. This means that turning on the screen will show the app's display instead of the watchface. However, the data is not visible on the ambient display.
• Adding 'complications' to the user's main watchface - modular icons and pieces of data that will show up alongside the main time display.
• Allowing an application to temporarily replace the watchface outright with a different display.
  I personally believe that the third solution is the most appropriate, for the following reasons:
• persistent applications add complexity to the user experience. Currently, when the watch is woken up, it always shows the watchface, a display from which you can get to notifications, app drawer, quick settings and events with one swipe. A persistent application first has to be dismissed before the user before they can perform the normal UI interactions. Then, when the display is turned off, will the persistent application automatically be returned to the screen (this is problematic because 'dismissing' the application does not kill it, which is unintuitive) or does the watchface behave as normal (meaning that the user has to bring up the application again manually, which is frustrating when engaging in, for example, sports activity).
• Complications generally take a secondary position on the watchface, but on general sports trackers the primary display generally prioritises the sports statistics. Secondly, when the user is not recording data, these complications will not work, meaning that the user will have a watchface with either broken UI elements or empty complication positions at all other times. Additionally, the user may just want to have a watchface that has nothing to do with sports most of the time, meaning they will have to manually switch these over before and after ever sporting activity.
  I see the ability for applications to replace the watchface as the easiest solution to this issue, which gives the best user experience. This behaviour should be able to be disabled to stop the application from overriding the watchface, but if the user is correctly informed about this behaviour this should make for the overall better user experience.

[Timo Könnecke]

First of all, i find the 3rd option to be the most logical option for the specified use case.
However, i must say that i can not find other usecases than a sports tracker. Where the user consciously decides to set the watch into a special mode with inherently different requirements to the presentation of the homescreen/watchface. To justify altering the user choosen watchface, clearly understand the benefit, cope with slight inconsitencies and find/know an obvious way how to end this mode. In best case, the user never really has the feeling to leave the sports mode after starting a recording. But perceives the temporary swap of the watchface as a feature of that mode/app.
So that app bound watchface should have a clear dedicated temporary character. Meaning, it should absolutely only be active while the sport is recorded, after the recording is started within the app.
Ending the recoding by means of that swapped in watchface (ie a rather prominent stop button) should bring the user back to the sports app for consistency reasons. Since that is the place the UI path started.
One inconstancy left with this approach might be:
The user perceives the swapped watchface as part of the app like we want to suggest after coming from displayAmbient waking the watch. And tries to operate it like an app but ends up in quicksettings or notifications.
This is quick to discover, learn and remember when bound to the mode however.

Thinking now, this should really be called a mode instead of app bound behaviour due to the UI implications?
As a mode, i could more easily understand that it involves an app and influencing the watchfacehomescreen.

[dodoradio]

looks like this was given the go ahead.
I'm proposing that we expose a secondary value (currently key: "/desktop/asteroid/watchface" is exposed for the watchface file location) through nemo.configuration that would be checked by the loader, probably somewhat like this:

    Component { id: centerPanel; Loader             { source: temporaryWatchFaceSource.value == "" ? temporaryWatchFaceSource.value : watchFaceSource.value } }

The issue I see is that the app providing the temporary watchface may crash (for whatever reason). A reboot/UI restart should fix this (the value should be cleared when asteroid-launcher is started) but I'm not sure if there should be another mechanism to check whether the temporary watchface should still be being displayed.