Flutter clean architecture with Bloc, RxDart and StreamBuilder, Stateless vs Stateful and dispose - flutter

I'm trying to implement a clean architecture with no dependency of the framework in the business' logic layers.
The following example is a Screen with only a Text. I make an API Rest call in the repository and add the response to a BehaviorSubject that is listened through a StreamBuilder that will update the Text. Since is an StatefulWidget I'm using the dispose method to close the BehaviorSubject's StreamController.
The example is simplified, no error/loading state handling, no dependency injection, base classes, dispose interfaces etc.
class Bloc {
final UserReposiotry _userReposiotry;
final BehaviorSubject<int> _activeUsersCount = BehaviorSubject.seeded(0);
Bloc(this._userReposiotry) {
_getActiveUsersCount();
}
void _getActiveUsersCount() async {
final response = await _userReposiotry.getActiveUsersCount();
_activeUsersCount.add(response.data);
}
ValueStream<int> get activeUsersCount => _activeUsersCount.stream;
void dispose() async {
await _activeUsersCount.drain(0);
_activeUsersCount.close();
}
}
class StatefulScreen extends StatefulWidget {
final Bloc bloc;
const StatefulScreen({Key? key, required this.bloc}) : super(key: key);
#override
State<StatefulScreen> createState() => _StatefulScreenState();
}
class _StatefulScreenState extends State<StatefulScreen> {
#override
Widget build(BuildContext context) {
final stream = widget.bloc.activeUsersCount;
return StreamBuilder<int>(
stream: stream,
initialData: stream.value,
builder: (context, snapshot) {
return Text(snapshot.data.toString());
}
);
}
#override
void dispose() {
widget.bloc.dispose();
super.dispose();
}
}
I have the following doubts regarding this approach.
StreamBuilder cancels the stream subscription automatically, but it doesn't close the StreamController. I know that you should close it if you are reading a file, but in this case, if I don't manually close it, once the StatefulScreen is no longer in the navigation stack, could it be destroyed, or it would be a memory leak?
I've seen a lot of people using StatelessWidget instead of StatefulWidget using Stream and StreamBuilder approach, if it is really needed to close the BehaviorSubject it is a problem since we don't have the dispose method, I found about the WillPopScope but it won't fire in all navigation cases and also and more important would it be more performant an approach like WillPopScope, or having an StatefulWidget wrapper (BlocProvider) inside an StatelessWidget just to do the dispose, than using an StatefulWidget directly, and if so could you point to an example of that implementation?
I'm currently choosing StatefulWidget for widgets that have animations o controllers (map, text input, pageview...) or streams that I need to close, the rest StatelessWidget, is this correct or am I missing something?
About the drain method, I'm using it because I've encountered an error navigating back while an API rest call was on progress, I found a member of the RxDart team saying it isn't really necessary to call drain so I'm confused about this too..., the error:
You cannot close the subject while items are being added from addStream
Thanks for your time.

Related

How do you initialise a provider with data taken from shared preferences?

