It's really difficult to tell if your scope is destroyed

[rjrjr]

Lately we've been playing with a technique where Views sometimes need to behave differently if their scope is dead, but with the Mortar's recent service-container changes that's really difficult to discover. I think the crux of the problem is that when you call MortarScope#getScope(Context) on a context with a destroyed scope, you get its lowest ancestor that isn't destroyed.

That's the right behavior for services in general, where contexts are supposed to fallback to parents. So was it a mistake to treat MortarScope as just another service? Or if that seems okay, should we add a separate static MortarScope#isDestroyed(Context) that does no fallback?

[rjrjr]

Chatted offline, it seems fair to declare "when you call MortarScope#getScope(Context) on a context with a destroyed scope, you get its lowest ancestor that isn't destroyed" a flat out bug.

[rjrjr]

We fundamentally screwed up service lookup, making destroyed scope behavior ambiguous. Refining the contract s.t. trying to use any service provided by mortar throws an exception if the nearest scope is dead. Also hiding the fact that mortar itself is a system service, making that an implementation detail.

Effects of this:

• MortarScope.getScope(context).isDead() returns true when you'd expect it to
• ObjectGraph.inject(context, object) throws if the backing scope is dead, as opposed to the current behavior where we instead try (and generally fail with a confusing message) to inject from an ancestor scope
• The behavior of MortarScope.hasService(String) is not changed in destroyed scopes. It always says yes if the service is provided by the receiving scope or an ancestor

[rjrjr]

Fixed