Looking at the Flutter Hero Transition, it appears to move the tagged Widgets to an Overlay class that exists in all Navigator Widgets but sits above the main content in the stack.
If this is correct, it allows the Hero to widgets to still respond to the Route scope and its animators but exist above the actual route content. How is this actually done efficiently? Surely this involves taking an entire Widget and storing it in a state for the duration of the animation. That Widget still has to respond to intrinsic responses from its original position such as slivers responding to active scroll actions.
Recreating this could be done with state management but I wondered how the standard hero actually does this. It seems like Widgets are effectively duplicated and then conditionally rendered on the screen defaulting to the overlay during the route animation and swapping out the original widget with an Offstage or similar. Is this how it is done?
The reason for trying to understand it is the need to replicate this behaviour in situations where Navigator is not an effective use case for a transition taking place internally on a page. I built an accordion style navigator but still want a hero transition to take place on the AppBar / NavigationBar. I know that this could be done with Navigator but it doesn't suit the use case. I could also predefine the AppBar content for each internal navigator state of the accordion but that is a lot of additional code.
Related
Is it possible to implement a Hero Animation in flutter but instead of being controlled by Navigator, be controlled by a custom AnimationController.
This is for a use case needs to go inside another element rather than a new screen as is the case with Navigator.
Alternatively, is it possible to directly inject a widget into an overlay that is fixed permanently elsewhere on the screen preserving the state, logic and controllers of where it was initially declared.
Imagine I have content that changes on a page based on a certain user interaction but still should animate a transition of a sliver app bar as if a new screen has entered when it had not.
In laymen's terms, I want to declare a widget wherever I happen to declare it but not actually render there. IT should render instead in a targeted location but still maintain any state or controllers it obtained or inherited from the position in which it was actually declare.
I'm looking for a way to redirect gestures(touches) from one widget to another. The use case for this is that I need to show a transparent screen(bottom sheet) above another screen(map) using Navigator and redirect gestures from that transparent screen to the one below.
Unfortunately Navigator route absorbs all gestures at the root level, thus they cannot pass-through. I'm also unable to use IgnorePointer because there are interactive elements in the transparent screen.
Is there a way to do this?
p.s. I'm aware that OverlayEntry solves this, but I'm looking for a way to achieve this using Navigator
When we want to achieve a button, we can choose raisedButton in flutter lib, also can a Container with onTap() function. So what's the difference between the two and which one should we choose in different situation?
Container function doesnot have onTap option, but you can achieve it by wrapping it in Guesture detector or Inkwell. There are no changes in the backend. But Raised button gives you the elevation, and animation on tap. You can also do it in the container, but it requires you to manually do it.
If you want a simple button quickly use RaisedButton.
If you want a more complex one, use Container or mixture of Containers, RaisedButton etc.
I am gonna offer something different... A tale of a treasure that is known to have answers to many questions, use cases and sometimes even examples. The name of this treasure is: official documentation. ;)
RaisedButton
A raised button is based on a Material widget whose Material.elevation increases when the button is pressed. Use raised buttons to add dimension to otherwise mostly flat layouts, e.g. in long busy lists of content, or in wide spaces. Avoid using raised buttons on already-raised content such as dialogs or cards.
Container
A convenience widget that combines common painting, positioning, and
sizing widgets.
GestureDetector
A widget that detects gestures. Attempts to recognize gestures that
correspond to its non-null callbacks. If this widget has a child, it
defers to that child for its sizing behavior. If it does not have a
child, it grows to fit the parent instead. By default a
GestureDetector with an invisible child ignores touches; this behavior
can be controlled with behavior. GestureDetector also listens for
accessibility events and maps them to the callbacks. To ignore
accessibility events, set excludeFromSemantics to true. See
flutter.dev/gestures/ for additional information. Material design
applications typically react to touches with ink splash effects. The
InkWell class implements this effect and can be used in place of a
GestureDetector for handling taps.
InkWell
A rectangular area of a Material that responds to touch. For a variant
of this widget that does not clip splashes, see InkResponse... The
InkWell widget must have a Material widget as an ancestor. The
Material widget is where the ink reactions are actually painted. This
matches the material design premise wherein the Material is what is
actually reacting to touches by spreading ink.
Well, technically you are right, they can both react to a click event. But a RaisedButton will have all the styles specific to the target platform taken care of for you (it inherits from MaterialButton).
note that it's the same in html: you can use a regular div with a click handler or use a button tag. The button will have a few styles already taken care of for you...
I have an app that uses a BottomNavigationBar to switch between two screens with their own navigation stack. I would like to use the Hero tag to create a custom transition between the two, but since I don't use navigation, but rather change the state to switch between screens, I'm not sure if this is possible at all.
Is there any way to recreate the transitions provided by Hero without using Navigator?
The Hero widget is not what you are looking for. Try the animations package made by the flutter team. Here the link to this package.
Is not easy to use, but get a try, or you can use the default Navigation built in.
I want users to scroll between pages in PageView, but I don't want to show them an animation when they try to scroll before first and after last page. I can switch between colorful animation, black animation and no scrolling, but I could not find any possibility to disable the animation at all.
If there is no such possibility, how can I change the color of that animation or make it transparent at least?
Based on your screenshot, I can say that you are using BouncingScrollPhysics for your PageView. This behavior is commonly used by iOS devices. Nonetheless, I have also reviewed the entire source code you have provided here.
What went wrong
You have added PageView without accompanying it with a Scaffold or Material widget at the top level that's why the background behind the children of the PageView is color black.
https://dartpad.dev/c709e410d0a68248ac5b387b3bc6af93
From the documentation:
Scaffold implements the basic material design visual layout structure.
Without this widget, you'll notice that your app may occupy the entire screen of your device, including the notification bar, because it (PageView) does not know where is the status bar is located in the screen.
What you can do
I noticed that all of the children added inside the PageView has individual Scaffold and AppBar, it's not really necessary to nest scaffolds and you may want to use TabBarView instead of PageView, and let the parent widget handle the AppBar changes via TabController.
But if you think it'll cost you too much effort to refactor, feel free to review the following options that require minimal changes which will suit your needs:
Option 1. You can wrap your widget inside a Scaffold widget.
https://dartpad.dev/4620ff91444353f5e000d2063594bd96
Option 2. Given that nesting Scaffold widgets is not a good practice, you can just use the plain Material widget to wrap your PageView with children wrapped with Scaffold widget.
https://dartpad.dev/43f8730e5592ce1f96193fc01f08a29c
These solutions will change the background color of the PageView from black to white.
Option 3. If you really want to get rid of the animation, the easiest way to hack it is changing your scroll physics:
physics: ClampingScrollPhysics(),
However, this still has a glowing or ripple effect when you try to swipe at the end of the screen.
To further get rid of this effect, I'll share with you these SO answers:
How to remove scroll glow? (works for Android)
How to remove overscroll on ios? (works for iOS)
Further reading
https://api.flutter.dev/flutter/widgets/ScrollPhysics-class.html
https://medium.com/flutter-community/custom-scroll-physics-in-flutter-3224dd9e9b41