Widget?

[house-of-abbey]

Widget?

[philipabbey]

Maybe the toggle state of a button, or if the home assistant instance is currently available for the watch. But I would start with the name only and adding more glance / widget somewhere in the future.

Whatever goes in the glance view, must be quickly retrieved for display. Connectivity could be done via an icon.

[Someone0nEarth]

Just thinking a bit: Maybe it is possible to have a hybrid project with two "Jungles" sharing the same source (using build exclusions)? One Jungle for app type and one jungle for widget type?

https://developer.garmin.com/connect-iq/reference-guides/jungle-reference/

[philipabbey]

I'll make some time to work through these comments and look at your branch this week.

[philipabbey]

My watch is a "Venu 2".

Widgets have been reimplemented as glances
https://forums.garmin.com/sports-fitness/healthandwellness/f/venu-2/279038/are-there-widgets-in-venu-2

I have played with glances in Venu2 for another application. Note they do not accept user input. For that you need an App. So App is the way forward, but you are welcome to try its just I won't be able to benefit from such efforts!

[Someone0nEarth]

Oh interesting... Hmm.. I did some googling.. looks like, that glances are a way to display information quickly (w/o direkt userinput). But: Clicking on a glance can start a widget or an app.

As far as I understand, that normal widgets are still work on devices like Venu 2, if the widget has a glance support:

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/widget-glances---a-new-way-to-present-your-data

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/widget-glances---a-new-way-to-present-your-data

[philipabbey]

It looks and smells just like an application with a glance view. Meaning the "widget" part of that could be quite misleading. When I create a "widget" project I get these classes, just like an application.

class widgetApp extends Application.AppBase {
class widgetView extends WatchUi.View {

This bit is glance specific (not 'widget', that's just the article's own naming convention):

class WidgetGlanceView extends Ui.GlanceView {

It looks just like an application with a glance view. Because glances don't accept user input they are not workable with the current "actions only" GarminHomeAssistant. I admit to be quite confused, and just assumed they related to older watches.

[Someone0nEarth]

Ops.. I accidentally double posted the one link in my last comment..I wanted to post this one too:

https://developer.garmin.com/connect-iq/core-topics/glances/

Okay.. and yep, I am a bit confused :)

But for example, this "widget" (it has type widget in the manifest.xml and a glance view) will work on your Venu 2, or?

https://github.com/hatl/hasscontrol

https://apps.garmin.com/de-DE/apps/3dce2242-473f-4f13-a6a9-299c3686611f?tab=reviews&criteria=rating&ascending=false&displayCurrentVersion=false

[JosephAbbey]

Hi Someone,

I have some thoughts on this topic:

• Supporting widgets or glances would require a new UI design due to their limitations (space/scrolling).
• Widgets don't make sense as a way of controlling the home but may work to quickly view the state of something (temperature or door). They would be too easy to accidentally activate and there isn't enough space to fit loads of buttons.

That being said if you want to try writing a widget or glance, you can pull request but this should be done in a simple way and should be configurable via the JSON in a similar style to how we are currently.

Thanks

[philipabbey]

Venu®‎ 2 Series Owner's Manual - Garmin International

In the Venu 2 user guide I can only find one mention of 'widget' as follows:

From the devices widget in the Garmin Connect application, select your watch.

This is talking about the Garmin Connect App rather than the watch. I don't think that I have any 'widgets' on my watch, and perhaps 'widget' is an alias for 'application' on later Garmin models?

[Someone0nEarth]

I have some thoughts on this topic:

* Supporting widgets or glances would require a new UI design due to their limitations (space/scrolling).

* Widgets don't make sense as a way of controlling the home but may work to quickly view the state of something (temperature or door). They would be too easy to accidentally activate and there isn't enough space to fit loads of buttons.

I think there is a misunderstanding what "widget" means (thanks to Garmins chaotic wording and documentation). My current understanding regarding glances, widgets and apps is:

• Glances are only for showing data (so no interaction and stuff)
• But: Clicking on them can start an app OR a "classic" widget. The widget needs to have a glance view, for being started on devices like Venu 2. (Btw I never had the issue accidentally activate something in Home Assistant using a widget. Because how this widgets are implemented. Hard to describe, maybe you can test it to see it :)
• A widget can be like an app, but has a few restrictions and will be closed after some time. Although a widget can be used just to display information, like a glance.
• An app has to be closed/stopped by the user
• Widgets and apps both extends App.AppBase (I think, the "difference" is the "type" in the manifest.xml)

All home assistant "apps" I used in the past year on my Venu were widgets (with equal "complexity" compare to GarminHomeAssistant) like:

• https://github.com/alanfischer/hassiq (no longer maintained)
• https://github.com/hatl/hasscontrol
• The store link https://apps.garmin.com/de-DE/apps/3dce2242-473f-4f13-a6a9-299c3686611f?tab=reviews&criteria=rating&ascending=false&displayCurrentVersion=false

Hasscontrol is a widget and has a glance view. I tried to test it on the Venu 2 emulator, but I could not compile it using Visual Studio Code (it looks like it is an Eclipse project).

Maybe you could install it on your Venu 2 using the store link just to see, how it works on a Venu 2? I would bet, the "widget" will be listed in the glances loop, displaying the name "hasscontrol" and when you click on it, it will start the widget and you can control home assistant with it.

Have fun,
someone

[philipabbey]

If we gave GarminHomeAssistant a glance view (not proposing we do), it would behave the same way. I'm seeing no advantage to getting on the carosel, glances still launch an App, but ought to display some info to have a purpose.

I still see (deprecated?) widgets as some alias for glance + app. I really don't see they are relevant to more modern models of watch when they are not mentioned in their manual. What you are proposing with all the experimenting is not without a significant amount of effort, and I'm afraid I am bandwidth limited.

Based on the evidence so far, I'm out. The app is precisely what is useful to me and I'm liking your recent proposed changes. Thank you!

[philipabbey]

Venu™‎ Owner's Manual - Garmin International

Venu1 does have widgets, they get plenty of mention in their manual. So I conclude you have an interest in them and I don't...! Sorry, I can't test widgets on my device.

[Someone0nEarth]

Hello!
Yes, I understand that Venu has widgets and Venu 2 has glances for the "loop ui part". But, as far I understand the whole thingy, Venu 2 can use/start "oldschool" widgets too, using glances to start them (like in hasscontrol). But I can´t test it atm. So an easy test could be, if you would install for example hasscontrol on your Venu 2 :) Its an "oldschool" widget with a glance view.
But sure, if you are not up to test it, its fine :)
I am trying to understand the whole widget/glanbce thing, purely out of interest. And sorry, maybe sometimes my writing can be misleading... My English is not on a mother tongue level :)

