Channels
#android
Title
# android
u
ursus
10/28/2018, 4:34 AMHas 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 PMyou 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 PMI 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 PMok 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 PMwell 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 PMtechnically, 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 PMhmm really? thats kind of a big hole in google "foreground all, notification, user knows about background activity" effort?
s
Sam
10/28/2018, 3:55 PMAnd for your design, yes an empty foreground service is just fine
u
ursus
10/28/2018, 3:55 PMheh thats sneaky, id expect for it to get shut down next release
s
Sam
10/28/2018, 3:56 PMI hope so too
u
ursus
10/28/2018, 3:57 PMIve 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 PMNot opinionated either ways, may be design folks can give you tip
u
ursus
10/28/2018, 3:59 PMwhat design folks? is there some channel?
s
Sam
10/28/2018, 3:59 PMother members, not that i'm aware of
u
ursus
10/28/2018, 4:01 PMoh I see, thanks
tldr; service instance as a sideeffect vs. service instance as a facade infront
2 Views