hello, Leora

how can I help you today?

Hi Mark

You were missed at Droidcon TLV....it was rather amateurish

but i digress

sorry!

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

we were using a handler, until we saw after 15-20 mins that the app is in background, it started to falter

"no concurrent sessions", meaning that the user is not downloading stuff on another device at the same time?

exactly

OK

so from reading your material and others...the correct conclusion would be to use JobIntentService for these pings correct?

um, probably not

it's not the downloading itself (which is handled by a third party)

oh....?

let's roll back to your Handler solution

is this being managed from a Service?

nope

is the downloading somehow guaranteed to be done only in the foreground?

or is the third party using a service?

no, we have download in background

OK, so, what is keeping your process around while the download is happening?

i lost you....WHICH process? i assume the third party is using some kind of service...i have to check furhter

your app's process

but will that info determine what i use for our own pings?

I am trying to figure out why the Handler solution is not working

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

from what i understood, Doze putting the CPU to sleep.

i also tested on a device less than M

then your download would be stopping too, and you would appear to have bigger problems

and it works fine on that device

¯\_(ツ)_/¯

regardless, JobIntentService alone is not a solution

as something has to cause the JobIntentService to run

and the JobIntentService would be good for just one ping

a timer...?

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

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

so then you're implying foreground service?

I am implying a foreground service, plus forcing the user to add your app to the battery optimization whitelist

as you have no way to prevent Doze mode otherwise

users will be... disinclined to do this

for heaven's sake....i don't think netflix behaves that way...

first, Netflix is doing its own downlaoding

er, downloading

OR is it more correct to pause the download in DOZE, and wake it appropriately

it is in continuous communication with the server

what do you mean 'it's own'

Netflix is not delegating the server communications to some black box/third-party solution, as you appear to be doing

[sheepish]

there's nothing necessarily wrong with what you're doing

but Netflix isn't a great comparison

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

I've never tried having a socket open when the device enters Doze

hmmm...good point

once the device is in Doze, you have no more Internet access, outside of designated "maintenance windows"

it's possible that an open socket stays open, even after the device enters Doze, which would allow the download to potentially continue

so the answer would be to keep the handler, but take appropriate measures when the ping comes 'late'

well, I'd start by having a Service manage the Handler (or better yet, have the Service manage a ScheduledExecutorService)

that will help eliminate the pings going away because your process does

and that assumes that the third-party stuff is using a separate process (and I don't know if it is or not)

Doze mode doesn't kick in until after an hour

but which service? i understand bound service can also be unbound (or at least from O)

as in, Android O

this rolls back to your foreground service question

it would need to be a foreground service on Android 8.0

well something is messing up the handler after 15-20 mins

or a JobIntentService, if you only need pings for 10 minutes, which doesn't seem to be the case

I recommend that you spend some time isolating the actual cause behind your ping problem

my best guess, based on this chat, is that the third party is using a separate process, and your process is being terminated

i thought i did - it always messes on M+, and doesn't on less

there are *lots* of variables here

yes i think so too

so...which service sir?

if you are needing these pings to go on for 20+ minutes, it would have to be a foreground Service

ooooo. heavy stuff

plus a WakeLock

i see

now, the third party probably already has a WakeLock, and you can use adb to confirm this

yes i will look into what's going on here. good idea

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

Android 7.0+ partial Doze/"Doze on the go" behavior adds new wrinkles: https://developer.android.com/about/versions/no...

personally, I have never needed to write something like this, and so I don't have a pre-packaged solution to point you to

to be honest, this whole problem screams "do something other than pinging"

hmmm, yeah they kept using the audio player example

ughhhh

the third-party stuff is downloading material from your server?

yes

then, why do you need the pings?

doesn't the server already know that it is downloading data to this device?

why do you need a separate socket connection to tell the server "hey, BTW, we have this other socket going, #kthxbye"?

this rolls back to the Netflix scenario

Netflix doesn't need to ping, because Netflix knows that Netflix (the app) is download from Netflix (the server)

er, is downloading from Netflix (the server)

[sheesh, I can't type this morning...]

the pings feel like a workaround for some server limitation

sorry just asked. the download and play stream is NOT from our server

oh

well, that certainly qualifies as a server limitation: it's not your server :-)

hahahah

still, there may be a solution that doesn't involve a continuous series of pings

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

not viable, cause we check for simultaneous streaming as well

download on device #2 kicks out play stream on device #1, etc

ok

I don't know what more to tell you

ok Mark, thanks soooo much. I will ponder what you wrote (as usual you have given me MUCH to think about)

I soooo appreciate this

you're very welcome

Thanks, have a good one

you too!

:)