DEV Community: Vinícius Veríssimo

Our experience becoming a Compose-first app

Vinícius Veríssimo — Sun, 29 Dec 2024 21:06:39 +0000

This is a little piece about our journey applying Jetpack Compose to our existing codebase at the Moises.ai App, where we have time-based features that require high-performance and scalable UIs while also taking care of the developer's experience.

Jetpack Compose Concerns

Since we work with a small team of developers, we had many concerns about the impact of adding a new technology to our project. How would it impact the team's performance and the challenges of building new things and maintaining the current one? We had to start our explorations with the Jetpack Compose and still keep up with the high pace of a startup.

We had to be cautious about fully relaying our solutions in a new way of building UIs. To do that, we had a few things in mind:

It cannot decrease our lead time;
It has to interoperate with our current codebase;
We must be able to automatically test the UI with our current tools (at the time, it was Appium);
We can't impact our app's performance;
The team needs to have time to build knowledge about it;
The team must have the confidence to use it.

With that, we started to fill those gaps.

Exploration Time

We started by choosing someone from the team to spend part of their time exploring this new technology and how we should integrate it with our current code.

This person had already studied Jetpack Compose using the Android Developer Courses and had created a few small projects in Compose to practice. It was necessary to understand how it works and the difference from using Android Views.

We realized that it wasn't just a matter of coding the views in different syntax; it was also necessary to rethink how we handle UI states to fully take advantage of the Compose UIs.

With this in mind, it was time to implement and ship a small thing in Compose to get an idea of how it could be used in our project.

Yes, we added Jetpack Compose to our codebase by writing new components with it and keeping the old ones untouched. Some people don't like this approach because it results in a codebase with mixed technologies, but we didn't want to risk changing thousands of code lines that were working fine to introduce a new way of doing things.

Adding Compose to the project

In addition to the standard Gradle setup, we also have a project-specific requirement to use Compose in our features; it must use our Design System.

We already had an implementation of our Design System in Android Views using a mix of components and styles. Since Compose handles themes, components, and styling differently, we have decided to re-implement part of our Design System in Compose.

We prioritized the implementation of Typographies, Colors, and Buttons, the basic elements to build any small Proof of Concept. The first challenge is the initial attachment of the Compose structure to the Material Theme. The available set of colors and typographies wasn't enough for our Design System, so we implemented our own custom Theme inspired by the Material Theme implementation but focused on our necessities. It was hard work, but we took advantage of this soon.

Finally, we were ready to add the Jetpack Compose to our main project, but we were still in the Proof of Concept state. We didn't want to add this new technology to our time-based features, which require high-performance UIs and complex business solutions.

We decided to start with a static screen with simple UI elements to see how it will integrate with our current implementation. The app's navigation was Fragment-based, so we implemented a Fragment wrapper for the Compose UI, and we managed to keep the navigation between fragments. It worked pretty well.

From the user perspective, there was no distinction between this new UI and the others. This achieves part of our interoperability criterion. I say part because we were essentially creating a whole screen in Compose without any mix of Compose and View on the same screen, but it was enough. Later, new requirements appeared, and we had the chance to use Compose only in part of an existing View screen, which we efficiently managed with ComposeView.

With an old codebase, it is easy to have parts of the code that reflect patterns, ideas, and concepts of a given time. In a startup environment, the code constantly changes, evolves, and quickly adapts to the needs. Even though the current patterns we used to control our UI states weren't the best to take full advantage of the Compose capabilities.

Our UI state control was mainly based on a few LiveDatas in ViewModels with different properties to be handled by the UI. As a better approach, we've decided to have the UI state as a Data class exposed by a Flow and collect it on the Compose side. This way, and using the concepts of the Unidirectional Data Flow, we managed to have more control over the UI state and provide it closer to the properties received by the composables. Later, we kept using it while maintaining some old view-based screens.

To make it shippable, we still had to make it compatible with our UI test automation.

Automated Validations Support

For the automated test support, we used the testTag modifier to make the automation of our screen validations possible with Appium. Later, we used the same property when we moved to Espresso. So, we achieved another criterion.
Okay, now we have a simple feature implemented with a testable new UI paradigm and architecture. Finally, it was time to ship it and see how it would perform.

