[feedhenry-dev] FH-Sync and Android O

[Summers Pittman]

On Tue, Aug 15, 2017 at 3:55 PM, Wei Li <weil at redhat.com> wrote:

> Yeah, agreed. Another thing we can also try is to call the sync API just
> before the app going into background. That should make sure the local data
> is uploaded even if the background sync frequency is very low.
>

Point of order, during onPause and onStop you are supposed to be releasing
resources and ending network connections, not starting new ones.

During backgrounding we should not start a new network request, we should
migrate pending requests to a background sync mechanism. (aka JobScheduler)


>
> On Tue, Aug 15, 2017 at 8:44 PM, David Martin <davmarti at redhat.com> wrote:
>
>> I think there might be an expectation from some users that ic they use
>> the app to update some data, that data will be make its way to the server
>> as soon as possible.
>> If I make a change in an app then immediately put the app in the
>> background, I would expect that change to be saved on the server pretty
>> soon as long as I'm online. It wouldn't seem right if that change I made
>> only got saved the next time I opened the App.
>>
>> To take an hypothetical example, if I use a particular app for logging
>> work, and log something last thing on a Friday . I then lock my phone,
>> which puts the App into the background.
>> The weekend staff take over on Saturday and pick up where I left off.
>> However, my changes never got synced so they end up repeating some work I
>> did.
>> Having some background sync, even if it was every 15 minutes ,could help
>> prevent this situation .
>>
>> On Tue, 15 Aug 2017 17:58 Wei Li, <weil at redhat.com> wrote:
>>
>>> 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>
>>> _______________________________________________
>>> 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/20170816/ede1e8ca/attachment.htm>