Data field size hack

I have tried to do the same - but I gave up.

There are some layouts where you can find out which datafield you are in. For example - 5A seems to have 5 equal fields, but the bottom field differs by some pixel (if I remember well).

There is a IQ datafield by flocsy for checking this: https://apps.garmin.com/apps/1535a238-cbac-463b-bde2-373403502a6f

Indeed. Look at that DF, the code is on github. It works more or less on some round display devices and almost doesn't work on rectangle devices (because there the only data you get is the field size, but the obscurity flags are all identical. So the only way to be identify multiple fields on the screen is if they have different size.

My other thought was to create an app but they're a bit awkward to use on an Edge as you have to exit to home and can't swipe between screens. Obviously I could just use a single whole screen field and draw everything myself but was a bit concerned how this might affect battery life. 6B/6C seem to work fine for me on a 1040 giving me two unique fields which I can work with.

Don‘t care about battery consumption on Edge devices. Here it is not relevant for IQ data fields—unlike watch faces.

Are you saying if I draw everything myself like lap speed, 10s power, etc. I won't use any more battery on an Edge? This data field is for LEL in a couple of weeks and I'll be on the bike for 4-5 days. Really would like to make sure I don't impact battery life.

9504990 said:

My other thought was to create an app but they're a bit awkward to use on an Edge as you have to exit to home and can't swipe between screens.

You can't used an app when an activity is running either.

You can use widgets during an activity.

On touch-screen Edges, you get to those by swiping down from the top of the screen. You can change the widget by using the left/right arrows at the bottom. The up arrow at the bottom makes the widget screen go away.

Widgets are lighter apps. Garmin is moving towards merging apps and widgets.

Although the built-in fields are probably not written in CIQ and are thus more battery friendly, I'd still guess that 10 fields that display some simple stats use more battery than 1 field that displays the same 10 stats because of the overhead each separate field has. Most of the data one would display is ready in the info object you already get anyway.

dpawlyk said:

Garmin is moving towards merging apps and widgets.

Garmin already did this 4 years ago, with the introduction of CIQ 4. 

[The following applies to watches, although Edge devices have recently undergone similar changes. I don't want to talk about Edge though because the UX for glances is a bit different, and Edge also has a slightly different meaning for "widget". For example, on watches, the "glance" concept completely replaced the "widget" concept years ago, but on newer Edges, "glances" and "widgets" are 2 different concepts which co-exist.]

On CIQ 4+ watches:

- strictly speaking, there is no widget CIQ app type. You can see this if you open the Connect IQ store app on your phone, select a CIQ 4+ device, and search for an app. You will see that the only available app types are Music, Watch Faces, Apps (device app / watch app), and Data Fields. If you select a device with CIQ 3.x or lower, you will see that the Widget app type is also available.

- when you build an app with a type of "widget" in the manifest, it's actually compiled as a "watchApp" (device app) instead

- all device apps are available from the activity/app launcher (as before)

- if a device app provides a glance view (by implementing getGlanceView()), it is *also* available from the glance list (just like a classic CIQ widget). 

- if a device app is launched from the glance list, it is subject to the same restrictions as a classic widget, such as:

- The app will time out and return the user to the watch face, after a certain period of user inactivity. 

- The app cannot record an activity

None of this is well-understood by the Garmin-using public -- most users and bloggers still refer to an app that's launched from the glance list as a "widget", even though internally, it's just a device app [or "app" to the end user] with a glance view.

Arguably it's not important for the end user to understand these nuances, except for one case: porting widgets from CIQ 3 (or older) devices to CIQ 4+ devices.

If a literal widget app is run on a CIQ 3 device which supports glances, and the app does not implement getGlanceView(), the device will provide a default glance view consisting of app icon and name. This was convenient when porting a widget from an older device which did not support glances but only full-screen widgets -- in this case the widget could run on a glance-enabled device with little or no code changes. However, if such an app is ported to a CIQ 4 device without implementing getGlanceView(), it becomes a regular device app with no glance view. (CIQ 4 devices don't provide a default glance view for apps which don't implement getGlanceView; in this case the app is only available from the activity/app launcher.)

This is a problem for apps that are designed to be launched from the widget/glance list, because they're meant to be used while an activity is running, but the dev ported them to CIQ 4 devices without implementing getGlanceView. This issue has already come up a couple of times - some widget that worked great on a CIQ 3 device is ported to a CIQ 4+ device, and users complain that it's useless because it can no longer be launched from the glance list, but only from the activity/app list, which means it can't be used during an activity.

IMO merging device apps and widgets was not a bad idea, but Garmin could've handled the transition / implementation a bit better.

For example, currently an app with a type of "widget" is simply changed to "watchApp" when it's built for a CIQ 4+ device. What Garmin could've done is also generate a default glance view for such apps, so that they can continue to be used as "widgets" (from the user's POV, this just means that the app can be launched from the glance list). At the very least, the compiler could warn the dev that the app has a type of "widget" in the manifest, but it lacks a glance view, meaning it won't be available from the glance list on CIQ 4+ devices.

As a side note, I really dislike that Garmin uses "app" with 2 different meanings depending on the context:

- A Connect IQ app¹ is any 3rd party program that can be downloaded from the CIQ app¹ store. Different app¹ types include: Music, Watch Faces, Apps² (device app / watch app), and Data Fields. 

- An app² is a specific type of Connect IQ app¹. This type of app¹ can replace a built-in activity such as Run and more or less has the capabilities and behaviour of what we think of as "apps" on other platforms, like a phone or smartwatch. i.e. An app² takes over the entire display, it can handle almost any kind of input, it (usually) keeps running until the user decides to close it, etc. Contrast with data fields which can only run in the context of a built-in activity, or a watchface which has very limited input capability.

Garmin tries to disambiguate the second usage of "app" internally by calling it a "device app" or "watch app", but those terms don't really clarify anything or mean anything to the end user. End users just call these things "apps" and so does Garmin (e.g. on the search page of the Connect IQ store phone app.)

I don't have a good solution for this, but I do think it makes it harder to discuss CIQ apps with non-technical users.

It's kinda like how Apple has an iPad model called iPad and used to have a MacBook model called MacBook.