I'm trying to create an app that has this structure:
I have several questions.
In what router delegate I should use RouteInformationParser? May be in both router delegates? I'd like to keep the authentication router and the nested router as separate as possible.
The same question applies to setNewRoutePath. In what router delegate I should implement it? Again in both?
In general may be this separate states idea is wrong. Should I abandon it and merge AuthPathState and NestedPathState? Please let me know.
You would usually have separate RouterDelegate if you want to include additional Navigator widgets to allow "nested" navigation (for example preserving a BottomNavigationBar which is part of the widget currently shown by the root Navigator while navigating with the nested Navigator).
Therefore for the use case stated here, I would merge those to something like AppPathState.
Related
When creating a Flutter application,
we use a Navigator to move back and forth between screens.
In my application, I have some class instances that
I want to share with all child widgets in the hierarchy.
An example is a Data Base driver class (stateful)
which holds all functionality of reading/writing to the actual database.
Currently - the 'main' function is initializing it,
then the resulting object is passed through all
constructors of the participating widgets.
How do I make it behave like the Navigator
so it would be available in the global scope
without importing it or passing it through a chain of constructors?
I would gladly accept any other approaches,
and still, if you can also address the exact question - I would be grateful :)
I opened the code of Navigator, Stateless and Stateful widgets,
I tried to google for the source of that Navigator instance
but came up with nothing helpful.
Have you tried using InheritedWidget?
From the docs:
Base class for widgets that efficiently propagate information down the tree.
Create DataBaseDriver class as inherited Widget class, access it in its child class using context as DataBaseDriver.of(context)
I'm writing a Flutter app and planning to use GetX for state management (amongst other things). The common design pattern seems to be to use one dart file per view (screen) and for each view to have its own associated controller file.
However, what is the best approach when you have state that isn't just used within a single screen, but instead needs to be shared across screens? It seems wrong to import controllers from one view into the view or controller for another screen. Is there a better way?
Thanks
You can use GetxService: https://pub.flutter-io.cn/documentation/get_state_manager/latest/get_state_manager/GetxService-class.html
As it says: Unlike GetxController, which serves to control events on each of its pages, GetxService is not automatically disposed (nor can be removed with Get.delete()). It is ideal for situations where, once started, that service will remain in memory, such as Auth control for example. Only way to remove it is Get.reset().
I'm trying to navigate between different screens using named routes.
I'm defining a root-Route (you may call it fallback route(?)), some other routes and an initialRoute, linking to a different screen than the root-Route.
The widget tree seems to load the root-route as well. But why?
TicketsScreen has many Widgets and I don't want them to be loaded beforehand.
BTW: This is only an example. When having multiple routes, it still loads both of the mentioned.
That's because /tasks has a leading /.
The navigation system pushes everything that's there, let me explain.
If you had there routes:
/
/tasks
/tasks/new
navigating to /tasks/new will push all of three.
If you want to keep "single" routes, you should use top level qualifiers. In your case that would be removing the / from /tasks.
This mechanism is useful to push a path and avoid strange pops if, for example,
you navigate to /tasks/new from a shortcut (not from /tasks) and then pop back. Would it be good to pop to the starting point? Would it be better if popping from a new task will lead to the tasks page?
That's a brief explanation of what the navigator tries to do, I guess.
I want to implement navigating a tree structure like it is done in e.g. the WinRT file picker. I then want to be able to drop this behavior as part of any page.
My current attempt, is to try and register a secondary FrameAdapter/INavigationService in the container and use that for a frame that is different from the app root frame. So far, I could not get it to work.
My motivation behind that, is, that I do not want to reimplement sth. that the INavigationService already provides.
Basic structure:
ShellView that represents the general app layout (header, footer, navigation) and is currently an OneActive conductor.
Frame control (x:Name="ActiveItem") on the ShellView inside which the hierarchical navigation should occur
The chosen conductor has no relevance yet, since I'll probably have to nest the FrameControl inside another view later to really set up a MDI interface. I'll will want to have multiple screens that should be able to hierarchically navigate
I could not find a CM WP7 example of such a scenario
Can you help me out here?
My problems so far:
How do I access the container from a view code-behind without resorting to using the Application.Current. I figured, it is in the code-behind where I would want to setup the secondary FrameAdapter, since it is here that I have access to the FrameControl
How do I setup the INavigationService so that the initial loading by CM (populating the ActiveItem) is registered with it. There does not seem to be a navigation event for this initial display of the ActiveItem.
Many thanks in advance,
Tobias
PS: I have cross-posted to the Caliburn Micro discussions (Discussion over at CodePlex CM)
first post don't hurt me :)
I am using a BorderLayout with the usual North, West, Center, South Panels. On the West ContentPanel, I've got a Tree. If an event (OnClick)occurs I want a particular dialog box displayed on the Center ContentPanel.
What is the best way for me to do this? Currently I'm using a function called returnPanel() that returns the center ContentPanel. In the event handler I call this function (MainWindow.returnPanel().add(myDialog)).
The way you are doing it is intuitive and works, but will start causing hell when the application grows, because different parts of the application are strongly coupled. The solutions to this problems are the MVC design pattern and the observer design pattern.
Ideally, using the MVC pattern, you don't want any widget to 'know' of any other widget. There is only class that knows all the widgets, which is the Controller. Anytime one widget needs to message/signal another widget, it tells it to the Controller class, which relays the message in the appropriate way to the appropriate widget. In this way, the two widgets are decpoupled and one can change without breaking the other. You may want to use an enum to enumerate all possible actions to which the controller has to responsd.
If your widget has to call only the Controller when an event occurs, you may simply call an aptly named (static) method on it and be done with it. However, as soon as multiple other classes needs to be informed of an event, you are better of using the Observer pattern, which allows you to signal multiple other classes, without changing your class. It simply calls notifyPObservers() in the eventHandler and that's it. How many listeners there are, and what type they are, is irrelevant. This way, you also decouple a class from it's listeners. Even if only the Controller listens, it may be advisable to use the pattern, as it clearly seperated the 'call back' code from the other code in the classes.
BTW, this has nothing to do with GWT or even Java in particular.