[philipabbey]

My point is, even if we did make widget (Venu1) or a glance (Venu2) what info would you populate in the carosel view? Why not save the bother and just launch as an App?

Your English is superb by the way.

[Someone0nEarth]

If we gave GarminHomeAssistant a glance view (not proposing we do), it would behave the same way. I'm seeing no advantage to getting on the carosel, glances still launch an App, but ought to display some info to have a purpose.

I still see (deprecated?) widgets as some alias for glance + app. I really don't see they are relevant to more modern models of watch when they are not mentioned in their manual. What you are proposing with all the experimenting is not without a significant amount of effort, and I'm afraid I am bandwidth limited.

Based on the evidence so far, I'm out. The app is precisely what is useful to me and I'm liking your recent proposed changes. Thank you!

Oh, I overlooked this post. I am not proposing to change GarminHomeAssistant to a widget yet (because of the current level of information I have about glances/widgets on never devices).

I think, it could be a possible improvement to use it as a widget (or a glance, that starting the widget), because it will be stop after some time automatically. So the user dont have to stop it. This can be comfy and although reducing possible battery drain. Although a widget can be started/used, when an app is already running (old Venu.. don`t know how this is applicable for modern devices too). On old devcies like the Venu, only one app can be running at the same time.

I am assuming that this widget behaviors would be the same on Venu 2, when a widget will be started by a glance. But, because of the poor documentation and wording on Garmins side.. this assumption is based on really weak indications. I would need to do some testing, to clarify it. Sadly I don´t get hasscontrol to be compiled yet. Maybe, I can write an widget with a glance view in the next days and run it on the Venu 2 emulator. But I fear, that using the emulator won´t be meaningful enough.

@ Your English is superb by the way: Thanks! I wish my english teacher back than would hear this ;-)

[Someone0nEarth]

I did some local tests using GarminHomeAssistant as a widget and a glance that is starting the widget on newer devices. It work really good. On newer devices, there were a glance with the name, and when you clicked it, it just started the "app" as normal (but I think with a different life cycle).
The Code is like 99,9% the same. But it would need some changes about the initial view instances etc. . So, I dont think it would be a quick hack to have the same code base for widget/glance widget and app.

I was using the (non-widget) app for two weeks now on a daily basis. And I often forgot to close the app, which led into high amounts of battery drains 🙈. Sure, the toggle status refreshment could be adjusted, but for me, an app like this is not a long running one like a running tracking app, music player etc.. it is more like a fire and forget use case :)

I am thinking about to clone (not fork) your project and changing it to be a widget (with a glance representation for starting it on newer devices).

There would be a possible way to extract core libs to use in for both cases. But I dont know if this effort would be appropriate for a small application like this project.

What are your opinions?

[JosephAbbey]

Hi, this sounds interesting, could you send some screenshots of the widget and glance views please.

[philipabbey]

Someone0nEarth:

but for me, an app like this is not a long running one like a running tracking app, music player etc.. it is more like a fire and forget use case :)

I share this philosphy. I've just not had a problem with closing the app 😃.

There would be a possible way to extract core libs to use in for both cases. But I dont know if this effort would be appropriate for a small application like this project.

Preference for one main code base.

We've done an App with a glance before (not published). For an idea of what we would be in for see https://github.com/house-of-abbey/GarminThermoNest/blob/main/source/ThermoNestApp.mc#L26. You will need various things marked with (:glance) to make them available in the Glance part of the code.

I've just checked on my Venu2. Adding a glance to the App does not force the invocation to only come from the glances carosel, the App also remains in the list of Apps. This means that I can continue to start the App my preferred way, and not be forced to clutter up my already busy carosel.

Testing the ThermoNest app on my watch just now, it does seem to close automatically after a period of time.

The galnce view remains a bit of "wasted space" as presently it is just an app name with no status to display, which loses some appeal for me.

I wonder if we could:

• Include a timer in the existing App such that after Properties.get("timeout") has passed since the last touch or button the app gracefully closes? That would mean each view delegate needs to update a central value with the time of last action, and then something needs to track that last time + timeout to close the App. Or

• We use https://developer.garmin.com/connect-iq/api-docs/Toybox/Timer/Timer.html with a callback? Extend the Timer class to add a reset() method which is essentially a stop() followed by a start() using the same callback. We reset() on each touch from each view delegate.

Do you have any further insights into the difference between a "widget" and an "App with a glance view"? Widgets are still sounding redundant on modern watches, like they have been replaced by an App that implements a glance.

[Someone0nEarth]

Hi, this sounds interesting, could you send some screenshots of the widget and glance views please.

Hello!

Here is the glance view:

When you click on it, the normal GarminHomeAssistant will be started. The widget view on older devices looks the same, only difference is, that it would be displayed on the whole display (and not in a 1/3 slot when in glance view).

[Someone0nEarth]

Here is the quick and dirty prototype:

https://github.com/Someone0nEarth/GarminHomeAssistant/tree/widget_glance_prototype

This change the type to widget (which also has a glance view for newer devices). On my Venu, it is no listed as an app (only as an widget)

@philipabbey Could you test it on your Venu 2, if this can be still "used" as an app?

[philipabbey]

Your screen shot shows that your "widget" is essentially working the same as an App with a glance view. I am trying your code locally presently and the simulation confirms the same. There seems to be no immediately discernable difference between widget and "app with glance".

My previous concerns with providing a glance remain, we have no status information to publish, and the app name alone is a bit 'naff'. We could provide the means to configure some status for display via the JSON, but I'm wary of over complicating things.

Is there another way to achieve your aim? E.g. closing the App after some period of inactivity?

[philipabbey]

On the Venu2, the "widget" execution is time limited and it appears in the list of Apps as well as being available as a glance. The glance can be removed to reduce clutter on the carosel for those who don't want it. This means that presently, the additions do not affect my own preferred behaviours and the changes can be considered benign. This leaves me pondering:

1. If we do have a glance, can we make it more useful, i.e. display some status... but what?
2. If we're most interested in the "quit on idle" behaviour, perhaps we could implement a timeout for the application based on some integer in the app preferences (Properties), with 0 being no timeout.

[philipabbey]

@Someone0nEarth could you take a look at #24 and consider if that would meet your needs for an automatic application exit on timeout?

[Someone0nEarth]

On the Venu2, the "widget" execution is time limited and it appears in the list of Apps as well as being available as a glance. The glance can be removed to reduce clutter on the carosel for those who don't want it. This means that presently, the additions do not affect my own preferred behaviours and the changes can be considered benign. This leaves me pondering:

1. If we do have a glance, can we make it more useful, i.e. display some status... but what?

Maybe the toggle state of a button, or if the home assistant instance is currently available for the watch. But I would start with the name only and adding more glance / widget somewhere in the future.

[Someone0nEarth]

@Someone0nEarth could you take a look at #24 and consider if that would meet your needs for an automatic application exit on timeout?

#24 (comment)

[Someone0nEarth]

Do you have any further insights into the difference between a "widget" and an "App with a glance view"? Widgets are still sounding redundant on modern watches, like they have been replaced by an App that implements a glance.

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

"Apps will behave differently when they are launched from the glance list versus the activity menu. If an app is launched from the glance list, a timeout will be applied to the app. If the user does not exit the app within a given time frame, the system will terminate the app and return to the home screen. If an app is launched from the activity menu, however, it will not time out, and the user must explicitly exit your application."

So, that just proofs our findings:

• On modern devices, there is no difference between app and widget type (and glance views will be displayed in the carousel) and both will can be an activity.
• On legacy devices, there is a difference: widgets are displayed in the carousel and will be shutdown by system automatically and "apps" are listed as activities and not listed in the carousel (even not when they have a glance view) and has to be stopped by the user.

[Peronia]

Hi, sorry to jump in. Today I installed the app on my Fenix 7 pro. Works nice, thank you. 👌🏻
I only want to support @Someone0nEarth. When I can scroll the watchface down to open the app, it will be better usability. However this is called.

[philipabbey]

https://developers.home-assistant.io/docs/api/rest/

So for the glance view you could test the API is alive with a call to the API URL and test you get the above message back.

We've used these icons before, from the same place as last time:

• https://github.com/house-of-abbey/GarminThermoNest/blob/main/resources-icons-48/signal_disconnected.svg
• https://github.com/house-of-abbey/GarminThermoNest/blob/main/resources-icons-48/phone_disconnected.svg

[Someone0nEarth]

https://developers.home-assistant.io/docs/api/rest/

So for the glance view you could test the API is alive with a call to the API URL and test you get the above message back.

We've used these icons before, from the same place as last time:

* https://github.com/house-of-abbey/GarminThermoNest/blob/main/resources-icons-48/signal_disconnected.svg

* https://github.com/house-of-abbey/GarminThermoNest/blob/main/resources-icons-48/phone_disconnected.svg

Nice. I suggest we should park this into the backlog. First start with displaying the name only for keeping it simple. Displaying a status won't work only with a glance: It should work for a widget, too. Don't now if there is a "background" part needed for the glance one... .

[Someone0nEarth]

So, this was a much longer and a quite unsatisfying trip for implementing the widget thingy.

My first approach was to return for the getInitialView() the HomeAssistantView... but for whatever reasons, a Menu2-View can`t be used as an initial view (thanks Garmin)... The app crashes silently.. with a cryptic error message in the sysout (thanks again Garmin).

So, my second approach was to use a normal view for the initial view, where you swipe left for closing the widget or swipe right to go back to the HomeAssistantView. Sadly, the InputDelegation of an initial Widget view won`t received swipe events (and a lot of other input events). Okay, in the deep jungle of Garmins documentation, you can find a hint for this. But, the text is saying this only for swipe up/down, so "swipe right" should work on the initial view.. but nope (thanks again Garmin).

So my final approach was the following:

You will see a loading screen while the menu config is being fetched (instead of the black screen). When you swipe left ("back") from the HomeAssistantView, there will be an "conformation view" (instead of the black screen), where you can swipe left again for closing the widget or tapping for going back to the HomeAssistantView.

This behavior is the same when started from the glance view and should be the same, when started as an app/activity. So, you guys can decide, if you can life with that :)

I still prefer the widget variant.. its much more comfy to use :)

The only way to get rid off this "RootView", would be to change the HomeAssistantView to a fitting view, which will working as an initial view. I did not do more testing, which view types will work for this.

The inital view of a widget always has the restricted possibilities of receiving input events. This should be the reason, why Menu2 and other views are not allowed for it.

This current state is good enough for me as the first roll.

You can pull the branch for testing it on your emulations/devices.

If you guys are up for this too, I will implement the translations for the RootView text and then it should be feature ready for a PR.

[philipabbey]

The bad news is, the RootView with the extra stage of exiting is a deal breaker for me.

The good news is, I don't think you need it. I just returned the menu view fine and tested on a Venu(1) in simulation. The was a bug with String parsing in that service.substring(service.find(".")+1, null) had to be replaced with service.substring(service.find(".")+1, service.length()). That's because null as an argument is not supported until a later API version, see Lang.String.substring(). I've had to change that before but then sometimes it works...

I've just pushed a small update to your branch at https://github.com/Someone0nEarth/GarminHomeAssistant/tree/widget_glance_prototype. Please can you verify the problem you were previously experiencing has not returned.

Thanks.

Philip

[philipabbey]

Just seen this highlighted by the editor. Its pretty insistent.

I wonder if this (:glance) annotation is not required for widgets?

Changing the API level supported will rule some watch devices out, so I'm keen to avoid that, and keen not to maintain two separate codebases too.

[philipabbey]

Changing the API level to 3.3.1 in manifest.xml then gives:

WARNING: Device name: 'Venu®' Part number: '006-B3389-00' CIQ ver: '3.2.6' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Forerunner® 245 Music' Part number: '006-B3913-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Forerunner® 245 Music' Part number: '006-B3321-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this project  
WARNING: Device name: 'Venu® Sq' Part number: '006-B3837-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Venu® Sq' Part number: '006-B4118-00' CIQ ver: '3.2.7' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Edge® 1030 Plus' Part number: '006-B3812-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Descent? Mk2 S' Part number: '006-B3930-00' CIQ ver: '3.2.0' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Edge® 530' Part number: '006-B3349-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Enduro?' Part number: '006-B3872-00' CIQ ver: '3.2.4' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Captain Marvel' Part number: '006-B3535-00' CIQ ver: '3.2.6' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Descent? Mk2 / Descent? Mk2i' Part number: '006-B3702-00' CIQ ver: '3.1.7' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'vívoactive® 4' Part number: '006-B3388-00' CIQ ver: '3.2.6' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Forerunner® 245' Part number: '006-B3145-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Forerunner® 245' Part number: '006-B3914-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'f?nix® 5S Plus' Part number: '006-B3134-00' CIQ ver: '3.1.6' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Instinct® 2 / Solar / Dual Power / d?zl Edition' Part number: '006-B4071-00' CIQ ver: '3.2.7' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'f?nix® 5 Plus' Part number: '006-B3089-00' CIQ ver: '3.1.6' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Descent? G1 / G1 Solar' Part number: '006-B4132-00' CIQ ver: '3.2.7' is being ignored by the package tool because it does not support the minimum API Level set for this project 
WARNING: Device name: 'Edge® 1030' Part number: '006-B2924-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Forerunner® 55' Part number: '006-B4033-00' CIQ ver: '3.3.0' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Darth Vader?' Part number: '006-B3538-00' CIQ ver: '3.2.6' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Venu® Sq. Music Edition' Part number: '006-B3838-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this projectWARNING: Device name: 'Venu® Sq. Music Edition' Part number: '006-B4119-00' CIQ ver: '3.2.7' is being ignored by the package tool because it does not support the minimum API Level set for this projectWARNING: Device name: 'Edge® 830' Part number: '006-B3350-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Rey?' Part number: '006-B3537-00' CIQ ver: '3.2.6' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'vívoactive® 4S' Part number: '006-B3387-00' CIQ ver: '3.2.6' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'f?nix® 5X Plus' Part number: '006-B3135-00' CIQ ver: '3.1.6' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Instinct® 2S / Solar / Dual Power' Part number: '006-B4091-00' CIQ ver: '3.2.7' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Forerunner® 945' Part number: '006-B3441-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this project        
WARNING: Device name: 'First Avenger' Part number: '006-B3536-00' CIQ ver: '3.2.6' is being ignored by the package tool because it does not support the minimum API Level set for this project
WARNING: Device name: 'Forerunner® 745' Part number: '006-B3794-00' CIQ ver: '3.2.5' is being ignored by the package tool because it does not support the minimum API Level set for this project        
WARNING: venu: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'venu' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: venu: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'venu' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: venusq: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'venusq' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: venusq: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'venusq' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: venusq: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'venusq' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: venusq: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'venusq' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: edge1030plus: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'edge1030plus' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: edge1030plus: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'edge1030plus' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: edge530: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'edge530' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: edge530: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'edge530' with minimum 
API Level 3.3.1. The glance annotation will be ignored.
WARNING: legacyherocaptainmarvel: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'legacyherocaptainmarvel' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: legacyherocaptainmarvel: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'legacyherocaptainmarvel' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: vivoactive4: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'vivoactive4' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: vivoactive4: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'vivoactive4' with 
minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: fenix5splus: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'fenix5splus' with minimum API Level 3.3.3. The glance annotation will be ignored.
WARNING: fenix5splus: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'fenix5splus' with 
minimum API Level 3.3.3. The glance annotation will be ignored.
WARNING: fenix5plus: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'fenix5plus' with minimum 
API Level 3.3.3. The glance annotation will be ignored.
WARNING: fenix5plus: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'fenix5plus' with minimum API Level 3.3.3. The glance annotation will be ignored.
WARNING: edge1030bontrager: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'edge1030bontrager' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: edge1030bontrager: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'edge1030bontrager' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: edge1030: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'edge1030' with minimum API 
Level 3.3.1. The glance annotation will be ignored.
WARNING: edge1030: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'edge1030' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: legacysagadarthvader: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'legacysagadarthvader' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: legacysagadarthvader: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'legacysagadarthvader' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: venusqm: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'venusqm' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: venusqm: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'venusqm' with minimum 
API Level 3.3.1. The glance annotation will be ignored.
WARNING: venusqm: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'venusqm' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: venusqm: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'venusqm' with minimum 
API Level 3.3.1. The glance annotation will be ignored.
WARNING: edge830: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'edge830' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: edge830: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'edge830' with minimum 
API Level 3.3.1. The glance annotation will be ignored.
WARNING: legacysagarey: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'legacysagarey' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: legacysagarey: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'legacysagarey' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: vivoactive4s: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'vivoactive4s' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: vivoactive4s: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'vivoactive4s' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: fenix5xplus: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'fenix5xplus' with minimum API Level 3.3.3. The glance annotation will be ignored.
WARNING: fenix5xplus: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'fenix5xplus' with 
minimum API Level 3.3.3. The glance annotation will be ignored.
WARNING: legacyherofirstavenger: <HomeAssistantPath>\source\HomeAssistantApp.mc:187: Glance applications are not supported for app type 'widget' on device 'legacyherofirstavenger' with minimum API Level 3.3.1. The glance annotation will be ignored.
WARNING: legacyherofirstavenger: <HomeAssistantPath>\source\HomeAssistantGlanceView.mc:31: Glance applications are not supported for app type 'widget' on device 'legacyherofirstavenger' with minimum API Level 3.3.1. The glance annotation will be ignored.
BUILD SUCCESSFUL

Hence the reason I originally lowered the API requirement.

[philipabbey]

Tried again for a watch-app with a return to API 3.1.0. I get a similar load of messages to the above.

[philipabbey]

BTW On this API business, I think we might have a bug waiting to appear in the original code.

            if (!(WatchUi.getCurrentView()[0] instanceof ErrorView)) {
                // Avoid pushing multiple ErrorViews
                WatchUi.pushView(new ErrorView(strApiUrlNotFound), new ErrorDelegate(), WatchUi.SLIDE_UP);
            }

On a Venu (1) device in simulation:

Error: Symbol Not Found Error
Details: Could not find symbol 'getCurrentView'
Stack: 
  - onReturnGetState() at A:\Philip\Programming\MonkeyC\HomeAssistantSomeone\source\HomeAssistantToggleMenuItem.mc:108 0x10002c9c 

Encountered app crash.

Now the method WatchUi.getCurrentView() is for a later API v3.4.0. I wonder if we get away with it when testing on devices that support much later APIs even if the project requirements are lower. Also, I'm annoyed the compiler did not pick that up before runtime.

[philipabbey]

Just a thought. Previously we were already returning a WatchUi.View pending the menus being created by the first HTTP GET to config_url:

return [new WatchUi.View(), new WatchUi.BehaviorDelegate()] as Lang.Array<WatchUi.Views or WatchUi.InputDelegates>;

(See https://github.com/house-of-abbey/GarminHomeAssistant/blob/main/source/HomeAssistantApp.mc#L105)

And then switching the View once we had created the menu structure

WatchUi.switchToView(mHaMenu, new HomeAssistantViewDelegate(), WatchUi.SLIDE_IMMEDIATE);

(see https://github.com/house-of-abbey/GarminHomeAssistant/blob/main/source/HomeAssistantApp.mc#L141)

So surely you can use the same trick for your RootView such that we don't need the extra swipe to exit the App? (That would remove my useability concern.)

This behavior is the same when started from the glance view and should be the same, when started as an app/activity. So, you guys can decide, if you can life with that :)

From my other separate App, this is not my experience. It should be possible to start the app from a glance without this extra work. In which case perhaps we just need some tweaking to get this working for both App+Glance and Widget? And the changes required are actually smaller?

I appreciate I can't see fully what you are experiencing.

[Someone0nEarth]

Hello!!

The bad news is, the RootView with the extra stage of exiting is a deal breaker for me.

Understandable ... the bad news: For widgets on non-glance devices, this can`t be avoided. The good news: I wrote a workaround, that should not showing this extra stage on newer devices :)

