DEV Community: Amaury

RIP XML (Welcome Compose)

Amaury — Wed, 02 Aug 2023 14:57:51 +0000

RIP XML "They killed an innocent" (welcome Compose)
"They killed an innocent," says a song. That's what is happening to XML in Android, Google and the community are slowly killing XML.

Since the announcement of Android Compose back in 2021 at the Google IO developers conference, developers have been testing and working with this new Declarative pattern for Android, and slowly Compose has been winning space in the Android community.

Big steps for a baby:
As with all, new things generate a lot of uncertainty, and usually, when you are adopting a new tech you have to be very careful with it, at the beginning we don't use to count on enough documentation or a community that supports it, so we strongly suggest considering this points before adopting new tech in general:

Learning curve: We should evaluate the learning curve of the new technology and determine if it is feasible to allocate enough time and resources to learn and become proficient in it.
Technical requirements: Analyze the technical requirements and determine if it is compatible with the existing infrastructure and software, and the company vision.
Availability of resources: Assess the availability of resources, such as documentation, tutorials, and support forums, to aid in the learning and development process.
Company goals: Determine if the new technology aligns with the company goals and if it can help achieve them more efficiently or effectively than the current technology.
Cost: Consider the cost of adopting the new technology, including licensing, training, and impact on productivity during the transition.
Risks and challenges: Identify risks and challenges associated with the new technology, such as security, adaptability, compatibility issues, or a lack of community support and updates.
User experience: Consider how the new technology will impact the user experience and whether it will improve or hinder it.

The transition
But the idea of doing the transition to Compose was always over the table, so we started to learn it, testing, documenting, fighting poor online documentation and tutorials, fighting with bugs and undocumented issues (🥲), new design approaches, and studying new architectures.

So trust me when I say this transition can take a while, when you have a big team, aligning all the team members in the same direction is a big challenge, so my advice is don't try to jump into a bottomless pool and start a project with a new tech, or the consequence could be catastrophic.
Right now we can say that Compose is mature enough to start taking it seriously and start the transition to it, so here it's the big question:

Is XML so bad that we need to move to Compose?
No really, in general, over other advantages, XML offers a structured, efficient, and maintainable way to define UI elements, promoting a good development workflow and a consistent user experience. But Compose provide several advantages over XML:

Declarative UI: is cleaner, more readable, and more performant than Imperative UI.
XML depends too much on the application's live cycle.
Compose allows you to do more with less code compared to XML, redefining all the views and simplifying their use, no more recycler views yea!!!.
Compose is more intuitive: as declarative UI you just need to tell the UI what to show changing the data state and not setting up the UI like in XML.
State management: data state is not attached to the app live-cycle, we don't need to take care anymore of that.
Memory: all the compositions are painted "on demand" so the user just sees what needs to see and doesn't have hidden views or unused views in the background, improving the app performance.
Design: the design system is more robust and intuitive.
Learn more about Compose

Why now?
Compose is in a stage where we can use it to create complex solutions, saving time and effort for the team. The Android Development community is adopting compose very fast, and XML will be obsolete in the future, the same thing that happens with Java for Android when we move to Kotlin.

On the other hand with Compose, you can create UI components more intuitively and concisely, using Kotlin code instead of XML. This makes it easier to understand and modify your UI code and reduces the amount of boilerplate code you need to write, improving the readability and the maintenance cost.

Also rovides a faster way to develop your app's user interface. You can use Compose to quickly prototype your UI design and see the results in real-time, without having to compile and run your app. This can save you a lot of time and effort, especially during the early stages of UI development.

And finally Compose provides a more flexible and customizable way to create UI components. You can easily create custom UI components and modify existing ones to fit your specific needs. With Compose, you can also easily reuse UI components across different parts of your app, saving you time and effort in the long run. Compose is designed to perform better than XML-based UI development. Uses a more efficient rendering engine that can reduce the amount of CPU and memory usage, resulting in a smoother and more responsive user interface.

Conclusion
The transition to a new tech could be a challenge depending on the context, as individuals you may take a risk, but as a team, we have to consider a lot of things.

