Voyager with Adriel Café

Some people put sushi on my side. Oh my god. Oh my god. Okay. I don't want to hear more. Okay. I mean everyone eats their own type of pizza and that's it. Hi everyone and welcome to the developer's bakery. A podcast about open-source projects, tools and libraries for software developers. My name is Nikola Corti and I'll be your host for the show. Make sure you subscribe to the podcast on either Spotify, Apple Podcast, Google Podcast or directly on the website the bakery.dev. Thank you for listening and enjoy the show. Hi everyone and welcome to another episode of the developer's bakery. Today I have another amazing guest. So please welcome Adrienne Ocafé, creator and maintainer of Voyager. And Hi everyone, Hi Nikola. Thanks for having me here. Thank you very much for being on the show today with us, Adrienne. And as I do with everyone, I want to give a little bit of time to introduce yourself. So maybe you can tell us where you're based, what you do, what you work, what your background and so on. Sure. So I'm based on Brazil. I live in a small town, college, Santanton, in Jesus. And like I say, I'm gonna do a free translation. It's something like holy and tonal for Jesus. I work as Android developer at Stone Payments. It's one of the biggest fintechs in Brazil. I work as Android developer for about a decade now. And my history with Android is started at the same time as I started contributing to the open source. So I've been doing some open social libraries since 2012. And I haven't stopped. I'm also a father of two. It's another full time job. Awesome. It's super great to have you here because I was a Kotlincon some weeks ago. And I was like speaking with people and asking like, Hey, which library you want to hear about next? And a lot of people mentioned you as an author of one popular library that today we have the pleasure to showcase. And the library we're gonna talk about today is Viager. So now I want to give you space to give us a live air pitch on what is Viager. So for sure. Thanks for anyone who is using Voyager who is contributing. We have some issues open by you guys some nice PRs. So thank you everyone. Voyager won't be possible without you. So what is Voyager in a city to see Voyager is a pragmatic multi platform navigation library with batteries included. So it's built for Jetpack Compose. But also your works now on iOS, Mac, Web. And in what I mean by pragmatic. So if you look at the read me every you see as Nipit and just by looking at this Nipit, you already know how to work with Voyager. So it's pretty simple to get started like you implement this interface create your UI and use the Navigator Composable function your activity on site, JNO, the composable. And create your instance your first screen and it's done. You are already using Voyager. You can do something like poppy and push to navigate forward your back wall. So it's a pretty simple API and about batteries included it is very complete. So out of the box, we have the basic stack navigation. So you can go forward and go back and you have a tab navigator. So in the video between tab is very common mobile. You have also a board of sheet navigator. So compose has the board of sheet and we can use the board of sheet navigator to put screens navigate site. We have nested navigation. So one navigate inside all the navigate inside all the navigator and so on. Multimodern navigation integration with coroutine is a recce java coin coding for the pin injection. We have transitions, basic to support you off the link is and so on. So it's very completed is it has it is very modular. So you can create your own extensions, you won't navigate to you won't kind of screen. Awesome. It's actually great to hear our many features you have out there. So now I'm wondering like how this library came to be. Is it something that you needed at work and then it got open service or you sort of add a side project that triggered this library and like you sort of extracted it like what's the story behind this Voyager. So as I said I have been contributing to open source for about a decade and everything with this open source. I started doing a site project. It's then I build some API. I see like I can extract into a library and made it public. So it started open source from the beginning. About the history. In 2000, I was experimenting jet per composer. It was on dev releases yet the pray alpha releases. So I was already doing some some text exploring see here waiting is gold. In 2021 composing was becoming a better right. So it was a good time to start working more closely and doing some real stuff. I build I don't know one to site projects. They are open source and Voyager born in 2001 when it was in alpha to beta. So at that time I was missing from composing two things. A simple navigation library and a better way to manipulate strings. Composing is great. Now we don't need to use XML anymore for write the UI to create your tin to declare dimensions and colors. Even drawables we can now write in Kotlin. But strings no strings. We still have to use the good old XML to manage it. That was the fresh library built it's color. So we feel it is it we can declare all strings using data clays in Kotlin. Each property each each to see off these data clays is a supported language. So now we can say goodbye on central to XML. So the next library built for composing was Voyager. So at that time you had some open source navigation libraries but they were very basics at the time. I think we had composing navigation from Jetpack already. But to be sincere I don't like the way the API walk is I think it's too verbose. So I don't know which was building use base on the previous navigation library which relies on fragments and I don't like fragments. I prefer use custom views over fragments. So I decided to build the navigation library for scratch. Só que o compositor de suporte não tem um reláido para um hidroide de platform. Então, eu estava falando de compositor internos, a língua, a hora de ter que ter um compositor local, um estátimo, o effects e etc. Então, a forma de ter que ter a língua, a hora de ter que ter compositor local, e para usar cada ideia que pode, para ter que ter a olhada na ligação de novos e para usar as reis. Então, eu estava em um momento, eu estava em um momento, eu era o local projectivo local, para ter que ter que ter um compositor, e eu do sono. Experimento se, se, em maiores dias, se eu me fazer algo useful, e não me invento, eu já estava em um momento, eu estava em um momento, e eu criei um repo, eu estava documentando, eu estava se procurando para usar as reis, como nós, em india, a multiplataforma do model, como para gerar o estado, apostar um stage com生as. Ela Louisity. Para ela na��at Integration embarrassing. É um Les티. As trevas 2016 estavamsenais, quando tudo continuous DNA&3 deu nosetonizados. O desafio було maior e cozy EN chief66NecessTV com jum Bil brothers para illegally esterando em casa. Food engineer era to disponível pelaança para num preside actually de unemployed, aonde você não quer. Eu acho que 70% de ações de delivery são extensões, e a corra é muito maior, a navegação é muito maior. Cool. Então, você está numa forma de coisas. Eu tenho muitas questões para você para você. O primeiro que você começou a fazer, você se toca sobre Multiplato de que você está se sentindo por uma coragem, por causa e tal. Eu estou realmente impressionado que você está em uma coragem de delivery para também web iOS, desktop e Android. Então eu estou com um curso, ok, em Android, eu não posso ter mais de um curso, mas eu estou com um curso de como é complicado para após o porto de uma coragem de delivery, para, por exemplo, iOS, que tem diferentes paradigmas de navegação de Android ou o desktop e o web. Então, isso é o que mostrou sobre Open Source. Eu não estava no developer de Multiplato de que você está em uma coragem de delivery. Então, o desktop me tentou suportar para o porto de que você está se sentindo por uma coragem de delivery, e isso foi feito por constantinho, que era o líder de que você está se sentindo de Multiplato de que você está se sentindo por uma coragem de delivery, então, o Open Apple request é que você se sentia de um suporte para o desktop, e isso foi uma vez em validation de que o delivery se sentia de um suporte, bem acerta para o comédio. Então, em uma coragem de delivery, o Bichel Sire, ele se sentia de um apio, ele se sentia de um suporte para o Mac e iOS, então não é uma contribuição. E aí, Gabriel Souza, que é um co-worker de mine, ele suportou para o web. Então, eu queria ter que estar muito tempo para ter que os dois, três que Open estenda de voyager, em algumas coisas que eu não estava expectando. Eu confinei em começar um pouco paraама-me. Pensean que se gráfico me명이 se gay opening Eu crecio em um débitoي 일이 Hirano, e você tem um tabo de navegação e um de que é o mais difícil. O tabo de navegação era um complexo, porque eu fui a implementar a navegação. Então, basicamente, você tem um naviguetor, quando você tem um tabo de navegação. Então, temos um naviguetor de um random, 3 ou 4, ou 1 por 1, e 1 por 1. E, dentro de 1, você pode ter um naviguetor independente, então, o naviguetor que tem, é um naviguetor independente de ou de 1. Então, eu me implemento em uma navegação e, então, do o tabo de navegação. Mas, se você não tem um complexo que me deu na noite de março, eu poderia dizer que foi o ândroide do live cycle e envio o modo de integração. Não é mais. Eu tenho que dizer muito da IP para o ândroide internas, como eu tenho implementado o meu live cycle, meu meu vio modo historial, meu meu save de stage é o 3º. Então, tenho a integração, tenho a integração vio em meu live cycle e eu tenho que ter a integração vio em meu live cycle, e isso foi muito complexo. Nós temos buggy para muito mais. Nós ainda temos um, mas o comunidade é uma coisa que ajuda a fazer, uma ofusão, para dar um exemplo de como produzir. Então, isso foi o mais desafio de coisas. Eu ainda tenho um topic, uma coisa que eu quero saber, que eu sei que é muito difícil implementar, é de aplicação. Então, você te mencionou, sua library de aplicação é de suporte de uma de box, então eu estou com a questão de como isso é handled. Sim, então, de aplicação, de aplicação é muito basic, certo? Então, o navigate composable function acertes a single screen, ou a list of screens. Então, você pode manualmente criar a list de screens e criar a predefina de Backstack. Então, vou ajudar a ver o navigate para o leite screen off-delicto e quando você come back, você pode retornar para os primeiros screens. E, basicamente, isso é o único suporte que nós temos para os links. Você tem que manualmente criar a list de stack. É uma de coisas que eu quero, para algum dia, para dar uma de uma de suporte, como a RIDIA, a UI e a Asociação de ATI, a IPA, a screen, a RIDIA, a screen, a Braking, a path, a block, a look out for this related screen, so I can build this list dynamically. There is one thing I want to do in the future. Got it. Still talking on technical stuff and, like, literally, I went through the documentation of your project and it's really extensive, and it works through a lot of the capabilities that this library has. So it really feels like a 3-poly standard production ready. But you wanted to, like, call out one of the features that I think we should spotlight, which is, like, multi-module navigation and nested navigation. Like, in a sense, like, connecting navigation that comes from different modules and how does it work? Because, like, when your app is more complicated, you're definitely going to have, like, a navigation that is not as, like, three tabs, but it's a little bit more involved. So yeah, please, if you want to tell us more, how does this feature works and why is it, like, so important for this library? Sure. So the nested navigation was built first, and it's not a common feature of an navigation library, but sometimes it is very requested. So I recommend using this navigation for very specific use cases because it can get very complex to understand which navigate I'm using right now. So, for example, we can have one navigate inside the other navigate, and so on. There's no limit of deep, of depth we can go. The nested navigation relies on composition locals from Jetpack Compose. So basically, inside a decomposable weekend, Reve a navegator e use o local navegator composable composição local proprépto. We can get the Cubent navegator. So, if I call, for example, navegator dot parent, I can see if the navegator reissom parent, I can do a navegation between differentions, navegators at the same time. So, it's very complex, but some use the cases required is a nice navegation, like the tab navegation we talk about. So, yeah, basically that. And the multimodal navegation. It's not very common, too. But it really helps when we want to modularize your project. And each feature is on separate modules. But one feature needed to access the screen of the other feature. So, we'll try to avoid cyclical dependents like the feature is important, the feature B directly. This can cause some problems with the spread. So, what I do is build a DSL similar to code in coin. So, you can create modules like the Dependence Injection Module, but it's a module to expose your public or shared a screen. And, for example, you can have a shared module, a navegation module. If you are in a easy class exposing the shared screen, in the app module, the main module of your project, we can register those screens. And that way, each feature module can import the shared module, without problem, we offer the cyclical dependencies. And, navegation from screen, from different modules, using a pretty simple DSL, like inside a composing, I can use the remember screen function to inject quotes. You can inject a shared screen, and use the remember screen function. And, that way you can navigate to different modules, similar ways. Awesome. So, I'm actually impressed to see, again, as I was saying before, I'm actually wondering, I see that the library is not a 1.0 yet, it's still in pre-release mode. What's I'm wondering? Are we going to see a 1.00 stable out soon? Or what's the deal here? Yep. We plan to release in the next two weeks a few months ahead. So, at the moment, we are fixing some bugs, some critical bugs, related to stage management, screen restoration, and so on. And, we are also considering some API breaking changes before the stable release, but it's not decided yet. So, we want to keep the API at its ease, but maybe we have some breaking changes today. But, we are pre-crossed from the stable release, we fixed a lot of bugs in the past few weeks, and we are pretty close. I don't have a date, but we are close. And, what is still on 1.0? Like, what is the most requested feature that you feel is missing in the library that people might expect to see sometime in the future? Yep. So, we have some like we talk about a very deep link support. Also, the iOS back navigation is not built yet. So, iOS, we can use the back navigation just to see the previous screens along the side of the current screens. So, there is an animation there. We need to do that to full support iOS. So, maybe not though they maybe took some time after the stable release to launch this because they are new features. So, they are not blocked for the stable release. Got it. Okay, so, we were talking about, yeah, the history of this library and like stable releases. But, I'm actually wondering, like, you still haven't mentioned if you are the only one developing this library or if there is someone else. I believe there is some other maintainers. So, maybe if you can please tell us who is behind this work. Sure. So, first, as I mentioned in the beginning, I'm father of two. So, when I built Voyager in 2021, I was father of one. Okay. So, I had time at that time. I had free time to work on my libraries. But, in 2021, in the end of December, I had my second child. And, in the end, I have more free time. So, in 2022, I haven't developed a working Voyager almost the entire year. The project was free. And then, my co-worker Gabriel, this year he started working on Voyager and fixing the bugs in the next thing in the library. So, he is the most active to maintain right now. And, I plan to do the end of year returning to also developing, also, do some things that I want to. But, he is the most active to maintainer. Also, another co-worker of my Thiago Santos, he helped the past doing the Hilton integration. For example, he improved some samples. He is working on a Houghton library in building an integration in Voyager. So, you can have something pretty similar to the web navigation where you have different Houghtons. It's like a deep link library that is building based on your Kato API. We probably have this pretty soon. We also have many contributions from, as I said, also from Michael Mitchell here. He has opened the iOS, Mac, Supporters, multiple of the bug fixes. And, you have many other developers we are helping with poor requests. So, those are the maintainers of the library, but no. Got it. Are you actually looking into importing new people? Or, it seems like you accept requests randomly, but I'm more wondering if you're looking into getting, like, a full-time maintainer that will help you with this? Or, how do you see this library growing? Do you feel like it will still be your site? Library, do you think this can be bigger or be migrated to a bigger organization? Yep. So, since we had multi-platforms, we now compose a multi-platform, and, in alpha, so, I think Voyager will play a great role in the future. So, yes, we want to keep maintaining, keep evolving. And, every help we can get, I appreciate. If you, I don't know, if you would like to help and maintain the library, we can talk through issues, each of the issues, right? We have your discussion tab on the, the poster, so we can talk from there. And, yeah, that's our way, we can contribute to the project. Yeah, still on this, actually. I'm wondering if, where people can chat and get support? Is it the discussion board on GitHub, or do you have a Discord, or a Slack channel where you coordinate a bit of the work? No, the GitHub is the only way. It's the only place where we talk, and then just discuss. So, it's the best place, it's very public, it's very nice to find the open issues. Got it. Okay, so now I want to touch on a little bit of a side thing, because when I was doing my researches for this podcast, I actually looked through your website, so that your title is Android and Web Developer, which I was super interested about. And so now, I want to ask you, how do you feel now? Where are the difference between being an Android engineer and a web engineer? what do you miss of WebBor? What do you enjoy the most now being around 100? So I don't consider myself a web developer anymore. It's like five, six, maybe seven years that I don't work professionally on a web project. But as I'm watching from afar, I'm seeing the web in mobile getting closer like the hot reload years ago was a web-only feature, right? So now, flip the reactiv-hairs, compose the hares hot reloads like something like hot reloads, rebuilds. So, God sharing between both platforms is now easy, then before you can use Kotlin Multiplates for me to share with Kotlin.js. And one thing that I'm really liking to see grow is the web assembly. So now we can have binaries on the web, we can have a safe-esteem environment, we can support more languages like Kotlin wasmys in alpha right now. Alpha no, sorry, it's in experimental right now. So I think web in mobile are very pretty close as a ecosystem. And what I like and what I dislike about web, well, when I was working with web, I really enjoy, I have done one time only, but I really enjoy publishing to npm was very easy. I think it's too common, it's a JSON configuration file and I publish a package of 20 p.m. And when I try to publish a new library, maybe I have to open a ticket to do that, I have to configure the Gradle. So it's an nightmare and npm was so easy at that time. I really miss the simplicity of publishing things and yeah. And what I dislike on web development, I think some issues with security, like the code is there to see if you don't want to skate for yourself. I don't know, you can open the console and change variables at one time. So it's not the safe it's environment. I think web assembly will help with that, give me a sandbox isolated from the browser. But yeah, security is one of my concerns. Yeah, totally publishing libraries is a big of a pain like un-forbable and I've been experienced that over and over. Anything from web that you actually disliked and now being on mobile, you pretty much enjoy, like something that under engineers do better. I think the modern whiteo kits like Composing Switch Y are great. The letters write to you eyes. Easy as never. We can create components and share UI components easily. So when I was programming with web, I was using view the set time. It's similar what Compose does, but mix code with HTML. I don't like this approach. And with the modern whiteo kits we have a mobile, we can write to eyes using the Kotlin, the Swift language. It's more secure, it's more easy to find issues. If the code we have hints, out complete and so on. So the language support to build UI is much better to like web. You have to use a mix of HTML and JSX. Last question about mobile versus web. How do you feel about the ideas? Like Android Studio versus whatever you were using a mobile on web? Well, when I was programming with web, I was using sublime text. It's extremely fast code editor. In Android we have IntelliJ which is great, but it's a lot of, it's a lot of have. We have memory issues. If you, when you open Android and Xcode to get, to code Kotlin, multi-platform. So we need to have, I don't know, three to dig as of run, to have enough memory to manage both. Also the build time on mobile, it's far longer than web. So, read or consume all my run. We have to constantly optimize the, the test keys. You use simple apps and look out to what modules you are importing to not importing too much modules. And have extended build time. Like I switched from one branch to another, I have to rebuild the project. So, build time in iris, the, the, the, the, the, the, the, the, the, the, the language of support off the iris. I like better than supply me or aton, or, or, or win. I know of this code editor. So, yeah. I, I, the, the pros are the big, they cost. Got it. Awesome. So, as we slowly move towards the end of the episode, I want to ask if you have like further readings, materials such as like book articles or, I don't know, other podcasts or blog posts or anything that either inspired you to write Voyager. Like maybe you got inspired by a library or something that people might find relevant for this library to learn more. So, anything to share? Sure. So, when I build Voyager, I had to look deeper into the composing, I had to learn how the building is internally. So, was, was a complex, a, a studio, a study that took several weeks to understand some composing, uh, fundamentals. And back that time, we don't have yet the jetpack composing, internal book from George Castillo, which if I had read the book and then write the library, it, I think I will use the composing features more extensively than now. Uh, after I read the book, he decided to do some optimizations in the code, but I have, having time, since I had to keep this. So, I needed to age to do those improvements in the future. But this book is great. He talks a lot about how composing works under the hood. So, it's somewhere to read. Awesome. So, we're gonna add the link in the show notes and we're gonna send greetings to Hierge. Maybe it will be on the show sometimes, soon, so last question before we wrap up, where people can find you online, if they want to reach out to you, like engage on the library contribute or just ask you questions. Yeah, so, uh, my username or platforms is the same, Andrea Ocafé. So, you can find me on Twitter, on Reddit, on the, the Kotlin's leg channel. It's the same username, it's, it's fine. If you have questions or suggestions about the voyage or any other library, you can just open an issue. We can discuss, uh, I'm happy as such, you know, requests also. Awesome. And with this, I want to thank you very much for being with us on the show today. And then I thank you for the time, for the invitation. Also, thanks everyone who is using Voyager. Awesome. And I also want to thank everyone for listening and it's you all in the next happy ZODE. [Music] (upbeat music)