Which device can run a widget as an app?

SylvainGa said:

the app must be launched from the Activity wheel and not the glance wheel, hence why I asked with watch has 'superapps' so I can exclude those that don't.

Perhaps I’m missing something, but you can accomplish that for *all* devices simply by:

- setting the app type in the manifest to “watch-app” (device app)

- *not* implementing a glance view

That way all devices (whether they support super apps or not) will only be able to launch your app from the activity/app list, and not the widget/glance loop. If I’m understanding correctly, I see no reason to exclude older devices. 

I am confused as to why you characterize your app as a “widget”, given what you said above. The main distinguishing feature of a widget is that it can be launched from the widget/glance loop. If the point of your post is to somehow force your “widget” to only be launched from the activity list, all devices already have that concept - it’s called a device app (*). (* On newer devices, it’s a device app that lacks a glance view.)

So to be clear, on devices with CIQ < 4:

- widget and device app (“watch-app”) are distinct app types

- Widgets are available from the widget/glance loop, and never the app/activity list. On devices with glances, if the widget doesn’t implement a glance view, the system provides a default glance view (which is basically just the app icon and name)

- Device apps are available from the app/activity list, and never the widget/glance loop

On devices with CIQ >= 4:

- There is no widget app type. Any app that has “widget” in its manifest will get compiled as a device app (“watch-app”). In this way, widgets have been merged with device apps (which was previously referred to as the “super app” concept, but again, good luck finding any mention of this in current documentation)

- Device apps are always available from the activity/app list

- Device apps are available from the glance loop, only if the developer implements a glance view (there is no system-provided default glance view)

There, done :-) Testing it before releasing at large. This is the section of the doc for it.

Dog mode watcher

On watch that can run this app from the activity wheel and not just from the glance wheel or as a widget, you can activate the Dog mode watch from the menu. Do not run the app from the Glance wheel for this feature since that wheel terminates the app after just a few minutes, unlike the Activity wheel which will leave the app running for as long as the user do not terminate it, or the watch runs out of battery.

When this mode is activated, the main screen changes to the following view:

The time is displayed at the top and follows the 12h/24h you’ve configured your watch to.

Below the time are three fields of importance to watch the state of the dog mode. The State of Charge (SoC), the current inside temperature (follows what temperature format you’ve configured your watch for) and the time since the last temperature reading was read from the car.

If the SoC gets below 25%, the temperature gets above 25C (77F) or the last time since the last temperature reading was read is over 2 minutes, the corresponding field will turn red.

Beside turning red an alert will be displayed on screen (except for SoC which will alert at 20%), and the watch will vibrate and sound an alarm (depending on the attention feature your watch has) for every second that any of these conditions are met.

Watches that can’t run this app from the activity wheel will simply display a message on screen saying it’s not available.

Use at your own risk. I can't be held responsible if the app fails to work as advertised and the climate fails in the car.

I haven't seen any Tesla app on other watches brand that has that feature :-)

2 questions:

Why don't you disable glance?

Is the Tesla side aware if the watch is getting the updates? For example if you are far away from your phone, or if there's no GSM in the phone?

SylvainGa said:

Testing it before releasing at large. This is the section of the doc for it.

Dog mode watcher

On watch that can run this app from the activity wheel and not just from the glance wheel or as a widget, you can activate the Dog mode watch from the menu. Do not run the app from the Glance wheel for this feature since that wheel terminates the app after just a few minutes, unlike the Activity wheel which will leave the app running for as long as the user do not terminate it, or the watch runs out of battery.

I guess I failed to communicate clearly before.

There’s no need to tell your users not run the app from a glance or as widget. The solution to your problem is don’t build your app as widget, build it as a device app without a glance view.

If you build your app as a device app without a glance view, then all watches (new and old) will only be able to run it from the activity list and not the glance/widget loop.

Again, I’m extremely confused why you want your app to be a widget but you don’t want it to run from the glance/widget loop. An app that can’t run from glance/widget loop is not a widget, it’s a device app (without a glance view).

Because Glance is useful to quickly look at the state of the vehicle (which grabs it every five minutes) without having to launch the app. Is Sentry On? Has it finished charging? A quick look at Glance will tell you. This is what the glance view shows:

I don't want to lose this by having just an app.

I see thanks for clarifying!

Then here's my suggestions:

- set minSdkVersion (which actually means min api level) in the manifest to 4.0.0. This will exclude all devices which don't support super apps

- in your app code, detect whether the main app was launched via glance or not (see below)

