Hello

hello, Venkat!

how can I help you today?

I have two questions related to the same thing ...

I have a websocket service which 3 different activities use. Each activity has a member for ServiceConnection. What I expected was a single websocket connection to the server shared by all activities but what I see is 3 different connections.

1. Any ideas why this is happening.

2. I am thinking of either using something like Greenrobot EventBus or a singleton - which would be better.

regarding #1, I cannot really comment on that, as I have no idea how this service is implemented

ok

regarding #2, your question is akin to "I am thinking of using a banana or a hammer - which would be better?", insofar as the choice of a singleton or an event bus are not strictly related

ok

and I do not know how either of those relate to the service and activities from #1

so, let's go back to #1

when and how does this service create a WebSocket?

Each activity has a member for ServiceConnection & in the override for onServiceConnected it attempts to create a websocket connection if not already done.

then the activities are the ones creating the websocket, not the service

and so if you have three activities, you will have three websockets

ok ...

if you want a "websocket service", the *service* should be creating the websocket, perhaps in onCreate() of the service

the activities delegate the websocket communications to the service

ok ... I will try that

To clarify ...

Does that create separate instances of the WebsocketService class for each activity?

probably not, but I do not know all of the details behind those two lines

ok

is WebsocketService a Service?

Yes, it extends Service.

is WebsocketService.LocalBinder a subclass of IBinder, where WebsocketService returns an instance of WebsocketService.LocalBinder from onBind()?

Correct!

OK

in the first line of your code snippet (WebsocketService.LocalBinder binder = (WebsocketService.LocalBinder) service;), what is service? Is that the IBinder passed into onServiceConnected()?

Yes correct.

and getService() on WebsocketService.LocalBinder returns... what?

WebsocketService.this

OK

then presumably all of these are in one process (as what you are doing will not work across process boundaries)

Yes

whether mService is the same object or N objects depends on the timing of the binding and unbinding

and whether you are also starting WebsocketService

once you call unbindService(), if there are no other current bound connections from other bindService() calls, and if the service was not started, the service is destroyed

so, suppose that your three activities are A, B, and C

Ok ...

if A binds and unbinds before B and C get a chance to bind, and if A did not start WebsocketService, A will have worked with a different instance of WebsocketService than will the others

Ok ... that complicates things a bit ... I did not know that.

this is one of the reasons why I am not a big fan of the binding pattern -- the bookkeeping gets complex

I think that is what I am doing wrong

... there is no call to startService in my code.

depending on your activity flow, you *may* be able to make that work

you would have to bind in onCreate() and unbind in onDestroy()

(plus use a retained fragment or something so that you do not unbind and re-bind on a configuration change)

basically, you need to ensure that B has a chance to bind before A has a chance to unbind

(and similarly for C)

Ok ...

I will read up more on services + change the code as you say.

I just had one more comment on the book.

I needed to implement tabs in my application and my first attempt was based on the example in your book (I don't remember the details). Later, I learnt that the recommended way is to use android.support.design.widget.BottomNavigationView

there are lots of tab implementations

Just thought a note in the book about that option would be helpful.

BottomNavigationView is not "the recommended way" necessarily

Ok ... :-)

I do not anticipate covering BottomNavigationView any time soon, sorry

Ok ... I thought BottomNavigationView was recommended ... I don't remember the source though. Something to do with placement at the bottom of the screen.

some people like that, some people do not

Ok

I am not going to be covering every possible UI permutation -- I simply do not have that kind of time

:-) ... I fully understand ... the reason I asked you is to simply know if that was an oversight or intentional.

it's an intentional oversight :-)

Thats all.

The book as it is is very extensive.

Android is vast

the Android ecosystem is even more vast

Yup ... and your book does a great job as a first source of reference.

thanks!

Thanks for your help & best wishes of the season.

Goodbye.

have a pleasant day!

hello, Leora!

Hi Mark, 3 minutes left!

I can help you with a quick question, if you have one

yeah, I need to query the DB using room...but when the user or OS kills the app.

you do not get control when Android terminates your process (by user request or automatically when you are in the background)

I'm using a service to catch the event just before the activity is destroyed

do you mean onTaskRemoved()?

I'm using it in onTaskRemovedBroadcastReceiver

yes sir!

AFAIK, that is not reliable, but if you want to do some work there, you are welcome to try

so, the query won't work with context that is being destroyed

but my boss doesn't want me to call the function beforehand

since the query is unnecessary beforehand

well, you can try using the Application context (call getApplicationContext() on any other Context)

what would you recommend then to, for example, pause downloading content

ok, application context option. anything else? better solution to make sure method is called?

I am not quite certain what that has to do with Room, and it would depend on how the downloading is being done and what interruption options it has

well, onTaskRemoved() is only called on some devices in some situations

some devices do not appear to call that when the user swipes the task off the overview screen, for example

cause the previous queries were not on another thread

based on complaints that I have been seeing in Stack Overflow, etc.

ahhh, i didn't know that

so far it's worked

I also do not expect it to be called if the user does a Force Stop from your app's screen in Settings

but i ALWAYS wanted to know how to handle last second methods that HAVE to happen before app is killed

by then, it's too late

whatever work you wanted to do should have been done much sooner, such as when the app moved into the background

or when the data changed

or something

but content should keep downloading in bckgrnd

by definition, it will not be, as your process is being terminated

(exception: downloading being done in another process, such as DownloadManager)

and be suspended before app is closed

you need to handle *lots* of downloading interruptions

onTaskRemoved() represents a subset of those, at best

i'm afraid i don't understand what you are suggesting

since the downloading will be stopped when your process is, you need to be able to handle that when your process starts back up again

as that will handle cases where the downloads are interrupted due to lost network connections, airplane mode, etc.

oh i see

in addition to mid-flight process termination

yes i see

moreover, on Android 8.0+, you need to use a foreground service, since the download might take more than a minute

confused, yet understand, sort of

:)

such a service should still run even if the user swipes the task off of the screen

it should? i'm rather surprised you say that

worked when I tried it recently for an issue with my CWAC-Presentation library

that may have been a Samsung-specific behavior, but AFAIK it is the norm

it should keep downloading until the user herself pauses it?

if that's what the service is doing, yes

at least, for most devices

there will always be edge cases, where the manufacturer ties the overview screen to Force Stop or something

in addition to the problems with network connections and whatnot

so, if I were in your shoes (which probably do not fit me, but, anyway...) I would be using a foreground service, but still have "disaster recovery" logic to deal with an interrupted download when my process starts up again

i don't want to keep you any later. i will reread what you wrote and ponder

and not worry about trying to somehow magically get control on every possible process termination scenario, since that's impractical

OK

and btw, i have big feet

well, then, there's hope for me yet! :-)

(or at least for my feet)

i just don't know how i can get the 'actual' status of the content, but ok

thank you so so much

you're welcome! FWIW, the next chat in this time slot is Thursday of next week

are you coming to droidcon TLV tomorrow as a surprise guest speaker?

:)

not that I am aware of

darn it

the transcript for this chat will go up on https://commonsware.com/office-hours/ shortly

have a pleasant rest of your day!

namaste