As a team, this is the moment to start developing products with Compose, very soon we will bring you a base project with an initial setup for an Android project with Compose including Theming, Navigation, Testing, DI, and more. We encourage you to start learning Compose to be more productive and bring to the end user a better experience.

Keep calm and code clean. 😜

keywords: #android #compose #xml #google

Serverless architecture

Amaury — Wed, 29 Mar 2023 15:00:11 +0000

What's the meaning of serverless architecture?

If you are thinking of "Apps running without servers", the answer is NO.

The terms refer to apps(web|mobile|games) that use a third-party service as a back-end with infrastructure already implemented instance of using a dedicated server. For example, Amazon with AWS Serverless Application Repository | AWS Lambdas, Google with Firebase, Microsoft with Azure Serverless, Node JS with RealmDB that uses GraphQL, and others.

Traditional architecture:

Serverlees architecture:

Understanding the server-less architecture

Now, let’s see what the images above mean with two real application scenarios.

Imagine that we have a blog app and we want to create a new blog post.
- Using traditional architecture: We sent that information to the server, and the server verifies that we have permission to create a new post and saves the data into the database, the Front-End doesn’t care where or how the server is protecting the data.
- Using server-less architecture: All we have to do is save the data into the database directly and the same database checks with the security rules if the data can be saved, and the server-less service takes care of the security in both cases, so we don't have to take care of it.
In the same blog app, we now need to show the feed of posts.
- Using traditional architecture: We ask for the feed, the server verifies first that we have the authorization to call that endpoint, then we ask the database for the data and respond to the data in a certain format.
- Using server-less architecture: All we have to do is create a function to get the data or make a call to the database, and the server-less service takes care of the security in both cases, so we don't have to take care of it. Note that in both cases when you are using a server-less solution the tests in the back end are not needed, however with traditional architecture, we need to write a lot of tests besides coding the entire solution.

Advantages:

The service takes care of the infrastructure.
They take care of maintenance.
Have strong security rules that you can modify if needed.
You only have to focus on the application logic.
SDKs for all platforms.
Enhanced Latency(better user experience) & Geo-location.
The cost depends on the use*.
The learning curve is quite fast.
Human resource cost.
Horizontal scalability
Services provide integration with other platform services.
Use his authentication service and integrations with other authentication tools like Google, Facebook, Apple, etc...

Disadvantages:

Limitations with business logic.
Scalability is limited to service capabilities.
It's hard to debug functions or tasks.
Sometimes the security rules are very complex.

The cost depends on the usage: Usually, the cost is cheaper than traditional cloud solutions, but you have to consider in your business analysis that the more you use the service the higher the price will be. If you have 2k users it will probably be free but if you have 200k users the cost will go up, depending on how many actions/functions you are using, so just keep that in mind. Before selecting the service to use, take a look at the operational cost of users/actions. Usually, all services have pricing calculation tools. With traditional architectures, you are billed monthly by the cloud provider, it doesn't matter if your application has traffic or not. In the case of a serverless solution you "pay as you go" so you don't have to worry about extra billing.

Use Cases:

News, Blogs, Reservations, etc.., in general applications that only show information and with little or no backend logic needed, most of the business logic is in the front.
Chats, bots, customer services.
Applications that share real-time data like the stock market, the weather, IoT applications, geo-location, games, and others.
Social networks.
Microservices.

In conclusion, serverless is a great option for applications that do not need complex business logic or need real-time data. Also, development time can be optimized, since you don't need to write any code for the back end or deploy any solution and a single developer can take care of both the front end and the back end, which is a saving in human resources.

Keep calm and code clean. 😜

Android XML reported death

Amaury — Mon, 27 Mar 2023 16:56:17 +0000

"They killed an innocent," says a song. That's what is happening right now to XML UI's in android, Google and the community are slowly killing XML.

Since the announcement of Android Compose back in 2021 at the Google IO developers conference, developers have been testing and working with this new Declarative pattern for android, and slowly Compose has been winning space in the Android community.

Big steps for a baby:
As with all, new things generate a lot of uncertainty, and usually, when you are adopting a new tech you have to be very careful with it, at the beginning we don't use to count on enough documentation or a community that supports it, so we strongly suggest considering this points before adopting new tech in general:

Learning curve: We should evaluate the learning curve of the new technology and determine if it is feasible to allocate enough time and resources to learn and become proficient in it.
Technical requirements: Analyze the technical requirements and determine if it is compatible with the existing infrastructure and software, and the company vision.
Availability of resources: Assess the availability of resources, such as documentation, tutorials, and support forums, to aid in the learning and development process.
Company goals: Determine if the new technology aligns with the company goals and if it can help achieve them more efficiently or effectively than the current technology.
Cost: Consider the cost of adopting the new technology, including licensing, training, and impact on productivity during the transition.
Risks and challenges: Identify risks and challenges associated with the new technology, such as security, adaptability, compatibility issues, or a lack of community support and updates.
User experience: Consider how the new technology will impact the user experience and whether it will improve or hinder it.

But the idea of doing the transition to Compose was always over the table, so we started to learn it slowly, testing, documenting, poor online documentation and tutorials, fighting with bugs and undocumented issues(🥲), new design approaches, and studying new architectures.
So trust me when I say this transition can take a while, when you have a big team, aligning all the team members in the same direction is a big challenge, so my advice is don't try to jump into a bottomless pool and start a project with a new tech, or the consequence could be catastrophic.

Right now we can say that Compose is mature enough to start taking it seriously and start the transition to it, so here it's the big question:
Is XML so bad that we need to move to Compose?
No really. But Compose provide several advantages over XML:

Declarative UI: is cleaner, more readable, and more performant than Imperative UI.
XML depends too much on the application's live cycle.
Compose allows you to do more with less code compared to XML, redefining all the views and simplifying their use, no more recycler views yea!!!.
Compose is more intuitive: as declarative UI you just need to tell the UI what to show changing the data state and not setting up the UI like in XML.
State management: data state is not attached to the app live-cycle, we don't need to take care anymore of that.
Memory: all the compositions are painted "on demand" so the user just sees what needs to see and doesn't have hidden views or unused views in the background, improving the app performance.
Design: the design system is more robust and intuitive.

Learn more about Compose

Why now?

Maturity: We consider that Compose is in a stage where we can use it to create complex solutions, saving time and effort for the team.
Community: The Android Development community is adopting compose very fast, and XML will be obsolete in the future, the same thing that happens with Java for Android when we change to Kotlin.
Knowledge: For the past year the team has been working to improve their skills with Compose, to deliver high-quality products faster and with the highest industry quality standard.
Declarative UI: On the other hand with Compose, you can create UI components more intuitively and concisely, using Kotlin code instead of XML. This makes it easier to understand and modify your UI code and reduces the amount of boilerplate code you need to write, improving the readability and the maintenance cost.
Faster UI development: Compose provides a faster way to develop your app's user interface. You can use Compose to quickly prototype your UI design and see the results in real-time, without having to compile and run your app. This can save you a lot of time and effort, especially during the early stages of UI development.
More flexibility and customization: Compose provides a more flexible and customizable way to create UI components. You can easily create custom UI components and modify existing ones to fit your specific needs. With Compose, you can also easily reuse UI components across different parts of your app, saving you time and effort in the long run.
Improved performance: Compose is designed to provide better performance compared to XML-based UI development. Compose uses a more efficient rendering engine that can reduce the amount of CPU and memory usage, resulting in a smoother and more responsive user interface.

Conclusion

The transition to a new tech could be a challenge depending on the context, as individuals you may take a risk, but as a team, we have to consider a lot of things. As a team, we feel like this is the moment to start developing products with Compose, very soon we will bring you a base project with an initial setup for an android project with compose including Theming, Navigation, Testing, DI, and more. We encourage you to start learning Compose to be more productive and bring to the end user a better experience.

Keep calm and code clean. 😜

Imperative and Declarative UI Pattern - Is Declarative Programming the future?

Amaury — Thu, 16 Mar 2023 13:42:00 +0000

Check out the Original post

Behind every mobile application, a UI framework determines how developers create the application and how well it performs. Today, UI frameworks fit into two categories: declarative and imperative. The majority of apps use the imperative approach.