The good news is, I don't think you need it. I just returned the menu view fine and tested on a Venu(1) in simulation. The was a bug with String parsing in that service.substring(service.find(".")+1, null) had to be replaced with service.substring(service.find(".")+1, service.length()). That's because null as an argument is not supported until a later API version, see Lang.String.substring(). I've had to change that before but then sometimes it works...

Funny, this "bug" occurred to me every time in the emulation (couldn`t trigger anything on Homeassistant), but on the device it worked perfectly, so I never did a deeper look into it.

On the other side, this has nothing to do with the extra stage RootView thingy: Widgets on legacy devices (== non-glance devices) has the getInitialView() as "base view". This base view can´t be "popped" by the application itself (also there are no up/down input events on it (I wrote about this earlier)). And switchToView dont work too (it is technically a pop + push). Only way to close a "legacy" widget manually, is to swipe from left to right (or pressing the back button)... even System.exit() wont work. On your "original" version, the base view was a black view, which you have to swipe off to close the widget. That was the reason, why I introduced the "RootView": The text shows the user, that another swipe off would close the widget and "tapping" would go back to MenuItemView.

But with this workaround, the RootView won`t be shown if the widget was started from a glance or as an app.

I could test this with Venu 2 on the emulator (that means I started the widget from a glance). But I can`t test the scenario "widget started as app" on modern devices. Could you test this scenario on your Venu 2?

If this would work, too, then I would say we have a working solution :)

Greets,
someone

[Someone0nEarth]

Just seen this highlighted by the editor. Its pretty insistent.

I wonder if this (:glance) annotation is not required for widgets?

It is required for widgets on "glance" devices. This message is "normal", it is only a hint, that the annotated code for the current device will be discarded. But yep, very insistent... .

[Someone0nEarth]

BTW On this API business, I think we might have a bug waiting to appear in the original code.

            if (!(WatchUi.getCurrentView()[0] instanceof ErrorView)) {
                // Avoid pushing multiple ErrorViews
                WatchUi.pushView(new ErrorView(strApiUrlNotFound), new ErrorDelegate(), WatchUi.SLIDE_UP);
            }

On a Venu (1) device in simulation:

Error: Symbol Not Found Error
Details: Could not find symbol 'getCurrentView'
Stack: 
  - onReturnGetState() at A:\Philip\Programming\MonkeyC\HomeAssistantSomeone\source\HomeAssistantToggleMenuItem.mc:108 0x10002c9c 

Encountered app crash.

Now the method WatchUi.getCurrentView() is for a later API v3.4.0. I wonder if we get away with it when testing on devices that support much later APIs even if the project requirements are lower. Also, I'm annoyed the compiler did not pick that up before runtime.

Yes, this monkey c compiler behavior is really annoying.. happens to me already a few times now.

Should we open an issue, for fixing this?

[Someone0nEarth]

From my other separate App, this is not my experience. It should be possible to start the app from a glance without this extra work. In which case perhaps we just need some tweaking to get this working for both App+Glance and Widget? And the changes required are actually smaller?

I tried many many many ways to achieve this. I often got trapped by Garmins design decisions... but I really think, that my final workaround (the one I mentioned earlier) should do do the job :)

[philipabbey]

If this would work, too, then I would say we have a working solution :)

I've had the quickest of plays with this version on my Venu2, both as a glance started app and normal app. Its very encourgaing.

I need to do a proper test and review, but based on this I would suggest we move forward to the pull request you hoped for. I will have a proper look hopefully on Friday.

Well done, that was painful I appreciate.

[Someone0nEarth]

If this would work, too, then I would say we have a working solution :)

I've had the quickest of plays with this version on my Venu2, both as a glance started app and normal app. Its very encourgaing.

Nice! Thanks for testing :)

I need to do a proper test and review, but based on this I would suggest we move forward to the pull request you hoped for. I will have a proper look hopefully on Friday.

Okay, I am confident, that this solution will do it. So I will try to fine tune the last thingies (like i18n) until Friday!

Well done, that was painful I appreciate.

Thanks, and yep, it was painful. On the bright side.. people have similar "pains" with ConnectIQ since years... So at least I didn't feel alone with my pain 😉

[Someone0nEarth]

Hello!

I rebased the branch to current main. One of my worst pull rebase experiences I ever had... git was doing really strange and annoying things.

You will recognize that I moved the initialization of the QuitTimer from the contructor to the getInitialView: The constructor and other methods of the app class have restricted possibilities when a glance view is implemented.

Added i18n for the RootView strings. Tomorrow I will change the RootView to a ScalableView.

[philipabbey]

Please comment carefully the necessary changes for the widget version that must not be undone by any future changes. Best include what the problem was and how the fix solves it. It would be unfortunate for future commits to reverse something necessary that can't be so easily simulated/emulated.

[philipabbey]

So far, the code changes are looking pretty clean and thankfully unexciting.

[Someone0nEarth]

Please comment carefully the necessary changes for the widget version that must not be undone by any future changes. Best include what the problem was and how the fix solves it. It would be unfortunate for future commits to reverse something necessary that can't be so easily simulated/emulated.

Good idea. Normally I would write tests for ensuring something like this.. but I am afraid, that this not really possible.. at least not within spending an acceptable amount of time.

[Someone0nEarth]

So far, the code changes are looking pretty clean and thankfully unexciting.

In the end, it was not very extensive 😅

We should put our heads together, if we should do change the exiting app to the widget one in the app store.. or should we publish the widget as a new one and set the original app deprecated?

I don`t know what happened, when an existing app would replaced by a widget.

[philipabbey]

I think we change to widget and see what happens. We might also need a health warning when this goes live and ask for helpful people to report errors instead of rubbishing the app. And have a fall back to revert if things go horribly wrong. This is more about the change to widget across the list of devices rather than your code quality! 😜

[Someone0nEarth]

Please comment carefully the necessary changes for the widget version that must not be undone by any future changes. Best include what the problem was and how the fix solves it. It would be unfortunate for future commits to reverse something necessary that can't be so easily simulated/emulated.

Good idea. Normally I would write tests for ensuring something like this.. but I am afraid, that this not really possible.. at least not within spending an acceptable amount of time.

Please have a look, if this is working for you:

aeb7620

[Someone0nEarth]

I think we change to widget and see what happens. We might also need a health warning when this goes live and ask for helpful people to report errors instead of rubbishing the app. And have a fall back to revert if things go horribly wrong. This is more about the change to widget across the list of devices rather than your code quality! 😜

😉 ... don´t what happened with an existing watch-app app store installation will be replaced with widget, using the same uuid. But I think, we can test it with the beta release, right?

The fallback should be easy: Just the same code, just with "watch-app" as type. Worked for me locally.

[Someone0nEarth]

Just did a little more thinking about the publishing thingy:

I would suggest, that we will have two apps in the store:

• The exiting one still as "watch-app" type. This will now provide the glance view as additional goodie for "newer" devices. And on legacy devices, it still can be used as an real "app"/activity, for people they still want to use it like this.

• Another publishing in the store as "widget" type with the name "GarminHomeAssistant Widget". This is for "legacy" devices, to have the possibility to use the app as a widget.

They would use the same sourcecode. We just would need two manifest (and maybe two jungle files) in the repo. And in the manifests, the only differences would be the type and the uuid. This could be maintenance easily.

What you think?

[philipabbey]

😉 ... don´t what happened with an existing watch-app app store installation will be replaced with widget, using the same uuid. But I think, we can test it with the beta release, right?

Already tested, and its fine. So I'm thinking we can afford the risk. We'll call it "GarminHomeAssistant 2.0" and use the major update as an excuse.

I would suggest, that we will have two apps in the store:

My preference reamins to avoid splitting. We need to keep the same App ID so that people do upgrade. If we split, they have to take action to migrate. I think the risk is manageable as we will simulate the application on multiple devices and have tested on both Venu1 and Venu2 between us. We just make sure we've both used the same commit intended for release.

What's the worst that can happen after all these checks?

[philipabbey]

Please comment carefully the necessary changes for the widget version that must not be undone by any future changes. Best include what the problem was and how the fix solves it. It would be unfortunate for future commits to reverse something necessary that can't be so easily simulated/emulated.

Good idea. Normally I would write tests for ensuring something like this.. but I am afraid, that this not really possible.. at least not within spending an acceptable amount of time.

Please have a look, if this is working for you:

aeb7620

Do we need any comments on how the RootView must not be interferred with? i.e. anything special that it does to support widgets that needs to be retained.

[philipabbey]

Keen to get a pull request for this merged as I have plans for a bug fix to follow it up. I just don't want to create a merge nightmare for you by commiting to dev before you. 😃

[Someone0nEarth]

😉 ... don´t what happened with an existing watch-app app store installation will be replaced with widget, using the same uuid. But I think, we can test it with the beta release, right?

Already tested, and its fine. So I'm thinking we can afford the risk. We'll call it "GarminHomeAssistant 2.0" and use the major update as an excuse.

I would suggest, that we will have two apps in the store:

My preference reamins to avoid splitting. We need to keep the same App ID so that people do upgrade. If we split, they have to take action to migrate. I think the risk is manageable as we will simulate the application on multiple devices and have tested on both Venu1 and Venu2 between us. We just make sure we've both used the same commit intended for release.

The only real downside is, when we will go for only one published app is, that "legacy" devices can`t longer use this "app" as an app/activity. On these devices, it will be only usable as a widget. But I think, that this is fine, because the usage scenario of this app is way more to be a widget, than to be a "watch-app"/activity. And if there will be people out there, who want to use it on legacy devices as an "watch-up", they could change it easily by themselves, just changing the type in the manifest.

What's the worst that can happen after all these checks?

I think, this is will do it!

[Someone0nEarth]

Please comment carefully the necessary changes for the widget version that must not be undone by any future changes. Best include what the problem was and how the fix solves it. It would be unfortunate for future commits to reverse something necessary that can't be so easily simulated/emulated.

Good idea. Normally I would write tests for ensuring something like this.. but I am afraid, that this not really possible.. at least not within spending an acceptable amount of time.

Please have a look, if this is working for you:
aeb7620

Do we need any comments on how the RootView must not be interferred with? i.e. anything special that it does to support widgets that needs to be retained.

There are some restrictions regarding input events when in widget mode. I can add these comments in 2 hours or something and then will do the PR. And thanks for waiting with the bug fixing, so I won`t have a possible pull rebase pain :D

[Someone0nEarth]

Added widget related hints to RootView: 0f157ac

And the PR is created ✌️

[philipabbey]

Looking for a form of words to add to the README.md file to explain the major change in 2.0. Please confirm this is correct:

"For older devices that use widgets as opposed to applications with "glances" (e.g. Venu1), the Garmin HomeAssistant application can only be started from the widget carosel. The application will no longer appear in the list of applications and activities.

"For newer devices that allow glance views in their applications (e.g. Venu2), the Garmin HomeAssistant application can be started either as a glance (with only the application name, no status) or from the list of applications.

"Two users of older devices have requested this change, both for launching and so that the application will timeout when not used for a while. If the built in widget timeout competes with the user selectable application timeout in the settings, set the application settings timeout to 0."

[Someone0nEarth]

• Changed "Garmin HomeAssistant" to " GarminHomeAssistant "

"For older devices that use widgets as opposed to applications with "glances" (e.g. Venu1), the Garmin HomeAssistant application can only be started from the widget carosel. The application will no longer appear in the list of applications and activities.

"For older devices that use widgets as opposed to applications with "glances" (e.g. Venu1), the GarminHomeAssistant application can only be started from the widget carousel. The application will no longer appear in the list of applications and activities.

• Typo fixed: carosel -> carousel (or is "carosel" correct too?)

"For newer devices that allow glance views in their applications (e.g. Venu2), the GarminHomeAssistant application can be started either as a glance (with only the application name, no status) or from the list of applications.

For newer devices that allow glance views in their applications (e.g. Venu2), the GarminHomeAssistant application can be started either from a glance (with only the application name, no status) or from the list of applications

• The app is started from a glance not as a glance.

"Two users of older devices have requested this change, both for launching and so that the application will timeout when not used for a while. If the built in widget timeout competes with the user selectable application timeout in the settings, set the application settings timeout to 0."

• The built in widget timeout doesn't compete with the selectable application timeout, because in widget mode, the timer won`t have any effect (System.exit() don't have an effect for a widget). Should we explain this in the corresponding settings description? And should we extend the README settings section with all the new app settings?

