On 6/19/13 3:34 PM, Tab Atkins Jr. wrote:
This is missing the point. You don't want to wait until it's actually time to create the context. Unless you torture your code flow, by the time you're creating a context you should already know that the context is supported. The knowledge of which context to use is most useful well before that, when you're first entering the app.
But supportsContext doesn't give any guarantee that the getContext will succeed.
Plus, it doesn't matter how late you do the detection - if you do a straight *detection* at all rather than an initialization (that is, if you throw away the context you've just created for testing)
OK, but why are we making that assumption? I guess if people insist on doing that, then we do in fact need something that will basically try to guess whether getContext might succeed.
Like @supports, the supportsContext() method can be easy and reliable with a very simple definition for "supports" - it returns true if calling getContext() with the same arguments would return a context rather than erroring, and false otherwise.
Just so we're clear, this is _not_ what supportsContext is specified to do. As specced, it will return false if you know for a fact that getContext would return null. It will return true if you think that getContext might not return null. This means that a true return doesn't really mean squat about what getContext will do.
And the reason for that is that you can't tell whether getContext will return null until you try to do it, given how getContext is specced.
-Boris
