6

It appears from all the code examples that we only want to invoke #unbindService (on the same context), if we have invoked #bindService, which is accomplished via a boolean check.

But there are no similar checks in the #bindService call -- i.e. we do not check if we have already bound first to avoid "double binding".

So my questions --

  1. "will bad things happen" if I bind a service multiple times but only unbind once, or it's only bad if i bind once and unbind multiple times? Such asymmetry seems weird to me but wanted to see if anyone knows the answer. I am playing with it now myself trying to figure it out but would prefer an "official" answer from more experienced devs.
  2. What is considered a "bind" and "unbound" operation -- is it the fact that i have simply invoked the #bind (or #unbind) API, and those calls must be paired, OR is the bound/unbound state indicated by the #onServiceConnected/Disconnected callback that must be paired? Google's own examples seem to indicate the former is true, could anyone confirm? If former is true, then a final more subtle question: if #bindService returns false, i.e. android won't even attempt to connect as it couldn't resolve the service, in that case is it safe to invoke #unbindService?

Thank you.

Creos
  • 2,445
  • 3
  • 27
  • 45
  • How come you can bind twice (or more) with the same service connection? – pskink Jan 20 '15 at 19:28
  • yes I've seen the documentation, and it isn't quite answering my questions.it seems that you CAN bind twice to the same connection even if it "makes no sense". That's part of the reason why I'm asking this question. I was looking for formal contracts around these methods so I can create a robust application, not just the general guidance of a sample usage. As always google's doc is very superficial and not a proper contract spec. There are situations where you might not get a perfect connect/disconnect pairs in my app and I want to understand better how to handle them. – Creos Jan 23 '15 at 16:25
  • 1
    even if you call bindService with the same ServiceConnection, multiple times onServiceConnected is called only once, that indicates that the second call and later calls are no-ops and one unbindService will do the work – pskink Jan 23 '15 at 17:31
  • agreed, it appears so, the point is that there is 0 documentation on the invariants and contracts around these methods. google just leaves everything unspecified and next release if they change they behavior it's like "well too bad". They need to define some contract and stick to it. Today, it silently ignores it (it seems), tomorrow it might throw. Ugh. Thanks anyway – Creos Jan 23 '15 at 18:07

1 Answers1

-2

I doubt that Android allows to bind to same service several times, but it makes no sense.

You bind to service and get a Messenger object. Next time you check, if messenger is null. If it isn't there is no need to bind again. Once your activity ends and the messenger is not null, you unbind.

The details are here.

cyanide
  • 3,885
  • 3
  • 25
  • 33
  • 1
    yes I've seen the documentation, and it isn't quite answering my questions.it seems that you CAN bind twice to the same connection even if it "makes no sense". That's part of the reason why I'm asking this question. I was looking for formal contracts around these methods so I can create a robust application, not just the general guidance of a sample usage. As always google's doc is very superficial and not a proper contract spec. There are situations where you might not get a perfect connect/disconnect pairs in my app and I want to understand better how to handle them. – Creos Jan 23 '15 at 16:25
  • 1
    also google's examples is wrong. Indeed, to be precise you should not just set the variable "isBound" to true, you should look at the return value of #bindService to ensure the system even will try to invoke the callback, so there's already a bug in the link you sent. Again, that was the purpose of my question, I think it is being dismissed without being fully understood... the downvote is also silly – Creos Jan 23 '15 at 16:29