Raveesh Agarwal

Information & Communications Technology

Software Craftsmanship Product Development Consultancy Design

Kolkata, West Bengal, India

Raveesh Agarwal

Director, Cookytech

Building businesses and experiences through years.

Current sessions

Guide to State Management with Flutter, Android, PWAs etc

State Management is a hot topic of debate in multiple technical circles. Developers can not even find a common ground to agree on what "state" really is.

With the experience of building apps with multiple platforms, having developed actions on google, websites and PWAs with technologies ranging from WordPress to Angular, Android Apps in Java and Kotlin, and finally a list of "huge" flutter applications,

I realized the importance of state management to the quality of any application as my apps kept getting bigger and bigger.

This session is a culmination of all the research and experience in that course.

The answer to "how to manage state" should not end with "learn how to use package X". State management is a fundamental skill that all software engineers should hone.

State has been a well-defined term and is one of the 23 "gang of four design patterns". Something as concrete and infallible as that gives me the leverage of avoiding debate. Defining "State" and "State Objects" in a way we can all agree.

Once the state has been defined, we know what to manage. The final question is, how to manage it? This is where management comes in (not the ones that you hate. No. Not that management).

I look at it as a bunch of questions we need to ask when dealing with state objects and the approaches we take to address those questions.

1. How many state objects do we need? (Do we even need one)
For the welcome message on the front page of the website, we might not need a state object. We hard code it within the HTML file.
For a carousel on the homepage for the featured posts... The array of the featured posts is one state object(that syncs with the server because the list keeps changing), and then another state object is the integer in which current active index from the list is shown in the carousel. So.. 2 state objects!

2. How long do we keep state?
Persistent vs Ephemeral State. For example, if I buy a digital course, the course's state changes from not accessible to accessible. This needs to be persisted beyond app ka installation-cycle, kahi server pe.
If I change the app theme, this can be persisted offline and linked to app ka installation cycle, I will set the theme if I ever install it again.
If I slide through the carousel to the next post, this is an ephemeral state and can be lost with the App's lifecycle. I don't mind sliding when the app starts the next time.
Anyone who has used state bundles in Android will know what they were actually doing after relating to this. " savedInstanceState: Bundle? "

3. Where to store that state?

Persistent State (Beyond installation cycle)::
Online database(SQL databases and NoSQL databases in general, some that provide stream-based APIs like firebase's RXFire project(firestore))::

Persistent State (Tied to installation cycle, cleared on uninstalls)
SQLite, shared preferences for Android, (ROOM is an ORM for SQLite) indexedDB, or cache for browsers, etc, etc

Ephemeral (Tied to app lifecycle)::
-> Within the view: An animation controller, for example, will get instantiated, work, and destroyed with any standalone animated widget
-> Within the view-hierarchy: Now if the same controller has an effect on two siblings in that widget tree, we "lift the state up" and the controller is now instantiated and tracked with the parent
-> Outside the view-hierarchy: People(Paolo Soares and Team) who came up with BLoC Pattern were trying to share code between two UI frameworks(Flutter and Angular Dart). They needed the state cycles to live outside the view-hierarchies. (Enabled by the facts that flutter is a declarative UI framework and has reactive asynchronous capabilities inbuilt,)

4. How to modify and keep track of the state?
in non-declarative UI frameworks, the functions where the state changes need to know which views to update and that is what leads to the findViewById calls.
in declarative frameworks, like flutter, react native, or jetpack compose, UI = f(state) so if state changes, UI does that automatically.
LiveData and ViewModel were architecture patterns constructed specifically to allow this convenience to Android developers.

5. Advanced Performance Optimisations.
Now that we have all these awesome tools and understanding in hand, can we use it to really optimise the user's experience? PWAs did just that.
On-Device(app-lifecycle) Persistence is much faster than online persistence(beyond app persistence) of state. The problem with the web platforms was, developers did not have granular control on the on-device persistent mechanisms, until service workers!
Now with clever use of service worker and indexDB APIs, people are enabling near-native levels of performance. I learnt about this workflow with my Mobile Web Specialist course where we synced UI changes with local persistence and online persistence with local persistence using an interesting transactions API. Getting the best of both worlds.

People usually develop with one technology at a time. Having experienced so many technologies and built so many products with them I am in a position to put into perspective, this picture that will pique the interest of the software architects, empower developers from all stacks (backend, android, flutter, web etc) to think in a platform agnostic way about the quality of state management within their applications. The implications from here are vast and I will not be able to cover everything about state management. What I will be able to cover, is a different way to look at it, with examples, which I hope will inspire further discussions allowing me to learn from the experiences of other developers in the community.

State Management is a hot topic of debate in multiple technical circles. Developers can not even find a common ground to agree on what "state" really is.

The answer to "how to manage state" should not end with "learn how to use package X". State management is a fundamental skill that all software engineers should hone.

I will try to cover a different way to look at it, with examples, which I hope will inspire further discussions allowing us to learn from the experiences of other developers in the community.


Experiments.on(context): A State Management Adventure In Flutter

State management is listed as one of the major pain points by the Flutter Developers. As it turns out, flutter has a list of amazing tools for handling the same, all that's missing in their lives... is this session. :-p

This is a hands-on session, which has been designed to be very focused and efficient in focusing on the concepts
Sections are as follows:
> De-mystifying BuildContext and setState
> Passing state changes via constructor and setState() function
> InheritedWidget, how it works. ScopedModel, why/when not to use it
> Promoted to a Plumber with Streams
> RxDart helps with init. BehaviorSubject is just a stream with a cache tho
> BLoC, and the layered way of writing flutter apps.

Will time-test it at least in two sessions before the final delivery