Shaping the Compose muscle

The final reception was excellent. The screen performed as intended and was seamless with the other screens, but it was lighter and had a few smooth animations. This is how we could differentiate the implementations of the final product.
The team was satisfied with the result. The new feature was used as a proof of Concept for using Jetpack Compose in our platform and as a way to introduce Compose to the other team members.

At the time, one person had more knowledge about Compose than the others. With the new technology approved, it was time to grow the team's knowledge about Compose.

Because of the exploration moment, we had someone who knew all the paths to learn Compose. Then, there were months of mentoring, study, pairing, and building new features to practice composing in a real scenario with more dynamic screens with CRUD and reactive content.

We had the opportunity to create more wrapped screens with Compose, partial Compose screens, and Compose screens with partial View content that wasn't yet supported in Compose. We tested new ways to organize components, files, and new supports on our Design System theme, rewiring exited components to fit our needs, highly based on the Material's patterns.

More criteria were achieved:

The team was happy to learn a new thing and to see it quickly being applied and shipped to production;
The team was happy with Compose itself, how fast it built a new screen, listed things, created components, etc.
We had the curve of being slower because we were trying to understand new concepts, new patterns, new small and big animations, and new ways to solve problems. However, once we were comfortable with Compose, we became faster and produced more code that was easier to read and understand.

Even though one criterion was missing, the one about using it in a feature that required high performance. Eventually, we had the opportunity to use our knowledge in a big feature with UI challenges.

Performance Challenges

We received the request for a new feature:
An audio recording screen that will render a waveform on the screen during the recording phase. Then, the user can seek the waveform, override any part of the recorded audio, play it, and process it.

This was our first real big challenge in Compose. Long story short, we struggled to draw the waveform with Canvas in Compose in a performative way; we had many performance problems because the data kept changing fast, and we needed to draw the waveform smoothly for the user. We almost gave up using Compose to do it, but we were decided to make it work. In the end, we managed to reorganize the composables and structure the data to avoid unnecessary recompositions; we used the Layout Inspector and other available tools to evaluate our approaches.

This challenge was necessary to achieve the last criterion; the screen performed great, and we were ready to do any other Compose challenge. It consolidated our ideas, patterns, and strategies.

A few months later, we had more features that required performance and were time-based, but we were already sold to the Compose. We were already thinking of Compose-first solutions; using the old Views wasn't an option anymore.

Conclusion

It takes time to adopt new technology in existing projects. In a startup environment, you can go fast and break many things or reduce your speed just enough to shape your ideas and have more substantial outcomes.

We introduced the Jetpack Compose in baby steps. Even knowing this was the way to go, we needed to be sure that it would solve our needs, and we focused on spreading the knowledge across the team so everyone could work seamlessly in the code base.

Rotary Input in Wear OS with Compose

Vinícius Veríssimo — Tue, 15 Nov 2022 20:39:17 +0000

The Rotary Input is one more way to the user interact with their wearables devices. You must handle this type of input since your users will expect this even unconsciously.

Currently the users can perform the Rotary Input on smartwatches in 3 ways: crown, physical bezel, touch bezel. All of these option are transparent for us when handling the input, that is, for a simple handle of this input we don't need to know which one the user is using to interact with our app.

So, let's see some examples of how to handle this with ScalingLazyColumn and Picker.

💡 The following examples are using the version 1.1.0-rc01 of Composer for Wear OS

ScalingLazyColumn

First of all, in order the handle the Rotary input, the component must have the focus. We can achieve this by manually requesting the focus to a component. So, let's create a instance of the FocusRequester:

val focusRequester = remember { FocusRequester() }

And then, set up this in our ScalingLazyColumn :

ScalingLazyColumn(
    modifier = Modifier
        .focusRequester(focusRequester)
        .focusable(),
    {...}
){
    {...}
}

Next, we need to force the request of the focus.

LaunchedEffect(Unit){
    focusRequester.requestFocus() 
}

Now our ScalingLazyColumn will always have the focus. The handle is not done yet, now we need to actually react to the Rotary Input and scroll our list with it.

