Everything you need to know about NEW Navigation 3

Summary

Highlights

• Jetpack Navigation 3 introduces compos native navigation with improved API and backstack management. 🎨
• The library is inspired by the Voyager navigation, enhancing multi-screen display on larger devices. 📱
• Developers gain complete control over the backstack, simplifying the navigation process in apps. 👍
• The API's current alpha stage promises future updates, including support for the iOS platform. 📈
• Remember Nav Backstack helps persist app state during device rotations, improving user experience. 🔄

Key Takeaways

• The new Jetpack Navigation 3 library offers full control over the backstack, correcting limitations from previous versions. 🎉
• It introduces a navigational solution inspired by the Voyager library, optimizing apps for larger screens like tablets and desktops. 🚀
• Developers can now easily handle navigational backstack using serializable keys through enhanced entry providers. 🔑
• iOS platform stability is imminent, but web target remains in alpha, indicating future web-oriented developments. 🌐
• Practical examples demonstrate creating two-screen navigation flows with the new API, emphasizing its flexibility and ease of use. 💡

Overview

Chapters

• 00:00 - 00:30: Introduction to Jetack Navigation 3 The new Jetack Navigation 3 library introduces fresh improvements in compos navigation. This chapter provides an overview of key concepts and features, explaining the necessity of this updated library. Practical examples will be showcased to enhance understanding. The Jetack Navigation 3 library has been built from scratch to offer these advancements.
• 00:30 - 01:00: Reasons for New Navigation Library The chapter discusses the reasons for adopting a new navigation library. The primary reasons include the need for a more concise and compose idiomatic API as well as overcoming the limitations faced with the previous navigation approach, particularly in managing the backstack. The backstack in the original navigation library was difficult to manage and allowed only indirect observation, which was often frustrating. The new navigation tree library provides full control over the backstack, rectifying these issues.
• 01:00 - 01:30: Inspiration from Voyager Navigation Library This chapter discusses the inspiration drawn from the Voyager navigation library for creating a new navigation library. The official Voyager library is noted for its clean and native navigation solution using the composer. One of the key reasons for developing a new navigation library is the limitation of the original composer navigation library, which only supported displaying a single screen on top of the backstack. This limitation prompted the need for an enhanced navigation solution.
• 01:30 - 02:00: Limitations of Original Compose Navigation Library The chapter discusses the limitations of the original Compose Navigation Library, particularly in its inability to effectively support large screen devices such as tablets, desktops, and web platforms. The need for displaying multiple panels side by side on these devices is highlighted. The chapter also notes that as Compose Multiplatform becomes stable on iOS, the web target remains in alpha, suggesting an upcoming focus on improving web capabilities, thereby necessitating the development of a new Compose Navigation Library.
• 02:00 - 02:30: Key Concepts and Terminology: Backstack This chapter introduces key concepts and terminology related to the back stack in navigation systems. The back stack is explained as a stack of screens where the current screen is always on top. When navigating back, the top screen is removed, revealing the screen underneath, which becomes the new current screen. The back stack plays a crucial role in navigating through a screen hierarchy.
• 02:30 - 03:00: Backstack Keys and Stability The chapter 'Backstack Keys and Stability' discusses the concept of using keys as references to content within a backstack. Instead of storing the content itself, the backstack stores keys which reference this content. These keys are usually simple serializable data classes, although they can be of any type. This approach offers several advantages: it simplifies navigation by allowing keys to be pushed onto the backstack, and if the keys are serializable, it ensures the backstack can maintain stability and function effectively.
• 03:00 - 03:30: Navigation Flow Implementation This chapter delves into the details of implementing a navigation flow using the navigation 3 API. The discussion begins with the importance of persistent storage to survive configuration changes and process death, crucial for maintaining the navigation state. The unique aspect of navigation 3 API is highlighted, where developers have the responsibility of creating and managing the back stack. By manually constructing the back stack, developers then pass it as a parameter to the navigation 3 library, demonstrating a hands-on approach to navigation management. The chapter moves from theoretical explanations to practical implementation, guiding through setting up a simple navigation flow between two elements.
• 03:30 - 04:00: Current State and Dependencies The new library being discussed is in its alpha state, indicating that significant changes may occur. There are numerous artifacts available, which will be included despite not all being covered in the current video. Additionally, the Cotlin X serialization artifact and plugin are necessary.
• 04:00 - 04:30: Understanding Nav Display Composable The chapter titled 'Understanding Nav Display Composable' discusses the importance of including dependencies in both the plugin and the gradu file. It notes that the current version of the library does not support the iOS platform, with potential support in future releases. A demonstration is provided using a single screen seal class with two destinations, one of which can be represented as a Kotlin object because it does not accept inputs or parameters.
• 04:30 - 05:00: Managing Backstack State The chapter titled 'Managing Backstack State' discusses the transition from using 'nav host' to 'nav display composible' in Kotlin. The latter acts as a container for composable screens, essentially changing how navigation is set up in an application. The first argument in this transition doesn't require parameters, while the second involves a data class with a single argument.
• 05:00 - 05:30: Handling Screen Rotation and Persistence The chapter discusses handling screen rotation and persistence, focusing on the 'nav entry' class, which maps each composable screen to its unique key. This key could be the screen's child class or a predefined object. The back stack in this context is a custom creation, represented as a snapshot list, enabling the management of navigation states effectively. Details on maintaining UI state across screen rotations and ensuring persistence of navigation features are outlined, ensuring a seamless user experience.
• 05:30 - 06:00: Using ViewModel with Nav Entry This chapter discusses the integration of ViewModel with navigation entries in a software application. It covers how to handle the back stack, utilize transition animations, composible screens, and an intercepting lambda for the system back button. The chapter emphasizes the removal of the 'popback stack' function, highlighting an alternative approach of managing the back stack by simply removing the last screen from a list.
• 06:00 - 06:30: Scoping ViewModel to Nav Entry In the chapter titled 'Scoping ViewModel to Nav Entry,' the focus is on how a ViewModel can be scoped within an entry in a navigation system. The chapter discusses the use of an entry provider parameter, which is a function responsible for resolving a given key to its corresponding nav entry object. When the key is supplied by the navigation display, the entry provider function retrieves the associated nav entry. This nav entry includes both the key and its related content. Within a lambda function, it's possible to access this nav entry key, which is essential for managing the state and behavior tied to navigation entries.
• 06:30 - 07:00: Lifecycle and Instance Management of ViewModel This chapter discusses lifecycle and instance management of ViewModels. It highlights the usefulness of determining which composable screen to render based on the current back stack. Specifically, when the key is 'screen home', a button is displayed at the center. Clicking this button utilizes the back stack state to add a new screen to the stack, while also passing an argument, enabling smooth navigation and data passing.
• 07:00 - 07:30: Invitation for Further Exploration and Conclusion In this chapter, the focus is on the implementation of a two-screen navigation flow in an application. The process is described as simple and intuitive, with a specific emphasis on utilizing key parameters of the entry provider lambda to display text on the details screen. The chapter also highlights the functionality of a back lambda, which is triggered automatically when the back gesture or system back button is used, enhancing user navigation between the home and details screens.