However, as the newer, declarative frameworks develop and reveal their many advantages, several major tech companies have switched to developing their apps with declarative UI designs.

As declarative programming becomes more popular, we want to evaluate its advantages and disadvantages and consider how it improves upon imperative designs.

In this article, we will define and compare imperative and declarative UI design and explore the benefits and drawbacks of designing apps with declarative programming.

Understanding Imperative and Declarative UI Designs
Imperative and declarative UI frameworks refer to frameworks that use imperative and declarative programming styles, respectively. Below, we define these terms as they relate to UI design and describe the differences between the two paradigms or models.

Imperative Programming
Currently the most common paradigm, imperative programming requires the developer to write step-by-step how the program will reflect the desired state or perform an operation. For UI creation, developers write detailed code that tells the device how to display the components.

Declarative Programming
Declarative programming allows developers to design the user interface based solely on what they want to be displayed without regard to how the device will update its state.

Oftentimes, declarative frameworks rely on an underlying imperative implementation that translates the declarative command into a set of imperative instructions for the device to complete.

Let's look at an example
Website designer sitting at a computer
Web design
Consider a simple mobile app with a button that toggles its color.

Imperative design
A developer must create a button component and add an event handler function to it. The event handler function would run when clicked and contain an if-else statement that changes the color based on the button's color when pressed.

Declarative design
The developer creates a button component with the property toggle color. The declarative design appears much simpler and more intuitive.

However, the declarative example only works because of an imperative implementation in the framework that interprets the toggle color property and assigns the proper event handler that determines the current button color and how it needs to change.

Why use Declarative Programming?
Less code, faster development
Imperative programming requires a lot of code to manage the UI. Developers must determine the contents, define themes, position components, and manage event handlers. With many responsibilities, developers have less time to polish the design and debug other UI issues.

Moreover, imperative UI design typically requires multiple programming languages, one for the UI design and another for the functionality of each UI element.

With declarative programming, on the other hand, we only need to design UIs within the Swift (for IOS) or Kotlin (for Android) code, eliminating the need to maintain and handle separate UI files. In short, declarative UI programming means less code and faster development.

Theming
Declarative UIs come with a pre-configured theme. Developers can customize this theme to meet their preferences by altering properties like typography, color, buttons, etc. A pre-configured yet fully customizable theme saves developers time as they don't need to build a theme from scratch.

Dynamism
Declarative UI frameworks provide control structures developers can use to manipulate the drawing of the user interface. Compared to imperative frameworks typically used for Android and IOS development, declaratively developed user interfaces can use these control structures to be more dynamic.

State management
With an imperative design, developers face the difficulty of syncing the UI with the app state by manually updating all the components to reflect the changes in the app. Traditionally, developers created a user interface with a tree of widgets/layouts.

Whenever the app's data or state required a UI component to update, the program had to traverse through the tree of widgets, select the right one, and change it. As the tree of elements grows, the design becomes more complex and error-prone.

The declarative UI paradigm eliminates this process of manual synchronization. The declarative framework automatically updates the UI to match the app's state, simplifying state management by a significant degree.

Other Advantages of Declarative UI Design

Live previews for rapid UI development.
SwiftUI & Compose foster collaboration between designers and web developers
It's an opportunity to learn a valuable skill.

Disadvantages of Declarative UI Design
Since declarative programming has only emerged in the past few years, there are still unresolved issues and disadvantages. Current problems with declarative UI design include:

Declarative UIs only support more recent operating systems
You may encounter problems no one has faced before
Some features are only available in native, imperative UI frameworks
Best declarative programming practices and conventions have not yet been established
Insufficient documentation
Small developer community
Little integration with third-party libraries
The learning curve can be very steep initially
Many issues with the declarative paradigm, however, are likely temporary. As more companies and developers see the advantages of declarative design and invest more resources into growing the development community, they will resolve many of the aforementioned issues.

Why you should start thinking declaratively?
Declarative app development requires a new perspective. Many assumptions that developers might have, in regards to app development, no longer apply if using a declarative design.

