Nowadays it’s getting harder and harder to build a meaningful app and not rely on Google Play Services to aid us in some commonly required features such as maps, better location provider, geo fencing and so much more. Unfortunately up until now the library shipped as a giant monolith ripping us from one third of dex method limit. For curious reader here’s are method counts in couple of versions:
As I mentioned in my previous post having meaningful log entries comes handy during development. When an app reaches beta testers as well as goes live it’s equally or even more important to be able to figure out why the app you’ve carefully coded isn’t behaving as it should. Testing the app on all android flavours is literally impossible that’s why getting an insight into what caused a crash is vital.
android, materialdesign, android-support-library
People around the world are waiting for Google to push Lollipop to theirs smartphones. Material Design completely changed the appearance of Android, and did it right. Material Design is really beautiful. But who says we have to wait to see Material.Theme in action? Most of features has been packed into android-support-library. Use it and build app with material for pre-lollipop devices.
Every now and then you have a bug that is hard to reproduce or only happens on certain phones or android versions. The thing that really comes handy in such case is a detailed application log. That’s why it’s so important to take time to add useful log entries in every non trivial part of the codebase. At the very minimum you’ll want to log any errors.
I’m experimenting with ShareJS library, which is intended to allow live concurrent editing like in Google Docs. The demo on their website seems incredibly easy, even though later on the page they are so cruel: “ShareJS is mostly working, but it’s still a bit shit.”. I wouldn’t be so harsh as I was able to have it up and running in less than few hours. But the fact is it wasn’t as easy as it seemed.