FH-Sync and Android O

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

FH-Sync and Android O

supittma
Administrator
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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: FH-Sync and Android O

David Martin

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, <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: FH-Sync and Android O

Wei Li
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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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

IM: wtrocki


On Tue, Aug 15, 2017 at 8:55 PM, Wei Li <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: FH-Sync and Android O

supittma
Administrator
In reply to this post by Wei Li


On Tue, Aug 15, 2017 at 3:55 PM, Wei Li <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: FH-Sync and Android O

supittma
Administrator
In reply to this post by David Martin


On Tue, Aug 15, 2017 at 3:44 PM, David Martin <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: FH-Sync and Android O

supittma
Administrator
In reply to this post by Wojciech Trocki


On Wed, Aug 16, 2017 at 4:48 AM, Wojciech Trocki <[hidden email]> wrote:
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.


JobScheduler coordinates with the Android OS to bundle operations so they are more respectful of battery and network conditions.  It is the official "here is how you do this" solution of Android ;)

Not to be confused with the official sync solution for Android.  SyncAdapters are overkill for the most part.


 

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


On Tue, Aug 15, 2017 at 8:55 PM, Wei Li <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev