Question for Flutter users.
I have a class which holds a number of static values regarding a project. These values need to be accessible in various widgets.
Is it more efficient to create one instance of that class in the main.dart file, and pass it's pointer through to all the widgets that need it, or should each widget create it's own instance of the class? Given that the parameters within the class will never change.
I suspect both is fine (especially when there are only 20 or so parameters), but I want to select the more efficient approach.
Related
I have a big project and manage a lot of data with firebase. For this I have a class "MyFirestoreDatabase" in which I have every single firebase function, which I then call from my providers.
The problem is, that the MyFirestoreDatabase class has gotten really really big and I would want to split it up into sub classes and different files.
Every time I call a firebase function I use MyFirestoreDatabase.instance.functionName(),
so I don't think I want different classes, because then I would have multiple instances of the database open at the same time right?
Would it work to extend the class?
Calling FirebaseFirestore.instance always returns the same (default) instance, no matter how many times you call it. This is the essence of the singleton pattern.
So calling it in each separate class won't make any change in resource consumption, nor in the number of connections to the backend servers.
Say I have an instance of a class which i need access to in many different places of my app. I have come up with three solutions so far
Passing the instance as an argument in every class of the app
Making a top level Provider above the MaterialApp-widget that exposes the instance to every method that has access to the app's context
Storing the instance in a static field
Which way is the best performance wise? Will the Flutter-framework ever discard the instance stored in the static field?
Which way is the best performance wise? Will the Flutter-framework ever discard the instance stored in the static field?
In this case, I like to use the DI framework like get_it
With the DI you can specify what is the object that you want and you can have it in your Wiget or Component, without coupled it with the specific implementation.
Use the get started guide to see how it is simple to use and what are the benefits.
Get Started
Suggestion
I suggest wrapping the library in one component inside your app, with the only motivation that with your own wrapper around the DI library you avoid to coupled all the app with the get_it, and you can change it easily in the future if you want.
Not sure about the performance, but the second option (Provider way) is what I am using in my projects and that's even a recommended approach (https://flutter.dev/docs/development/data-and-backend/state-mgmt/options#provider).
Passing the instance as an argument in every class of the app
This could lead to a very cumbersome code, every constructor would be cluttered by the same property passing all the way down to the Widget tree - not a Flutter way at all, that's why InheritedWidget was introduced some time ago, and later - Provider.
Storing the instance in a static field
It depends. E.g. it is ok to store all the colour constants inside a class having static fields - that's just convenient to access them everywhere. This option could also work in your case (not sure about the size and the amount of information stored in that class instance), but implementing your class as a Singleton would probably make more sense than storing the whole instance in a static field.
I am new to Flutter. As of now when I pass data between Stateful Classes the data becomes immutable for the receiving class. This should help be re-render widgets in both classes whenever ever one class updates the data.
How does inheritance work in flutter so that I can make data mutable between classes ? Can someone explain this with a sample code example.
I currently have 5 ViewPart-s which show similar data but in various ways, using jit visualisation. I want to combine them into one class with parameters.
From my IPerspectiveFactory I'm adding these selectively, e.g. just first 2 views.
My question is, how can I instantiate the same view with different parameters(like parametrized constructor). Later I'll be adding them with secondary id..
There is no way to pass parameters to a view.
I would suggest using a base class containing most of the common view code and then a class derived from that for each of the different views.
What is a good way to design a class? I'm trying to create a simple chat program. I want everything the objects in the screen use to be encapsulated. I've created a few classes, a logging class, a message pile class (for holding the messages which have been received and sent), a textbox class, and a button class. I want the message pile, the textbox, and the button to share the same string variable, except I want it encapsulated within the classes.
I did try creating a Base class. This would hold all the data and functions common to the textbox and button classes. Those three classes would derive from Base to use its shared variable. Only when I did this the variable was not shared. Is there a way to do this? Kind of like a global variable? Only within its own class and its derived ones? Both objects of the two derived classes should be able to access the Base class object's variables.
You are mixing up classes and objects. When you have a base class with some member variable then all derived classes can (potentially) access the member variable in the base class.
However when you instantiate the different derived classes, or one of them multiple times, then each object has a complete independent set of member variables, including the ones from the base class, because that's exactly what an object is.
If you want certain groups of objects to use the same "shared" variables then you could stick these shared things into a dedicated "shared" class. Then for each group of objecst that need to share these "variables", you create an instance of this "shared" class, and pass it to all of the objects in the group.
This is also more flexible than fiddling around with "static" class members, or whatever they are called in the language you are using, because you can have multiple of these "groups" of objects by having multiple "shared" objects and deciding exactly which "actual" objects share the same "shared" data/variables.
Without knowing more about what's going on it's hard to give any more recommendations on how to design the class and object hierarchy.