[feedhenry-dev] FH-Sync and Android O

[Wojciech Trocki]

Just to provide context. JavaScript version has no background operations -
sync is happening only when on foreground.
When changes are made (add) sync loop is triggered automatically. This may
be considered as workaround for problem mentioned above.

Having service and waking up application to make request will have huge
impact on app battery usage.
Best to find some tradeoff between battery life and update times.

WOJCIECH TROCKI

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

IM: wtrocki
<https://red.ht/sig>

On Tue, Aug 15, 2017 at 8: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.
>
> 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>
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20170816/e1f5b115/attachment.htm>