For example, with declarative programming, developers can rebuild the UI to reflect the app's current state instead of modifying it directly. The formula below illustrates this new perspective.

When the state of your app changes (for example, the user flips a switch in the settings screen), the state changes, which triggers a redraw of the user interface. There is no imperative changing of the UI itself (like a textView.text = "Hi").

Conclusion
Several major names in the tech industry, such as Meta, Google, and Apple, have already adopted the declarative paradigm because they see its value as a simple yet effective method of app development.

These companies believe it is the future of front-end development. Here at Rootstrap, we believe we should be ready for it too, and we encourage developers to explore how declarative design could improve UI development.

Flutter Navigation: Navigator vs Go Router

Amaury — Thu, 16 Mar 2023 13:35:48 +0000

In this post we are going to learn a little bit more about Flutter Navigation and go_router.

Check the original POST

How does flutter navigation work?

Flutter navigation provides a way for you to navigate from one widget to another in your app. This is achieved by using a navigation stack, which is essentially a collection of routes.

Navigator is a built-in Flutter widget that provides a simple and convenient way to manage the navigation stack and navigate between routes. It's straightforward to use and can be a good choice for basic navigation needs. On it a route represents a widget and its associated data. When you navigate to a new route, it is pushed onto the navigation stack, and when you navigate back, the current route is popped off the stack.

Navigator provides a number of navigation widgets, including Navigator, MaterialPageRoute, and CupertinoPageRoute, that make it easy to manage the navigation stack and provide common navigation patterns.

With Navigator, you can push and pop routes, as well as manage the navigation stack. MaterialPageRoute and CupertinoPageRoute are two common types of routes in Flutter that are used to transition between pages. They provide animation and visual effects appropriate for the material design or Cupertino design languages, respectively.

Overall, Flutter navigation is designed to be flexible, allowing you to create complex navigation patterns that meet the needs of your app.

But there are some limitations and potential problems that you should be aware of:

Limited routing features: Navigator provides basic routing functionality, but it doesn't offer advanced features like named routes, path parameters, query parameters, or wildcard matching, which can make it challenging to build more complex navigation patterns.
Code complexity: As your app grows in complexity, managing the navigation stack with Navigator can become more challenging, making your code more difficult to maintain and debug.
Lack of customizability: Navigator provides basic animation and visual effects for transitioning between routes, but it doesn't allow you to customize the routing transitions and animations.
Global state management: Navigator doesn't provide a built-in solution for managing the global states, which can make it challenging to share data between routes.
Inconsistent navigation patterns: Because Navigator is a low-level widget, it can be challenging to ensure that navigation patterns are consistent across your app. This can lead to a fragmented user experience.
These limitations can make it challenging to build complex, scalable, and consistent navigation patterns with Navigator. If you encounter these limitations, you may want to consider using a third-party routing library, such as go_router, to address them.
On the other hand, go_router is a third-party routing library maintained by the Flutter team, that provides advanced routing functionality that is not available in Navigator. For example, go_router provides features such as named routes, path parameters, query parameters, and wildcard matching, which can be useful for building more complex navigation patterns.
Additionally, go_router provides a more elegant and declarative approach to routing, making it easier to manage the routing logic in your app. This can help to make your code more organized and maintainable, especially as your app grows in complexity.
So, if you need advanced routing features and a more elegant routing solution, you may consider using go_router. But if your navigation needs are simple, Navigator may be a more appropriate choice.

There are several advantages of using go_router in Flutter:

Named routes: go_router supports named routes, which makes it easier to manage and organize the navigation logic in your app. Named routes allow you to define the routes in a central location and then reference them throughout your app, making it easier to make changes to your navigation logic in the future.
Path parameters: go_router supports path parameters, which allow you to pass data to your routes based on the URL. This is useful for building dynamic navigation patterns, such as when you need to pass an ID or other data to a route.
Query parameters: go_router also supports query parameters, which allow you to pass data to your routes through the URL query string. This is useful for cases where you need to pass data that is not part of the route path.
Wildcard matching: go_router supports wildcard matching, which makes it easy to define catch-all routes that can handle any URL that doesn't match another route.
Declarative routing: go_router provides a more elegant and declarative approach to routing, making it easier to manage the routing logic in your app. This can help to make your code more organized and maintainable, especially as your app grows in complexity.
Custom routing transitions: go_router allows you to customize the routing transitions and animations, making it possible to create custom and unique navigation experiences in your app.