- if the app was launched by glance, you can switch to a limited functionality mode with whatever functionality that won't be impaired by the "widget timeout". Or you could just display a message telling the user to exit since there's nothing that can be done in this mode. (Or some combination of the two - e.g. perhaps display a message saying that this is limited functionality mode, and they need to launch the app from the activity list to get full functionality.) Or even better, just have the app behave normally, but display a message when they try to use functionality, like dog mode, which won't work properly when launched from a glance.

- if the app was not launched by glance, enable all functionality

It's just my opinion, but simply putting a note in the store page / docs that tells the user not to launch your app from its glance will not lead to a good user experience. There will always be users who don't read the docs.

EDIT: In your specific case, if the user launches the app from its glance, and they try to activate dog mode, then you can display a message which says it won't work here, and direct them to launch the app from the activity list. That would be the best approach imo - only display an obtrusive message when necessary. Ofc that's assuming that most of the functionality will still work properly when launched from a glance.

sabeard said:

In the SDK, core topics file there is an example of how to check if an app was launched from the glance.

https://developer.garmin.com/connect-iq/core-topics/application-and-system-modules/#launch

you can check the state in the onStart function for the :launchedFromGlance object.  It if exists and is true, then the app was launched from the glance view, otherwise it was not.  The link above has an example or more detail in the onStart method in the API reference.

https://developer.garmin.com/connect-iq/api-docs/Toybox/Application/AppBase.html#onStart-instance_function

But even if I launch it as an app but later (let's say accidentally) I exit (go back to the watch face) I won't know when my did will start to be cooked...

There's things that can be done to mitigate the risk of accidental app exits though.

I can think of 3 ways that an app can be accidentally exited (terminated):

- User accidentally presses BACK or swipes right at the top level view

This can be avoided by overriding onBack() at the top level and implementing an app-specific menu. (Similar to the activity pause menu)

- User accidentally exits the app using an app-specific action (e.g. menu item)

In this case, the app should be designed so that it's not easy to accidentally trigger an app-specific exit action. e.g. if the app is in dog mode, any attempt to exit the app could come with a confirmation prompt

- User presses a hotkey (whether built-in or user-defined) to return to the watchface

(I understand that on Fenix 7, holding BACK is a built-in hotkey to return to the watchface. On devices like 955, there is no built-in hotkey, but you can assign a user hotkey to do the same)

This is a little tricky. *Normally* when you return to the watchface this way, the app will be terminated, meaning that if you reopen the app, all state will be lost (other than what has been saved and restored at startup ofc.)

But if the app is recording an activity, then:

- on older watches you simply won't be allowed to return to the watchface. (not relevant in this case since OP only wants to support new watches) (there may be convulated ways to return to watchface, like opening the stopwatch from the controls menu and selecting "return to watchface", but they're not likely to be triggered accidentally, and they do cause the app to crash iirc)

- on newer watches you'll return to the watchface, but the app keeps running and when you press START or BACK at the watchface, you'll be returned to the app (with no way to select any other activity or app.)

So to partially mitigate this problem, you could starting recording a dummy activity when the user turns on a mission-critical app mode (like "dog mode"). (When the user turns off dog mode or otherwise exits the app on purpose, you can discard the activity.) This won't prevent the user from returning to the watchface indefinitely, but at least the app will still be running.

Additionally, vibrations or tones will still play while the app is still running, an activity is recording, and the user is at the watchface, which means the app will still be able to alert the user of a dangerous condition. (I tested this on my FR955 with a modified version of the RecordSample that plays a tone and vibrates every few seconds while the app is recording.)

TL;DR if it was me, I would:

- design the UI so it's not possible to accidentally exit the app via BACK / swipe right at top level or an app-specific action (e.g. menu item), at least when the app is in a mission-critical state (like "dog mode")

- handle the "return to watchface" hotkey loophole by recording an activity during a mission-critical app mode (like "dog mode"). that way when the user returns to the watchface, the app won't be terminated, and any vibes or tones that the app plays will still be felt/heard by the user.

Well the app is a back up to the mail phone app so there is still that. Beside what FlowState mentioned as mitigation technique, I thought about something that I'll need to try if it works, although it will require the Crystal-Tesla watch face being used as well.

If the app abnormally terminates (as in crash) with the Dog Mode watch still active, its background process will be made aware of it (through a Storage value) and will push a Complication telling so. That same Complication will be sent if the user accidentally presses BACK or swipes right at the top level view. When the watch face receives that Complication, it will relaunch the Tesla-Link application (like for OnPress). When relaunched, it will auto go back into the Dog Mode watch view. If it works, it would be a neat trick to keep the app active (with a max delay of 5 minutes before respawn).