Multiple Data Fields

OK Newbie alert whilst I've a number of years of IT behind me in both infrastructure and programming I am new to developing for the Garmin Edge (targeting the 1000, 1030 and 1040 as I own these)

I am looking at having a Complex Data Field (5 fields) with various calculated functions based on activity.

My challenge/question is - If I wanted one of the fields from my 5 (say field 3) to appear as the 10th field on a data screen how could I do this or do I need to create 5 individual apps with a field in each.

I've download a few apps (hopposite) as testers as well as an app that does mutlifield. Adding individual hopposite works but means I would have 5 separate developments each with its own field/calculation rather than 1. If I add a 10 field multifield app onto the remaining app space I just get the first field if that makes sense.

Any guidance/example code/project would be great :-)

Top Replies

jim_m_58 over 3 years ago in reply to FlowState +2

You can figure things out using dc.getWith() and dc.getHeight() and comparing it to System.DeviceSettings.screenWidth/screenHeight. I use that when my DF will run in either full screen or half screen.
…
peterdedecker over 3 years ago in reply to FlowState +1

FlowState said:
All of this would be moot if Garmin would allow more than 2 CIQ data fields in the same activity on watches

Adding the same ciq field to 1 layout twice would also count as 2.

All Replies

0 peterdedecker over 3 years ago in reply to FlowState

FlowState said:
May as well just create multiple clones in the store

I'm not a fan of clones.

I think clones litter the store, it also increases the maintenance side of things for yourself as you have to export / release / update multiple times.

Because of the latter reason it could in fact make perfect sense to let a data field have multiple output paths, eg 2 calculations could have the same base calculation and you save cpu cycles as compute only needs to run once. Another use case is if you want to have a textual and graphical representation of the same value(s)

The idea of counting the occurences of onUpdate is an interesting idea that actually could work, but afraid that if you would depend on it it could have serious side effects as real devices have been known to misimplement onUpdate (calling too much) and events like pop-over events would also (rightfully) cause an extra onUpdate

0 FlowState over 3 years ago in reply to peterdedecker

TL;DR clones suck but clones are also useful for:

- saving memory on settings

- allowing the same app to be used in different activity profiles with different settings. (Especially when those different profiles are for the same sport, such as running.)

peterdedecker said:
I'm not a fan of clones.

I think clones litter the store, it also increases the maintenance side of things for yourself as you have to export / release / update multiple times.

I don’t like clones either, for the same reasons. The only reason I made clones was because users kept asking for them. A long time ago I made one of those feature requests that I knew would never be fulfilled: the ability to install the same app more than once (with distinct settings). IOW, Garmin could implement “clones” for us on the device side, but I can see why that would never happen. Not only would it be a lot of work, it would be very complex (*) and unfriendly, from the user’s POV. It’s not like any mobile or desktop OS supports something similar. (Sure, in Windows you can sometimes install the same app twice if you change the installation location, but settings are usually stored in a fixed/central location, such as the registry or the user profile.)

(* I also don’t have much confidence that something as complex as this would be implemented in a robust manner, sorry to say. Just look at the flood of bug reports for CIQ, and every new device that Garmin releases.)

Having said that, if you only have a single app which supports multiple instances:

- You need additional settings for each instance. So if your app supports 2 instances, that doubles your settings memory consumption (and associated code). This is especially bad for older devices, and even somewhat modern devices which still have 32 KB of RAM for data fields (same limit as a lot of older devices)

- Another reason users want clones is to have separate settings, but for different *activities*. e.g. Some users have asked for 4 clones (including original) of an app, so that they can have 2 for running and 2 for cycling, for example.

Sure, you could handle this by allowing the user to enter different sets of settings which take effect based on the sport type (I actually implemented this for one of my apps, but only on large-memory devices.) Now what happens if the user has two different Run profiles (e.g. the original Run profile with auto-lap enabled, and a Run Workout profile with auto-lap disabled), and they want different settings for your app in each of those activity profiles? You have no way to distinguish between those profiles, and the only option is to have a 2nd clone in the store. This is actually a use case that applied to me in the past, although these days I just use the same settings for that app in both profiles. If I ever wanted to change that situation, using a 2nd clone of my app in the store would be the easiest way.

Another issue with differentiating profiles by sport type is that getCurrentSport() only supports generic, running, biking and swimming, so you’re out of luck if you want to differentiate between two different “generic” sports.