• State Verified Answer
  • Replies 13 replies
  • Subscribers 19 subscribers
  • Views 3975 views
  • Users 0 members are here
Options
Related

Is it possible to make an app support multiple app types?

6125703
over 1 year ago

In theory, can a single app be a watchface, widget, and datafield?  I mean, assuming it can live with the RAM size and API constraints for the different modes, is it possible for one app to tell the system it supports these different modes and to have the system retrieve the right kind of initial view in each case?

This seems like it would be desirable for an app with settings and state it could then share between these different UI modes.

I have seen some CIQ apps that seem to act as a glance widget,  and device app on my FR255.  I.e. they are installed once and can be in the glance loop, show more detail when selected, and also show up as an app in the activities list. Is this having multiple app types?  Or is this just the way Garmin presents a widget type of app on my device?

From examples I've seen, the different types seem to start with Application.AppBase.getInitialView() but there doesn't seem to be a parameter which could tell it which view type to create. Then there are variations like getSettingsView() and getServiceDelegate() that are for specific purposes.

It seems unfortunate that there isn't getWatchfaceView(), getDatafieldView(), getGlanceView(), etc. or conversely a single getView() with a parameter to tell it which view it wants.

Top Replies

All Replies

  • 0 over 1 year ago

    Thanks for the answers and discussion!

    It is nice to know that I'm not the only one finding the limitations a bit arbitrary and unfortunate. All together, the situation is almost discouraging me from really spending time getting into CIQ programming, despite my software development career of almost 30 years...

  • 0 over 1 year ago in reply to 6125703

    While challenging, it isn't all that bad if you organize your code to be sharable among different devices and app types.  source, resource paths and exclusions are your "friend" (and a pain in the ass, just like all good friends Slight smile)

  • 0 over 1 year ago in reply to pstoppani

    The code management challenge is not really my issue. It's the seemingly artificial runtime obstacles. My motivation is to scratch my own itch to customize my FR255. I've barely got my feet wet using the very convenient "watchfacebuilder" website, and started adding custom code written to Toybox APIs. It got me to the point where I start imagining that as my prototyping workbench, maybe going the extra mile to reimplement my design as my own CIQ app once I've field tested it a bit.

    I've made a watchface I like for myself. It's fairly pedestrian. Kind of a cluttered "yet another Enduro" layout tuned for my offline-always usage model, function-over-form sensibility, and ~50 year old eyes.

    I think I'd like a similar watchface in walk and hike activities. On my FR255, I can't put a hike activity in the background to go back to the watchface. I can only configure a couple basic Garmin watchface designs as another data page in the loop. But, I really don't like these standard Garmin watchfaces very much.

    I've considered making a full-screen datafield copying the same design as my custom watchface. I like the idea of a abusing a datafield because I want to add it to any existing activities. I still want to be able to use the existing configurable pages for basic timers, metrics, graphs, navigation, etc.

    This inability to make a multi-type app or otherwise share state is an annoyance. It means I'd have to make my datafield watchface more stateless, unable to consider the accumulated data my watchface has prepared all day or all week. And, my watchface would need to do something "redundant" to incorporate data from during the activity, e.g. a background task or at least some processing of hours of sensor history data.

    Another annoyance is that I'd want to be able to make my datafield do the same low-power dance as a watchface, to reduce battery consumption in all day hikes. I like to maximize battery endurance. But as I understand it, a datafield is forced to render frequently, as if it is stuck in high-power mode? All this effort would be fruitless if the datafield is going to kill my battery if left on screen for hours at a time.