Overall, go_router provides a number of advanced routing features that can make it easier to manage and organize the navigation logic in your Flutter app. If your navigation needs are complex, go_router may be a good choice for your project.

Let's see an example of how we can structure our app:


 Dart
static GoRouter onBoardingRouter(AuthState authState) => GoRouter(
        initialLocation: "/logIn",
        navigatorKey: onBoardingNavigatorKey,
        routes: [
          GoRoute(
            name: "login",
            path: "/logIn",
            builder: (context, state) => const LoginPage(),
            //Example of redirection        
            redirect: (context, state) => authState == AuthState.loading ? "/splash" : null,
          ),
          GoRoute(
            name: "splash",
            path: "/splash",
            builder: (context, state) => const SplashPage(),
          ),
          GoRoute(
            name: "signUp",
            path: "/signUp",
            builder: (context, state) => const SignUpPage(),
          ),
          GoRoute(
            name: "passwordReset",
            path: "/passwordReset",
            builder: (context, state) => const ResetPasswordPage(),
          ),
        ],
      );


static GoRouter mainRouter = GoRouter(
    initialLocation: "/main",
    routes: [
      ShellRoute(
        navigatorKey: mainNavigatorKey,
        builder: (context, state, child) {
          return Cookies(
            child: HomeCorePage(
              child: child,
            ),
          );
        },
        routes: [
          GoRoute(
            name: "main",
            path: "/main",
            builder: (context, state) => const HomePage(),
            routes: [
              GoRoute(
                name: "postDetails",
                path: "postDetails",
                builder: (context, state) =>
                    PostDetailsPage(postId: state.params['id'] ?? ""),
              ),
              GoRoute(
                name: "chat",
                path: "chat",
                builder: (context, state) => ChatPage(),
              ),
              //...........
            ],
          ),
        ],
      ),
      ShellRoute(
        navigatorKey: mainNavigatorKey,
        builder: (context, state, child) {
          return Cookies(
            child: SettingsCorePage(
              child: child,
            ),
          );
        },
        routes: [
          GoRoute(
            name: "settings",
            path: "/settings",
            builder: (context, state) => const HomePage(),
            routes: [
              GoRoute(
                name: "profileEdit",
                path: "profile",
                builder: (context, state) => const EditProfilePage(),
                routes: [
                  GoRoute(
                    name: "resetPassword",
                    path: "resetPassword",
                    builder: (context, state) => const ResetPasswordPage(),
                  ),
                ],
              ),
              GoRoute(
                name: "themeSetup",
                path: "theme",
                builder: (context, state) => const ResetPasswordPage(),
              ),
              //...........
            ],
          ),
        ],
      ),
    ],
  );

Go_router manages different types of routes:
ShellRoute: is a container, basically, all the child routes will be rendered inside of its widget.
i.e: Here HomeCorePage can have a container that renders a child widget with a classic nav drawer or a bottom nav bar to nav between screens, as usual when you change between screen we de HomeCorePage render again the new child and keeps the state of the rest of the screen.


 Dart
static GoRoutermainRouter= GoRouter(
  initialLocation: "/main",
  routes: [
    // Home Navigation with drawer or bottom nav bar
    ShellRoute(
      navigatorKey: mainNavigatorKey,
      builder: (context, state, child) {
        return Cookies(
          child: HomeCorePage(
            child: child,
          ),
        );
      },
      routes: [
        GoRoute(
          name: "main",
          path: "/main",
          builder: (context, state) => const HomePage(),
        ),
        GoRoute(
          name: "settings",
          path: "/settings",
          builder: (context, state) => const SettingsPage(),
        ),
      ],
    ),
  ],
);

GoRoute: the main route type, this is where you declare your route with the widget to render, and can have different children, let's see:


 Dart
