Why am I switching to Flutter in 2024

today I'm going to tell you why I'm switching to flatter the reasoning behind it and then we'll go over the project to show you the progress so far and how I tackled some areas like State Management storage or navigation as some of you know I have an Android app with about 13 million downloads I've talked about it in a previous video you can watch it the link is in the description below at the moment it is written in a mix of cotlin and Java the calculator part is Legacy Java code and to be honest I hardly understand it by now the rest of it like the converters here are written in cotlin it has a Firebase backhand and when the user is logged in it stores all the settings and the data in a fir store database now why am I switching everything to flatter I can think of three major reasons dated UI technical depth and lack of iio support first dated UI the app looks a bit too old and it needs a refresh also the last time I wrote it I didn't really have a plan I scribbled a sketch on a piece of paper and began to code as a result the user experience could be better I usually do this refresh every 2 to 3 years it helps to keep the users engaged to let them know the app is maintained and it's not an abandoned project this time I found a designer who wireframe the screens for the app it's not much and the app as you'll see is not going to look exactly like this but they help a lot when it comes to improving the user experience throughout it and later with structuring the code well what has that to do with flut to be honest the is simple and 80% of it it's just UI so I might as well just rewrite it from scratch and flatter will help me do that it's so much easier to write UI and flatter after you get the hang of it a list for example looks just like this a few lines of code compared to the recycler view adapter view item behemat we had on Android and it just works everywhere the second reason is technical depth as you might have already noticed I have not made the switch yet to Jetpack compose I'm still using good old XML views I got so used to them that it's hard to even imagine something better but the whole life cycle binding view model live data monster we had for a long time now on Android it's just ah also Android decided to deprecate so many methods I had used for years and years I knew I had to switch sometimes but I just wasn't ready yet this goes hand in hand with a third reason which is lack of iOS support I always wanted to have my app on iOS 2 but I was pretty intimidated by it knowing how much time it took me to gain my Android development experience now with a family and with kids I just didn't have that luxury anymore hiring a developer was also in my mind and I almost got to do it when it hit me why not flut I can hit two birds with one stone get rid of the technical depth and have my app on iOS 2 all that by learning one framework instead of two jetpack compose and iOS and there are big names in the industry that already use it so here is what I have so far I'm going to show you my flatter project and how I handled State Management resources like strings localization and images authentication navigation storage and maybe theming and responsive UI in the end I feel that these are the building blocks of any flatter project now for State Management I use River pod the second iteration of Provider I had to choose between it and block and for me as a fresh flatter developer it was a bit easier to comprehend and I liked it it lets me keep every component State separate and I don't really have to worry about inherited or stateful widgets so much I just use stateless widgets with providers easy for Strings and localization I use the flatter localization package I need translations for my app and with it I can put every translation in a single folder it will then generate me all the classes needed to use them accordingly here you can see the strings class I made as a wrapper over the generate localization class in the app I will call strings of context to get every string and it will handle localization on its own for images I use flutter gen and flut SVG I need to be able to handle Vector files and this allows me to do it it generates the assets class with the contents of the assets folder as in the strings case I can later use the SVG files in code using images of context to get every Vector as a widget authentication is handled through Firebase it's just a single click class with a sign in a sign out and a user provider through this provider I can throughout the app check the user authentication State and get the user details if the user is not null we're logged in if the user is null we're logged out navigation is handled through go router since flatter can run in the browser too I needed an easy way to be able to manage links with it I can use an address like/ settings to go straight to the apps settings it helps with inapp navigation to handling the navigation stack I definitely recommend it for storage well here things get more interesting I have two layers of storage a local one and the remote one if the user is logged out I store everything in the shared preferences if the user logs in this local data gets synchronized with the data on the cloud in this case the fir store database I handled this through two River POD notifiers at an abstract level when I create a repository I can choose it to be local or remote for example the settings repository is synchronized to Firebase and the theme repository it's local on the device I use a key for each repository to save the data either locally or as a fir store document the model class holds the data and handles Json serialization and parsing the Notifier updates the data and stores it accordingly and the provider well it provides you can see I used an autod dispose Notifier provider that's because I want the providers to be disposed when not in use it's not nice to keep Firebase connections open for themes I build everything theme based on a seed color and I can have light and dark variations for everything theme I keep them in the configuration and I can initialize them like this changing the color here changes the theme then I can listen to the theme provider remember storage to rebuild the app whenever the theme changes this way I can easily do this with this single line of code last we get to the responsive UI it's basically an inherited widget I made I can initialize it like this and provide a phone t and desktop layout in the three I can get the current layout with layout of context and these three methods I'm about to start building the main calculator sounds easy on paper but it's pretty complicated with history graphs different layouts for different screen sizes and so on that's what I have so far not much but it's a nice starting block let me know what you think what I missed what I could have explain better as always I was Andre thank you for watching

Channel: Andrei Lupsa

Views: 59,642

Keywords: all-in-one calculator, application, android, ios, flutter, development

Id: 3WAEQ-zKAqg

Length: 7min 0sec (420 seconds)

Published: Fri Jan 12 2024