First we need a instance of the ScalingLazyListState and use the modifier onRotaryScrollEvent to listen to the Rotary Inputs. Be aware that we need to perform this scroll with a Coroutine Scope.

val focusRequester = remember **{** FocusRequester() **}**
val scrollState = rememberScalingLazyListState()
val coroutineScope = rememberCoroutineScope()

ScalingLazyColumn(
    modifier = Modifier
                .onRotaryScrollEvent {
            coroutineScope.launch {
                scrollState.scrollBy(it.verticalScrollPixels)
            }
            true // it means that we are handling the event with this callback
        }
        .focusRequester(focusRequester)
        .focusable(),
        state = scrollState,
    {...}
){
    {...}
}

LaunchedEffect(Unit){
    focusRequester.requestFocus() 
}

That's all. With a small configuration the ScalingLazyColumn is reacting to the Rotary Input.

Picker

For the Picker component the setup will be basically the same:

val pickerState = rememberPickerState(
    initialNumberOfOptions = 100,
    initiallySelectedOption = 50
)
val focusRequester = remember { FocusRequester() }
val coroutineScope = rememberCoroutineScope()

Picker(
    state = pickerState,
    contentDescription = pickerState.selectedOption.toString(),
    modifier = Modifier
        .onRotaryScrollEvent{
                    coroutineScope.launch{
                        pickerState.scrollBy(it.verticalScrollPixels)
                    }
                    true
                }
                .focusRequester(focusRequester)
          .focusable()
        {...}
    ) {
        {...}
    }

    LaunchedEffect(Unit) {
        focusRequester.requestFocus()
    }

Conclusion

You notice some things:

There is no haptic feedback
- If you test other apps that handle this input you will notice a haptic feedback during the scrolling, sadly this is not automatic, you need to do this manually or use the Horologist.
The Picker is not snapping to the selected item
- With this approach sometimes the Picker doesn't snaps to the selected item, you can improve this with Horologist, but by my test it isn't working 100%.

The Rotary Input callbacks from the foundation library and Horologist are still in Experimental state, so soon they can change and be improved.

References

Code

You can check these and more example on my repository

Vnicius / rotary-input-samples

Sample codes showing the usage of Rotary input on Wear OS with Compose ⌚︎

Rotary Input Samples

Sample codes showing the usage of Rotary input on Wear OS with Compose ⌚︎

Samples

Basic Example - This sample contains the basic handle of Rotart input with ScalingLazyColumn and Picker.

View on GitHub

Criando um gerador automático de letras de Forró

Vinícius Veríssimo — Sat, 07 Nov 2020 17:56:28 +0000

Costumo dizer que o Forró é a trilha sonora do Nordeste, é realmente algo que está no ambiente. A maioria das músicas das bandas mais conhecidas eu nunca parei realmente para ouvir, mas conheço todas elas apenas por estar no Nordeste.

Há uns meses a Dandara Sousa teve uma ideia (ao meu ver) genial de aplicar conceitos de análise de dados com músicas de Forró. Como? Ela decidiu utilizar os dados das músicas da banda Calcinha Preta numa série de posts (Vol. 1, Vol. 2, Vol. 3) e palestras.

Daí me surgiu a ideia de também fazer algo utilizando o forró como contexto.

No forró feito pela Calcinha Preta e muitas outras bandas, grupos e cantores, não só a melodia característica do gênero musical se destaca, mas também as letras que literalmente marcam gerações. Em sua maioria se resumem em desventuras amorosas e declarações de amor.

Seria uma máquina capaz de escrever uma música de forró comparável aos grandes cancioneiros populares? É o que veremos a seguir.

Dados

Primeiramente vamos aos dados.

Irei utilizar as letras das músicas da Calcinha Preta, Cavaleiros do Forró, Limão com Mel e Aviões do Forró disponíveis no letras.mus.br. Nada que um scraper não resolva.

Foram um total de 2.309 músicas.

Pré-processamento

Para esse caso vou fazer um pré-processamento simples, apenas deixar tudo em minúsculo, separar as pontuações das palavras e colocar uma música por linha.

