[feedhenry-dev] FH-Sync and Android O

[Wei Li]

I don't think it's necessary to run sync with high frequency when it's in
the background mode. The app is not being used by the user, so no one cares
if the data is actually up to date in the background.
>From this point of view, I think it's ok to use the JobScheduler when it's
in background. It probably will use less battery as well (I think perhaps
we can reduce the frequency of sync when it's running in the background for
old Android versions too?).

However users do expect the data is up to date ASAP when the app is in
foreground mode. So this change is made, we probably should explain how
developers can still achieve relatively good UX when the app is in the
foreground again.
We can either:
* make sure sync API is called automatically when the app is brought into
foreground. Or,
* provide documents & code sample of how to invoke the sync API when the
app is in foreground mode.

My 2 cents...

Thanks,

On Tue, Aug 15, 2017 at 5:34 PM, Summers Pittman <supittma at redhat.com>
wrote:

> So fh-android-sdk uses a polling thread with a one second timeout to
> perform sync operations.  While the application is in the foreground this
> is fine since this thread just checks the Sync configuration and makes HTTP
> calls to sync if a sync timeout has been reached.  Because we want a
> real-ish time experience our demos keep this timeout rather low.
>
> Prior to Android O when the application is in the background these
> aggressive sync timeouts keep the local data updated until the application
> is killed by the system.  After Android O those requests fail and will
> begin to call the failure callback while the application is backgrounded.*
>  The way that Google advises apps to work around this is to use the
> JobScheduler APIs.
>
> JobScheduler has one downside though, you can't schedule background tasks
> to run as frequently as the sync APIs want to run.  I believe the minimum
> is once every 15 minutes.  For polling from the background this probably
> isn't a big deal especially if there is a way to return the app to a more
> aggressive state when it is in the foreground.
>
> For the next sprint the client SDK team is looking at implementing
> JobScheduler for sync because this will make the sync APIs work better in
> Android O.  Does anyone have any objection/points of discussion or
> clarification to the behavior and restrictions I mentioned?
>
> Thanks,
>
> Summers
>
> * Specifically if the phone has gone into Doze mode.
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>


-- 

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile <https://www.redhat.com/>

weil at redhat.com    M: +353862393272
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20170815/5a3b8665/attachment.htm>