Learning new released libraries is great, but applying it right away in your professional project can be very dangerous: the libraries are released on alpha, with some bugs and lacking stability. One way of keeping updated with the latest technologies without compromising the production code is having a personal application to be used as playground.

When studying new components we usually create a separate project for each one. That’s fine but does not take in consideration one important point: in single technologies project we always implement the happy path. In real world, you need to connect and inject different libraries, and it is common to find problems during the process. Creating a personal project is handling all the particularities of a professional project but with less responsibility.

This January my personal application turns one year old in Google Play and two years old in development. Alkaa is a simple to-do application created for studying the latest Android technologies, serving as a sandbox to implement anything without any restrictions.

It was a simple playground to start learning Kotlin (Alkaa means start, begin in Finnish). I started adding more libraries, more architecture concepts and it grew to the point of being ready to be a Google Play application with active users. In this article I want to share some of the lessons learned during this last year.

Be in constant evolution

One of my passions in software development is architecture. However, in the first few times I helped to design the architecture of production applications, I broke some principles and the apps were not easy to maintain. But I’m proud of this nonetheless. All the mistakes, the study and breaking code helped me a lot of understanding better the architecture principles.

Having a playground to try, fail and retry helps a lot to gain more knowledge and confidence. The following architecture design represents the first version of Alkaa, which was released on January 2019.

Alkaa 1.0 architecture

It was a single module ( :app ) and the separation of layers was very simplistic. The arrows represents the dependency flow, which means that the block A that points to block B knows the code of block B. As you can see there is a lot of cross dependencies between them and, because of this, any change in one package significantly impacts other packages.

Now the following architecture design represents the version 1.5, released on December 2019:

Alkaa 1.5 architecture

This architecture has four main modules ( :app , :features , :data and :libraries ) and its submodules, with a better separation of concerns. It tries to follow some Clean Architecture, SOLID principles and Google’s recommendation about modularization. Here the arrows still represent the dependency flow, but now there is no cross dependencies. Also, the dependency are inverted to the most important module, the domain , which contains all the business rules and should not change based on other modules.

Everybody has some point that want to improve: it can be the architecture, the user interface, the knowledge in Android framework etc. Focus on the skills you want to improve and don’t be afraid of trying and failing. Also, don’t be afraid of starting something new because you feel that you don’t know enough. Learning is a process. Your personal project is a safe place to try everything you want.

Test your application

Testing your application is always important. It will save you a lot of time, make the changes more reliable and you more confident. Everybody has worked on some professional project without test codes, but usually there’s a test team to be the last defense line between the app and the final user. Working alone has less pressure but also less external help.

When I first started my project tests were not a priority. All I wanted was to implement the features with new libraries, draw the the user interface, make the app runs. The tests could be done later, it was just a playground. But after every single change in my structure, I had to test all the flows manually to ensure that everything was fine.

We all know that tests are needed, but sometimes we overlook them. My recommendation here is take baby steps: try Espresso Recorder to generate Instrumentation tests automatically for you. After some time you will realize that you can write your own tests with custom Matchers and they are easier to read and maintain. Then you will notice that Instrumentation tests takes too long to run and you will try unit tests and so on.

Once you starting test your application, there is no turning back. Give it a try.

Aboard the hype train

Every year Google shows great new libraries in unstable states and it’s difficult to adopt them in our work projects. A new version of the library may break your code or you can find out that it is not the best solution for your problem and decide to remove it completely after some point.

Fortunately this is not a problem in your personal project. You can (and should) try new libraries in this controlled environment. It will help you gain expertise in this new tool and be able to use it much faster after reaching a more stable state. In Alkaa I jumped aboard a lot of hype trains: Kotlin, Navigation, WorkManager, Contraint and Motion layout, Koin, Coroutines, Flow, Dynamic Delivery and much more. Now a lot of them are used in my professional projects.

Help the community

When implementing new libraries probably you will face some issues which the solutions are not easily found in the internet. If this happen, open an Issue Tracker, ask on Stack Overflow or open a discussion in AndroidDev Reddit. It not only helps you solve it but serves as reference for the Android community.

Another great way of help the community is writing an article about the new technology you are studying. Share the obstacles you faced, the tricky parts of the code and how to achieve the final implementation. You may think that this is not needed because someone else already did it, but it is important to share your point of view.

Share your knowledge with your work team, share code snippets, talk about new technologies, give your point of view and help during code reviews. One key point of learning is sharing.

Treat your project with love

Once your project starts getting more structured, you will realize that breaking your code is not as fun as it was in the beginning. After all your effort, you will be more careful before merging changes in your codebase.

In order to better protect the code, my first recommendation is to protect the master branch from commits. This change only allows new code in the master branch through Pull Requests, avoiding any breaking changes or unfinished features to be merged. It is very important to know the GitHub Flow (or similar in another platform) but to summarize, the master branch should always be deployable.

One of the most important parts of sustainable development is assure the code quality. Adding static code analysis, automated code review and continuous integration in the project will help a lot its maintainability. Tools like Detekt, Ktlint, Codebeat, Travis CI and Circle CI are free for non-commercial use and works perfectly with Android projects.

Find your own pace

Developing in your personal project is challenging. You are responsible for every single step of the app, from the software architecture and UI design, to Google Play deployment. But it’s not because you have many roles that you should push yourself to the limit. Respect your pace, develop in your free time, there is no deadline or customer demanding deliveries. Your project should be fun and rewarding.

During Alkaa development over this two years, there were times I didn’t touch the project for one, two months. And that’s completely fine. There will be times where your professional life demands a lot, sometimes it will be your personal life or you simply want to spend time doing something else. Do not turn your project in something to be hard on yourself.