Architectural thinking on Flutter State Management | Majid Hajian #DevFest 2021

[Music] thank you very much hello everyone those who are watching me right now or you are in the call with me or maybe you're going to watch this talk later today um i'm going to talk about the most controversial topic in flutter world or maybe in many applications not just flutter state management i will uh explain to you like why i chose this and what is my approach on that so you know when you start a project sooner or late you're gonna need like somehow some type of estate management so so your application grows your needs and requirements also grows and then you need more advanced stuff you know to manage your estate but how should you do that how should you choose an estate manager what is the best one for your application so these are the things that i'm going to talk about it today so first of all i will walk you through the architectural thinking and then we're going to talk about flutter state management different possibilities and then we're going to talk about some characteristic of architecture and how an architect can decide based on those characteristics so before that again let me introduce very quickly myself my name is majid and you can find me on internet by this handler mhl everywhere linkedin twitter wherever you want to find me and i'm a google developer expert for flutter and a passion software engineer and a solution architect at the moment in telia so let's get started and that's the main reason i chose this topic architecture or thinking most of the things that you you'll you'll hear from me at least for in the first part is uh you can find them mostly on this book which is great book if you are a software engineer and you have not done any software architecture before you want to get into the software architecture so i strongly recommend you to read this book fundamentals of software architecture so there are three points that is mentioned in the book generally so one of them is that architecture architecture is all about trades off right so and one more important thing is that you need to take into account the business drives and i also added team drives because we're going to talk about it more into the team level today and at the end you need to have a breeze of knowledge i'll explain all of this very quickly so that we all of us will be on the same page what really these stuff means uh let me give you a real example so i was flying actually a couple of weeks ago to london to give this talk and uh you know to the right camp and i was like looking at the air aircrafts after a couple of years like maybe two years not traveling um and then i realized that you know this is a very good example for architectural thinking because you know an aircraft usually what we see is it has like the engines below the wings right and there are some aircrafts which is probably you haven't seen very often is those aircrafts that have the engine on top of the beans in fact when i researched i realized that there are also some aircrafts that they have embedded in jeans to the wings and some other type as well it was funny to research that because uh as an architect when i was thinking about this i was thinking like okay which one is better than why i'm seeing always like maybe wings or engines on the wings why not others when can we use that one on this one which one is better really so let's uh let's have i i actually researched a bit and i will talk about three factors right now safety and structural strength and maintenance when i researched i realized that so when you have the in wings under the engine it seems like this is the most safest or like the securest um way to architecting uh an aircraft uh or putting the engine below the the wings the reason is that it's a little bit further from the cabin and also the gas you know so tank so in case of any emergency or any problem firing so it's less problematic and also when it's uh has like some kind of problem with uh you know engines so the aerodynamic of the uh the aircraft it's easier to handle apparently so these are the research uh things that i found in my research and also when you have the wings under the sorry you have the engines under the wings definitely you can you can have more engines or even bigger engines so it's more flexibility here on the other hand because these uh let me talk about this first maintenance of these engines is also seems to be easier the reason is that because the engines are closer to the ground so the maintenance can usually work you know on engine and you know do something with it but then obviously if i ask a question right now after this topics or these criterias that i mentioned which one is better you might say hmm probably if the engine is below the you know wings is the best right but there are other factors that i also found in my research one of them is aerodynamics for example and that also leads to the cost so let me let me talk about it a little bit it seems like when you have the engines on top of them you know on top of the wings so the aerodynamic uh or the physiques that is just handling the air for the aircraft it's uh much more flexible which means that you you consume less energy and and that is like leading to cost so it's less costly at least in terms of fuel right when you have this engine below the wings though there are a couple of other problems here as well for example so when you sit behind or like the seats end of the aircrafts you hear the sound the noise of these engines loud they're wild when they are you know on top of the wings apparently it's less noisy and there is also one more problem with the wings when they are under the uh you know wings and it's because it's closer to the ground they're actually absorbing more dust and you know that leads to more maintenance and again that increase the cost while when the engine is on top or embedded that's not the case so after hearing this then now the question is which one is better well all architects usually tell you two words which is so irritating and boring right that gives you this answer it depends but it depends because in in the world of architecture everything is a trade-off if like having safety and also maintenance more important for like that aircraft then probably you should put the engine below their rings but if cost is the most important things perhaps or uh like yeah maintenance cost is the most important things then you probably need to do the other way like put it on top there is one more thing that architects should know here is that you know you or all of us are pretty good at some specific knowledge or technical that's what we call a technical depth right we're very good at one skills or a couple of skills and when you when it comes to the architecting and application or let's say architecting um a software then the stuff yet that that you know you don't know it's very important that is what we call it technical breeds you need to learn more and more even though you're not specialized on that you need to learn a lot of things and no most a lot of you know information that is impacting your decision let me let me give you an example um well i hope that i was in the venue today that was the plan to be honest but i couldn't make it um but it was if i was there the question was here who knows right now what is triple pattern or segmented state pattern if anyone knows just let me know in the comments it's it is it is quite interesting right because that is the part i'm talking about this is the technical briefs so if you want to talk about like making a decision about an estate management which one is better then you need to have a breeze of knowledge you need to know most of them just just knowing two or one or hearing about some stuff and making decision is not particularly a good reason for your application in fact this is mentioned right into the documentation of flutter state management under options so the last one is this pattern all right why i'm saying this when i'm talking about flutter estate management then there are lots of things but i'm gonna give you an example about an application that i was creating so what the application that i was creating was um a coffee application so a simple application that had like a login a registration a home screen menu screen you move to different screens you have support log out and etc etc i wanted to choose which state management i need to have for this application and see what i have done for making my decision first of all i started to thinking like okay i can actually based on my current knowledge i can have maybe states per screen maybe or maybe i can have a state as a single object globally and then share it across the screens and well which one was better it depends well i was not really sure which one is better so i said that okay maybe i should go and you know have a diagram here and say okay i need to understand these estates who or which widgets are requiring these states for example if all widgets or most of the widget or some of the widgets are requiring a state then that is app state that's what we call it upper state right we treat that differently compared to when only one single widget requires an estate that is a thermal estate so it's a temporary state requiring only by one widget it's absolutely correct or okay to have state management temporary estate management for one single widget if any other widget doesn't need that estate okay but then i had a lot of options that's the most difficult part especially for those who are coming to flutter and say oh what should i do i see provider river pod block get it mobix um you know i know you've set estate or inherited widget i have redux well which one should i use really and if actually i give you this picture which is made by a friend of me and a good member of community mike so you see that the options are more than 30. it's impossible to go and actually cover all of them right so if you want to make a decision it takes forever to just uh test every single one read about it research about it and then find out which one is better for you but then i said to myself you know well i have these 30 options oh that's good by looking at you know the description of these the readme of these at least packages i can do something here let me give you what i did i've done i said i can categorize these state management into three different categories those packages that are based on flutter features like for example provider based on inherited widget or those packages that are kind of conveying the reactive programming base for example mobix or block it's like using a lot of streams or those packages that are inspired by functional programming for example redox then or maybe some of them so these are the things that i could categorize them i said now okay based on this and a couple of other factors probably i can narrow down my list for comparison okay how did i narrow down my list i said these are top 30 estate management all right so then i need those packages that are widely used so maybe most the stars most use github stars and likes on pop.dev some indications that are widely used and it was very important for me that that the package has code coverage over 70 percent at least so i didn't want to use any package that has less than that i also wanted a package that somehow just do only estate management i just didn't want to use a package that does a couple of other things i just needed an estate management solution and also a dependency ejection probably was a plus it was not a requirement so if the package for example together with another solution can give me both it was a good solution for me i read the documentation i wanted to know that if these packages have good documentation and and most importantly if these packages are active uh in terms of maintenance and i could narrow down my leads to seven or six options and i started to making my characteristic to compare them but here is the part i told you that the architects are trying to value the business drive right it's very important because we are creating a software that gives some value to business we're not just creating software we will create a software for fun for sure i mean but the point here is that at the end of the day it has some value to deliver so as of the characteristic of uh the architecture characteristic of a software you know usually architects are very fond of ility's word and they say scalability adaptability you know testability productive uh let's say agility or simplicity you know but these are the terms that architects understand or maybe developers can also relate to that but business they want more precise and you know they want the same language that they can oh they can't understand not the language that architect talks so then it's important when you are talking to your pm or you know maybe other folks from business side especially i have this map of like what does it mean when we say scalability of this package for example it means if later we want to add more and more and more features can we extend that can we adopt that can we in terms of flutter developers you know concerns does it have a lot of toilet plate because it just takes so much time to extend it or is it easy to extend quickly just create a class and do something with it how about the maintenance is it easy the time to market it's just can be mapped to agility or testability or deployability like so business say we want something very fast on the other hand flooded developers or developers say yeah can we easily learn it can we easily set that up can i just quickly uh do that in my application and and run it or customer satisfaction in business terms or death satisfaction in this case which uh can be some concerns in in development for example does this package come with code generation do i like code generation does my team like code generation at all does it come with the depth tools or a good example or documentation because these are these are the terms that makes my team productive and it makes it easy to handle errors or test the package and at the end the timing and budgeting because the more complex the package is of course the more knowledge and requirement you need in terms of your flutter concern teams and that means simplicity characteristic in architecture but let's have a look at that these are the least my list that has narrowed down so the first option was of course set state i realized that city state is a valid choice so many people quickly skip over that but in fact you don't need to so maybe you need that let's let's compare it i started to um reading some you know documentation as well as code and also implementing some of these already i also had some knowledge about these packages so it was easier for me to make this decision or this comparison chart but in fact you don't need to write a code in each of these slides that i'm going to show you these packages you can also go to there are some repositories on github that you can read read about the architecting of your application based on each of these packages and i think that the name is uh architecture of a flutter architecture or something like that by by brian so you can actually find that it's already linked in my slides so you can get it later as well so when i check this uh state management i realized that this is actually a perfect choice perfect choice for affirmative states like i mentioned in earlier right and it's a very good example for a rapid prototyping so i don't need to learn anything because it comes with flutter quickly well but you know there are some downside also to it there the trades off here is that it's not very testable it's not very scalable if i if i want to pass down states to very nested uh child children now down to the widget tree it's a little bit cumbersome it's it's hard it's very complex but on the other hand adaptability or agility is quite high because as i said it comes with a framework i started to uh checking provider and change notifier which gives you this estate management i'm not gonna talk about this because the author of provider remy mentioned several times especially mentioned to myself personally that he does not recommend provider anymore instead he he recommends river pot which is a new package by him and as he said maybe provider 2.0 so that is the good provider so let's talk about this instead then i started looking at to the river part so it was very simple but not as simple as statement a set of states there was some learning curve there so how things works i needed to read documentation and see examples and you know maybe dig into the code a little bit understand how things working um of course it made me productive but not as productive as i was with the native sort of state it came with a very fantastic testing kit which gives me a confident that i can test everything and it seems to be very scalable to me at least when i read the documentation and write some code with that so but there are also some downside to it for example maybe not most of my teams are familiar with the pattern and or the package so they need some time to learn it to learn the best practices and things like that right so i came up with some suggestion like uh where you should use riverpod even like maybe most of application can use it but then in fact if you do not have maybe reactive approach that's the best things to use maybe because then if you have a reactive programming approach in your application you have a websocket you need real time you know flow in your application data flow that's probably you need to go back to the reactive programming uh category that i mentioned and check those packages and block is actually from that category so i started to look into that i had some experience with it and based on that i gave some ranking here i said oh that's uh to be honest it's not very simple the idea for my team l i they need to understand it so it's it's a bit hard um to start probably but it's highly testable because it comes with a let's say a good key and it's highly scalable it's a very very good solution for a big application especially if you have stream and observable or reactive programming pattern in your application but on the other hand maybe because it's complex and it comes with a lot of boiled plate it makes you less productive or less agile maybe um [Music] i started to look into the mobx another one from this category the the reactive programming category it was simpler than block of course and then it made me more productive the testing well it was kinda in middle i had some glitches but most of the time it was okay and then um well i realized that the pattern is easier to understand while uh at least compared to maybe block which is another competitor of this category and it's also scalable it's quite good for especially medium to large application but especially if you're a fan of code generation that comes with code generation maybe that's something that you like but personally me and my team didn't like code generation so then we skipped that as well well i didn't escape actually we just had some observations redux was another one it's well again it was not simple for a app developer to understand the idea it was perfect for the team that maybe comes with a lot of web developers or especially medium to large applications it's quite good it comes from functional approach with the concept of pure function and you know immutability which is very good but at the same time comes with a lot of boilerplate and you know codes that you need to write because well in dart writing uh you know uh things similar to javascript it's not as easy as we think so it's a little bit more work so it's uh it makes us a little bit less productive perhaps for that particular application that i showed you mj coffee app and then the last one was get it together with get it mixing so these are all the packages that i i told you uh i narrowed them down and this is the last one was pretty simple the get it comes with an idea of like service locator um service locating and then if you don't like perhaps contacts or you want to just get your service very quickly with service locator together with mixing makes it a very good um state management uh it's pretty simple to start up and running it might come with some glitches in casting but still very testable and makes you way um very good and unproductive maintaining that is not that hard because it's less work less code to write and perhaps it makes you even agile so but then i made this chart then at the end so i started to looking to the six or seven solutions i actually crossed provider here because i said we need to switch to river pod and then based on this now that is the time that i want to make decision which one of these is better for me well i added some characteristic right what i want technically what i wanted in my application because i wanted to create my application in a day i want to just so quickly get it done or maybe day or two i mean very fast and now i wanted to choose which one gives me the agility and it's simple so i didn't don't need to go and read a lot on you know these packages to understand how they work i just didn't want to play around with it right just i want my team and myself become very sim productive and agile to to get this application out so you may guess right now based on this criteria which one comes to my application right yes i'm so i'm sorry to interrupt majid but we are running out of time so sure calm down i'm done yeah yes uh i am done so yes the only thing i wanted to tell you is that when you are talking about an estate management you just think about it depends because actually it's very irritating but actually really depends um and as i showed you make this comparison and make sure that you choose the best that is working for your application and that particular application that you are deciding upon thank you very much [Music] you

Channel: Google Developers Group - GDG West Sweden

Views: 88

Keywords:

Id: Jtk-OPVBX2Y

Length: 29min 21sec (1761 seconds)

Published: Fri Dec 03 2021