New notifications api

I agree that the wording of the announcement, and the content of the API docs, are fairly confusing.

A new notifications API to provide the user with additional information while in the background.

My educated guess is that, in this context, "background" does not refer to "Connect IQ backgrounding / background process", but the more common (to end users) usage of "the app is now running in the 'background' because I used the app switcher or a hotkey to return to the watchface". In other words, the app is running but its UI is not visible, because the user is currently in a different part of the watch's UI.

I can't find it right now, but I could've sworn that the CIQ docs have used "background" in this sense before. Something along the lines of: "CIQ apps can now run in the background, due to the app switcher that's available in newer devices."

EDIT: the above text is probably wrong

EDIT2: it's half-right / half-wrong. Notifications can be sent either from the foreground process or the background process.

Looking at the notification API docs, I gleaned the following:

- A CIQ app can send notifications to the end user while it's in the "background". These notifications consist of a title, subtitle, body text, and a list of actions that the user can select from. One example could be a notification which tells the user they received a text message, and gives them the ability to forward or reply to the message.

(yes, I stole that example from the docs)

 Notifications.showNotification("Jeff", "Something Happened", {
     :icon => Rez.Drawables.EmergencyIcon,
     :data => {},
     :actions => [
        { :label => Rez.Strings.ReplyAction, :data => MY_NOTIFICATION_ID_REPLY },
        { :label => Rez.Strings.ForwardAction, :data => MY_NOTIFICATION_ID_FORWARD },
     ],
});

- The app which sends notifications can register a callback to handle the following notification-related events: the user selects a notification action or dismisses a notification.

So it seems to me that this API would allow someone to be able to implement a 3rd-party messaging app in Connect IQ, for example. (Idk how useful that would be, unless more Garmin watches get LTE.)

I think there really needs to be a new core topic in the dev docs to explain all of this.

EDIT: the Notifications sample shows an example of the background process calling Notifications.showNotification, so maybe I was wrong above.

I wonder if it's possible for the foreground process to also call Notifications.showNotification, and if so, whether it would make any sense

I will say that the sample doesn't seem to work very well in the simulator. When a temporal event is triggered, it looks like a notification is displayed but then instantly dismissed (without any user action).

There's a Notifcations sample in the 8.1.0 SDK.  I'd start with that

In looking at the sample (only for a few minutes) backgrounding is involved.

permissions:
<iq:permissions>
<iq:uses-permission id="Background"/>
<iq:uses-permission id="Notifications"/>
</iq:permissions>

and in AppBase:

the getServiceDelegate()

Backgrounding is involved.

I'm thinking the notification comes in from the phone, is seen in the background, then it triggers the main app by way of the onNotification callback

jim_m_58 said:

Backgrounding is involved.

Yes, I updated my previous comment to reflect that, after you mentioned the sample (thank you for that). It is obvious after a few seconds of looking at the sample. (I should've looked for a sample before guessing, since Garmin often provides a sample app for new features, even when the documentation is initially thin.)

jim_m_58 said:

I'm thinking the notification comes in from the phone, is seen in the background, then it triggers the main app by way of the onNotification callback

I tend to agree with this, except I don't think the notification necessarily has to come from the phone.

In the sample, they seem to be generated with a temporal event vs a phone, but in the same background

jim_m_58 said:

In the sample, they seem to be generated with a temporal event vs a phone, but in the same background

Exactly.

So I am saying that nothing appears to prevent the developer from calling showNotification() from a background process for any reason at all, not just because a message was received from a companion app or data was received from a network request.

For example, it seems that the Notifications API could be used to implement the type of alarm app that devs have been asking about for years. The background process could send a notification to the user after a predetermined period of time passes. (Yeah, probably not too different in principle from requestApplicationWake, except with much greater flexibility.)

But remember, the temporal event runs at most every 5 minutes, were an external notification can happen more often, it seems.

I looked at the sample a bit more closely and I can now answer my own question:

Yes, notifications can be sent from the foreground as well. (In the sample, press the START button.)

In fact the sample app's UI explicitly shows the notification message source (background or foreground), which seems to drive the point home.

It seems that Garmin purposely showed examples of sending notifications from both the foreground and background because both use cases make sense (aside from simply being possible).

Yes, I see that now too when I run the sample.