GoRoute(
          name: "main",
          path: "/main",
          builder: (context, state) => const HomePage(),
          redirect: (context, state) {
                if (!isUserAuthTo("main"))
                         return "/unauth";
                if (!state.params.containsKey("id"))
                      return "/main"
                    // return null to continue to the sub route
                return null;
          },
          routes: [
            GoRoute(
                name: "details",
                    path: "/details/:id",
                    builder: (context, state) => const Details(id: state.params["id"] ?? ""),
                ),
),
@amaury901130

Here we can see different things:
Every route can have N sub-routes.
We can add validations before nav to a sub-route and redirect the user to any other page that we need in case don't match the validation.
Another advantage of go_router is that we can manage nav errors easily in the GoRouter class:


 Dart
GoRouter(
   // when trying to nav to a missing route.
      errorBuilder: (context, state) {
          return ErrorPage(ErrorCode.e404);
      },
      initialLocation: "/main",
      routes: ....
)

Deeplinks:
When a deep link is received from the platform, GoRouter will display the configured screen based on the URL path. To configure your Android or iOS app for deep linking, see the Deep linking documentation at flutter.dev:

Enable deep linking on Android
Add a metadata tag and intent filter to AndroidManifest.xml inside the tag with the ".MainActivity" name:


 xml
<!-- Deep linking -->
<meta-data android:name="flutter_deeplinking_enabled" android:value="true" />
<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT"/>
    <category android:name="android.intent.category.BROWSABLE"/>
    <data android:scheme="http" android:host="flutterbooksample.com" />
    <data android:scheme="https" />
</intent-filter>

A full restart is required to apply these changes.
Test on Android emulator
To test with an Android emulator, give the adb command an intent where the host name matches the name defined in AndroidManifest.xml:


 xml
adb shell 'am start -a android.intent.action.VIEW \\ -c android.intent.category.BROWSABLE \\ -d "<http://flutterbooksample.com/book/1>"' \\ <package name>

Replace the <package name> with the package name of your Android app. If you named the package com.example.myflutterapp, run the following command:

adb shell 'am start -a android.intent.action.VIEW \\ -c android.intent.category.BROWSABLE \\ -d "<http://flutterbooksample.com/book/1>"' \\ com.example.myflutterapp

For more details, see the Verify Android App Links documentation in the Android docs.

Enable deep linking on iOS
Add two new keys to Info.plist in the ios/Runner directory:


 xml
<key>FlutterDeepLinkingEnabled</key> 
<true/> 
<key>CFBundleURLTypes</key> 
<array> 
    <dict> 
    <key>CFBundleTypeRole</key> 
    <string>Editor</string> 
    <key>CFBundleURLName</key> 
    <string>flutterbooksample.com</string> 
    <key>CFBundleURLSchemes</key> 
    <array> 
    <string>customscheme</string> 
    </array> 
    </dict>
</array>

The CFBundleURLName is a unique URL used to distinguish your app from others that use the same scheme. The scheme (customscheme://) can also be unique.
A full restart is required to apply these changes.
Test on iOS simulator
Use the xcrun command to test on the iOS Simulator:
xcrun simctl openurl booted
customscheme://flutterbooksample.com/book/1

In conclusion
Go_router is an alternative to Navigator that offers some advantages over the latter, especially in large and complex applications. We strongly recommend that if you're working on a complex application and need advanced navigation management, you should consider using go_router.
Below are some reasons why we should consider using go_router instead of Navigator:

Greater flexibility in defining routes: Go_router allows for a more flexible definition of navigation routes than Navigator. With go_router, we can define routes based on any criteria, such as the access route, URL parameters, application state, etc.
Better navigation management: Go_router offers more advanced navigation management than Navigator. For example, go_router allows us to define multiple navigation stacks for different areas of the application, making it easier to navigate between them without losing context.
Integration with the BLoC pattern: Go_router integrates well with the Business Logic Component (BLoC) pattern, which is a popular architecture pattern in Flutter. Go_router allows us to define routes that are directly linked to BLoC events, making it easier to manage navigation and application state.
Better performance: Go_router offers performance improvements over Navigator in large and complex applications. Go_router uses a tree-based data structure to store navigation routes, allowing for faster and more efficient route lookup.