Navigate routes not recommended for most applications flutter in flutter docs - flutter

I was reading here about navigate with named routes, and in the document itself it says that it is no longer recommended to use it in many applications. Can anyone recommend me what is correct to use now? Or some article talking about.

Flutter docs suggests using go_router package for Navigation.
Explanation:
Limitations of trivial approach
Although named routes can handle deep links, the behavior is always the same and can’t be customized. When a new deep link is received by the platform, Flutter pushes a new Route onto the Navigator regardless where the user currently is.
Suggested Better Approach
Flutter applications with advanced navigation and routing requirements (such as a web app that uses direct links to each screen, or an app with multiple Navigator widgets) should use a routing package such as go_router that can parse the route path and configure the Navigator whenever the app receives a new deep link.
Reference questions regarding go_router:
Flutter: go_router how to pass multiple parameters to other screen?
Go_Router Pass Object to new route

Related

Do I have to use Getx Controller for all in my Flutter App?

A developer friend of mine told that if I use getX, I have to use getx's on navigator. So you cannot use flutter's navigator. Same for Clipboard and MediaQuery.
Is it correct? I searched about this topic but did not find any proper answer.
I acutally learn what are the restrictions and the flutter's or custom packages that I cannot use if I use getx
You can still use Flutter's navigation, clipboard, mediaQuery and everything else, and other custom libraries using GetX.
GetX is also a one of custom libraries so there's no any restriction.

best way to share data between pages in flutter

I have many pages and I want to share file content between some pages, also giving this pages ability to modify content, the file contains (obj, data (int, bool, ...)).
1st: share file content between some pages can be done by using Constructor.
2nd: ability to modify conten can only be done by global variable+ key, but go for stateManagement.
I suggest, you should go for StateManagement. It can handle that.
I perefer using riverpod, also people suggest using getx being easy to use.
for more read this.
You can try the provider package as it's an effective tool for sharing data a cross your flutter app: https://flutter.dev/docs/development/data-and-backend/state-mgmt/simple
Either use constructors to dig through the widgets or simply use one of the packages for state management like provider, getx, bloc and many others.
But if you are a beginner then go with provider package as it is recommended by flutter team

Which is the best way of Routing in a Flutter App

Which is the best way of Routing in a Flutter App?
I've tried named routes, routes array, flutter navigation 2.0. But I am still not sure which is the best.
Flutter docs suggests using go_router package for Navigation.
Explanation:
Limitations of trivial approach
Although named routes can handle deep links, the behavior is always the same and can’t be customized. When a new deep link is received by the platform, Flutter pushes a new Route onto the Navigator regardless where the user currently is.
Suggested Better Approach
Flutter applications with advanced navigation and routing requirements (such as a web app that uses direct links to each screen, or an app with multiple Navigator widgets) should use a routing package such as go_router that can parse the route path and configure the Navigator whenever the app receives a new deep link.
Reference questions regarding go_router:
Flutter: go_router how to pass multiple parameters to other screen?
Go_Router Pass Object to new route
Navigator 1.0 and 2.0 are usable. None is deprecated.
For mobile app only Navigator 1.0 is the best, I use onGenerateRoute field from MaterialApp and that's all I can handle all my routes and deep links. Some times, I used the Navigator widget for specific routes in app page but it's rare.

MaterialApp must it be only one in the whole application?

I have an interesting question. Seeing Flutter's MaterialApp class, you will find congruences with an activity on the entire application that we are going to build for Flutter. But my doubt is this. Do I have to enter N MaterialApp for each section where I can't go back? Or is it thought to be unique?
The internal design of MaterialApp indicates that it is designed to be used only once in the application. It has fields like localizationsDelegate,theme, and routes, which will be bad design if it used more than once , because most of these field will resort to default values causing a significant memory waste.
If you just want to use it to prevent navigating back to other screens or "sections", there are plenty of options provided by flutter like Navigator and WillPopScope.

Navigation with new Ionic (version 4)

Up to Ionic3, it was closely packed with Angular.js. So probably the navigation jobs were done by some Angular.js functionality. I can be wrong since I have not worked with Ionic or Angular.js before.
Ionic4 will be framework agnostic, written with Stencil.js and compiled with Stencil.js Compiler to Web Components standard components.
I wonder how navigation tasks will be handled, and by whom? Does Ionic4 have routing capabilities? Or it does not and developer's client-side router of choice must be used, especially I wonder the use case with Stencil.js since it has a router too. For example, how it should be used for a tabbed application Mark up and styles by Ionic, and routing with Stencil.js?
Ionic will now use angular router. it will make use of angular router-outlets. for the tabbed application markup, each tab will be provided with a named router outlet. Read more here:
Ionic/angular v4 router
Ionic 4 will now use angular routing method instead of default ionic 3 (push/pop) methods.
Must read the migration notes from ionic team.
Ionic has a component for simple navigation: https://ionicframework.com/docs/api/nav
But it's meant for simple navigation inside modals that doesn't affect the browser's url.
This navigation is controlled by calling methods on the element, so in Angular you have to use #ViewChild and it becomes complex to handle state and have deep navigation trees.
You should use a client-side router for most of your view to take advantage of code splitting and lazy loading your js bundle.