Has anyone thought about having "empty" foreground...

# android

[ursus]

Has anyone thought about having "empty" foreground service, i.e. not owning object references nor thread and having the object live "separately", where it emits its state, where some other code just starts / stops the service accordingly, for androids background (foreground) sake?

[radityagumay]

@ursus what the use case you want to achieve?

[Sam]

you could start from background using the ContextCompat API

[Sam]

just make sure to call startForeground() from the service within 5 seconds of launch

[Sam]

this is needed for Android Oreo's background service limitation

[Sam]

but yeah if the app is in background without any foreground service and waiting for the state to change (from a thread), it is more likely to be killed

[ursus]

I know all that oreo stuff

[ursus]

Rational behind is, I have a very stateful api, that is guared by statemachine. However if this api sits inside the service, and somebody misuses it, i.e calls wrong method at wrong time, that means the intent is routed through service, and albeit state machine refuses the input, it already started the service, since any intent will (and I cant just stopSelf if statemachine rules invalid, as the state could be ongoing, which would cancel it) and there fore it is sitting in memory for no reason

[ursus]

So statemachine needs to sit before service, but I dont feel comfortable having no machine behind it as well, and all in all that domain > android > domain sandwich feels bad

[ursus]

But if I were just to not deal with the service, code would call my foomanager directly, where the inputs would be guarded by statemachine, but inside foomanager so its transparent

[ursus]

and service would be only be mirrored, i.e. only started when call is ongoing, stopped when call hanguped, and only setting startForeground stopForeground, and nothing else

[ursus]

do you know what I mean? usually service has your object reference, and you send intents to service, and service routes those intents to your object's methods

[Sam]

ok is the foreground service just because you don't the app to get killed? A normal bound service too does the job

[ursus]

well yes because of background, and no bound service wont do because it needs ui to bind to, calls should not stop when ui killed

[ursus]

problem is not in the service, its about the design, wether do you put your callManager inside it, or next to it horizontally so to speak

[Sam]

technically, you can bound without a UI component like using application context

[Sam]

so then the different is just the importance of your app for Android (foreground service would give more lifetime than a bound service using application context)

[Sam]

anyways, that is out of the way

[ursus]

hmm really? thats kind of a big hole in google "foreground all, notification, user knows about background activity" effort?

[Sam]

Yup, check this out
https://medium.com/@debuggingisfun/android-o-work-around-background-service-limitation-e697b2192bc3

[Sam]

And for your design, yes an empty foreground service is just fine

[ursus]

heh thats sneaky, id expect for it to get shut down next release

[Sam]

I hope so too

[ursus]

Ive never seen such design before, everybody puts objects inside the service, i.e. service is a facade infront of their code

[ursus]

but would help out my code greatly, since i would have 1. have parcelable objects in order to be sent through intent, 2. dont have to have stupid logic like "if statemachine refused input and call state is disconnected then stopself)

[Sam]

Not opinionated either ways, may be design folks can give you tip

[ursus]

what design folks? is there some channel?

[Sam]

other members, not that i'm aware of

[ursus]

oh I see, thanks

[ursus]

tldr; service instance as a sideeffect vs. service instance as a facade infront