I am pretty new to Flutter / Dart and right now, I have a problem. I have a homepage in my App and it displays an AppBar, a BottomNavigationBar and a body. The body is a simple card with content in it. The problem is: I need to be able to display three different cards, depending on the status I get from a server.
So there is the ActiveCard, the InactiveCard and the ErrorCard. The ErrorCard has a Button to go back to the InactiveCard and the ActiveCard as well as the InactiveCard should be wrapped in an Inkwell or similar to start a ride for example.
Now I am wondering: I am not sure how to implement all this. Can I just create three Stateless Widgets for each Card and depending on the server status just "replace" or "change" the body in my homepage? And where can I "control" the current status? Like I said, the Cards need to be clickable and "erase" themselves to make space for the following card (e.g: InactiveTrip gets clicked, now there should be the Card for ActiveTrip, because I started my trip and the user should see that my trip is currently active)
I cant provide code really, because so far I have not really something with will be even close to the result I expect.
Maybe you have some tips and packages I can use.
You can convert the statelessWidget to statefulWidget ans use setState() method.This is
recommended for small application but if your apps have more complexity then you have learn the state Management like provider,bloc pattern or Mvvm architechture.
yes, you can use statelessWidget for this purpose.
and you can use bloc pattern
to manage the page state.
I will use stateless for page and stream for the card content:
//Card model is your data modal
StreamController<Card> _streamController = StreamController();
Card _currentCard = /* default inactivate */;
StreamBuilder<bool>(
stream: _streamController.stream,
initialData: _currentCard,
builder: (BuildContext context, AsyncSnapshot<Card> snapshot) {
//return Container(/*content of your card*/);
},
),
//Everytime you need to change the card content, you sink the new value
_streamController.sink.add(_currentCard = /*new card data modal*/);
Related
Here is the problem: I have a list of items displayed in a list view. I can edit these items with the dialogs displayed by clicking on them. After editing and closing the dialog, I also need to update the items on the list view. I'm currently doing this with the following code snippet in my list view item widget:
showDialog(
context: context,
builder: (context) {
return UpdateItemDialog(item: _item);
},
).then((updatedItem) {
if (updatedItem != null) {
setState(() => _item = updatedItem);
}
});
and by calling Navigator.of(context).pop(_item); from my dialog.
It works perfectly fine when there are no rebuilds occur until the dialog is dismissed. However, for example, if the orientation is changed when the dialog is open, I get Unhandled Exception: setState() called after dispose() error since the list view also rebuilt because of the orientation change and the then clause in my code runs on the destroyed widget.
Is there a way to access the rebuilt widget from a destroyed widget?
Or should I use a different approach to this problem?
By the way, changes should only be accepted after the dialog is dismissed, so I should return the item from the dialog.
I believe your best bet would be to introduce even a simple state management solution (Provider would be good) to handle communication between a dialog and other widgets.
Check out the Gist below (Run it on Dartpad.dev) as an example how you can keep it simple, yet clean and decoupled
https://gist.github.com/romanejaquez/8aed8d699fba8fdfff4b0966dfe47663
in which I show that instead of passing data from a dialog back to another widget, a State Management solution would allow you for a decoupled way of passing data back and forth, notifying each other and triggering rebuilds (which is kind of calling setState() since pretty much that's what you want - trigger a rebuild on the other widget. In this example, I'm sending a value back to the originating widget and triggering a rebuild (thanks to the Consumer widget listening to the changes triggered in the common service. That'd be my honest suggestion.
I have a typical CRUD operation task: (List Sites, Add Site, ...)
I created a SitesProvider. In the same provider, I added 2 methods for add and edit. I was thinking to use the same provider in the 2 screens (ListSites and AddEditSite)
In the ListSites screen, it works fine. Here is the problem:
I open the AddSite screen by clicking the AddButton in the ListSites screen
Hit submit (did not enter data, simulating error case)
The error gets displayed in the ListSites screen, not in the AddSite screen.
It makes sense. They both use the same provider, both screens are on the stack. It seems that the first one only consumes the state update and displays the error.
I use MultipleProviders approach that wraps the MaterialApp with all providers in the app.
Can we fix that without creating separate providers for each of the 2 screens?
EDIT:
I used provider.removeListener in the ListSites screen right before I open the AddEdit and it shows the error in the correct screen now. I still have to do some other tweaks to get it back to listen after I add. Not efficient I think but it is a step.
I ended up doing that:
Added Another Field in the provider (stateType: list/addedit)
Change the type per the screen I'm currently in
provider.stateType = UIStateType.add_edit;
await Navigator.push(context,
MaterialPageRoute(builder: (context) => AddEditSiteScreen()));
provider.stateType = UIStateType.list;
in build(), I check for the type
sitesProvider = Provider.of(context);
if (sitesProvider.stateType != UIStateType.add_edit) return Container();
I am writing an app that is making use of Cubits for state management. It is an audiobook player and you can look up the different audiobooks and display them. Then jump to the author or the series and explore around your library.
As it stands at the moment the different pages you move between are being rendered using a BLoC builder as follows.
class ScreenSelector extends StatelessWidget {
#override
Widget build(BuildContext context) {
return BlocBuilder<ScreenCubit, ScreenState>(builder: (context, state) {
if (state is HomeScreenState) {
return HomeScreen();
}
if (state is BookScreenState) {
return BookScreen(bookId: state.bookId);
}
return null;
});
}
}
There are genre, author and series screens as well that will work the same as the book screen. There is a cubit that is emitting the appropriate state hooked up to different clickable widgets on the home and book page. This all works as expected. There is also an authorization flow that is worked to either render the HomeScreen or go to the Loginscreen. This also works nicely.
But i'd like to use a navigator instead so you can go backwards to previous pages. That seems like the right way to navigate but i'm lost on getting Navigator to work with BLoC.
I tried constructing the MaterialPageRoutes and pushing them when the state changes instead of loading the page and I tried converting the BlocBuilder to a BlocListener. Trying to push the page in the BlocBuilder did nothing and the BlocListener would only ever throw an exception.
If anybody has a pointer to how I might go about doing this or knows of a simple example of using Cubits with Navigator 1.0 in flutter I would be most grateful. I looked around but all of the examples I found either mixed in an authorization example and I got lost.
I expect i'm approaching the problem incorrectly but i'm not sure where I have gone off track.
Turns out I just have really crappy GoogleFu and you can find the solution to the problem at
https://bloclibrary.dev/#/recipesflutternavigation
It has a nice recipe that explains it well by the author of Bloc
I know there have been certain questions on state management in flutter, but none of them seemed to solve my use case.
Recently I was building an app based on E-commerce and encountered this real need for state management.
I had 2 pages,
One is the products page, where I add a product to the cart.
Second is the cart page, where I see products added recently to cart.
Users can add the product to the cart and then navigate to the cart. In the cart page, they can also increase or decrease the quantity of the item.
As you can see, initially yellow item was added to the cart with quantity 3, but in the cart page, user pressed the (-) button and reduced the quantity to 1. Now if the user presses the back button, then the state of the yellow product will be still 3 on the products page. Similar situation with the pink product.
Hence I tried to resolve this using normal setState and some global data structures to keep track of the quantity. But as my app grew big, its really hard to maintain the state across the pages.
I have read about different state management solutions like redux, BloC pattern, Provider, ... but I am not clear how to use any of them in my use case.
Could anyone with experience, break down the rock and help me digest?
Any sample code and explanation about how to solve this would be appreciated!
Hope my problem is clear!
ANUP SAJJAN to achieve this you can use Provider package. See these codes examples according to your case:
import 'package:flutter/material.dart';
import 'models/cartmodel.dart';
class AppState with ChangeNotifier {
List<CartModel> _cartModel = new List<CartModel>();
// Cart data list
List<CartModel> get getCart => _cartModel;
// Add item to cart
addToCart(CartModel value) {
_cartModel.add(value);
notifyListeners();
}
// Remove item to cart
removeToCart(CartModel value) {
_cartModel.remove(value);
notifyListeners();
}
}
Create an instance in main.dart:
runApp(
ChangeNotifierProvider<AppState>(
create: (_) => AppState(),
child: MyApp(),
),
)
You can now control the state :
#override
Widget build(BuildContext context) {
final appState = Provider.of<AppState>(context);
...
// manipulation
appState.getCart
appState.addToCart(value)
appState.removeToCart(value)
...
}
The state is really a vehicle to control state of one screen, not a data storage. You probably shouldn't use State in this case, but rather a database. When a user is composing their cart, you create a cart record either on the user's device SQLite, or in the cloud (Firebase?). This may seem as an overkill at first, but consider that besides having a persistent storage that you can access from anywhere, you also get user behaviour data, i.e. what they added, how they proceeded, and how many dropped off.
As for the technical side of this, in Flutter it is common to use Providers. For me, the biggest benefit is business logic encapsulation. If you don't, your specific database logic will be all over the presentation layer, and should you want to change something, you will be in trouble :)
Here is a good article regarding providers.
I am developing a mobile application using Flutter. I am new to Flutter. I am using BLoC for state management. I know that it is specially designed for management async execution. But also the purpose of BLoC is for state management. But I am a little bit confused and not quite sure how to handle the primary data types in BLoC.
Let's imaging the I have a button and an image. The functionality would be that when the button is clicked, the visibility of the image will be toggled. Literally, we just need to use a boolean variable to manage the state of the image. This is how I would implement it.
I have a bloc class called HomeBloc with the following implementation.
class HomeBloc {
bool _isImageDisplayed = true;
bool get isImageDisplayed => _isImageDisplayed;
void set isImageDisplayed(bool displayed) {
this._isImageDisplayed = displayed;
}
//the rest of the code for other functionalities goes here
}
final homeBloc = HomeBloc();
Then in the HomePage widget, I update the state of the image like this inside the setState method when the button is clicked.
this.setState(() {
homeBloc.isImageDisplayed = false;
});
My question is that "is it the standard way to manage primary data type in the BLoC in Flutter"? Is this the best practice? Do we need to use StreamBuilder? Do we even need to manage it inside the BLoC?
It's not the best practice I guess, as using setState becomes really hard on big applications and re-rendering widgets that don't change for no reason. Imagine making an e-commerce app and you just go to the product page, you add the product you like into the cart, but you have designed in your home page a cart icon with a red dot with a number inside it to specify how much products you got in your cart, so you handle the state of that icon in the main.dart file by passing a function that setState the home page route or maybe the whole application, it's hard, isn't it?.
Thankfully, BLoC and Provider patterns are basically using setState but in a better way so you don't have to re-render the whole page just for a small change in a text or something else, but you just re-render a specific widget in your widget tree.
I also recommend using BLoC Provider which is built on Provider and RxDart (Streams) as it makes great isolation between UI code and business code.
Check Provider and BLoC Provider.