Everything you need to know about NEW Navigation 3 Transcription

• 00:00 - 00:30 The new Jetack Navigation 3 library has just arrived, bringing some new fresh improvements in a compos navigation. In this overview, I'm going to walk you through some key concepts and features, explain why this new navigation library was needed, and most importantly, showcase some practical examples to help you understand this library even better. Stay tuned. The new jetpack navigation 3 library was built from the ground up. One of the
• 00:30 - 01:00 reasons was to provide the more concise and compose idiomatic API. The second reason is the major issue and the limitations with a backstag specifically the fact that the backstack state could be observed only indirectly. Managing backstack often felt frustrating. The original compos navigation library handled the back stack internally leaving us with a limited control over it. But with a new navigation tree library that has been changed. We now have the full control over the back
• 01:00 - 01:30 stack. And from my experience it seems that they have received an inspiration from the official Voyager navigation library because a Voyager navigation library is a brilliant example of a clean composer native navigation solution. The third reason behind the need for a new navigation library is a single screen limitation. The original compos navigation library was designed to display only a single screen which is on the top of the backstack. However, that became an issue especially with the
• 01:30 - 02:00 new large screen devices like for example tablets, desktop and even web. Those are the perfect use cases where displaying multiple panels or screens side by side is essential. And let's not forget the iOS platform just became a stable for a composer multiplatform leaving only the web target in an alpha state. This all suggests that their focus will probably be on the web target itself. Thus there is a need for a new compos navigation library. All right. So uh now it's time to get familiar with
• 02:00 - 02:30 some key concepts and the terminology. First up the backstack. So we already know what it is, right? Essentially, the back stack is a stack of a screens where the current screen is always on the top. When you navigate back, the top screen gets popped off the stack and the screen underneath moves up to become the new current screen that is displayed in navigation tree. The back stack does not
• 02:30 - 03:00 actually contain the content. Instead, it contains the references to the content which are known as keys. Keys can be of any type but are usually simple serializable data classes. Using references rather than content uh has a couple of benefits. First, it is a simple to navigate by pushing keys onto the backstack. And a second, as long as the keys are serializable, the backstack can
• 03:00 - 03:30 be saved to persistent storage allowing it to survive configuration changes and the process death. The thing about navigation 3 API is that we own the back stack. We are basically creating the back stack by ourselves and then passing that same back stack as a parameter to navigation 3 library. Now enough theory. Let's see in practice uh how we can implement a simple navigation flow between two
• 03:30 - 04:00 screens using this new library. This library is currently in alpha state which means lots of things could potentially change in the future. There are multiple artifacts that are currently available. I will add all of them even though we are not going to cover everything in this single video. Plus, we also need the Cotlin X serialization artifact as well as the plug-in.
• 04:00 - 04:30 Be sure to include those same dependencies in the plugin in the gradu file as well. By the way, this library in its current state does not support the iOS platform. They will probably leave that for the future releases. Now, for the demonstration purpose, I will add a single screen seal class with two destinations. The first one can be represented as a cotlin object because it will not accept
• 04:30 - 05:00 any arguments while the second one should be a data class with a single argument. Next, we can create the new cotlin file where we can define the navigation. By the way, we no longer have the nav host function. Instead, we have a nav display composible. It represents some kind of a container that holds all our screen composibles. Composible screens on the other hand uh are represented through
• 05:00 - 05:30 the nav entry class. That class practically maps each composible screen to its unique key. In this case, the key is the screen's child class or an object that we have already defined. As I already mentioned, we are creating the back stack by ourselves and it's simply represented as a snapshot list. Here we are also defining a star
• 05:30 - 06:00 destination with a default value. Then we are passing the back stack to the nav display composible. This function accepts a couple of more parameters like the transition animations, composible screens and also on a back lambda that intercepts the system back button so that we can properly handle the back stack accordingly. No more popback stack function. Just remove the last screen from this list and that's
• 06:00 - 06:30 it. Then we have the entry provider parameter. This entry provider is a function that resolves a key to the nav entry object. Upon receiving the key from the nav display, the entry provider function provides the associated nav entry which contains both the key and the actual content. Inside the lambda, we can get that nav entry key which is in this case
• 06:30 - 07:00 the actual screen class. It's useful to decide which composible screen to render based on the current back stack that we have also passed to this function. If the key is equal to screen home, then we're going to display a button on the center. And when the button is clicked, we can use the above back stack state to add the new screen to the back stack. Also pass an argument along the way and we're good to go.
• 07:00 - 07:30 For the details screen on the other hand, just grab that same argument from the key parameter of the entry provider lambda and displayed inside the text. It's really simple and intuitive. If we now launch the application, you should be able to see in practice simple two screen navigation flow between home and details. Plus, if we use the back gesture or press the system back button, then on a back lambda will be triggered automatically.
• 07:30 - 08:00 By the way, we can also use entry provider DSL and replace this when block with a more cleaner syntax. So just call the entry provider function and within its block we can access the entry function as a type just specify the actual screen and inside its content parameter we can define the actual screen composible. Really nice and clean. Before we continue, let's recap
• 08:00 - 08:30 those new concepts once again. So first, when we are talking about the back stack, you need to know that we are now in control of creating and maintaining the back stack itself. The back stack contains the key and not the actual composible content. Keys are added or removed from the back stack in a response to user interactions. Then we have the nav display composible. This composible
• 08:30 - 09:00 observes the back stack that we pass to it. In its default configuration, it displays the topmost backstack entry in a single pane layout. When the top key on the back stack changes, the nav display function uses that key to request the corresponding content from the entry provider. The entry provider is a function that resolves a key to the nav entry
• 09:00 - 09:30 object. Upon receiving the key from the nav display, the entry provider provides the associated nav entry which contains both the key and the content. Finally, the nav display receives the nav entry and displays the actual content. As simple as that. Now one issue with the current approach is that whenever we rotate our screen the back stack will reset and we will
• 09:30 - 10:00 lose everything which is in one hand normal since now we have the full control over the back stack and currently we are not persisting the backstack itself. Luckily there is one composible function that does that for us. It's called remember nav backstack. For this to work and to be able to persist the keys in the backstack, we also need to annotate our keys with a serializable
• 10:00 - 10:30 annotation. But that's not all. Remember navback stack function returns a snapshot state list of a nav key type which means our screen class needs to implement that nav key interface as well because every key in the backst must implement the nav key interface. This uh interface acts as a marker that signals to the library that the key can be saved. So with this even if we rotate the screen after navigating to the
• 10:30 - 11:00 details everything will work fine. Now another approach for managing your back stack is to store it in the view model. So let's define one tople view model here I'm going to call it my view model. In this class we can create the mutable state list with a default value of a screen home. The backstack variable should now be observed from our composible
• 11:00 - 11:30 function. So let's go back and call the vodel function to initialize this new view model. You need to remember that when initializing the view model like this, that view model will be scoped to the actual activity life cycle. Stay with me because in a moment I'm going to show you how you can also scope the view model to a specific nav entry as well. Anyhow with this we can now observe the backstack variable and pass it to the
• 11:30 - 12:00 nav display composible. If we now launch the application the back stack should be persisted even after we rotate the screen. Great. So view models are in general used to retain UI related state across configuration changes such as screen rotation. By default, uh v models are scoped to the nearest vodel store owner, which is typically your activity or a
• 12:00 - 12:30 fragment. However, you might want to scope your view model to a specific nav entry on the back stack rather than a entire activity. Right? This ensures that the vodel state is retained only while that particular nav entry is a part of the back stack and is cleared when the nav entry is popped off. Luckily, there is already an artifact that will help us to achieve exactly that. And that is the life cycle view
• 12:30 - 13:00 model navigation tree. So let's define a new details view model. In this new v modelel, I will just print a simple message when we initialize this view model as well as one more message when its instance is cleared or removed. Now we can go back and initialize this actual view model in the scope of our nav entry. After that we can launch the
• 13:00 - 13:30 application and observe the log. When we navigate to the details screen, we can see that in the logs, it says that the details vodel has been initialized. And if we press the back button to navigate back and pop this current details screen from the back stack, you will see that the vodel instance was not removed. And that is because when you initialize the vodel like this, its instance will be scoped to the actual activity and not that specific nav entry
• 13:30 - 14:00 composible. To fix that, we need to provide one more parameter to nav display function. And that parameter is called entry decorators. This parameter accepts a list of nav entry decorators. And for now, I'm just going to pass a couple of decorators here that will help us to scope the instance of this view model to the specific nav entry composible. This time when we launch the application, navigate to the details
• 14:00 - 14:30 screen and go back, the view model instance will definitely be removed. Perfect. Okay, so those were some basics about the new navigation 3 library. Drop a like if you want to see some more complex use cases about this new library, like the integration with a bottom bar, tabs, or even a multi-pane layout, for example. Other than that, let me know your thoughts in the comment section down below. And thank you for watching. Oh my god. Oh my god. If I
• 14:30 - 15:00 die, I'm a legend. [Music]