Comments (6)
Added on branch dev 1.19.0-dev.
from getx.
This is not difficult to implement, I would do it in a few minutes, but my concern is that it can have side effects, and major performance problems.
I centralized everything that depends on context in a single navigatorKey, which causes less memory consumption compared to the standard framework.
In order to have NestedNavigators, it is necessary to create a Map of globalKeys, and the documentation is clear that globalKeys are expensive and should be avoided (and this is remarkable, as I mentioned above, only the fact of centralizing half of the GlobalKeys of the framework in one, already caused a noticeable difference in ram consumption).
It is a function that I understand necessary, but that will clearly bring performance problems.
Hypothetical situation:
The user enters a tab, navigates through 3 more tabs (in Flutter the navigation is superimposed, so one screen is literally on top of the other). Then he opens another tab, navigates through 5 more tabs, and does it successively. 15, 20, 30 screens that are not being used will be kept in memory and will not be discarded properly. I understand the need for this function, but I can't think of a single situation that would be worth having nestedNavigators at the expense of performance.
I could implement NestedNavigators now, but at least in my applications it did not have a good result, however if this is something urgent and more people have the same need, I can add it experimentally on the master, but for now, thinking about great applications, I don't really like that idea.
I will in the future use GetObserver to save the application's routes and global state, and thus, simulate NestedNavigators. The screens would not be open, but when the route that was already saved was clicked, Get would take you directly to the page where you left off. But I only have plans to do this for version 2.0, where I will include the permanent navigation feature. I'm working on it in my spare time.
from getx.
Do you think these are really practical concerns though? Dart is very fast, Flutter has low memory usage in general, is also very quick at inflating/deflating widgets.
I think this case of many navigators, with many pages all stacked up, is quite outside the main path of like 1 root navigator, and 1 or 2 sub navigators that I keep running into anytime I want to have some persistent chrome around my content pages.
Without this, I wonder how you would recommend doing anything like this currently? I'm thinking desktop apps specifically, where this sort of persistent menu/nav bar is always present:
http://screens.gskinner.com/shawn/Photoshop_2020-03-14_02-04-57.png
Also, as I understand page routes, unless you set them to be non-opaque, the widgets are removed, and the page route deflated, as soon as the new route has finished transitioning in.
https://api.flutter.dev/flutter/widgets/PageRoute/opaque.html
from getx.
Do you think these are really practical concerns though? Dart is very fast, Flutter has low memory usage in general, is also very quick at inflating/deflating widgets.
I think this case of many navigators, with many pages all stacked up, is quite outside the main path of like 1 root navigator, and 1 or 2 sub navigators that I keep running into anytime I want to have some persistent chrome around my content pages.
Without this, I wonder how you would recommend doing anything like this currently? I'm thinking desktop apps specifically, where this sort of persistent menu/nav bar is always present:
http://screens.gskinner.com/shawn/Photoshop_2020-03-14_02-04-57.pngAlso, as I understand page routes, unless you set them to be non-opaque, the widgets are removed, and the page route deflated, as soon as the new route has finished transitioning in.
https://api.flutter.dev/flutter/widgets/PageRoute/opaque.html
If there is no abuse, as in your case, there would be no problems.
However, as for opaque routes, this does not correspond to reality.
Opaque routes should work as in the documentation, but this does not actually happen, because the GlobalKey used in the Overlay that builds the base of navigation routes is not a const. Every time a new route is pushed, a new GlobalKey is created, and this causes the entire MaterialApp rebuild. So setting opaque = true has the exact opposite behavior to that of the documentation.
Currently, in the stable and beta version, opaque route is not a performance optimization, on the contrary, it is a complete bug, but necessary for the operation of the Cupertino Route, in fact it is not so necessary, but to make this work, I I would have to rebuild the Framework from the Widget Overlay for it to work properly, and it would inflate my library a lot.
If you want to see in practice how this happens, reproduce the example below and you will see that when pushing a new route, all the others below the opaque route are rebuild.
import 'package:flutter/material.dart';
void main() {
runApp(new MyApp());
}
class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
return new MaterialApp(
title: 'Flutter Demo',
theme: new ThemeData(
primarySwatch: Colors.blue,
),
home: new MyHomePage(id: 1),
);
}
}
class MyHomePage extends StatefulWidget {
MyHomePage({Key key, this.id}) : super(key: key);
final int id;
@override
_MyHomePageState createState() => new _MyHomePageState();
}
class _MyHomePageState extends State<MyHomePage> {
@override
Widget build(BuildContext context) {
print('Page ${widget.id} built!');
return new Scaffold(
appBar: new AppBar(
title: new Text(widget.id.toString()),
),
body: new Center(
child: new RaisedButton(
child: new Text('Open next page'),
onPressed: () {
Navigator.of(context).push(
new MaterialPageRoute(
builder: (_) => new MyHomePage(id: widget.id + 1),
maintainState: true
)
);
}
)
),
);
}
}
The widgets are not removed, they remain in memory, the only thing that changes is that the app will be bottlenecked by a setState in the entire materialApp.
Here is an example of the memory usage between Get with opaque = false and MaterialPageRoute with opaque = true:
https://www.youtube.com/watch?v=yVBqT6hg4VA&t=14s
However, goderbauer is solving this already. He did a recent pull on the master that took the GlobalKey from the overlay off the stage, preventing a new one from being created with each navigation, but this was reversed 2 days later because it caused instability in the snackbar, which needs a new GlobalKey to stack a OverlayRoute over the normal route. Numerous changes were made, which even caused this lib to be incompatible with the master, so I stopped following until the changes went to Dev.
If this is corrected, everything will be fine.
from getx.
Wow, good to know! Thx for the overview.
from getx.
I supposed this is the place to be for the nested navigators that you mentioned on the other ticket.
Looking forward to it!
from getx.
Related Issues (20)
- Instance "GetLifeCycleBase?" is not registered.
- Drawer Menu disappear after changing app locale in drawer
- when I use Get.dialog() to show a dialog, then I use Get.back() back dialog, at the same time ,the page widget's getxController operator onClose(), how to solve this problem. HOT 3
- Get.dilog().adaptive()
- Create a Getx organization HOT 3
- GetX update. HOT 2
- hello please add material design 3 to this package , thank for persue. HOT 1
- [GETX] "AddWorkerController" deleted from memory but actually not deleted HOT 1
- Displaying a Snackbar that is does not use the full width makes buttons on that height unclickable.
- [Flutter 3.16.5][GetX-5_RC5] PopScope issue HOT 12
- Error: Undefined name 'required'.
- Memory leaks HOT 1
- Can get.to specify context? HOT 1
- RxList in Getx bindStream, but Obx keep get old data emmited
- Nested GetRouterOutlet not working as expected HOT 2
- UI Not Updating with Switch/Toggle in ListView using GetX Controller
- Back button in browser don't behave the same as Get.back()
- Reactive variable observation issues HOT 2
- 是否可以在 GetMiddleware 中拿到正确的 arguments 值
- The GetxController is not automatically deleted if it is the first child of GetMaterialApp HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from getx.