Dynamic Delivery is one of my favorite tools in Android Development. With this serving model, it is possible to provide optimized APKs for your users creating smaller apps and also provide downloadable features even after your application is installed.
Before we get started, previously I wrote an article about how to create your own Dynamic Feature Module (DFM), with step-by-step explanation and code samples. Please, take a look on this article if you are not familiar with this concept.
If you want more information about Dynamic Delivery, please access the official documentation.
Recently I decided to port my whole application, Alkaa, to Jetpack Compose. In the first moment it was very challenging, specially because I had no previous experience with declarative UI toolkits. But after some trial-error (and a lot of help from the community), the development started to be easier and more intuitive in my mind. The intent of this article is to share the lessons I’ve learned during the process, as well as some references that helped me a lot during the development.
When developing an app, we need to carefully focus on the user experience, specially in the actions that may require a confirmation or possibility to revert the user decision. If we use
AlertDialog in every single interaction we need this behavior, it will easily annoy the user.
One way of solving this issue is using a component available in the Material Design, the Snackbars. It inform users about a process your app has performed or will perform without interrupting the user experience. The component also allows users to amend their choices.
Handling screen navigation is a complex task in any framework. Luckily we already have a great tool for helping in this flow, but some different scenarios may need more attention. One of these scenarios is opening the application on a specific Composable in Jetpack Compose.
The Jetpack Navigation Compose is an awesome tool: it uses a solid base from the default Jetpack Navigation for View System with the flexibility needed to handle Composable.
Jetpack Compose is right around the corner and testing your components is a very important part of the development cycle. There are several test examples in the official Jetpack Compose Samples repository to help you out but they cover simpler scenarios.
The basic syntax for testing in Jetpack Compose is pretty straightforward. Let’s take a look in our example:
In the test above we create a test to validate if the title is displayed in our Composable. For more information about different types of tests, please access the official documentation.
However, sometimes we want to test the same Composable…
Jetpack Compose is right around the corner. After the recent announcement that it is now in Beta, now is a good moment to start learning this great new framework. And to do so, I decided to rewrite my personal application, Alkaa using it.
My first decision was to get rid of
LiveData and starting using the new observables available in Kotlin. Once the repository returns a
Flow<List<Task>>, the first attempt was to use the
StateFlow, which at a first glance seems like a great alternative for
The updated ViewModel and Composable from
In 2018, Google Play introduced a new application serving model, the Dynamic Delivery, to help generating and serving optimized APKs based on the device configuration. It uses the Android App Bundle format to dynamically generate the APK for each device variant, which is much better than manually generating them.
Dynamic Delivery not only optimizes the APK, it also enables another feature in our apps: the Dynamic Feature Modules. These dynamic modules can be automatically installed based on device configuration or downloaded later, after the app is already installed and running.
Aprender novas bibliotecas é sempre legal, mas implementá-las direto no seu código profissional pode ser bem perigoso: as bibliotecas são lançadas em alfa, com alguns bugs e falta de estabilidade. Uma maneira de se manter atualizado com as mais novas tecnologias sem comprometer o código de produção é ter um aplicativo pessoal para ser usado como um playground.
Ao estudar novos componentes geralmente criamos um projeto separado para cada um. Isso é bom mas não leva em consideração um ponto importante: em projetos focados em apenas uma tecnologia, sempre implementamos o caminho feliz. No mundo real, precisamos conectar e injetar…
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…