Ask HN: Expert Advices for New Learners in Android Kotlin Development?

As an expert or an experienced developer in Android App Development with Koltin, what are your advices for new learners?

Are there best practices and things we should or should not do?

I started dabbling in Android App Development in 2009, and did it full-time since 2011. I started using Kotlin a few years ago.

Get familiar with using Android Studio as your IDE. Read the Kotlin and Android documentation. Look at the (newer) Android example apps Google puts up on Github. Watch the (especially more recent) Android Developer videos on Youtube, especially the I/O ones (although some other deep dive ones are good too). Look at the codelabs.

If you're already programming, one thing to be aware of is how ephemeral Android lifecycle classes (Activity, Fragment and associated Views) are. At any time the phone can be shut off and they can go away and be killed, and any state will disappear. So be aware of storing state in ViewModels and this sort of thing.

Also, under the hood android has a Looper and a main thread with a message queue, and handlers. On an API level your Manifest will probably have a start Activity that is the main launcher, and which can launch other activities - but you don't launch them, you send an intent to launch them and then the system launches it. You don't have to understand all of this right off the bat but you do have to understand some of it, including how there is a main (UI) thread, and then you can launch network or disk access or computation calls on other threads.

A statement is easier to fix than a function, a function easier to fix than a class, a class easier to fix than a module, a module easier to fix than the whole app. Getting the architecture right is important, as it is more difficult to clean up later. For a big app people often put network (REST API) access into its own module, put analytics into its own module etc. Plus functions are broken down. If HN had a big app, account might have its own module, submission threads and comments might have its own module, search might have its own module etc. Whatever makes sense. For a small app which won't grow, modularizing like that may be premature.

Also within a module in its internal architecture, MVVM is the main architecture used. Something like clean takes more effort to put in and keep - what does a company do if senior people come in and do not like clean and aren't using use cases or business rules without dependencies etc.? If engineering is not already filled with good senior people committed to clean, who are not taking shortcuts to get features out etc. I would think twice about trying to use clean, for social reasons more than technical reasons.

Android is notoriously difficult to test. Where do you put your tests? There is the testing pyramid of UI/e2e at the top, features/integration in the middle and unit tests at the bottom - the bottom of the period being the most tests. Except you can't really directly unit test Android lifecycle classes like Activity or Fragment with JUnit. So what do you do? You use the Google suggested unidirectional data flow from ViewModels into the lean lifecycle classes, sending in a UI model to the lifecycle classes to create the UI from. You unit test in the ViewModel the various scenarios and edge cases going out to the UI/lifecycle classes. You can unit test in other places but this is a way of indirectly unit testing UI. There are also UI tests like Espresso higher up on the test pyramid.

Lifecycle is one of those things that earns a native mobile developer's salary. It's the selling point where native beats hybrid, as well as web.

The other might be threading. Kotlin Coroutines and Flow is incredibly powerful and one of the coolest things on any system. I wish this kind of thing was available for servers and such. I'd argue that Looper and Handlers are deprecated once you understand Coroutines and Flow. It's probably one of the things you can skip these days.

The most popular Android app that I know of that uses RN extensively is Discord. Read the reviews here as the start of the answer to your question - https://play.google.com/store/apps/details?id=com.discord

There's a lot of bad practices out there. Android dev is actually a bit ahead of iOS development. The problem is that bad practices are commonplace, and most apps are greatly overengineered. So you end up needing 2 Android devs per 1 iOS dev, when the ratio should be closer to 0.8:1.

Google normally has good advice, but they tend to build to scale to a hundred engineers, and that includes "deprecated" stuff. You can go many times faster when building for only 1-2 Android engineers.

My rule of thumb is that if the example looks more convoluted than without it, it probably is. If it's good technology, the examples should make you think, "Oh shit, this is genius," not, "I'm too stupid to understand this."

Pick things up once something is actually a problem. Things with a fast ROI:

Kotlin: write 40% less code than Java

ViewModels: cleanly separates lifecycle stuff and reduces crashes

Network (Retrofit, volley): no more custom async and no crashes when the API changes a little

Compose: cut down all "recyclerview" code by 50%-80%, and have much more maintainable logic

Things with a negative ROI (feel free to argue for them):

Most architectures, e.g. MVP, VIPER, "clean". Architecture isn't a fixed pattern, it depends on what your app is trying to do. Most of the time it's like an apartment trying to emulate a hotel.

Butterknife: Replaced by Kotlin

Event bus: Replaced by Flow

RxJava: Replaced by Flow

Data binding or view binding: Replaced by Compose

Robolectric. It breaks for obscure reasons, takes forever to run (effectively locking you out of TDD). Espresso works. You shouldn't spend more time fixing tests than fixing code.

Android debugger. Idk, TDD catches plenty of bugs and plopping logs everywhere catches the rest.

Looper/threads: Replace with Coroutines

Some of the older UI things like animations, which might be obsoleted with Compose.