Open Bug 1945844 Opened 4 days ago Updated 2 days ago

[Search Consolidation] SPIKE : Investigate how often should Android look for remote server updates

Categories

(Fenix :: Search, task)

All
Android
task

Tracking

(Not tracked)

People

(Reporter: skhan, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxdroid][group3][search-consolidation])

How often should we be looking for updates of the APIs or perhaps RemoteSettingsServer.sync()? Believe desktop is doing it every 6 hours? Is every app start up a good solution for mobile?

Summary: [Search Consolidation] SPIKE : Investigate how often Android should look for remote server updates → [Search Consolidation] SPIKE : Investigate how often should Android look for remote server updates

Discussion so far on Slack:

:standard8 -

iirc, Desktop checks every 6 hours, but I'm guessing desktop browsers are more likely to be left open / force closed by the OS. Mobile is also potentially bandwidth constrained.
I think we might want to implement something that's "regular", to catch the long-running cases. Also, thinking about it - if we check after start-up, we should only do that if it has been longer than "n" hours since the previous check - otherwise if someone is restarting their mobile browser quickly, we'd be checking multiple times which isn't going to be good.
We should also try and do it in a idle moment - if we have a concept of that on mobile.

:skhan -

I think either we can club the app startup with at least “n” hours before rechecking or do a periodic request.
While Android doesn’t have a built-in way to directly detect “idle” moments, we can track the app’s foreground/background state and trigger background tasks when the app is idle (not in the foreground).
But I do think a periodic call here would make most sense if for example the app is not idle for a long period of time or is not restarted.

:leplatrem -

On desktop we have two mechanisms in place:

  • push notifications, received on startup as a handshake as soon as the user is idle, and within the few minutes after a new change is published on the server
  • background timer, that runs on startup once the user is idle and every 24H

Generally speaking, waiting on network during startup is a bad idea. That's why we would recommend having some good default data in the binary for users' first start, and initiate sync a few seconds once the user becomes idle.

And if a 24H background check is enough for your use-case, then that could be a first good value. If not then I wouldn't go below 6H, because then it makes more sense to implement push notifications.

Obviously 6H is completely arbitrary and would deserve a little study based on number of devices, user behaviour, etc.

:skhan -

Believe we can call the API during startup but not “wait” on it. We will be getting the records from the dump (also stored in Application Services). Simultaneously call a servery.sync() but not “wait” on it. Now after the sync I believe the dump is updated with the latest records? And we fetch the dump again. When do we fetch this dump again? Question here is how often should we do server.sync() ? That would mean how often do these remote configurations change? Maybe we don’t do it at every startup, maybe we do it every 3 days. Desktop does do it every 6 hours though. What would be an ideal time for mobile?

:leplatrem -

but not “wait” on it

Yes, you're right, that would work.

When do we fetch this dump again?

We call "dump" the binary data that is embedded within the application binary and that is used as the default data to initialize the local copy. Then, when you call sync() it fetches the remote data and updates this local copy.

Question here is how often should we do server.sync() ? [...] maybe we do it every 3 days.

That depends on your use case. If you are ok with clients using old data during 3 days, then the least often the better for our servers

Desktop does do it every 6 hours though. What would be an ideal time for mobile?

Desktop has two triggers as I detailed above. Push notifications and a "fallback" sync every 24h.
If 24H works for your use-case, then I think it's a reasonable default.
Where does your 6 hours comes from?

(In reply to Aaditya Dhingra [:adhingra] from comment #1)

Desktop has two triggers as I detailed above. Push notifications and a "fallback" sync every 24h.
If 24H works for your use-case, then I think it's a reasonable default.
Where does your 6 hours comes from?

The 6 hours was what I thought it was, but I was wrong, as :leplatrem says, desktop is 24 hours.

I therefore think we should:

  • On startup, setup remote settings service & clients objects, call getRecords() => this will get the locally cached data, or the data from the dumps if the cache is empty.
  • A little while after startup (preferably when the user is "idle"), check to see when the last update was:
    • If there has never been an update, or no update in the last 24h, call sync() to start it off.
    • Otherwise set a timer to call sync() when the current 24 hours expires.

Or something similar to that, depending on what timer handling is available.

This sounds very reasonable.

If, for whatever reason, you would need to synchronize more often than 24 hours, please provide us an estimated range of number of devices / amount of data, so that we can evaluate the cost.

You need to log in before you can comment on or make changes to this bug.