[feedhenry-dev] FH-Sync and Android O

[Summers Pittman]

On Tue, Aug 15, 2017 at 3: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 .
>
>
I understand the example you are trying to put forward, but I think it is
flawed.  In this case I would argue against using sync to send the data; it
should be a more traditional (HTTP PUT or POST) mechanism.  Sync is useful
for the eventually consistent use case.  Data is saved locally but it is
sent to the cloud when it is appropriate for the device.

To your use case though, currently in Android O we can't background sync
and in < Android O we can't guarantee a background sync.  With JobScheduler
we can and the developer gets a better experience.


> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20170816/381b896b/attachment.htm>