[Feature Request] App and widget in one binary

No need to duplicate logic, you can link in files from other folders in your jungle file. it's one of the things i do for Peter's race pacer (datafield) and Peter's pacer the app (app).

Yes, that is totally clear for me, that there are ways for reusing code from the developers perspective. What I was talking about is the fact that people need to download 2 different binaries with the same logic and store them on their device. Also reusing data between those is not possible.

Bye

I'm not 100% if I understand the point you're trying to make, but I'd suggest that you have a look at the possibilities which are already available with "intents" (https://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/System/Intent.html)

You can collect information from a web service with a widget and pass it as argument to an app (which doesn’t need to implement the logic of the widget). So reusing data between CIQ apps/widgets is pretty much possible.

I personally find it very interesting and initially I supported the idea very much. But I feel it hasn’t been very popular among other developers and maybe still too confusing for users. Garmin also gave signs they didn’t care much about it, when multiple bug reports were made about it and remained hanging for years (https://forums.garmin.com/forum/developers/connect-iq/connect-iq-bug-reports/1336215-vivoactive-hr-sys-exitto-intent-fails-to-open-another-ciq-app).

I don't think it will be confusing for the user. There is nothing that will change here, as the widget selection would simply contain also widgets that are defined via installed apps. Whether or not a user will select/use them, is up to him.

It is all about a deeper integration of apps and the widget loop. At the moment those parts are completely separated, which is not necessary in my opinion. If an app could define a widget view, this would simply be available in the widget loop allowing to access the data stored for the particular app. With "data" I mean the locally stored stuff like settings and values stored in the persistent storage. An advantage would also be that the widget can rely on the fact that the corresponding app is installed and thus open it directly if necessary.

All of these are thoughts that came into my mind when I had the idea of adding parts of my app logic into a widget. With the concept above this would work without a separate binary that people need to download but simply by updating the app.

Bye

There is a limit an both the number of CIQ apps on watches (the "slots") as well as the total space that can be used for .prg files on the watch. Having a single binary with say 3 widgets and an app in it would impact both. Depending on if/how this is done, the whole binary might need to be loaded when any of the apps/widgets are used.

Hi Jim,

I completely understand. My idea was to provide 1 widget interface per app, meaning one app can only include one widget view. Also the implementation must be done in such a way, that only the necessary parts are loaded when the widget/app loads to not exhaust the available memory. I am pretty sure this is doable, question is, if Garmin wants this or not.

Bye

There has been some discussion about doing apps with multiple entry points in the past. I think that this is an interesting idea, but it hasn't made it very far.

Right now the easiest way to do this is to have two separate apps that store data in the cloud. The user can install the app if they want that, the widget if they want that, or both. The only real disadvantages of this is that it make implementation more difficult and you have to have access to a mobile device to save/load settings.

Hi Travis,

sad to read that this was already discussed and got kind of rejected. So obviously there is no sense in trying to push it for a future release :)

The logic I am currently using is that my app has the ability to change the data and the changes are stored "In the cloud". The configuration for the web service (username/password and some other things) are defined in the app settings. Then I tried to simply compile my app as widget, but this approach failed as the widget has only 50% of memory available. Now I will try to create a widget that is limited to only a small part of my app. With this approach the idea raised in my mind that it would be really great if I could simply define an entry point for my widget in the app itself and reuse settings and logic.

Thanks for your clarification anyways!

Bye

in my humble opinion I don't think it would make sense to have both the app and widget code in the same app as the way they operate is very different (you don't have control over all the buttons in a widget, you have to push views in widgets for additional screens where as in a app you don't and can just redraw the current view with other content, etc...), also you have different memory limits for the different app types.

To reuse code you can do it with jungle-ing out it your code and to pass data I agree with r.485 that intents would fill that purpose (if the bugs reported on it could be addressed, so hopefully that's something that can be planned in)

Hi Peter,

from my experience there is not much difference in implementing an app and a widget. The only thing needed to be considered for a widget is the fact that allowing complete control needs to push a screen to "enter" it. Everything else is quite similar. That is why I think a deeper integration makes sense.

Bye