Building Android Apps — 30 things that experience made me learn the hard way

There are two kinds of people — those who learn the hard way and those who learn by taking someone’s advice. Here are some of the things I’ve learned along the way that I want to share with you

Think twice before adding any third party library, it’s a really serious commitment;

If the user can’t see it, don’t draw it!;

Don’t use a database unless you really need to;

Hitting the 65k method count mark is gonna happen fast, I mean really fast! And multidexing can save you;

RxJava is the best alternative to AsyncTasks and so much more;

Retrofit is the best networking library there is;

Shorten your code with Retrolambda;

Combine RxJava with Retrofit and Retrolambda for maximum awesomeness!;

I use EventBus and it’s great, but I don’t use it too much because the codebase would get really messy;

Package by Feature, not layers;

Move everything off the application thread;

lint your views to help you optimize the layouts and layout hierarchies so you can identify redundant views that could perhaps be removed;

If you’re using gradle, speed it up anyway you can;

Do profile reports of your builds to see what is taking the build time;

Use a well known architecture;

Testing takes time but it’s faster and more robust than coding without tests once you’ve got the hang of it;

Use dependency injection to make your app more modular and therefore easier to test;

Listening to fragmented podcast will be great for you;

Never use your personal email for your android market publisher account;

Always use appropriate input types;

Use analytics to find usage patterns and isolate bugs;

Stay on top of new libraries (use dryrun to test them out faster);

Your services should do what they need to do and die as quickly as possible;

Use the Account Manager to suggest login usernames and email addresses;

Use CI (Continuous Integration) to build and distribute your beta and production .apk’s;

Don’t run your own CI server, maintaining the server is time consuming because of disk space/security issues/updating the server to protect from SSL attacks, etc. Use circleci, travis or shippable, they’re cheap and it’s one less thing to worry about;

Automate your deployments to the playstore;

If a library is massive and you are only using a small subset of its functions you should find an alternative smaller option (rely on proguard for instance);

Don’t use more modules than you actually need. If that modules are not constantly modified, it’s important to have into consideration that the time needed to compile them from scratch (CI builds are a good example), or even to check if the previous individual module build is up-to-date, can be up to almost 4x greater than to simply load that dependency as a binary .jar/.aar.

Start thinking about ditching PNGs for SVGs;

Make library abstraction classes, it’ll be way easier to switch to a new library if you only need to switch in one place (e.g. AppLogger.d(“message”) can contain Log.d(TAG, message) and later realise that Timber.d(message) is a better option);

Monitor connectivity and type of connection (more data updates while on wifi?);

Monitor power source and battery (more data updates while charging? Suspend updates when battery is low?);

A user interface is like a joke. If you have to explain it, it’s not that good;

Tests are great for performance: Write slow (but correct) implementation then verify optimizations don’t break anything with tests.

Blog

Building Android Apps — 30 things that experience made me learn the hard way

Selina

Join Our Newsletter. No Spam, Only the good stuff.

Related