https://kotlinlang.org logo
#android
Title
# android
u

ursus

10/28/2018, 4:34 AM
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?
r

radityagumay

10/28/2018, 7:36 AM
@ursus what the use case you want to achieve?
s

Sam

10/28/2018, 12:03 PM
you could start from background using the ContextCompat API
just make sure to call startForeground() from the service within 5 seconds of launch
this is needed for Android Oreo's background service limitation
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
u

ursus

10/28/2018, 3:21 PM
I know all that oreo stuff
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
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
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
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
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
s

Sam

10/28/2018, 3:39 PM
ok is the foreground service just because you don't the app to get killed? A normal bound service too does the job
u

ursus

10/28/2018, 3:52 PM
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
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
s

Sam

10/28/2018, 3:53 PM
technically, you can bound without a UI component like using application context
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)
anyways, that is out of the way
u

ursus

10/28/2018, 3:54 PM
hmm really? thats kind of a big hole in google "foreground all, notification, user knows about background activity" effort?
And for your design, yes an empty foreground service is just fine
u

ursus

10/28/2018, 3:55 PM
heh thats sneaky, id expect for it to get shut down next release
s

Sam

10/28/2018, 3:56 PM
I hope so too
u

ursus

10/28/2018, 3:57 PM
Ive never seen such design before, everybody puts objects inside the service, i.e. service is a facade infront of their code
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)
s

Sam

10/28/2018, 3:58 PM
Not opinionated either ways, may be design folks can give you tip
u

ursus

10/28/2018, 3:59 PM
what design folks? is there some channel?
s

Sam

10/28/2018, 3:59 PM
other members, not that i'm aware of
u

ursus

10/28/2018, 4:01 PM
oh I see, thanks
tldr; service instance as a sideeffect vs. service instance as a facade infront
2 Views