Feature request: vibration from watchface and/or vibration from background process

If you can't do Attention from a background process for a widget or watch-app (I've not checked but that wouldn't surprise me as there'd be no way to display anything when it occurred), you can pass a flag of some sort in BackGround.exit() and have the app or widget do it themselves. You may have to prompt the user if they want to open the watch-app or widget (the prompt itself may do a vibrate - again, I've not checked), unless it can wait until the next time the widget or watch-app runs.

Just doing a vibrate in the backround could be a bit confusing to users as it might be unclear as to why it happened. Case in point, in one of my apps I vibrate every 5 minutes while the recording is paused as a reminder (it's helped me a few times when I forget to resume :) )

On watches with OHR (at least in the past on semi-rounds) when a CIQ app was paused, after 2 minutes, the RHR info was displayed. In one case, a user got that vibration after 2 minutes, and then my reminder about 2 minutes later while still viewing the RHR screen, and reported it as a problem with the rhr screen redisplaying every 2 minutes to the FW folks and not just the one time, and it wound it's way back to me as it was my app..

With watchfaces, while you may only want to use Attention a couple times a day, if it's there, watchfaces could use it much more often and impact the battery.

if it's there, watchfaces could use it

Of course when it's there you can use it, that's the whole point of this feature request :)

you left off the last part of my sentence..

...much more often and impact the battery.

:)

I didn't want to elaborate on it as I don't think it'll be an issue ;)

... and sure I could write the app I want for my Android phone, but I think notification type of apps are better suited to the (Garmin) watch as I'm wearing my watch all the time (I can't say the same for my phone :))

Backgrounding isn't the right solution in this case, since it's intended to run a process in the background and optionally give the user an opportunity to switch to the relevant app (e.g. My weather app just received new data via a background process, would you like to see the new info?). What you're really after is the ever elusive ability to present Notifications. We actually have a design drafted for this kind of feature, some of which is fulfilled by backgrounding. However, there are a few open questions that still need to be addressed before we'd get something like this in place.

TL;DR This is something we want to do, too. :)

a short vibration a few times a day will not consume too much power

Sure, but if we allowed this API, we have no way of enforcing the "a few times a day" part.

An optional fly-by message saying what the vibration is about would be a nice to have, but not a necessity

You should take a look at Background.requestApplicationWake()

An optional fly-by message saying what the vibration is about would be a nice to have, but not a necessity

You should take a look at Background.requestApplicationWake()

I've looked at it but I don't consider this a valid option:
* it does not draw your attention (no buzzer - you have to look at your watch, if you don't look you don't see it)
* of less importance but the message type is not of the fly-by type as it requires user input

a short vibration a few times a day will not consume too much power

Sure, but if we allowed this API, we have no way of enforcing the "a few times a day" part.

If you want to restrict it sure you can, you have plenty of options to do that:
* you can disallow beeps
* you can only allow vibrations up to a certain duration
* you can only allow vibrations up to a certain strength
* you can keep a counter and only allow the watch face to have a certain amount of vibrations per day...

But honostly I think if the feature is misused it would self-regulate as users would be "happy" to give 1 star reviews to an app that annoys the hell out of them :)

As to the power consumption, imho I don't think it's a valid reason not to allow vibrations from the watchface as...
...there are many ways you can do bad programming:
* if you're doing a lot of calculations over and over or in an ineffective way you'll burn the battery rapidly...
* if you're using ineffective/excessive looping you'll burn the battery...
* if you're drawing overly complex graphics you'll burn the battery...
* the same holds true for using the buzzer feature... of course buzzing your watch all day will burn the battery, that is something that is to be expected...

The reason I proposed to enable vibrations in the watchface is because it's low-hanging fruit here
* extremely easy to implement: it's only a matter of allowing watchfaces to do vibrations and you have the ability to create a notification-type of app
* there's no interference with other apps, so no open questions for this type of application.

Implementing fly-by messages with vibrations is a lot more developer-intensive for the connect iq team...

Backgrounding isn't the right solution in this case, since it's intended to run a process in the background and optionally give the user an opportunity to switch to the relevant app (e.g. My weather app just received new data via a background process, would you like to see the new info?).

I think most notification type of apps don't need much of an interface really,... it's just app settings, (a lot of doing nothing), waiting for the event to happen and reminding that the event is about to happen...

It's not the app I have in my mind to create but let's as an example use a "meeting reminder" app.
Personally I prefer the gentle approach to reminding: all I need is a buzzer and a 2 second flyby with 2 lines of text that displays the meeting subject and meeting place...
(sure you can also implement this kind of reminder app in a way that you require user interaction to make sure that the user acknowledges that he saw the message, but personally I would dislike it that while I'm using another app (or worse while running) I have to start pushing buttons and/or am pulled out of the app I'm currently using)

What you're really after is the ever elusive ability to present Notifications.

Correct.
All I need is a 2 second fly-by with a buzzer :)
Other people might prefer the acknowledge-approach so I assume they will prefer a buzzer in combination with the Background.requestApplicationWake

We actually have a design drafted for this kind of feature, some of which is fulfilled by backgrounding. However, there are a few open questions that still need to be addressed before we'd get something like this in place.

TL;DR This is something we want to do, too.

I'm happy to provide answers to your open questions, but then you'll have to read it of course (sorry this post is even longer). ;)

I understand that the proper Notification approach will be more complex to implement, which is one of the reasons why I proposed the enable buzzer in the watchface approach.
I don't think that having planned to do a proper notification implementation necessarily has to exclude the enable buzzer in the watchface approach, you can do both! ;)

The Attention module in Watchfaces just isn't the type of thing that fits the scope of what they are designed to do.

The best thing we have is Background.requestApplicationWake(). If this request string doesn't trigger a device vibration and/or tone (when they are enabled), then I would consider that an integration bug on the devices. We can't really request an application start if we don't bring the request to the users attention.

Brandon mentioned that we have considered a notification API that is more ideal for your use case, but we can't make any promises regarding if/when that type of thing is going to appear.

The best thing we have is Background.requestApplicationWake(). If this request string doesn't trigger a device vibration and/or tone (when they are enabled), then I would consider that an integration bug on the devices. We can't really request an application start if we don't bring the request to the users attention.

I just verified on my 735XT with the new 2.3.1 SDK and FR735XT 8.20 fw release, the message from requestApplicationWake is shown but there is no vibration or tone. In my System menu I have both vibrations and tones enabled. I don't have any other recent Garmin devices where I can verify this on, but I agree with you that the requestApplicationWake should be accompanied by a notification.

If this is indeed a bug, can you then make a ticket for the FR735XT device team? Thanks.