I have a main widget that nest home page widget and setting page widget. inside setting, will have a nest pageView widget
main:
home
setting
pageView
I have a main_bloc to house some interactive data selected_page_index, to set the initialPage of the pageView when navigate to the setting page. Below are my code for the setting page:
class _SettingPageState extends State<SettingPage> {
MainBloc _mainBloc;
PageController facilityBookingPageviewController;
#override
void initState() {
super.initState();
_mainBloc = BlocProvider.of<MainBloc>(context);
print(_mainBloc.selected_page_index); ///<-- this give me the correct value
facilityBookingPageviewController = PageController(
initialPage: _mainBloc.selected_page_index,
);
}
I can print() out the correct value in the initState(), but somehow the initialPage will only get the _mainBloc.selected_page_index original preset value.
I believe I done something wrong in terms of timing. How to properly do this?
The controller.currentPage returns a double value. For example, when the page is being swiped the value goes from 1 to 2 gradually and does not instantly jump to 2. If use it jump second page directly. currentPage could use instead of initialPage if your _mainBloc.selected_page_index value is a double. Try this and let me know if it is worked for you
Related
Is there a way to navigate from one dart "page" to a specific point in another? This will get me to a given page
Navigator.push(
context,
MaterialPageRoute(builder: (context) => WK3()),
);
But I want to navigate to a specific child or row within that page (which are unfortunately fairly long, and would otherwise require a lot of scrolling).
I am used to working with html, where you just have to indicate a position within a page using a hash tag:
#here
That should be possible to do in Flutter/Dart, right?
This is not possible by just using the flutter Navigator. What I would do to tackle that issue is that I would pass an argument which contains the scroll position to the Navigator for example:
Navigator.pushNamed(
context,
'/wk3',
arguments: {'scrollTo': elementId}, // or any other logic like half of the screen or so
);
To read more about Navigator and arguments you can check out the official documentation here. You can also do that for none named routes obviously.
Inside your target widget you could then do the following approach.
Take the argument and parse it to whatever you need.
Depending on your page and your scroll behavior you could use the initState to directly scroll to your desired location. What happens next is a bit dependend on your concrete implementation or where you want to scroll. In certain situations it might be more useful to add a postFrameCallBack for your scrolling instead of doing it in the initState. I'll add it for educational reasons in the snippet below.
Assuming we have a ScrollController of a ListView for example the widget we navigated to knows where we want it to scroll to due to our passed argument. If you use for instance a position value here and we have the ScrollController to do something like this:
controller.position.animateTo(
widget.args.scrollTo, //make sure it has the correct type
duration: const Duration(seconds: 1),
curve: Curves.easeInOut,
);
There are also ways you could scroll to a certain element in a list or a column (like for example the 100th element). Check this question for more information. You can find a slight implentation with a scroll controller below:
class ScreenArguments {
final String scrollTo;
ScreenArguments(this.scrollTo);
}
class Screen extends StatefulWidget {
final ScreenArguments args;
Screen(this.args, {Key key}) : super(key: key);
#override
ScreenState createState() => ScreenState();
}
class ScreenState extends State<Screen> {
#override
void initState() {
scrollMeTo = widget.args.scrollTo;
scrollController = ScrollController();
WidgetsBinding.instance
.addPostFrameCallback((_) => scrollTo(context)); // this is probably safer than doing scrollTo(context) directly in your initState
enter code here
// if you do not use addPostFrameCallback you can call scrollTo(context) directly.
//scrollTo could use scrollControler.animateTo() etc.
}
I dont have ScrollController / ListView implementation
If thats not the case and you do not have a ScrollController and you want just to scroll to any element on your widget things get a little bit more complicated. In that case I'd recommened you to use flutters Scrollable.ensureVisible. Taken from the documentation it does the following:
Scrolls the scrollables that enclose the given context so as to make
the given context visible.
Lets assume you have Column inside a SingleChildScrollView to have a foundation for your scrolling behavior. You would then define a GlobalKey for each section of your widget you would like to scroll to. This key would be the identifier which we pass in as an argument. Assuming we have a GlobalKey in the widget which is called second we could do the following:
Scrollable.ensureVisible(
GlobalObjectKey(widget.args.scrollTo).currentContext, //this would reference second
alignment: 0.5, //
duration: Duration(seconds: 2),
curve: Curves.easeInOut);
You can read more about Scrollable.ensureVisible here.
What approach to take is dependended on your needs and on your implementation.
A class Object passing from First Screen to the second Screen While on the second screen when the object changed its value, it's also changing the value on first screen.
Code of First Screen. (widget.templateModel is an object class that i am passing to the second screen)
Navigator.push(context,MaterialPageRoute(builder: (context) =>
EditEmojiTextTemplateScreen(templateModel: widget.templateModel,));
Code of Second Screen (On the second screen i am receiving the object and when i am changing the value of widget.templateModel it also changing the value on the first screen for a simple understandable code below i changed the value in initState while in the gif i am changing value in TextFormField)
class EditEmojiTextTemplateScreen extends StatefulWidget {
final TemplateModel templateModel;
EditEmojiTextTemplateScreen({
Key? key,
required this.templateModel,
}) : super(key: key);
#override
State<EditEmojiTextTemplateScreen> createState() =>
_EditEmojiTextTemplateScreenState();
}
class _EditEmojiTextTemplateScreenState
extends State<EditEmojiTextTemplateScreen> {
final SharedPreferences sharedPreferences = sl();
var txtNameController = TextEditingController();
var txtColorController = TextEditingController();
_EditEmojiTextTemplateScreenState();
#override
void initState() {
widget.templateModel.emoji[0].titleTwo = "kdfff"; //here i am changing the value and it also changing the value on first screen and i dont want this behavior of this object
super.initState();
}
Note: This is happening because of widget variable as mentioned in the documentation but i don't know how to prevent this behavior.
package:flutter/src/widgets/framework.dart
The current configuration.
A [State] object's configuration is the corresponding [StatefulWidget]
instance. This property is initialized by the framework before calling
[initState]. If the parent updates this location in the tree to a new
widget with the same [runtimeType] and [Widget.key] as the current
configuration, the framework will update this property to refer to the
new widget and then call [didUpdateWidget], passing the old
configuration as an argument.
Now I see what you are trying to do.
You could initialize a NEW istance of TemplateModel in the InitState of the second screen.
Then, set the new object's properties like this (or write a cleaner method to do that):
newObject.property1 = oldObject.property1;
newObject.property2 = oldObject.property2;
...
Once the user presses the save button, change oldObject's properties again, so that the first page updates.
You might want to take a look at state management to better understand how to approach this kind of problems.
As the other answer suggests, take a look at state management solutions.
Also keep the models immutable by creating them with final fields. Then to modify, create new instances via copyWith()
Please update you code after navigation.then method
template = snapshot.data;
Problem: CupertinoTabScaffold tab content does not refresh after closing new screen from CupertinoPageRoute
App:
There is a list of data in a Listview.
I open one data set and remove the favourite status (checked=false).
I close the data set and the listview should refresh (FutureBuilder to an SQL database).
Details:
I've got a Flutter App with two layouts (Material and Cupertino).
In each layout i have four tabs and the content widgets are the same.
On the Cupertino App every tab consists of a CupertinoPageScaffold.
When i press on an element it navigates to a new screen with CupertinoPageRoute.
After closing the CupertinoPageRoute the tab content is not refreshing.
The tab content is refreshing when i switch between the four tabs.
If one CupertinoPageRoute is open and i open a new one from here and close it again
then the content of the opened CupertinoPageScaffold is refreshing.
The data is refreshing without a callback etc., just by calling the future (i think).
Means there should be a problem with the CupertinoTabScaffold.
There is no problem on the Material App.
The tab contents of the Material App are refreshing when closing a MaterialPageRoute.
Question:
Is there a problem at this position?
Do you have the same issue or maybe a solution or workaround?
Code:
My code is not really representative so i will create a new clean project for you.
please confirm if code is necessary.
What i tried:
I tried a lot of solutions from the internet like callbacks, setState, .then, .whencomplete for the route.
nothing seems to work.
Thank you in advance.
EDIT 03.10.2021: the tabcontroller with SingleTickerProviderStateMixin reloads the open tab when i open or close an new screen. if i just use DefaultTabController Widget than it doesn't. So i have to edit the CupertinoTabController.
class _MyHomePageState extends State<MyHomePage> with SingleTickerProviderStateMixin {
late TabController _tabController;
final CupertinoTabController _cuptabController = CupertinoTabController();
Future<void> _refreshdata() async {
downloadJSON1();
setState(() {
});
}
callback() {
_refreshdata();
}
#override
void initState() {
_refreshdata();
super.initState();
_tabController = TabController(vsync: this, length: 2, initialIndex: 0);
_cuptabController.index = widget.starttab;
}
#override
void dispose() {
_tabController.dispose();
super.dispose();
}
...
}
I can suggest a few options:
Option 1:
change your FutureBuilder into a StreamBuilder.
FutureBuilder does not refresh automatically when you save the data which StreamBuilder does very well.
Option 2:
Use a setState but not on the context of the route you are closing, but rather on the context of the original page you want to refreh
setState(() { });
for the moment i solved it with a .then-callback from PageRoute. i just passed the callback to the deepest Widget/PageRoute. But if you have a solution/idea for the tabcontroller would be great.
Souce:
how to refresh state on Navigator.Pop or Push in flutter
Navigator.push(context,
CupertinoPageRoute(
builder: (BuildContext context) => MyWidget(
'myparameters'),),).then((value) => setState(() {callback();}));
I am working on a location based app and in the settings page I have an option the allows users to change their location radius using the slider package. Such that when the slider is moved, more or less content gets shown in the home screen.
I tried sending the data using setstate but it seems not to be working for integer values
Am encountering the following problems
1.When the slider is moved, the changes dont reflect on the home page, I know this since ive inserted a text widget in the home screen to display the slider value.
2.On the settings page where the slider is, whenever I slide it, it updates but when I navigate to another screen then back to the settings screen, the slider resets to the minimum value.
How can I solve the above problems?
Here is my slider code on the settings page
Slider(
value: radius,
onChanged: (newRadius) async{
setState(() {
tasks = newRadius.toDouble();
String step2 = radius.toStringAsFixed(2);
twodecimalradius = double.parse(step2); //converting the slider value to 2 decimal places
});
print(twodecimalradius);
await Home(twodecimalradius:twodecimalradius); //passing the slider value to homepage
await Home.staticGlobalKey.currentState.getposts();//a function in the homepage that gets called whenever the slider value is changed
},
min: 10.0,
max: 500.0,
//activeColor: Colors.red[400],
)
And in my homepage this is the code that is supposed to display the slider value in a text widget
class Home extends StatefulWidget {
var twodecimalradius;
static final GlobalKey<_HomeState> staticGlobalKey =
new GlobalKey<_HomeState>();
Home({
this.twodecimalradius,
}): super(key: Home.staticGlobalKey);
Widget build(BuildContext context) {
return Scaffold(body:Text(widget.twodecimalradius))
}
I have a screen, which contains a Form with a StreamBuilder. when I load initial data from StreamBuilder, TextFormField show data as expected.
When I tap inside the TextFormField, the software keyboard shows up, which causes the widgets to rebuild. The same happens again when the keyboard goes down again.
Unfortunately, the StreamBuilder is subscribed again and the text box values is replaced with the initial value.
Here is my code:
#override
Widget build(BuildContext context) {
return StreamBuilder(
stream: _bloc.inputObservable(),
builder: (context, snapshot) {
if (snapshot.hasData) {
return TextFormField(
// ...
);
}
return const Center(
child: CircularProgressIndicator(),
);
},
);
}
How do I solve this?
Keyboard causing rebuilds
It makes total sense and is expected that the software keyboard opening causes rebuilds. Behind the scenes, the MediaQuery is updated with view insets. These MediaQueryData.viewInsets make sure that your UI knows about the keyboard obscuring it. Abstractly, the keyboard obscuring a screen causes a change to the window and most of the time to your UI, which requires changes to the UI - a rebuild.
I can make the confident guess that you are using a Scaffold in your Flutter application. Like many other framework widgets, the Scaffold widgets depends (see InheritedWidget) on the MediaQuery (that gets its data from the Window containing your app) using MediaQuery.of(context).
See MediaQueryData for more information.
It all boils down to the Scaffold having a dependency on the view insets. This allows it to resize when these view insets change. Basically, when the keyboard is opened, the view insets update, which allows the scaffold to shrink at the bottom, removing the obscured space.
Long story short, the scaffold adapting to the adjusted view insets requires the scaffold UI to rebuild. And since your widgets are necessarily children of the scaffold (likely the body), your widgets are also rebuilt when that happens.
You can disable the view insets resizing behavior using Scaffold.resizeToAvoidBottomInset. However, this will not necessarily stop the rebuilds as there might still be a dependency on the MediaQuery. I will explain how you should really think about the problem in the following.
Idempotent build methods
You should always build your Flutter widgets in a way where your build methods are idempotent.
The paradigm is that a build call could happen at any point in time, up to 60 times per second (or more if on a higher refresh rate).
What I mean by idempotent build calls is that when nothing about your widget configuration (in the case of StatelessWidgets) or nothing about your state (in the case of StatefulWidgets) changes, the resulting widget tree should be strictly the same. Thus, you do not want to handle any state in build - its only responsibility should be representing the current configuration or state.
The software keyboard opening causing rebuilds is simply a good example for why this is so. Other examples are rotating the device, resizing on web, but it can really be anything as your widget tree starts to get complex (more on that below).
StreamBuilder resubscribing on rebuild
To come back to the original question: in this case, your problem is that you are approaching the StreamBuilder incorrectly. You should not feed it a stream that is recreated each build.
The way stream builders work is by subscribing to the initial stream and then resubscribing whenever the stream is updated. This means that when the stream property of the StreamBuilder widget is different between two build calls, the stream builder will unsubscribe from the first and subscribe to the second (new) stream.
You can see this in the _StreamBuilderBaseState.didUpdateWidget implementation:
if (oldWidget.stream != widget.stream) {
if (_subscription != null) {
_unsubscribe();
_summary = widget.afterDisconnected(_summary);
}
_subscribe();
}
The obvious solution here is that you will want to supply the same stream between different build calls when you do not want to resubscribe. This goes back to idempotent build calls!
A StreamController for example will always return the same stream, which means that it is safe to use stream: streamController.stream in your StreamBuilder. Basically, all controller, behavior subject, etc. implementations should behave this way - as long as you are not recreating your stream, StreamBuilder will properly take care of it!
The faulty function in your case is therefore _bloc.inputObservable(), which creates a new stream each time instead of returning the same one.
Notes
Note that I said that build calls can happen "at any point in time". In reality, you can (technically) control exactly when every build happens in your app. However, a normal app will be so complex that you cannot possibly have control over that, hence, you will want to have idempotent build calls.
The keyboard causing rebuilds is a good example for this.
If you think about it on a high level, this is exactly what you want - the framework and its widget (or widgets that you create) take care of responding to outside changes and rebuilding whenever necessary. Your leaf widgets in the tree should not care about whether a rebuild happens - they should be fine being placed in any environment and the framework takes care of reacting to changes to that environment by rebuilding correspondently.
I hope that I was able to clear this up for you :)
I faced a similar issue in my application. What resolved my issue was to make my "widget tree clean" as suggested by one of the programmers on this forum.
Try moving the definition of your stream to init state. This will prevent your stream from disconnecting and reconnecting every time there is a rebuild.
var datastream;
#override
void initState() {
dataStream = _bloc.inputObservable();
super.initState();
}
#override
Widget build(BuildContext context) {
return StreamBuilder(
stream: dataStream,
builder: (context, snapshot) {
if (snapshot.hasData) {
return TextFormField(
// ...
);
}
return const Center(
child: CircularProgressIndicator(),
);
},
);
}
It can be resolved by creating a stateful widget like following
class StatefulWrapper extends StatefulWidget {
final Function onInit;
final Widget child;
const StatefulWrapper({#required this.onInit, #required this.child});
#override
_StatefulWrapperState createState() => _StatefulWrapperState();
}
class _StatefulWrapperState extends State<StatefulWrapper> {
#override
void initState() {
if (widget.onInit.call != null) {
widget.onInit();
}
super.initState();
}
#override
Widget build(BuildContext context) {
return widget.child;
}
}
and wrapping the stateless widget using the wrapper
Widget body;
class WidgetStateless extends StatelessWidget {
WidgetStateless();
#override
Widget build(BuildContext context) {
return StatefulWrapper(
onInit: () async {
//Create the body widget in the onInit
body = Container();
},
child : body
)
}