hello, Eric!

how can I help you today?

Hi Mark!

I have a more empirical question for you today about GCM

In your experience

How reliable is it?

my experience with GCM can fit on the back of a postage stamp, with room left over

Would you say it delivers 50%, 80%, 99% of the time, from the projects you have worked on?

OK so you have not worked that much with it

it's one of the reasons I dropped the GCM chapter in the book

Ah ok

the vibe I get from others is that it's probably in the high 90's

Have you an experience with people attempting to create long-running sockets in background services?

We only keep our socket open while forgrounded

yeah, and it sucks on Android 6.0+, courtesy of Doze mode

we close it 30 sec after being backgrounded

that's a reasonable pattern

Long-running BG sockets? Ah good point about Doze mode

Yeah so we do that and then hope that GCM will come thru for us, but it's been spotty

OK so my next question --

We have a service that is started or triggered when we get a GCM message

(obviously)

Is this service ever terminated, assuming the OS does not have a low-memory situation?

No, right?

if you do not stop it, the user theoretically could, in the Settings app

I read that services must be manually terminated by our code, otherwise the OS will only terminate in low-memory conditions

right right

of course

correct

OK got it

So,

I am thinking that I might implement a polling solution in our service

and then, it doesn't so much terminate the *service*, as it terminates the *process*

Right, the process contains the service

because the service has access to that singleton application object

which is where it gets access to a singleton networking object we use

that controls all API requests, etc

I am thinking that service should do polling

Say, ever 10 or 30 min or something

Since GCM has been so spotty for us

if this is "what if GCM doesn't come through", you could treat it more as a fallback

Right

when a GCM message comes through, set an alarm to get control in N minutes

including cancelling the previous alarm, if still outstanding

I was using the sendDelayedMessage

and Handlers

that way, you're not polling unnecessarily, when GCM is behavingg

right

oh, right, OK

I'd just use ScheduledExecutorService

Is there a big difference?

Is ScheduledExecutorService better than what I proposed?

not a ton, admittedly

OK I just ask because I am v familiar with that design pattern but not at all with ScheduledExectorService

you have to remember to use a HandlerThread, as you don't really want to be getting control on the main application thread

exactly

OK

anyway, your Handler approach is probably fine

So polling in a service as a fallback to GCM -- that is the design pattern you would use given the problem I have described?

Or is there a better approach you can think of?

if by "polling" you mean "poll when GCM is not pushing", then yes

that's the only GCM-centric approach that I am aware of

though there can be variations in how the polling is done

usually, I recommend that people don't try to keep services running any more than they have to

Well

Once GCM activates my service

It's running indefinitely, unless I stop it, right?

yes, with the idea that you stop it when you are no longer *actively* delivering value to the user

watching the clock tick is not actively delivering value to the user

True

so long as your service is running, Android's going to try to keep your process around

from your standpoint, that's wonderful

For a messaging / chat app however, you never know when a new message could come in

from the user's standpoint, not so much

very trye

er, true

And given GCM's spottiness,

OK

Last question --

Have you heard of this approach: https://eladnava.com/pushy-a-new-alternative-to...

Using "MQTT"?

I know of MQTT

haven't heard of Pushy itself

allegedly

neither Facebook or Whatsapp use GCM

they both use custom implementations that keep proprietary sockets open at all times

that use MQTT

MQTT is probably the leading non-GCM push solution

however, that's where the Doze mode challenges start to creep in

in principle, if you have an MQTT socket open on mobile data, an incoming packet should wake up the device

OK

and allow you to process the message

Have you ever worked with or implemented an MQTT solution?

I'm under the impression that Doze mode interferes with that flow, though

not personally

though it's on my to-do list

And is that some kind of "new" socket or mode

I thought a socket is a socket

can you "tag" a socket as an MQTT socket on Android?

Starting with version XXX or something?

yes, but the processors treat things differently

OK, interesting, so different devices treat an MQTT socket differently

if you go back and watch the 2012(?) Google I|O presentation on C2DM (the GCM predecessor), they get into some of these details

basically, it's how GCM works, to keep a long-lived socket going with minimal power usage

Ah ok

again, I haven't played with MQTT, particularly in the past year

There must be some kind of native understanding of MQTT in android for this then

not strictly for MQTT

this is a flag I can pass in Java.io.

just for open socket connections on mobile data

which MQTT eventually uses, when the device falls off of WiFi

Ah ok

my suspicion is that with Doze mode, the MQTT-using app might not get control when the device falls off of WiFi

but that's just an educated gues

er, guess

Looks like IBM also ships some kind of library that can be used for this

yes, IBM was one of the MQTT creators, IIRC

Ah, makes sense

MQTT predates Android, IIRC

OK, well, I will look into MQTT, but probly start by trying to implement polling

Oh, interesting!

MQTT mostly seems to be used for two cases:

1. non-Play ecosystem devices, where GCM simply doesn't exist

2. places where even using encrypted GCM messages might be too much exposure (e.g., medical data)

OK

makes sense

the reason why I want to add an MQTT chapter in my book is that I try to promote non-Play-specific tech, where I can

because I think a good chunk of my readership writes apps for non-Play-ecosystem devices

That must be what they are using in China too

that, or I think some manufacturers there have their own GCM equivalents baked in

That's interesting that you can essentially install another GCM-substitute on your device, but it makes sense

yeah, but GCM gets preferential treatment, with respect to stuff like Doze mode

ah, good point

which is why this stuff is on my list of "if anyone ever asks me for antitrust ammo against Google..."

haha

don't mind them shipping with their stuff baked in and pre-enabled

but locking it so third parties cannot compete as equals has anti-competitive overtones

yah true

OK cool...can I ask one more question unrelated to any of this?

go right ahead -- it's a quiet chat room tonight

OK great --

We are prepping a new launch

getting lots of feedback and crash logs into Crashlytics

at this point, most of the crashing is OOM exceptions

sometimes my code

sometimes OS code

frequently image decoding or XML layout decoding

In your experience, is this just the state of the Android world?

it depends on the nature of the OOM

A slow drip of OOM exceptions?

if the OOM is because you are trying to allocate something huge, that's an app bug

if the OOM is because you are trying to allocate something normal, that's just the state of the Android world

(and is one of the reasons to let your process die, so you get a nice unfragmented heap)

Yeah exactly

these are allocating "normal" things

and so the process dies yup

ART helps some

so I would hope that you're getting somewhat fewer OOMs on Android 5.0+

OK good question -- I will inspect these logs and look at the OS version

When you look at Crashlytics logs of projects you have helped or worked on

Do you see a lot of OOM exceptions for "normal" things too?

not usually

Gosh, this is something Crashlytics could also answer since they get so much data about this...I should suggest that to them

OK

again, process lifetime is fairly important

this sort of thing is one of the reasons why some people split long-running services out into a separate process

so your UI process can die

Ah

so later runs of your UI get a fresh process and fresh heap

Very good point

personally, I think it's a bit of a Band-Aid

but, certain types of apps may need it more

something like yours, for example

Yeah...that design pattern makes sense as a work-around

OK, great

Thank you for your help and input

It is most appreciated!!

you are very welcome

Have a great evening!

you too!