Jan 4 | 8:55 AM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Jan 4 | 9:00 AM |
Leora | has entered the room |
Mark M. |
hello, Leora
|
Mark M. |
how can I help you today?
|
Leora |
Hi Mark
|
Leora |
You were missed at Droidcon TLV....it was rather amateurish
|
Leora |
but i digress
|
Mark M. |
sorry!
|
Leora |
i inherited a bug...while a user is downloading content, the app pings the server every 30 seconds to make sure there are no concurrent sessions
|
Jan 4 | 9:05 AM |
Leora |
we were using a handler, until we saw after 15-20 mins that the app is in background, it started to falter
|
Mark M. |
"no concurrent sessions", meaning that the user is not downloading stuff on another device at the same time?
|
Leora |
exactly
|
Mark M. |
OK
|
Leora |
so from reading your material and others...the correct conclusion would be to use JobIntentService for these pings correct?
|
Mark M. |
um, probably not
|
Leora |
it's not the downloading itself (which is handled by a third party)
|
Leora |
oh....?
|
Mark M. |
let's roll back to your Handler solution
|
Mark M. |
is this being managed from a Service?
|
Leora |
nope
|
Mark M. |
is the downloading somehow guaranteed to be done only in the foreground?
|
Mark M. |
or is the third party using a service?
|
Leora |
no, we have download in background
|
Mark M. |
OK, so, what is keeping your process around while the download is happening?
|
Leora |
i lost you....WHICH process? i assume the third party is using some kind of service...i have to check furhter
|
Jan 4 | 9:10 AM |
Mark M. |
your app's process
|
Jan 4 | 9:10 AM |
Leora |
but will that info determine what i use for our own pings?
|
Mark M. |
I am trying to figure out why the Handler solution is not working
|
Mark M. |
one possibility is that the third-party downloading thingy has its own service, with android:process set up so that service runs in its own process
|
Leora |
from what i understood, Doze putting the CPU to sleep.
|
Leora |
i also tested on a device less than M
|
Mark M. |
then your download would be stopping too, and you would appear to have bigger problems
|
Leora |
and it works fine on that device
|
Mark M. |
¯\_(ツ)_/¯
|
Mark M. |
regardless, JobIntentService alone is not a solution
|
Mark M. |
as something has to cause the JobIntentService to run
|
Mark M. |
and the JobIntentService would be good for just one ping
|
Leora |
a timer...?
|
Mark M. |
if you want to ping every 30 seconds, you have to prevent the device from going into Doze mode, and you have to ensure that you have a process running all of the time
|
Mark M. |
all of this is relatively user-hostile, and so you will want to ensure that you unwind it once the download completes or the pings are otherwise no longer needed
|
Leora |
so then you're implying foreground service?
|
Mark M. |
I am implying a foreground service, plus forcing the user to add your app to the battery optimization whitelist
|
Jan 4 | 9:15 AM |
Mark M. |
as you have no way to prevent Doze mode otherwise
|
Mark M. |
users will be... disinclined to do this
|
Leora |
for heaven's sake....i don't think netflix behaves that way...
|
Mark M. |
first, Netflix is doing its own downlaoding
|
Mark M. |
er, downloading
|
Leora |
OR is it more correct to pause the download in DOZE, and wake it appropriately
|
Mark M. |
it is in continuous communication with the server
|
Leora |
what do you mean 'it's own'
|
Mark M. |
Netflix is not delegating the server communications to some black box/third-party solution, as you appear to be doing
|
Leora |
[sheepish]
|
Mark M. |
there's nothing necessarily wrong with what you're doing
|
Mark M. |
but Netflix isn't a great comparison
|
Mark M. |
going back to Doze, presumably your download is already stopping when the device goes into Doze mode, or at least is at risk of stopping
|
Mark M. |
I've never tried having a socket open when the device enters Doze
|
Leora |
hmmm...good point
|
Mark M. |
once the device is in Doze, you have no more Internet access, outside of designated "maintenance windows"
|
Mark M. |
it's possible that an open socket stays open, even after the device enters Doze, which would allow the download to potentially continue
|
Leora |
so the answer would be to keep the handler, but take appropriate measures when the ping comes 'late'
|
Mark M. |
well, I'd start by having a Service manage the Handler (or better yet, have the Service manage a ScheduledExecutorService)
|
Jan 4 | 9:20 AM |
Mark M. |
that will help eliminate the pings going away because your process does
|
Mark M. |
and that assumes that the third-party stuff is using a separate process (and I don't know if it is or not)
|
Mark M. |
Doze mode doesn't kick in until after an hour
|
Leora |
but which service? i understand bound service can also be unbound (or at least from O)
|
Leora |
as in, Android O
|
Mark M. |
this rolls back to your foreground service question
|
Mark M. |
it would need to be a foreground service on Android 8.0
|
Leora |
well something is messing up the handler after 15-20 mins
|
Mark M. |
or a JobIntentService, if you only need pings for 10 minutes, which doesn't seem to be the case
|
Mark M. |
I recommend that you spend some time isolating the actual cause behind your ping problem
|
Mark M. |
my best guess, based on this chat, is that the third party is using a separate process, and your process is being terminated
|
Leora |
i thought i did - it always messes on M+, and doesn't on less
|
Mark M. |
there are *lots* of variables here
|
Leora |
yes i think so too
|
Leora |
so...which service sir?
|
Mark M. |
if you are needing these pings to go on for 20+ minutes, it would have to be a foreground Service
|
Leora |
ooooo. heavy stuff
|
Mark M. |
plus a WakeLock
|
Jan 4 | 9:25 AM |
Leora |
i see
|
Mark M. |
now, the third party probably already has a WakeLock, and you can use adb to confirm this
|
Leora |
yes i will look into what's going on here. good idea
|
Mark M. |
basically, your ping service needs to work like a streaming audio player, insofar as you need it to be running for a long time while retaining network connectivity
|
Mark M. |
Android 7.0+ partial Doze/"Doze on the go" behavior adds new wrinkles: https://developer.android.com/about/versions/no...
|
Mark M. |
personally, I have never needed to write something like this, and so I don't have a pre-packaged solution to point you to
|
Mark M. |
to be honest, this whole problem screams "do something other than pinging"
|
Leora |
hmmm, yeah they kept using the audio player example
|
Leora |
ughhhh
|
Mark M. |
the third-party stuff is downloading material from your server?
|
Leora |
yes
|
Mark M. |
then, why do you need the pings?
|
Mark M. |
doesn't the server already know that it is downloading data to this device?
|
Jan 4 | 9:30 AM |
Mark M. |
why do you need a separate socket connection to tell the server "hey, BTW, we have this other socket going, #kthxbye"?
|
Jan 4 | 9:30 AM |
Mark M. |
this rolls back to the Netflix scenario
|
Mark M. |
Netflix doesn't need to ping, because Netflix knows that Netflix (the app) is download from Netflix (the server)
|
Mark M. |
er, is downloading from Netflix (the server)
|
Mark M. |
[sheesh, I can't type this morning...]
|
Mark M. |
the pings feel like a workaround for some server limitation
|
Leora |
sorry just asked. the download and play stream is NOT from our server
|
Mark M. |
oh
|
Mark M. |
well, that certainly qualifies as a server limitation: it's not your server :-)
|
Leora |
hahahah
|
Mark M. |
still, there may be a solution that doesn't involve a continuous series of pings
|
Mark M. |
if the objective is to prevent simultaneous downloading, perhaps just checking the status immediately before each download, and updating the status when the download completes, would suffice
|
Jan 4 | 9:35 AM |
Leora |
not viable, cause we check for simultaneous streaming as well
|
Leora |
download on device #2 kicks out play stream on device #1, etc
|
Mark M. |
ok
|
Mark M. |
I don't know what more to tell you
|
Leora |
ok Mark, thanks soooo much. I will ponder what you wrote (as usual you have given me MUCH to think about)
|
Leora |
I soooo appreciate this
|
Mark M. |
you're very welcome
|
Leora |
Thanks, have a good one
|
Mark M. |
you too!
|
Leora |
:)
|
Jan 4 | 10:00 AM |
Leora | has left the room |
Mark M. | turned off guest access |