StateX — Story 2
The Lifecycle Events of your Flutter app
--
The Cycle Of Life
Another reason I wrote the state_extended package was that I was coming from the Android world and had grown accustomed to working with the ‘life cycle’ events that commonly occur in mobile apps. I soon discovered implementing such a means in Flutter apps involved the WidgetObserver class with the command: WidgetsBinding.instance!.addObserver(this). With this, you would then have the didChangeAppLifecycleState() function available to you. Of course, the StateX class makes working with the app’s life cycle very intuitive by including specific public functions. See the screenshot below.
Init The State
Take this package’s example app and port it into your own IDE. I’d suggest you then place some breakpoints, run the code, and witness how the StateX class allows you to now work with the app’s life cycle. The first screenshot below is that of the controller class, Controller. For demonstrational purposes, all the event handlers are implemented with the print() function. As you know, when you run a Flutter app, a State object’s initState() function is called before it displays its content. Now if it was a StateX object with accompanying controllers, you’ll discover their own initState() functions would also be called. The second screenshot below displays the means to do so. Powerful stuff.
Take A Pause
A common requirement should be the ‘pausing’ of your app’s operations when it’s deselected and or placed in the background — when another app comes into focus for example. It’s good practice to release any ‘expensive’ resources and only attain them again if and when your app regains focus and resumes its processing. The state_extended package makes all this a breeze.
The two screenshots below are again that of the controller object, Controller. In the video below, you can see the app being ‘paused’ and then quickly resumed (brought back into focus). A lot is going on in that short amount of time. Two event handlers, for example, are triggered when the app retreats to the background: inactiveLifecycleState()and pausedLifecycleState() They are fired in that order. When the app returns to the foreground, the event handler , resumedLifecycleState(),is then triggered. With this, you have a ready means to regulate your app’s resources — and you can do this from a controller object as well. Can you see how easy that makes things?!
I Like Screenshots. Tap Caption For Gists.
As always, I prefer using screenshots in my articles over gists to show concepts rather than just show code. I find them easier to work with frankly. However, you can click or tap on their captions to see the code in a gist or in Github. Tap or click on the screenshots themselves to zoom in on them for a closer look. With that, you’ll find it best to read this article about mobile development on your computer than on your phone.
No Moving Pictures, No Social Media
There will be gif files in this article demonstrating aspects of the topic at hand. However, it’s said viewing such gif files is not possible when reading this article on platforms like Instagram or Facebook. They may come out as static pictures or simply blank placeholders. Please, be aware of this and maybe read this article on medium.com or on their own app.
Let’s begin.
Function of Events
In fact, with the state_extended package, you’re now privy to a number of system events making your app that much more responsive in everyday use. All are readily accessible by the ‘State Object Controllers’ as well, and all are in the form of functions listed below. You may recognize some of them and appreciate their potential.
Access The State
The remaining functions found in the controller objects pertain to that ready access to the State object. A function so coveted by many developers using Provider and GetX — whether they realize it or not. Indeed, it’s a powerful capability.
Error Handling
Finally, there was the need for error handling. We developers are guilty of two things. We don’t do documentation, and we don’t do error handling. We spend so much time getting the app to work right, that we tend not to anticipate if and when things go wrong. You have to face the fact errors can happen — even in your precious code. This is another reason why I wrote this framework — to easily implement error handling.
One of my more popular articles, Error Handling in Flutter, dives deeper into error handling. The link is not behind a paywall and so is free for your perusal. Being such an important yet often overlooked aspect of development, it’s one I addressed early on when learning this marvelous cross-platform solution we call Flutter.
As I got to know how Flutter works. I came to appreciate the fact that each StatefulWidget in my apps was a little micro-app in itself. Following the modular approach to programming, the State object within each StatefulWidget was responsible for one particular task in most cases. In other words, these StatefulWidgets were self-contained — relying only on their own little bit of code (mostly found in their ‘new’ State Object Controller). However, if that one StatefulWidget blew up, there tended to be a cascading effect and the whole app would crash. You’re then greeted with that ‘Red Screen of Death.’
And so, another reason for the StateX class was because I felt each StatefulWidget should be able to handle its own errors. You should have the option to implement an Error Handler in any and all of your app’s State objects, and so I provided that option.
The first screenshot below is of the package’s second example app. By using the StateX class, the State object, _MyHomePageState, could implement its own error handling. The second screenshot below is that of the StateX class itself and its last defined function, onError(). If the State object, _MyHomePageState, does not override its onError(), any errors during its run will produce the good ol’ ‘Red Screen of you-know-what.’ Otherwise, you could implement its onError() function and have options. Gotta love options.
Conceivably, you could assign each StateX object its own error handler. Possibly, in different parts of your app, you want to catch specific errors in a specific fashion depending on certain circumstances. You can then safely save data when necessary, close low-level files, etc. It’s a good practice to be modular in your business logic and in your error handling.
For now, I would suggest you read on and imagine the possibilities.
Cheers.
Next article…
