ActivityRecording:Session Tones and Vibes

I'm looking for some clarification from Garmin on expected behavior from addLap, save, discard, start, and stop.

I just tested these on a Fenix3. All 5 of these do not produce any response on the display (addLap used to display the native lap screen, but it doesn't anymore).

However, all 5 of them cause the native vibrate and tone responses to occur. This is perfectly fine for my application because I'm trying to match the native activity functionality as close as I can. I just want to verify that this is the long term expected response. It seems a bit inconsistent to have these commands cause the native audible and haptic responses, but not cause the native display responses.

I'm OK with either doing or not doing the audible and haptic responses. I just want to make sure I'm coding for the intended functionality and that all watches will act the same way.
  • Hi Roger,

    Our expectation was that when the native lap notification was removed, the accompanying vibe/tones would also be removed or disabled. Apparently, there's something separately triggering these behind the scenes.

    I'm submitting a ticket to have this investigated so a decision can be made about this. Based on some of the conversations I've been a part of, I'd expect these to be disabled eventually, but I can't say for certain.
  • I too want to make my app as cohesive as that of the native Garmin as well.
    Hence it would be fantastic if Garmin would make it easier for the devs to implement.

    You mentioned specifically about the Addlap screen. But you didn't (or I may have Mis understood) that your comment was also for the start/stop/pause etc as well which was what Roger was seeking clarification for.

    Can you please re clarified?
  • With the native apps (vivofit), there is a vibration when recording is started, stopped, saved, or there is a lap. I think that CIQ apps should be consistent with the native apps in this area.

    The native lap screen for CIQ apps didn't bother me, and I understand why it is no longer used, but I guess i wouldn't mind it being an option (maybe with a bit customization) for CIQ apps.
  • @NIKEOW: I'm awaiting clarification on this myself, because we don't have a set requirement for what should happen when start, stop, etc. are used in CIQ. I believe that the tones/vibe should have been disabled with addLap (since the native notification was disabled), but remain for the other methods. I'll have to wait until I get more info before I can say for certain how this should behave.
  • @NIKEOW: I'm awaiting clarification on this myself, because we don't have a set requirement for what should happen when start, stop, etc. are used in CIQ. I believe that the tones/vibe should have been disabled with addLap (since the native notification was disabled), but remain for the other methods. I'll have to wait until I get more info before I can say for certain how this should behave.


    It would seem most consistent to have all 5 activity methods (start, stop, save, discard, and addLap) have the same response (automatic native vs nothing/do it yourself) for the 3 UI types (display, audible, haptic). Why should addLap be different than the other 4?
  • It would seem most consistent to have all 5 activity methods (start, stop, save, discard, and addLap) have the same response (automatic native vs nothing/do it yourself) for the 3 UI types (display, audible, haptic). Why should addLap be different than the other 4?


    I think all 5 by default should have the same tone/vibrate as in the native apps.. After you're used to the native apps, you expect those tone/vibrates when things happen. This includes laps..

    The odd duck here is the lap screen, as it's the only thing that has it's own display and not just a vibrate/tone.

    I like it, but it really doesn't fit my app. As of now it seems to cause FW/CIQ issues on at least some devices, so I can see why it's removed, but long term, I think displaying it should be the default, with options to not display it, or to customize it.
  • We had a discussion about this yesterday, and the consensus is that the native behaviors currently triggered with start(), stop(), addLap(), etc. need to be removed. The reason for this is that there are apps (like FindMyCar) that use activity recording where the native behaviors don't make much sense. The SDK already provides APIs for vibes and tones, so apps can still mimic native behaviors if desired.

    I believe this relates directly to this post:

    https://forums.garmin.com/showthread.php?226985-Activity-Info&p=553350#post553350