Newbie developer questions

I guess my posts are moderated because I'm new, but as the post datetimemark was not it misfired the active topics. So I hope it's oke I kick it.

It also says now all replies are moderated? I hope this is in error..

3. possible. You need to create an array constant that includes all the Rez.Drawables.icon1, Rez.Drawables.icon2, ... and then load them on demand with loadResource.

4. You don't need complications for body battery. Use: SensorHistory.getBodyBatteryHistory

Thanks for replying. I actually do like to event based push principle of the complications system. Using SensorHistory would also add an extra question for rights to the user. I guess it will be fixed in the future, but for now it works.

beva said:

1. Settings. Is it because I have a Venu3 I cannot use settings directly from the watchface?

All devices with CIQ API level >= 3.2.0 support on-device settings, which is all devices released in roughly the past 6 years, including Venu 3. Venu 3 is a device that's currently supported with firmware updates, and it has CIQ 5.1.0.

https://developer.garmin.com/connect-iq/core-topics/properties-and-app-settings/

On Device Watch Face and Data Field Settings

Since API level 3.2.0

Device applications, widgets, and audio content providers all accept user input that allow them to implement on-device settings in the app. Watch faces and data fields are not allowed to accept input or push views that would allow on device configuration.

If you want to provide an on-device settings user interface for your watch face or data field, you can implement AppBase.getSettingsView(). getSettingsView() functions similarly to AppBase.getInitialView() where you return a WatchUi.View and WatchUi.InputDelegate pair that can serve as the initial view.

Watch face configuration is available to the user in the system Watch Face menu. Data field configuration is available from the activity menu.

beva said:

Is it helpfull to store the background drawn over partially to have it partially restored the next second, or is this something done by the system itself nowadays?

Depending on how complex your rendering code is, it might be helpful to render to a BufferedBitmap so you only have to re-render the parts that change. The system will not do this for you.

Couple of potential issues though:

- buffered bitmaps will use the shared graphics pool which is nice because it doesn't use your app's memory, but is not so nice because it counts against the graphic pool memory shared by all apps

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

Buffered Bitmaps and the Graphics Pool

BufferedBitmap objects, like other graphics resources, now take advantage of the graphics pool, as well. The advantage of this scenario is that you can now liberally use temporary graphics buffers without running out of application heap.

As noted earlier, the graphics pool will intelligently purge and restore resources from the pool if the loaded resources exceed the available pool space. Unlike static resources that are reloaded from your executable, BufferedBitmap are not restored if they have been purged. This works fine if you are using a short-lived, temporary buffer, but if your bitmap is purged after allocation, you need to re-render its contents. Alternatively, you can call the get() method on the reference to get a locked version of the bitmap. This will prevent the BufferedBitmap object from being purged from the pool, but it can also lead to the graphics pool running out of available space if more resources are loaded.

AMOLED devices update once per minute in "low-power mode" (when user isn't looking at their watch) and once per-second in "high-power mode" (which is active for a few seconds after the user turns their wrist to look at the watch.

MIP devices are similar, except if you implement onPartialUpdate, you can also update your watchface once per second in low-power mode.

So onPartialUpdate() isn't intended to save energy per se, it's intended to allow you to update your watchface at 1 Hz all the time. (Ofc it's also designed to do so in a way that doesn't use too much energy. The point is that using onPartialUpdate() doesn't save any energy compared to not using onPartialUpdate(). If anything, using it would consume more energy than not using it, but not obviously not to an extent that's unacceptable to Garmin.)

There's a good explanation of this stuff here:

[https://developer.garmin.com/connect-iq/user-experience-guidelines/watch-faces/]

Thanks for your reply, this helps me a lot.