Any reference in Java can be null, as is the case in most languages. So developers only check the ones they know "could" be null, in normal operation. If you only distribute your app via the Play Store, attempting to access it will never fail, thus there's no more point in checking for null pointers than there is in checking the result of String.split: it will never fail, short of something wacky and unexpected like a broken JVM.
> So developers only check the ones they know "could" be null, in normal operation.
Not the good ones. Normal operation isn't when you're dealing with a mobile device, there could be any number of reasons why your app can't reach a certain service delivered by some API so better to be prepared for that eventuality.
Actually the way you check for Google Play services doesn't involve nulls at all, it's a status code.
And related to null-checking, I took the pervasive approach in one of my apps for fun. It's hilarious - almost 1/3 of my app is checking if something is null. Makes you wish for a switch to a language where nulls don't exist unless explicitly asked for.
Not always. If you use maps, for instance, then calling getMap on a map fragment when Play Services isn't installed will give you back a null reference.
mike_hearn|11 years ago
jacquesm|11 years ago
Not the good ones. Normal operation isn't when you're dealing with a mobile device, there could be any number of reasons why your app can't reach a certain service delivered by some API so better to be prepared for that eventuality.
edgyswingset|11 years ago
And related to null-checking, I took the pervasive approach in one of my apps for fun. It's hilarious - almost 1/3 of my app is checking if something is null. Makes you wish for a switch to a language where nulls don't exist unless explicitly asked for.
njs12345|11 years ago