Improve report comment push notification background updates

Both iOS and Android impose limitations on how frequently push notifications can wake the app from the background, and on how long those apps can remain awake in the background. Some variables that help determine whether this happens are:

• How much battery life the device has
• Whether the device is on low-power mode
• The availability of cellular data
• How frequently the user uses the app

iOS is far more strict, warning that developers “shouldn’t count on more than 2-3 background updates per hour”. While we likely can’t do anything to circumvent these OS limitations, we can make the most of the background time we’re given.

Action Performed:

With the app backgrounded or closed, receive a report comment push notification that wakes the app for a background update.

Expected Result:

1. Look at the sequence number of the ReportAction included in the payload of the push notification.
2. If it is equal to the highest sequence number we had previously in Onyx plus one, just add the single report action to Onyx.
3. Otherwise, fetch all the report actions between the highest sequence number we had previously in Onyx and the one included in the payload of the push notification. Thus ensuring that any messages we missed on that report will be added to Onyx.

Alternate Solution

Always fetch the report actions for the given report. Use pagination and fetch the newest ones first, until we receive a response that contains a report action with the highest sequence number we previously had in Onyx. This might be simpler, but also might be “riskier”, because I’m not sure that the OS will want to let you make network requests when woken from the background. So we might only want to fall back on that behavior if necessary.

Actual Result:

The one ReportAction included in the payload of the push notification is added to the report in Onyx.

Workaround:

n/a

Platform:

iOS Android

Version Number: 1.0.77-2

View all open jobs on Upwork

[quinthar]

I like doing them both – push notifications will be fast but unreliable, and background polling will be reliable but slow. This combined with doing an update on open should provide the best possible experience.

On Mon, Jul 26, 2021 at 2:29 PM Rory Abraham @.***> wrote:

Okay, so it sounds like you’re suggesting we implement something like react-native-background-fetch https://github.com/transistorsoft/react-native-background-fetch to reliably update Onyx in the OS’s preferred method. I think it’s a good idea, but do you think that we should do this instead of or in addition to background updates via push notifications? I think it would be great to do this in addition to the background updates via push notification that we’ve already built out.

This might require further development from Urban Airship

Also, since scheduled background updates are largely unrelated to push notifications, I’m not sure this will require any further development from UA.

this could solve also the problem of dropped notifications and missing Onyx data

Hmmm are you saying that some notifications have been dropped altogether? I’m not sure I observed that – only that Onyx isn’t consistently updated when a notification is received.

It is possible to run any code in service unrestricted as long as it is scheduled correctly and we display a foreground notification to the user

Can you provide a link to the documentation that states that a foreground notification is displayed to the user? NDB because we can probably generate that locally using react-native-push-notification, but would be good to know for sure that this is necessary.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Expensify/App/issues/4008#issuecomment-887040598, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEMNUXKUTD2TZVYVHPFY5LTZXHTJANCNFSM5AJT2CUQ .

[Julesssss]

Yeah, I think this should be in addition to the notification background updates (but we probably wouldn’t need to implement the expected result listed in this issue description).

Hmmm are you saying that some notifications have been dropped altogether? I’m not sure I observed that

Nope, what I meant to say is that if we use periodic checks instead of making additional API calls in a background service, then I think the OS would throttle our notifications less often. This remains to be seen though.

Can you provide a link to the documentation that states that a foreground notification is displayed to the user

Sure, here. Here is the change introduced in Android 12, which mentions that if less than 10 seconds, the notification won’t be displayed.

Background Service Limitations: While an app is idle, there are limits to its use of background services. This does not apply to foreground services, which are more noticeable to the user.

It’s worth mentioning that this is not just any notification, but a special notification that is tied to the background service. According to this blog post, not all of the React Native libraries support this, so we’ll need to check carefully if we believe that following these rules will lead to less throttling of notifications.

Finally, here is the main point. This limitation will apply once we target Android 12 (we will be forced to within 12 months):

Apps that target Android 12 (API level 31) can no longer start foreground services while running in the background, except for a few special cases.

The special cases that we will depend on are:

• Your app receives a high-priority message using Firebase Cloud Messaging
• Your app transitions from a user-visible state, such as an activity (or the foreground notification)