I am new to flutter and dart so the answer to this may be simple, or I may be going about this COMPLETELY the wrong way.
I basically want to use Provider for state management, and Shared Preferences for local storage.
I have a class called 'ResolutionsProvider' which contains a list of custom 'Resolution' objects
which are used throughout my app. It contains methods for adding and removing Resolutions and it all works fine.
The problem is that I want the data to be persistent if the user restarts the app...
I'm trying to use SharedPreferences for this so I have methods within 'ResolutionsProvider' to save data to, and load data from Shared Preferences...
I know through print calls that the data is saving to shared preferences correctly...
My (potentially wrong) thinking is that I need to achieve the following...
App is run
ResolutionsProvider is instantiated as a ChangeNotifierProvider
ResolutionsProvider.loadData() is run to populate List from SharedPreferences...
I've tried to call ResolutionsProvider.loadData() from within an initState but I get the following error...
E/flutter (30660): [ERROR:flutter/lib/ui/ui_dart_state.cc(209)] Unhandled Exception: dependOnInheritedWidgetOfExactType<_InheritedProviderScope<ResolutionsProvider?>>() or dependOnInheritedElement() was called before _AppState.initState() completed.
E/flutter (30660): When an inherited widget changes, for example if the value of Theme.of() changes, its dependent widgets are rebuilt. If the dependent widget's reference to the inherited widget is in a constructor or an initState() method, then the rebuilt dependent widget will not reflect the changes in the inherited widget.
E/flutter (30660): Typically references to inherited widgets should occur in widget build() methods. Alternatively, initialization based on inherited widgets can be placed in the didChangeDependencies method, which is called after initState and whenever the dependencies change thereafter.
So i guess the question is two fold...
If my approach is correct, how do I call the 'loadData' method to populate my provider on booting the app if I can't do so within initState
If my approach is incorrect, what's the right approach to achieve my basic objective?
Here's my main.dart code
void main() async {
WidgetsFlutterBinding.ensureInitialized();
await LocalStorage.init();
runApp(
ChangeNotifierProvider(
create: (context) => ResolutionsProvider(),
child: const App(),
),
);
}
Here's the relevant code from my App.dart
class App extends StatefulWidget {
const App({Key? key}) : super(key: key);
#override
State<App> createState() => _AppState();
}
class _AppState extends State<App> {
#override
void initState() {
loadData();
print("app initialised");
super.initState();
}
void loadData() async {
await Provider.of<ResolutionsProvider>(context).loadResolutions();
}
#override
Widget build(BuildContext context) {
return MaterialApp(blah blah blah);
Here's the relevant parts of my ResolutionProvider.dart
class ResolutionsProvider extends ChangeNotifier {
List<Resolution> resolutions = [];
// Interfacing with Shared Preferences
loadResolutions() async {
resolutions = await LocalStorage.getResolutions();
print('${resolutions.length} resolutions loaded');
// notifyListeners();
}
saveResolutions() async {
LocalStorage.saveResolutions(resolutions);
}

Flutter: Provider and how to update records from the DB in the background

I am new to Flutter and I have this simple use case: in my Cloud Firestore DB I have a list of JSON representing events. I want to show them through my Flutter app in a ListView.
My requirements is that the ListView doesn't refresh in real-time but only when a pull-on refresh (implemented using RefreshIndicator) is done by the user or when the app resumes from background
I tried to implement this in 2 ways (I am using provider package for state management):
Using StreamProvider to create a stream of records from the DB. This continuosly updates the list view (basically the widget changes while the user is looking at it and I don't want this)
Using a ChangeNotifierProvider that refers to a EventManager class which holds a List<Event>. This class has a pull method which updates its internal state. I call this method when the user does the pull-on refresh (in the onRefresh callback of RefreshIndicator).
Option 2 seems to work well however I do not know how to implement the refresh when the app resumes from background. As I said I am using provider (and therefore StatelessWidget) and apparently there is no way to bind to these events when using StatelessWidgets
Do you have any suggestions and best practices for this use case?
You need to access Flutters lifecycle methods and fire a callback when the app resumes.
You can add a stateful widget with WidgetsBindingObserver and put that somewhere in the scope of your Provider, but as a parent of whatever widget you use to display the info.
Or you can make your PullToRefresh widget stateful and do the same thing.
class LifeCycleWidget extends StatefulWidget {
#override
_LifeCycleWidgetState createState() => _LifeCycleWidgetState();
}
class _LifeCycleWidgetState extends State<LifeCycleWidget>
with WidgetsBindingObserver {
AppLifecycleState _appLifecycleState;
#override
void initState() {
super.initState();
WidgetsBinding.instance.addObserver(this);
refreshOnResume();
}
#override
void didChangeAppLifecycleState(AppLifecycleState state) {
setState(() {
_appLifecycleState = state;
});
refreshOnResume();
}
void refreshOnResume() {
if (_appLifecycleState == AppLifecycleState.resumed) {
print('resumed');
// your refresh method here
}
}
#override
Widget build(BuildContext context) {
return HomePage();
}
}
Add the following to your main method if it's not there already.
WidgetsFlutterBinding.ensureInitialized();
Another way to do it without adding a stateful widget would be with GetX. You can still keep all your Provider stuff but only use the SuperController which provides lifecycle methods. This I can't test because I don't have your Provider code but you can probably get away with creating the class below and initializing the controller somewhere within the scope of the relevant Provider widget with
Get.put(LifeCycleController());
Then call the function in the onResumed override and you can use Get.context if you need context.
class LifeCycleController extends SuperController {
#override
void onDetached() {
debugPrint('on detached');
}
#override
void onInactive() {
debugPrint('on inactive');
}
#override
void onPaused() {
debugPrint('on pause');
}
#override
void onResumed() {
// your refresh function here. Access context with Get.context
debugPrint('on resume');
}
}

How to have access Context in didChangeAppLifecycleState lifecycle hook using flutter HookWidget?

I'm trying to access context so i can read my provider but since this lifecycle hook is out side the widget tree. it's not accessible. is there a way to get access to context?
I researched a little bit and finally discussed with narcodico from the flutter bloc community, so the credits are for him.
Therefore, mixin WidgetsBindingObserver on a state class, the context is available even in the overrides like didChangeAppLifecycleState since they are part of the state class.
Also, take in consideration to move to BlocProvider above the state widget.
Example
class HomePageProvider extends StatelessWidget {
#override
Widget build(BuildContext context) {
return BlocProvider(
create: (context) => getIt<InAppPurchasesBloc>(),
child: HomePage(),
);
}
}
class HomePage extends StatefulWidget {
#override
State<StatefulWidget> createState() {
return _HomePageState();
}
}
class _HomePageState extends State<HomePage> with WidgetsBindingObserver {
...
#override
void didChangeAppLifecycleState(AppLifecycleState state) {
if (state == AppLifecycleState.resumed) {
context
.read<InAppPurchasesBloc>()
.add(const InAppPurchasesEvent.getPurchaserInfo());
}
}
...
}
I am afraid you can't access context inside didChangeAppLifecycleState.
For anyone interested, you can save your scaffold state in a global key, and access the context from its current state.
You can use useEffect function, read more:
https://pub.dev/documentation/flutter_hooks/latest/flutter_hooks/useEffect.html;
Widget build(BuildContext context) {
useEffect(() {
//what would you write in initState
},
);
You may consider using the Riverpod package instead of Provider. Riverpod is from the same author as Provider and considered the "better Provider", but with many improvements including Flutter independence, meaning it does not rely on a context to work, and you can use it almost the same way as provider.
Using Riverpod, along with Flutter Hooks, you can do something like:
// create a provider in a global context
final myProvider = Provider((ref) => myClass());
// access the provider inside your class
class MyWidget extends HookWidget{
//access the provider using a hook
final myClassProvider = useProvider(myProvider);
//... your logic
#override
Widget build (BuildContext context){/* ... build widget tree... */}
}
Consider this very useful and concise tutorial with how to use Riverpod with Flutter Hooks and StateNotifier, ChangeNotifier, etc...

Flutter firebase provider architecture

I have a stateful widget that has an animated container. Inside that animated container I have a streamProvider connected to firebase. My problem is that when I animate using setState the entire widget rebuilds and another call to firebase is made. My solution was to lift the streamProvider up and wrap the widget that's animated with that streambuilder. But that means I need to create another widget and hence more boilerplate.
I feel like what I'm doing is wrong but I'm kind of stuck because all provider resources are related to authentication...
Does anyone have any ideas how I can get around this in a clean way? and is setState the right way to trigger animations in a stateful widget?
For animating, try using AnimatedBuilder its the easiest way to animate, but I guess it won't fix your issue.
Personally I always use the Provider package, I don't know if you are doing it too.
So usually firebase provides you with a stream of data (if you are using it with cloud functions its different)
Now you could use a StreamBuilder with the Stream firebase provides you and use the data of the stream. With this version rebuilding the Widget won't lead to the app connecting to the server and fetching new data.
If you really like to use a ChangeNotifier you can use that stream inside the ChangeNotifier, listen to it and always notifying listeners of changes to occur with this implementation there won't be any unnecessary network calls either.
Some examples for the second version:
class SomeNotifier extends ChangeNotifier {
List<MyData> dataList = [];
SomeNotifier() {
Firestore.instance.collection("MyCollection").snapshots().listen((data) {
dataList = data.documents.map((doc) => MyData.fromDoc(doc));
notifyListeners();
});
}
}
class _MyWidgetState extends State<MyWidget>
with SingleTickerProviderStateMixin {
AnimationController _controller;
#override
void initState() {
_controller = AnimationController(vsync: this);
super.initState();
}
#override
Widget build(BuildContext context) {
return ChangeNotifierProvider<SomeNotifier>(
create: (context) => SomeNotifier(),
child: AnimatedBuilder(
animation: _controller,
builder: (context, child) {
var notifier = Provider.of<SomeNotifier>(context);
return Container(); //Here you can use your animated widget, it will be rebuilt to animate propperly
//It will also rebuild every time data in firebase changes
},
),
);
}
}
I hope this answers your question.

Why should didUpdateWidget be implemented for subscriptions and ChangeNotifiers?

I created a custom widget that listens to a ChangeNotifier and invokes a provided callback whenever the notifier fires. This is used for performing one-time tasks like navigation when the notifier changes.
Everything seems to work fine, but just by accident I stumbled upon the documentation of didUpdateWidget that states:
If a State's build method depends on an object that can itself change state, for example a ChangeNotifier or Stream, or some other object to which one can subscribe to receive notifications, then be sure to subscribe and unsubscribe properly in initState, didUpdateWidget, and dispose:
In initState, subscribe to the object.
In didUpdateWidget unsubscribe from the old object and subscribe to the new one if the updated widget configuration requires replacing the object.
In dispose, unsubscribe from the object.
I'm handling the first and last point for obvious reasons, but could somebody shed a light on why I also have to implement didUpdateWidget? What could go wrong if I don't?
Bonus question: I'm not using provider in my application, yet. Does it offer something like this already out of the box? I couldn't find something like this.
My widget code:
class ChangeNotifierListener<T extends ChangeNotifier> extends StatefulWidget {
final Widget child;
final T changeNotifier;
final void Function(T changeNotifier) onChanged;
ChangeNotifierListener(
{#required this.child,
#required this.changeNotifier,
#required this.onChanged});
#override
_ChangeNotifierListenerState createState() =>
_ChangeNotifierListenerState<T>();
}
class _ChangeNotifierListenerState<T extends ChangeNotifier>
extends State<ChangeNotifierListener<T>> {
VoidCallback _callback;
#override
Widget build(BuildContext context) => widget.child;
#override
void initState() {
super.initState();
_callback = () {
widget.onChanged(widget.changeNotifier);
};
widget.changeNotifier.addListener(_callback);
}
#override
void dispose() {
widget.changeNotifier.removeListener(_callback);
super.dispose();
}
}
This part of the documentation is about how it is feasible that your widget rebuilds with a different parameters.
For example, with StreamBuilder, a first build may be similar to:
StreamBuilder(
stream: Stream.value(42),
builder: ...
)
And then something changes, and StreamBuilder is rebuilt with:
StreamBuilder(
stream: Stream.value(21),
builder: ...
)
In which case, stream changed. Therefore, StreamBuilder needs to stop listening to the previous Stream and listen to the new one.
This would be done though the following didUpdateWidget:
StreamSubscription<T> subscription;
#override
void didUpdateWidget(StreamBuilder<T> oldWidget) {
super.didUpdateWidget(oldWidget);
if (widget.stream != oldWidget.stream) {
subscription?.cancel();
subscription = widget.stream?.listen(...);
}
}
The same logic applies to ChangeNotifier and any other observable object.