As we all know, tech field evolves rapidly when modern technologies and approaches to develop new products appear.
Reading about what could be the tool that’s going to be most requested by companies if you want to stay on top and get better job opportunities can be key.
Guessing the future is impossible, but we can try, and sometimes the outcome we thought could happen, completely or partially.
I want to share with you what I think is going to be important in the Android development world in the following years, based in my own experience and thoughts.
If you are an Android developer, and you haven’t read or listened to anything about Jetpack Compose in the last two years, where have you been?
Since the moment Kotlin was integrated for Android development, the technology has been looking forward to work using a single language instead of what we were doing before with Java, XMLs and Groovy.
It started replacing Java, and then Groovy with Gradle KTS and now is replacing the last thing we couldn’t do before with just Kotlin, XMLs with DataBinding.
I encourage you to start learning this technology, as there are already companies that have migrated their entire Android native apps. This is not something that might happen in the future, this is happening now.
The learning curve is hard at the beginning, as you need to think completely different, but once you’ve been playing with it a few months, it gets easier.
After that, every time you need to go back to XMLs to support legacy code, you are going to wonder how could you’ve work without Compose before, as it’s so much easier to use.
Adapting apps to foldable devices and tablets
In 2019, Samsung released a new type of phone that brought a feature we’ve never seen before in smartphones, a foldable device.
Slow and steady, new iterations of this phone have been improving, and some other cheaper alternatives have appeared too.
Maybe it’s too early, as the consumer base that can afford these products it’s still small, but I strongly feel that in some years this is going to be the standard smartphone phone factor.
There’s also the fact that Google is going to release a new tablet after a big hiatus (last one was in 2014), so they are going to promote software creation for big screen devices with possible new tools and guides.
These two changes in the market are going to increase Android users who can take advantage of bigger screens, and so is going to increase the necessity of Android developers that know how to implement this responsive behavior.
If this happens, we would have a new form factor to support in the size of a traditional tablet, and then all the crazy ideas that come with foldable devices, like split screens, rollable devices, secondary displays…
Kotlin Multiplatform Mobile
In my short career as a software engineer, I’ve tried different hybrid frameworks for mobile development, like Flutter and Xamarin.
These technologies never convinced me, as they have penalization in terms of performance, access to sensors and the need to learn a completely new language and framework when coming from a native development experience.
In 2021, I entered a project at my company where Kotlin Multiplatform Mobile (KMM) was being used. This technology works different from the other hybrid alternatives I mentioned before.
In this case, the idea is to write in Kotlin (no need to learn a new language in our case as we are Android developers) all the code that is not UI, that is, all the code besides Jetpack Compose or XMLs, or in the case of iOS, SwiftUI.
From the outer layers of the architecture to the ViewModels, all code is reused for the Android and iOS app. This is great because now you can avoid repeating a lot of code, and keep fully native the access to sensors, the UI code (avoiding performance drawbacks), permissions…
The only thing that can hold back a team nowadays, is that it’s still not officially stable. In my case, we are already using it in an app in production with a relatively big size user base, and it’s working great.
I don’t see a reason to avoid this technology. It can save costs in the iOS team, code is not repeated in both platforms, and the learning curve is pretty manageable, specially if you come from a background of Android development with Kotlin.
Managing over-engineering and architecture
The irruption of modularization, Clean Architecture and Single Activity Pattern in mobile platforms has been huge in the last years. New apps have push to implement this approach, and older ones have migrated their base code.
Thanks to it, we have now more scalable, decoupled, testable and easier to work with apps, improving the final product for our users and the well-being of developers that work in a now more satisfying basecode.
Lately I’ve noticed in my team and in the articles that I read online, that we’ve reached a point where this over complexity is being applied mindlessly in projects, just because it’s the new normal and the “best practice”.
Don’t get me wrong, I think that this evolution is great, but I don’t agree when it is being used always. This implies code repetition, barriers when developing determined features, and let’s be honest, that short life or small app that you are building with modularization and Clean Architecture is not going to have a good or even any test coverage
In my opinion, testing is what usually take more advantage of this approach in mobile development, so, if we take it out of the equation…
I think that once this hype-wave passes, we are going to see teams building apps with simpler architectures, maybe even going back to monoliths.
These are my opinions based on the facts I know and the experience I have, and that’s to where I will try to point my career to in the near future.
Featured image by Guido Coppa on Unsplash
If you want to read more content like this without ads and support me, don’t forget to check my profile, or give Medium a chance by becoming a member to access unlimited stories from me and other writers. It’s only $5 a month and if you use this link I get a small commission.