I am trying to decide If I need to write a data field or a watch app, but I'vedifficulties to clearly understand the difference ? can someone help me or clarify these ?
There's actually 3 choices in your case: Simple Data Field, Complex Data Field and Device (Watch) App.
In all 3 cases, you are able to record data to the FIT activity file, although data fields can record less data than device apps.
Simple Data Field - You want to add functionality to an existing built-in activity, such as Run or Bike. The user still has access to other data pages and activity features (navigation, alerts, lap screen. etc.) - You want to let the watch handle formatting and layout of data. This means you are only displaying one value (e.g. "Number of beers earned"), which consists of only letters and numbers. (Usually just numbers). This also means the label is static and you can't add colors or change the font. - You can see any number of examples in the store, such as Current Grade %: https://apps.garmin.com/en-US/apps/4...7-c609b542b2c1
Complex Data Field - You want to add functionality to an existing built-in activity, such as Run or Bike. The user still has access to other data pages and activity features (navigation, alerts, lap screen. etc.) - You want to handle formatting and layout of data yourself. You can draw anything you want in your own area of the screen, including using colors and graphics.
Some complex data fields use the whole screen, which makes it possible to display as many as 12 items on the same page. (Or more, if you're adventurous and/or hate your users.) This is a very popular type of app typically called a "single run field" e.g. Dozen Run: https://apps.garmin.com/en-US/apps/9...7-f92ca02118ad
---
From the user's POV, there is absolutely no difference between a simple and complex data field, other than the fact that the complex data field can probably display fancier things than the simple one. From the coder's POV, you save time coding and memory on the watch by using a simple data field. If you are calculating very complicated things, you may not be able to fit that code in a complex data field on an older watch like FR230, but it may fit in a simple data field.
--
Device App - You want to replace the functionality of a built-in activity. User has no access to built-in activity features or native data pages - You have to handle almost everything yourself, except for gathering and interpreting sensor data. e.g. -- Drawing multiple data pages -- Calculating any metrics that users want which aren't provided to apps (like lap data, grade or distance to start) -- Lap screen -- Alerts
As you can guess, device apps are more suited for doing something completely different from built-in activities, because of all the trouble you'd go to just to recreate the built-in functionality, and because users might miss whatever functionality you couldn't recreate.
I'm an absolute fan of data fields as they enrich what's already there. Data fields are also what made me choose connect iq over other sport/smart watches. For me when my app is to be used in a classic sport (eg running, hiking, biking, ...) I don't think twice and a data field is the way I go. :)
peterdedecker I agree, but the sad thing about data fields is there's zero user interaction, except for Edge cycling computers.
There's a whole class of very useful apps that are either impossible or impractical because of this. I know because I wrote a couple, and the UX is just terrible (quickly scroll away from the data field and back to view laps >_<).
I'm hoping that Garmin will add user interaction in CIQ4.... (Travis mentioned the possibility of data fields hooking into the menu, similar to built-in datafields like the map or music controls.)
And the memory limits for datafields are pretty strict, especially on old CIQ1 watches like 230, but even on newer CIQ2 watches like 935.
You have to work with what's there. In my apps the lap key press is ok for the purpose.
But ideally I'd like user interaction in all apps including data fields and watch faces.
User interaction in data fields is the one that's harder to implement imho, eg if data field 1 says it has handled the button press do you still forward it to data field 2... the logical thing to answer would probably be yes. But a follow up question might be does app 2 need to know app 1 has handled the button press.
User interaction in watch faces might be denied as it could have a negative impact on power consumption.
peterdedecker as I mentioned, the proposal seems to be that data fields could add their own entry to the context menu. It's exactly how the Music Controls and Map native datafields handle pushing a new view so you can actually control your music or zoom your map. It's also similar to what you get when you scroll to a widget and open the menu (without "entering the widget" first.)
It's an extra step for the user, but it's better than nothing.
I think there's a more serious problem with directly handling button presses in data fields, which is that all the buttons are already used for something else. Yes, even today data fields can react to pressing START and LAP, but those buttons already do something else that the user doesn't want to do just to interact with your data field. Nobody wants to add extra laps to their activity or quickly stop/start their activity just to make an app do something.
For touchscreen watches, why not allow touch support for data fields? (I can think of a few reasons, tho.)
As much as I dislike the 630 touchscreen and the idea of the VA3 with one button, I do wish 5-button Garmins had an optional touchscreen. But the 630 flopped (I think), and even Suuntos disable the touchscreen during an activity, so I guess it's never gonna happen.
Think of a datafield as an "add on" to an existing activity. You have the native running app, but you want a way to show some data that's new or show something in a unique way, The user then adds your data filed to the running app, along with native data fields that are already available (distance/time/speed/etc), and in most cases, one other CIQ data field. They have limited memory compared to device apps, but a bunch of the things a activity does, you don't have to worry about - like recording the basic fit,auto pause, auto lap, and others.
A device app, everything is up to you - starting/pausing/stopping recording (for a recording app), starting up GPS (if needed), accessessing sensors (HRM, etc), but allows you to add anew activity - one that's not supported as a native app.. They are also a bit more flexible, in that if you want to do communications, you just do it, while in a DF, comm requires a background process. And device apps allow plenty of choices for user input.
Which you want to do really depends on what you want to build
I missed that proposal of travis, a context menu is ok for settings changes but it won't satisfy the need of fast paced action i'd typically want when i'm running.
peterdedecker agreed. So there is no solution for non touchscreen watches then. Not even the native map or music controls data field allow for direct input. The last thing they want to do is block basic functions like Start/Stop, Lap, and Up/Down just because some random data field is in view.
Hilariously, the real problem is that five buttons isn’t enough. I guess long press is the only solution, but I just went through the nightmare of implementing a stopwatch that handled long press, and concluded that in general you can only use long press for optional behaviours, with a very few exceptions. (Yes, and Jim and others could’ve told me that from day one, but I’m stubborn.)
Even in five button watches where long press is ideal, there’s always the possibility that the user set a system hotkey which overrides that long press.
I suppose if long press of start were reserved at the system level for datafield interaction, that would be a different story. For VA3 it would have to be a tap of the screen, of course.
In DataField what's available from sensors ? is it depending from the built-in activity from which it integrate ? if so how can I know for each activity what's available ? (would like to have accelerometer information for eg )
In a DF, some things are easy to get - like Heart Rate - it's in the info structure passed to compute. And location data is there if the activity is set to use GPS.
For Sensors like the Tempe, it's a bit tricky as you have to use a background process to get it, and then, you can only get it at most every 5 minutes (same with the internal temperature on Edge devices.). For the accelerometer, I've not tried, but again, I think you need to use a background process, so only every 5 minutes at most (you get it my way of Sensor IIRC).
So.. I'm thinking you probably want to look at doing a device app where you don't need a background process instead of a DF.
