GoogleApiClient Must Not Be Null [Awareness API]

I'm trying to find out why the Google Play Services is crashing with a nullpointerexception after the application is coming back from a background state such as device sleep or tog

Solution 1:

In your onStart() method only connect the googleApiClient's object and the rest things implement in onCreate() method .

Solution 2:

First thing I'd go for is move the part in onStart() to onResume(), to make sure they are there when the user needs them, as that is the last method called before the App is shown. Same thing with onStop() to onPause(). But somehow that would seem like a too simple an answer.

Solution 3:

I assume that Awareness.SnapshotApi.getWeather(client) is probably where your code begins the call to com.google.android.gms:73, so adding the NPE to your catch statement actually might be worth, particularly as it's intermittent.

& now a Note to others: I only suggest this because I see that they're using rxJava with some skill; look at the terseness of the two monad declarations in their GoogleApiClient! All they need to do is a retryWhen(Func2<Integer, Throwable, Boolean>) and evaluate the predicate in said functional parameter to be true given throwable instanceof NPE and count of 1, maybe 2. Before the zip, I think logging and releasing further NPEs--making further anomalous behavior apparent--might satisfy the firm, educated voices telling us never, ever to catch an NPE. ...or, if tweaking the noses of those firm, educated voices sounds like a good time, they could filter out further Exceptions by type while providing appropriate downstream reactions to this predictable event...

I was about to say that you can do that because there isn't a bunch of code hanging around in the monad create() methods wishing it could be part of a side effect; however @buddhabath, I notice those create()s can generate exactly the subscription side effect you are describing--right on the subscription thread, actually:

You "should be" catching whatever comes out of those trys and sending it down the rxChooChoo; the extant onError shouldn't be a problem b/c only one will be called per evaluation. Just point the parameter of the catch at subscriber.onError() and any Throwable-excepting these Exceptions-will be kept within the tracks, perhaps like the tracks I described above the Kermit, but that leaking create() is your bug.

tl;dr: Manually defining monads with create() deserves one's full attention; it's the real world, very "imperative"; literally anything could happen in there. Myself, I just now had the pleasure of discovering the new fromEmitter and also am glad to see Observable.Generate on the menu for rxJava 2.0.