Esse último passo do pré-processamento eu resolvi fazer assim pois num teste anterior utilizando um verso por linha eu não obtive um bom resultado. Acredito que seja pelos versos geralmente serem bem pequenos e com pouco contexto, além de ser muito comum que uma frase seja dividida em vários versos. Nesse caso decidi colocar todos os versos de cada música numa mesma linhas, mas separados por um token (#).

Ou seja, o nosso algoritmo irá gerar a letra completa de uma música de uma só vez.

Treinando o algoritmo

Para criar o modelo de geração de textos, eu vou utilizar a biblioteca textgenrnn que possibilita criar e treinar uma rede de geração de textos com Redes Neurais Recorrentes em poucas linhas de código.

Por exemplo, treinei o modelo assim:

from textgenrnn import textgenrnn

textgen = textgenrnn(name="new_model")
textgen.reset()
textgen.train_from_file(data_path, num_epochs=10,
                        gen_epochs=2, new_model=True,
                        word_level=True, rnn_bidirectional=True,
                        rnn_size=64, dim_embeddings=300)

Resultados

Segue alguns exemplos de letras desse feat de Calcinha Preta, Cavaleiros do Forró, Limão com Mel e Aviões do Forró.

Eu não preciso de você
O que eu sinto por ti
É por favor, me faz enlouquecer
Toda segunda a me entregar
Me diga, sem me deixar, ah
Eu vou te dar o que você quiser
Eu não consigo te esquecer
Eu quero ver você falar de mim
Já cansei de esperar
Acabou nosso amor
E agora eu sofro por você
Mas eu não consigo esquecer
Você é linda e eu mais
Pra mim e não quer mais saber
De verdade
Você não vai me dominar
Você não vai me dominar
Você não é dona de mim para me dominar

Não sei o que fazer
Com tanta dor
Você não pode entender
Como a força desse amor
Vem fazer amor
Me dar calor
Me deixa louca
E me chama de ti
Digo sim pro meu coração
Isso tinha tudo que eu quis
Eu sei que te amo
Se ligue pra mim
Que nao da mais te esquecer

Você não sabe o que é amor
Me diz como é complicado
Mas não se amar ninguém é segurar
Eu amo você
Eu te amo demais
Eu não posso ficar
Eu te avisei
Eu te chamo
Quando me diz o que eu faço
Se você me vê
Agora eu me apaixonei
Por você toda vida
Eu queria ouvir você dizer
Te amo, mas
Mentir pra mim
Ainda é te amo ninguém
Hoje eu te amo, amo, amo
Sei que eu te amo, amo, amo
Amo, amo, amo...

Você é o meu amor
Só você me faz sentir tão sozinha
E agora que há 100 anos de viver
Eu não te esqueci
Nem sei o que fazer
Você me faz sofrer
Não vou deixar você fugir
Mas eu não posso te perder
Não posso te amar
Eu sei que vou ficar sozinho olhando pra você
Tenho muito medo que eu te dou
E não quis assim
Me diz o que é que eu faço pra ter você
Menina eu confesso: eu te amo demais!

Alguns dos versos são 100% "originais", ou seja, em nenhuma das letras tem um verso exatamente igual. Algumas vezes ele gera de 1 a 3 versos exatamente iguais a de alguma música, em outras ele gera 1 verso e meio de uma música e completa com outra música diferente.

O que eu achei mais incrível é que com pouco treinamento ele já ser capaz de gerar versos e até mesmo estrofes com uma construção gramatical correta, original e com uma certa linha de contexto.

Todos os códigos que eu utilizei estão nesse repositório.

DEV Community: Vinícius Veríssimo

Our experience becoming a Compose-first app

Jetpack Compose Concerns

Exploration Time

Adding Compose to the project

Automated Validations Support

Shaping the Compose muscle

Performance Challenges

Conclusion

Rotary Input in Wear OS with Compose

ScalingLazyColumn

Picker

Conclusion

References

Code

Vnicius / rotary-input-samples

Sample codes showing the usage of Rotary input on Wear OS with Compose ⌚︎

Rotary Input Samples

Samples

Criando um gerador automático de letras de Forró

Dados

Pré-processamento

Treinando o algoritmo

Resultados

Vnicius / lyrics-generator

Generate lyrics with textgenrnn