[philipabbey]

😉 ... don´t what happened with an existing watch-app app store installation will be replaced with widget, using the same uuid. But I think, we can test it with the beta release, right?

Already tested, and its fine. So I'm thinking we can afford the risk. We'll call it "GarminHomeAssistant 2.0" and use the major update as an excuse.

Do clearly I was not careful enough with my trialing.

I would suggest, that we will have two apps in the store:

Looks unavoidable.

[Someone0nEarth]

Dang

😉 ... don´t what happened with an existing watch-app app store installation will be replaced with widget, using the same uuid. But I think, we can test it with the beta release, right?

Already tested, and its fine. So I'm thinking we can afford the risk. We'll call it "GarminHomeAssistant 2.0" and use the major update as an excuse.

Do clearly I was not careful enough with my trialing.

Dang... I was kind of afraid that this would happen :/

I would suggest, that we will have two apps in the store:

Look unavoidable.

Yep.. I will have a look to the jungle specification, if something like one repo with two jungles/two manifest is possible without an unacceptable overkill... .

Plan B could be new store release and the existing one will be deprecated, with a notification for the users.. .

[philipabbey]

Currently playing with manifests and jungle files. I think we can have a batch file to compile two versions from the same source. The jungle files reference separate manifests. VSCode becomes unhelpful unless there is a manifest.xml and a monkey.jungle, so those files at least must be retained rather than (as I hoped) using manifest-app.xml and manifest-widget.xml (and corresponding jungle files).

This does offer some hope that we can maintain both widget and app as separate and current app store submissions. I'm quite a long way down getting this to work.

For the release we will have the widget + bux fix for old API watches + internationalisatino of settings + 20 new devices I just found I failed to include. So we will need to properly test the final commit to dev.

Also we found an old Vivoactive 3 gathering dust to test on.

[Someone0nEarth]

Currently playing with manifests and jungle files. I think we can have a batch file to compile two versions from the same source. The jungle files reference separate manifests. VSCode becomes unhelpful unless there is a manifest.xml and a monkey.jungle, so those files at least must be retained rather than (as I hoped) using manifest-app.xml and manifest-widget.xml (and corresponding jungle files).

Yes.. I got stuck there too :/

There is a possible way using two subdirs, one for widget and one for app. Each subdir has its own jungle, manifest and vscode file and symbolic links to the source and all the resources directories (or one subdir contains these directories and the other one has symbolic links to them). This would work on Linux and MacOS, not sure about Windows.

I am looking forward to your batch solution!

For the release we will have the widget + bux fix for old API watches + internationalisatino of settings + 20 new devices I just found I failed to include. So we will need to properly test the final commit to dev.

👍

Also we found an old Vivoactive 3 gathering dust to test on.

Nice!