Complete Flutter Architecture using Provider and Stacked

[@hasanimam82]

I watched this many times, and every time i see how elegant it is. I'm looking forward for the upcoming episodes, thank you Dane!

[@FilledStacks]

Nice!! Thanks man, I'm very excited to share the other parts of the architecture. I'm finishing the written tutorial tomorrow. I'll try my best to record and edit tomorrow as well.

[@gideonmuiru5808]

This is brilliant! I think most people complaining about building the whole widget tree have not understood the power of the .reactive and .nonReactive constructors in combination with splitting views to single widgets. I cannot wait for the next episode in this series. Thank you and keep it up!!

[@FilledStacks]

Brilliant is a strong word but I'll take it! I think so too. It also gives me an idea of what content to make for the series to get that idea across. I'm very happy to hear you're excited about the series. I'm excited to share it as well.

[@nero9061]

i know provider approach can just re-render only where changed, so i have a question, this architecture (stacked) can not do that ?

[@demosongsheetmusic]

@@nero9061 This does re-render only when changed. Actually, it re-renders whenever you call `notifyListeners` in a ViewModel which is being `reactive`-ly monitored by a `ViewModelBuilder`. @FilledStacks can confirm :)

[@dreamerslab]

Thanks for such great efforts. I took me half a day to understand your stacked package and why we need it. And now I just love the way it works and the whole idea is really great.

[@FilledStacks]

That's awesome to hear man. I usually tell developers not to use it and use the basics fo Flutter to build their app. When that becomes tedious I can then easily point out why you'd want something like stacked to help you with your state management and general app development functionalities.

[@giampaologabba1030]

This is exactly what i was searching for. I'm approaching to flutter and saw a lot of tutorial without a clean architecture, mixing business logic in views and i was a bit worried :) I studied BloC but there is too much boilerplate and not a clean separation of concerns. Liked provider and your implementation of it is very, very clever. I love it. Nowadays learning flutter to properly develop complex applications is a tricky task, there is a lot of clumsy informations sticking around and is very, very easy to end up with some unmaintenable spaghetti code :) Having developed some HUGE mobile applications in Xamarin i have to say that your architecture is the beest for me, i will use it a lot :) Now i just need something flexibile and clever like the sqlinet-pcl package but for flutter then i'm sold!

[@FilledStacks]

I really appreciate you taking the time to type that out. I knew I wasn't alone when I was starting to think about just making my own architecture that is easier to maintain and simple enough to understand. The separation of concerns was a big problem for me when I first looked at BLoC and some of the other presented architectures. The great thing is that it'll only get better over time.

[@andreykaok9497]

After I have refactored my pet-project with the Stacked (and supported) packages, this approach looks like a "Silver Bullet" of Flutter architecture for me! It is so elegantly and cleverly written! Awesome job!

[@FilledStacks]

Thanks a lot man! I Use if for everything and have had great experiences with all project so far. I'm only seeing more things to improve so I'm excited to see how those moves forward.

[@markdioneeb8997]

This whole tutorial series deserves to be on Flutter's official doc cookbook or on those udemy/lynda courses that cost's $100 , this is too good to be free, nothing can beat simplicity, Stacked by FilledStacks is the best. Thank you very much

[@FilledStacks]

Thank you Mark! I appreciate your kind words. I'm planning on releasing an updated few videos in the coming weeks. I'm just a bit tied up, but they will all be free. As long as we are building apps I'll release all my content on it for free. I'm happy that it helped you.

[@georgedicu6001]

@@FilledStacks HI, Amazing videos, I am using all the stacked packages you offer, amazing work. Wondering if there are new video series coming. Also as MarkDionee said, ill pay also for them.

[@FilledStacks]

@@georgedicu6001 Hey yes, we're actually in the process of updating the docs so we can do a proper release of v3 :D I have a few new videos planned to show how it should be used.

[@davido3871]

Thanks man, I am really new in flutter however I have a lot of experience in many other frameworks and languages, this is probably the closest thing to what I would expect of good architecture, it is simple to understand and simple to implement, and very extensible. Gracias hermano, soy muy nuevo en flutter, sin embargo tengo mucha experiencia en otros frameworks y lenguajes, esto es probablemente lo mas cercano a lo que yo esperaria de una buena arquitectura, simple de entender y simple de implementar, y muy extensible.

[@FilledStacks]

You're very welcome. You're basically my perfect audience :) I aim to provide a great entry point for developers with experience that's just starting out with Flutter. I struggled through the proposed architecture and I landed on this. Something I brought with me from the Xamarin and C# days. It feels more "natural" when building mobile apps.

[@ebenezerferguson3756]

This concludes my search for a good flutter architecture. Thanks

[@FilledStacks]

Woooohoooo!!! That's great to hear. I'm happy that I could help you with that.

[@youdube1203]

@@FilledStacks me too i love this package very much it changed my coding level up

[@FilledStacks]

@@youdube1203 That's good to hear! Thanks for leaving a comment about it. I appreciate it.

[@kenhee]

This architecture really helps so much in separating the UI and logic. Coming from a MVC background, this has certainly helped me so much in my mobile development. Really excited and look forward to future episodes on how much this architecture can help me in writing maintainable and readable code. Right now, I'm almost done refactoring my entire app using this architecture. On a side note, thank you Dane for all the flutter videos you have made, it has helped me tremendously in my development, words can't explain how thankful I am.

[@FilledStacks]

Hi Ken. thank you very much for those kind words. You're very welcome. I'm happy to hear that it's making such a great impact. And I'm happy to see that it's not only helpful to me and my team but also to other devs in the community.

[@shardulnalegave4636]

I was about to search for tutorials on this topic! Great work!

[@FilledStacks]

Thank you! :) I hope you like it.

[@user-wb6cs3bt9e]

There are many videos about different topics but junior developer lack one common thing which is architecture. Thank you so much for these videos. Subcribed

[@FilledStacks]

It's my pleasure, I'm happy that they are still helpful.

[@nosmirck]

This is amazing! One step closer to a perfect architecture. Now, the only thing I have an issue with (and it's the same issue with every other state management solution so far) is that changing the state of one thing will rebuild the whole screen. If the page is much more complex and I have only one little thing changing, why would I want the whole screen to re-render? This happens almost no matter what you use, from just setState to BLoC, Provider and this Stacked solution. Except when you use pure vanilla Bloc with Streams. Only the stream you sink something will cause the builder to trigger and re-render only that part (in a counter example, if you make you page a stateless widget and let the value of the counter react to a Stream with a StreamBuilder, only that text will rebuild and the appbar, floating action button and the rest of the page will remain the same), saving a lot of unnecessary re-rendering, specially when we have more complex custom widgets with complex painters. I know flutter behind the scenes is very efficient and will simply reuse the same objects in the widget tree, so no real harm is done, but not all the time is like that, some widgets are disposed and need to re-render. Now, with your approach, we can still use streams and StreamBuilders to fulfill the same purpose, but that's a lot of boilerplate and something easier could be done. Now, I know you're a very smart guy and I'm sure you can find a solution and I have an idea that could work, I've been experimenting with it for the last couple of days, with no success (and also I have not invested too much time), but maybe you can get it going! Imagine an extension to Widget that returns another widget that rebuilds based on a stream (it's like just a wrapper for StreamBuilder) but no need to have all the boilerplate in the UI, something like this: Text('${model.title.value}') .Bind(model.title) In this case, model.title is a BindableProperty and calling .value on it will return the current value of it. BindableProperty is an object that holds a value and whenever you set it will trigger rebuild on the binded widgets (behind the scenes it simply wraps a stream controller) and as mentioned, the .Bind wraps the widget in a StreamBuilder but I'm pretty sure this is where it stops being possible, maybe something different that by exploiting the extension methods we don't need so much boilerplate? I don't know, it's just an idea :)

[@FilledStacks]

Luis! I thought you had left the community, I haven't seen any of your comments around anymore. Before we get to your awesome suggestion, Stacked actually has a solution to the screen rebuilding. You construct your viewmodelbuilder with nonReactive for the View and then you use the ViewModelWidget for the views you want to rebuild. ONLY those views will be rebuilt and their reactive functionality can be switched off at runtime :) The view itself will never be rebuilt. You can also use the .reactive constructor for those widgets and supply the viewmodel using Provider.of to get the existing one from the parent. That said all the widgets that are set to react will react to the change, but if you have some widgets that will only interact with the viewmodel and never change you can set their reactive property to false. I'll show all of that in the coming episodes. And about your solution I like that alot. Currently we have basic Specialised viewmodels for dealing with Futures and Streams automatically. But I really like what you're getting at. If you look in the Stacked architecture source code you'll see I'm using RxValue which does something similar. When the value is changed you can listen to that change which allows us to do some cool reactive stuff. I'm very excited to share the solutions in this package. I'm going to think more about what you mentioned. I'm actually going to make an issue to see if I can figure something out around it. Thanks for taking the time to give some great feedback and solution suggestions, it helps with the development of these package and the ideas for videos.

[@nosmirck]

@@FilledStacks great! I never left! I was a bit off the grid because I started a new job and was very very busy, I'm having the opportunity to start a new project (actually refactor/re-do an old project that can't handle anything new anymore) and I was planning on using your Provider architecture, but then I saw this video and I liked it even more! You got all the terms right, the explanations to the point, perfectly understandable and I believe this should be the defacto solution for any flutter project, your package can become like Prism (Xamarin.Forms) but for Flutter! Now, I haven't seen the code yet, I'll start a pet project tomorrow and try Stacked out (btw, perfect name for the package) and see how it works with the reactive/nonReactive builders, but my question now is, how do you know which is going to rebuild and which not? Let's say I have a column and 10 Text widgets, each one will render a different property value from my ViewModel. If I modify one of the properties in my VM and notify, will it re-render all the 10 widgets or only the one that was modified? Because so far, unless you have each property as its own notifier and warp each text with a different listener and call notifyListeners inside a specific notifier, I don't see how that is less code than a stream. Anyways, I'll try tomorrow morning and come back here with mi thoughts :)

[@FilledStacks]

@@nosmirck You're right, in that case all the viewmodels will be listening and rebuilding. Each viewmodelwidget has a reactive property which you can use. I might add a basic value comparison type functionality that will only rebuild viewmodels where the value they depend on has changed. Will take some time but it's something I'd like to add when I get some more free time. At the moment I haven't found any problems with performance and the way we're doing things here since it's the same as base Provider implementations. It'll rebuild where you're listening with a simple stream. I will be spending some time on it soon to see if I can improve the multiple rebuild situation on one viewmodel.

[@nosmirck]

@@FilledStacks sounds good! and of course, even if we had hundreds of widgets rebuilding at the same time when just one changes you won't see much of a performance issue, even with custom painters, overriding the shouldRepaint properly is better because it will guarantee that the painter will not repaint again, so, with very expensive custom painters it will still perform nicely. But, you know how it is, if you can squeeze every drop of performance, you should, because you never know when you're going to need it to actually work with only rebuilding the changes and not the entire thing.

[@fifanrg]

​@@FilledStacks Firstly thanks for the awesome tutorial and much appreciated it! I've been a native mobile dev for both iOS and android for quite a long time and recently explored the possibility of rebuilding my projects in flutter. (yeah!) However I did notice this UI rebuild issue with Provider and most of the flutter solutions. I know that you have quite a number of production app in the market, and my question is that would this UI rebuild issue quite impact the performance of the app if you have a really complex UI structure and with lot of animations? Thanks again for this awesome architecture again! Legend!

[@ComputerScienceAcademy5220]

THIS IS THE BEST VIDEO I HAVE EVER SEEN REGARDING WORKING WITH FLUTTER (architecture, state, routing...) OMG! I love the way you think! (e.g. regarding block) Thanks!! Will watch the whole series...

[@FilledStacks]

That's great to hear! I'm very happy to hear that. This is quite old and a lot of it has been updated to be generated using a CLI which you can see here. stacked.filledstacks.com/ , once you understand the architecture you can remove a lot of the boilerplate by using the cli to generate the code for you.

[@eduardoADSL]

Thank you Dane and all the guys that shared their solutions for the issues that happened as the packages were updated.

[@FilledStacks]

It's my pleasure. And yes, the community is awesome for sharing their updates ovet time.

[@codemonza2840]

Thank you so much for sharing your knowledge! Love the elegance of your way. It's been almost a year and there are changes I had to make, mostly due to auto_route and injectable updates and null safety requirements.

[@codemonza2840]

1. In router.dart: @MaterialAutoRouter( replaceInRouteName: 'View,Route', routes: [ AutoRoute(page: StartupView, initial: true), AutoRoute(page: HomeView, initial: false), ], ) class $AppRouter {}

[@codemonza2840]

2. In main.dart: class MyApp extends StatelessWidget { // This widget is the root of your application. final _appRouter = AppRouter(); @override Widget build(BuildContext context) { return MaterialApp.router( routeInformationParser: _appRouter.defaultRouteParser(), routerDelegate: _appRouter.delegate(), ); } }

[@codemonza2840]

3. And then in the generated locator.config.dart: Replaced {String? environment, _i2.EnvironmentFilter? environmentFilter}) { by {String environment, _i2.EnvironmentFilter environmentFilter}) {

[@codemonza2840]

4. In pubspec.yaml, had to change the sdk from 2.8.0 to 2.11.0, but you might not need to do so (to deal with an null safety error related to #3): environment: sdk: ">=2.11.0

[@codemonza2840]

5. Also the command to build is now: % flutter packages pub run build_runner build

[@wickedgummybear3104]

The only reason someone could downvote this, is because they don't understand it. Just love this way of structuring architecture. So clean..

[@FilledStacks]

Thank you :) I'm happy you like the content.

[@simontai3900]

I am using BloC which is a totally nightmare. I love your architecture. it is more intuitive and simple than what I am using. I wish I watched this before

[@FilledStacks]

Hi Simon, I'm very happy to hear that. I hope you get to experience it in production 1 day. It's so great to use in production for us.

[@omoruboreoluwatobi6115]

Since following FilledStacks. I now write less buggy code. Dan teaches best coding practices in a simple way. If you are not clear on something Dan said in one class, trust me, you will find it on the next topic you search. Thanks to the Filledstacks team

[@FilledStacks]

Thank you for the kind words. I really appreciate it. .P.S. My name is Dane 😆

[@ayushpratap4726]

Professional & Amazing! Absolutely Clean Code ! & Highly Organized Style! Something I can't Live Without, I really like your philosophy that we have to live with that code every day!

[@FilledStacks]

Thank you very much. I appreciate your kind words and feedback. I also like the philosophy. You can't force someone to use a specific architecture if you're not going to be coding with them, in the code every single day. That's why I use this one, and my team does too. If they don't like something they mention it and we change it, simple as that. Goodluck on your coding!

[@ayushpratap4726]

@@FilledStacks Hey Thanks for replying back! You're absolutely correct on that, Ultimately we have to choose what suits us best, Some people sought perfection while others get away with just workable, which can kill passion to outstand. I followed your code but M getting an error while building routes through command flutter pub run build_runner build, Though files don't have an error, neither while building an app but when the app is launched it shows home view instead of the initial route ie startup view.

[@ayushpratap4726]

That was a silly mistake from my end, I did not remove the home property in Material App, Now One error is coming Class 'LabeledGlobalKey' has no instance method 'call'.

[@FilledStacks]

@@ayushpratap4726 You have to set the navigator key if you're using Get directly or from the navigation service.

[@anjena]

Beautiful architecture that's been helping out this Flutter beginner who is just launching his second app. Your mind works in fast forward. When I'm following along I play in 0.75x speed. xD

[@FilledStacks]

hahaha, I'm happy to help. i do move at a rapid pace, i don't like slow tutorial videos. Thanks for watching!

[@danielenqvist725]

I was studying domain driven design architecture with BLoC's for my project. Yeah, it works but I felt like my soul has left the body. Your architecture seems to combine both worlds for my taste. I enjoyed the setup of the project and can't wait for the next part. Thank you, thank you, thank you!

[@FilledStacks]

I'm very happy that I could help you on that process. When I started with flutter, like everyone else I also took up Bloc and I struggled to produce functionality for a long time until I decided to bring some of these MVVM principles over to Flutter. Im working on the new video today :) Very excited to shared it

[@enryd...]

@@FilledStacks gosh I'm excited

[@FilledStacks]

Haha, me too!

[@things_i_forget]

Thank you so much for Stacked. I watched your previous Video and was thinking why not wrapping all this boilerplate and core codes in a single package...and here it is.... . Btw using many packages is making this tutorial hard for me. Although I am understanding how it helps a lot. I guess I just have to go slower, spending a lot of time grasping documentation of each packages you mentioned will make things easier I hope. Thanks again.

[@FilledStacks]

Hey Hey, Yeah we thought the same after using it for a few projects. Instead of rewriting the code we just created a package to provide the functionality. Using a lot of packages can definitely do that, but we think it's the best at the moment to combine those packages. We're starting to merge it into stacked and providing easier ways of using it.

[@KresnaPermana]

This is what I want, I (until now) holding myself to start making a big project in flutter. Because I've seen the architecture on BLoC, Provider and even MobX (with the code generator tool) doesn't really fit and too much implementation, I know someday the arch would make some "flutter fatigue" on me 😄. Your Stacks is cooler, going forward to learn and start use it 👍

[@FilledStacks]

That's awesome to hear! Thanks for letting me know about it. i hope you enjoy it as much as we do

[@AntiThesis10125]

I love this architecture! thanks for sharing. All of the state management has always been extremely cumbersome and bloated but I've always settled on provider - for the rest - awesome!

[@FilledStacks]

Thanks man. we like it too. There's a lot we can improve on, hopefully as more people use it we can create better patterns within the overall setup and produce something great to build apps with.

[@michaelkroupa6996]

Thank you so much for your effort here ;) I just started out programming flutter apps coming from xamarin. And the biggest challange which I was facing, was the unreadability of the code which you are thrown to when starting out new. This tutorial series is exectly what i was looking for! :)

[@FilledStacks]

Awesome! I'm happy, and welcome. I also came from Xamarin 2 years ago

[@berosolo866]

Great improvement to the architecture I hope you stay home Dane the flutter communty can't afford to lose you ❤

[@FilledStacks]

I'm very happy that you think that. I think when you see the new functionality it will be even better, I'm very excited to share it. And yes, I am at home, locked down and writing code :) Thanks for your concern

[@berosolo866]

@@FilledStacks waiting for new videos 😁

[@FilledStacks]

Haha, I'm writing more on Thursday. Hoping to get the written tutorial done so I can record the video.

[@nzuzomal4545]

Awesome work man, great to see such programming talent being showcased coming from our country :)

[@FilledStacks]

Thanks a lot man. I appreciate the kind words and the support. There's a lot of us here in SA :) Just need to put out what we can do so the world can know about it too.

[@bibash3128]

Switching to stacked now. But I still prefer manual way of adding route and service in locator.. great job .. waiting for what you have more for us.. thanks...

[@FilledStacks]

Can't argue there. One of the only reasons I'm using it is the argument generation as well as the route names. That's all we're using in there.

[@botondkoncz1961]

this is just crazy good!!!! it should be the official architecture for flutter!

[@FilledStacks]

Yeeaaahhh!! I'm happy to hear that you think so. I find it very easy to develop in and build the apps we're building.

[@danielcardonaisern]

Christmas on April, thankyou!!

[@FilledStacks]

Haha, you're welcome. I hope you enjoyed the video :)

[@manesvenom123]

Such a venerable guru of flutter :) That would be wonderful if there is a new episode to update the demo sample in tutorial (Flutter Provider Architecture - Sharing Data Across your Models) using Stacked architecture.

[@FilledStacks]

Thank you :) I won't be updating those tutorials with this architecture as this new set of videos will cover everything in there. I'm leaving it all to exist as is and I'll make new videos to cover the old topics in the same way.

[@kobowo]

Wow its been awhile since I've taken a look at your tutorials. I've gone through a couple of architecture examples and actually used it for apps (your provider one and reso coder's tdd one) and I've just started watching this and the 2nd part and so far I think this is probably gonna be the cleanest one among them! Excited to go through the videos. Thanks for the quality content!

[@FilledStacks]

heyoooo! thanks man, I'm happy you like it. So far it's been absolutely amazing. We've built a few apps with it, new app starting at the end of this year or close to the new year. It's been absolutely great. There's a few additional things I want to add which will make it even better to use.

[@musabnasreldeen2009]

Amazing Mr Dane 🎯 more videos like this please

[@FilledStacks]

Thank you :) That's the plan. I have 4-6 planned in this series

[@musabnasreldeen2009]

@@FilledStacks great 👌😍

[@augustemmery-funch620]

This is awesome! I use this architecture in my two medical apps:)

[@FilledStacks]

Nice! I would love to hear your experience with it and how you find development with it.

[@augustemmery-funch620]

My experience with it is that it is very intuitive to understand. It has a great workflow. And the learning curve is not too steep. I recently taught this architecture to my co-developer, and he got it very quickly. I have only used this recently; I am no master. But it sure will be the architecture I use in my future flutter apps.

[@FilledStacks]

​@@augustemmery-funch620 That's the exact intention of it. Thanks for sharing that with me. I've never focused on the technical side, I've always wanted something that's teachable and easy to understand. The goal of this was to keep everything very simple so it's easy to grasp but make it powerful enough to build large apps with. Sounds like it worked out that way. Thanks again for sharing.

[@mallen1846]

As a fan of MVVM in .NET this looks perfect to me and makes complete sense 👍

[@FilledStacks]

Woooohooooo. Another .net dev. I'm from that world too so I've been striving to create something that feels comfortable. I'm happy you found the channel.

[@hurbes101]

this is some next level stuff ... excited for the series

[@FilledStacks]

Whoooop whooooop!! Very excited too. Can't wait to share all the new functionality.

[@narcodico]

With your architecture approach whenever your state changes it will rebuild the entire screen which is definitely not desirable. In your example when a simple Text changes it will also rebuild the scaffold and the center. In a real app there's a lot more widgets on a screen. There's also no way to conditionally rebuild a specific sub-tree. There's not a clean and easy way of implementing stuff like debouncing, throttling, etc which are quite common, e.g.: forms, search boxes. You should definitely be using whatever makes you happy, but I don't see this being nearly as efficient on medium/large apps as bloc.

[@jesusidev]

Interesting, @rolly is there a better approach?

[@thexinoip]

Rebuilding all of the screen is dependent on where you put your "ViewModelBuilder", as i understood. Like if you put it at the root of your whole page it will obviously rebuild the whole page when state changes, but if you use it to wrap only widgets that needs the state changes then this won't be a problem. Anyways, i don't see anything new here, it seemed like a less boiler plate provider-consumer approach. Registering your view model as a ChangeNotifierProvider and then using the view model inside Consumers seems more mature approach to me. Seeing new architecture approaches are always good though.

[@FilledStacks]

I'd love to see a comparison between this and bloc implementing the same functionality. Luckily I only build large apps so I have quite a lot of experience with it and a lot of real world scenarios. If you made that text it's own widget with it's own model only that part will rebuild which is exactly how I build it. Similarly to how you would have a bloc that would only be hooked up to one widget and rebuild that one only. If however you hook the block up to the view the same thing would happen. I actually haven't seen an architecture that doesn't rebuild the view if you don't want it to. You can split your view into multiple single widgets with models and only those ones will rebuild. using the nonReactive constructor at the top level and then then reactive ones for lower level children. Should be an easy peasy lemon squeezy change. I've tried Bloc. Twice actually. So much work for no added benefit, in my opinion of course.

[@FilledStacks]

Using viewmodels for the lower level children only and not the entire view would be a better approach but I doubt the performance gain would be measurable with the human eye.

[@narcodico]

@@FilledStacks I would not want to need to create a new model for a text, that'd be ridiculous. I would like to be able to get the slice I want from the existing model and only rebuild that text widget when only that slice changes from the state. This is one of the aspects where provider+consumer and bloc are superior. But hey, it's personal taste at the end of the day. I also understand you don't like bloc, but you're discrediting the most starred state management library on github when it offers more than what your take on state management does, and that's the only reason I bothered writing something about this topic, which is very subjective, as already mentioned.

[@ChinmayPatil23]

Awesome please share the next videos Love the Work Very impresive.

[@FilledStacks]

Thank you. I will, I'll be continuing the writing on Thursday then hopefully record and post on Sunday

[@blickwinkeltour]

Wow thank you very much. This is exactly what I was looking for ( although I wasnˋt really looking for it).

[@FilledStacks]

haha, awesome. I'm happy you found it. I hope it helps.

[@yashinherenttech6396]

Glad now I don't have to manually generate every route and much more improved stuffs from the last architecture, great job as always and also it's much easier for me to understand as I've already working with your previous arch. And also I would like to request a tutorial for shrinking/decreasing the production app size or you may refer article that do so and also like to ask you what's your average app size(release). Thanks !!

[@FilledStacks]

Yeah it's a big time saver, especially as you add in parameters to pass around. It's much faster to generate all that than to manually type it. The average app size depends on what assets are in there. But I haven't checked that. When I build my fat apk with all the supported libraries in there it's about 20 MB, when i build a bundle it's about 12MB , don't have ios stats in my head right now.

[@yashinherenttech6396]

@@FilledStacks I created an app about 4 5 days ago, it had literally 4 pages and firebase admob included, generated signed release apk, it was 30 mb why is that am I missing something? I also included settings like minify & shrinkify commands in android manifest file. I don't what is the issue and also which flutter channel you use? I used dev channel that time.

[@FilledStacks]

I use the stable channel. Did you make a fat apk? that includes the libs for 32 and 64 bit into 1 apk.

[@yashinherenttech6396]

Yes I did made fat apk, I use this project now as starters and continue on that and check the app size on adding each functionality. Thanks :)

[@yashinherenttech6396]

​@@FilledStacks I noticed something odd, I updated everything to latest and stable version and created starter project did in vscode run --release(6.2 mb) file size generated and did build apk --release (15.0 mb) & bundle build is also(15.2 mb), cannot really figure out what's going on and same while generating signed apk over android studio 15.0 mb files. Please help if you have any insights.

[@MOhan-ur4ei]

Woah, thanks for the feast, I know there's more to come. I can't wait for the next video. How to dispose view models in your architecture.

[@FilledStacks]

I'm also excited. It disposes automatically unless you set disposeViewModels to false

[@MOhan-ur4ei]

@@FilledStacks cool

[@vilks_jan]

Dude! Thank you I was just looking for it! Love your videos!

[@FilledStacks]

haha awesome! Thanks for watching. I hope you enjoy this and the rest coming out.

[@ericsison3911]

This is comparable to some paid content. The quality of knowledge you're sharing is amazing. Now, it's time to refactor my code. HA HA! Been learning BloC, and I agree that it's not as straightforward as your approach (not that I hate BloC).. I'm interested in learning more from this series. Thanks a lot! *Looking forward for your next upload. :D

[@FilledStacks]

Hey Eric, thanks man! I appreciate the words of encouragement. I'm also happy that you see my comments on BLoC that way. I don't have it AT ALL. It's just a bit too complex for me for building large applications. I'm looking forward to making the next ones :)

[@ericsison3911]

@@FilledStacks Yes, I believe it all boils down to preferences. By the way, I think 2 of your videos from this series were uploaded twice?

[@thiyraashdavid7784]

Great improvement man!! 👍👍👍👍 You are rocking!

[@FilledStacks]

Thanks Thanks! I'm happy you think so. Thanks for commenting

[@B6Videos]

Been using your Provider arch v2, this was a lot to swallow first time watching... Will come back later!

[@FilledStacks]

It's quite a bit of setup. but not more than any other production app, and this is without analytics, firebase, logging, crash handling etc. I'll be making a package that bundles all of this. I wanted to show everything first before creating a package that makes it all a few lines of code this way I have a video to point to when people do get confused in the future when I hide everything behind a package.

[@B6Videos]

@@FilledStacks that's nice. am looking forward to what's coming next

[@FilledStacks]

@@B6Videos Me to. Thanks for checking it out

[@bluedev6304]

Great Content! But I realized that the setup of the navigation part doesn't work now (with flutter 3 from the stable branch), but I just followed the auto_route package's docs. As it turns out, they made a lot of changes. Now you don't need that navigation service class, it's built into the package, they have also changed the way you register the router, and they have also changed the material auto-router annotation. And I read in the comments, that it looks like you are quite busy, and that's why you don't update things much. and that's okay, I'm leaving this comment so that you can pin it for others encountering issues with following the navigation part.

[@FilledStacks]

Hey hey, thank for watching and leaving a comment. .We've moved away from Autoroute over a year ago now. This video is quite old. As you can't go back and update an old video, there's new ones that has been released :D we're using everything in stacked directly with our own generator. It's flutter 3 compatible and the docs can be seen here stacked.filledstacks.com/

[@bluedev6304]

@@FilledStacks oh! That's interesting, I'll take a look at that

[@bluedev6304]

@@FilledStacks Also just had a question pop up in my mind, what do you think about melos for flutter project monorepos? Is it something you follow or you think is a good practice for medium to large apps?

[@FilledStacks]

@@bluedev6304 Melo's doesn't really come into the realm of good practice, it's a package you can use to manage your dependencies. If you're wasting time navigating into multiple folders and running the same command in each folder then it would be a good choice to stop doing that and use something like melos. I'm moving away from it and using a custom tool since it's hard to configure it to wait for dependent packages to run before others.

[@enriqueortiz7251]

Dear Dane, I was sold in your architecture since Provider v1, but you always manage to outdone yourself!. Stacked is what the doctor ordered for a project I was struggling with using BloC and whatnot; the simplicity of Stacked along with the new code generation packages are the streamlined workflow an aspiring indy developer like me dream off. I just have one question, in the Future example you mention there are more "elegant" ways to handle errors, could you please elaborate a bit? Thanks man!

[@FilledStacks]

Hey Enrique, Thank you very much for your kind words. I'm very happy to hear that you have found the setup as great as I have during development. We put a lot of time and effort into client applications and this is the architecture that came out after production application builds. For the more elegant way of handling Futures if you use the FutureViewModel it will catch the error for you and call the onError callback where you can handle custom error logic. It will also store an hasError property that tells you there's an error along with the error itself which you can display anywhere in the app.

[@isevadigital3076]

Really great video love it, expecting more videos like this

[@FilledStacks]

Thank you. There are already 7 parts in the series :D

[@limei5414]

Thank you! It looks similar to provider and consumer

[@FilledStacks]

You're welcome :) It is, exactly the same. Just a more readable approach, to managing all of that.

[@kothanzaw]

Thanks for your effort and sharing.

[@FilledStacks]

You're welcome :) Thanks for watching and commenting

[@YazeedAlKhalaf]

I suggest you add Giffy_Dialog as a choice in the dialog service. Try the package, it is awesome 👏. I also suggest adding a popCurrentContext() function in the navigation service. Btw those are things I use personally with your great architecture 😍😍😂

[@FilledStacks]

Awesome! I will be filling out the Navigation service today as I'm working on the new tutorial.

[@themindstorm9947]

I had a question about services I hope you can answer. I have an authentication service which has the below functions: - login - register - getCurrentUser I also have a cars service which has the below functions: - getAllCars - addCar - removeCar The function addCar needs to add a car for a particular user, and therefore requires the logged in user's ID. This is received from the getCurrentUser function of the authentication service. What do you think is the best way to implement this? A) Make car service depend on authentication service. When I need to get the current user, I can call getCurrentUser directly inside addCar. I am not sure if one service depending on another is a good thing B) in my view model, get the user ID by calling the getCurrentUser method, then passing the user ID into the addCar method. This way, the services don't depend on anything, but rather the view model depends on both, authentication service and car service. Which way, A or B is preferred?

[@FilledStacks]

Great question! Thanks for asking. You should always opt for B, but if you have to do that in multiple places then always opt for A to avoid code duplication. "Composition over inheritance" is the idea. Single responsibility services that that you compose new functionalities with. This doesn't mean services shouldn't be used with each other. In fact that's what makes it so powerful. You can combine single services in a new service that does all the coordincation between services to remove code duplication and make your code cleaner from the outside. So B if it's in 1 place, A if you'll always need that functionality and there's a possibility of it being called, the same way, from multiple places in your code.

[@ericjubber7868]

This is great. I've started a new Flutter app that I plan on releasing on the App Store. I began with your other architecture videos and implemented that, but will likely switch to the Stacked package once the other videos are released. Thanks so much.

[@FilledStacks]

Hey Eric. You're very welcome. At the bottom of the stacked readme there's a full migration guide since it's just naming that changes and the viewmodel property is now a builder. I did migrations on my other code bases in 10-20 minutes. I'm happy to hear that it's so timely for everyone. I was expecting quite a bit of push back for the first episode because there's not a lot that's new that the provider_architecture package didn't do but in the coming episodes the difference will be very clear. Can't wait to share it.

[@ShoebSurveEngg]

@@FilledStacks Waiting for the second part to release as soon as possible. I need to start my new app development using the Stacked package.

[@FilledStacks]

@@ShoebSurveEngg Nice. I'm starting with it now, it should be out in a few hours.

[@ShoebSurveEngg]

@@FilledStacks Thanks alot.

[@swashington1995]

Hi Dane, that was a totally unexpected video. Looking lit!! Looking forward for the series mate. 🙂

[@FilledStacks]

Yeaah yeaaaaaay! Can't wait to share it man :) I'm very excited

[@learningisgrowinglig]

Putting all the common services to the package is a very good decision

[@FilledStacks]

I think so too. Now I just need to spend some time to update it and keep it in line with what we're using in production.

[@learningisgrowinglig]

@@FilledStacks yes, will be very helpful if all firebase services with required general operations are also included so as to speed up or just package firebase base services with common things so as to include them as third party services. If you could mention all the third party services you use in production and list them and make them available on pub.dev, it would really be help all of us to speed up for any type of data driven app development

[@FilledStacks]

@@learningisgrowinglig That is apart of the plan as well. I'll be putting my firebase services in there too.

[@danishmehmood5375]

Well done. I was using provider before, its the same. but more effecient

[@FilledStacks]

yes, stacked uses provider as well. The only reason it exists is because I don't want to re-write all my base classes in every project. Doing 6 a year but it's still exactly the same as my first provider architecture video.

[@kaito3131]

Great work man 👍 waiting for the rest

[@FilledStacks]

Thanks Youssef! I'm excited to start making the rest.

[@Manuel-wj1xs]

Que triste no entender inglés y que este tutorial no esté en español. Me subcribo al canal igualmente, que te lo mereces. Increíble contenido.

[@FilledStacks]

Lamento oír hablar de la barrera del idioma. Tengo un miembro del equipo español, tal vez intentemos traducir algunos tutoriales en el futuro. Al menos los escritos. Gracias por suscribirte. Esto es de G translate, así que disculpe los errores gramaticales.

[@Manuel-wj1xs]

@@FilledStacks Sería estupendo tener traducido tan fantásticos tutoriales ^^ y seguro, que al igual que yo, hay muchas personas que lo agradecerían ^^.

[@FilledStacks]

@@Manuel-wj1xs I'm sure of it too! I'll see what we can do about it.

[@user-ds6qh2um6v]

Tbh I liked stacked architecture more than bloc. It's simple, easy and obviously very close to MVVM, my personal favourite.

[@FilledStacks]

It's my personal favorite as well :) I might be biased but I have tried quite a few others and none of them felt this "nice" to use

[@user-ds6qh2um6v]

@@FilledStacks same bro same. That's why I decided to use it in my apps.

[@rikyriky966]

In theory, it doesn’t change anything from my current architecture done by provider, as far as I understand the Stacked. However, in practice, this let you get rid of a lot of boilerplate. (yet stacked introduce new boilerplate code too but it is simpler to manage)

[@FilledStacks]

Yes, you're right. When I show the new functionality it will remove quite a lot of other boilerplate. Things like the FutureViewModel, StreamViewModel and HookViewModelWidget makes a big difference in the code.

[@aseemshrey400]

Great work as always :)

[@FilledStacks]

Thank you! I appreciate the kind words.

[@tarmiziahmad1306]

For those unlucky enough to follow along with this tutorial today, it seems the latest release of get package (3.10.0 and 3.10.1) broke something. stacked_services package now doesn't work with it and will generate build error. Temporary solution is to revert to last working version of get by specifying 'get: 3.8.0' as a dependency in the pubspec.yaml file. Hopefully it'll be fixed by the time anyone reads this!

[@FilledStacks]

Thanks for the tip Tarmizi! I didn't know about the break but I've published a new version of the stacked_services that fixes this

[@RaymondAtivie]

Amazing content. Just what i was looking for.

[@FilledStacks]

Thanks Raymond. I hope you enjoy the rest of the series too.

[@RaymondAtivie]

FilledStacks i honestly cannot wait!!!! 😅. I already developed a scaffolding app for all my mobile development based on your tutorials. (Two in production already). Looking to overhaul that using this new series!! You’re doing great work and I really appreciate your content

[@FilledStacks]

@@RaymondAtivie Woooooohoooo!! That's awesome man. Such great news to get. It makes me very happy to hear that it's helping you produce apps, hopefully in a more maintainable way as well :) Thanks for sharing man. I really appreciate it.

[@DevLife717]

Could not agree more with your bloc rant and the disconnect with being able to trace thru the code. Love the approach you're taking with this architecture. Are parameters passed view model to view model? Looking forward to the rest of this series, good stuff!

[@FilledStacks]

I'm happy to see there are others that agree with me. Parameters are passed through the navigation to the view then the view can set it on the ViewModels. Because we navigate using named routes we have to pass using the arguments parameters. The auto_route package will generate all your parameters for you so you can just add it to the view and then pass it where you construct your ViewModel.

[@OmaralaaHEROMORA]

I'm sorry i am new to this, but aren't we losing a bit of performance rebuilding the whole build method for the whole page, in normal provider implementation we would use consumer only for the widgets that we would like to be notified and not entierly rebuild the whole page.

[@FilledStacks]

No need to apologise for a lack of experience :) No we are not, that's what Flutter does anyway. But if you are concerned about that you can watch part 2 of the series where I rebuild only parts of the UI

[@ericmaro]

Long time, i have been waiting for such video. thanks

[@FilledStacks]

Great to hear you were waiting. Can't wait to share the rest with you. It's very exciting.

[@yogeshbhati1359]

Awesome. I cannot wait for the next episode in this series. I have already started using this package. I'm in a situation where I have two tabs "Upcoming Requests List" and "Scheduled Requests List". I want to get the list only once when I go to that tab. I'm calling the api function in ViewModel using onModelReady and I set false for "disposeViewModel" and "createNewModelOnInsert". Still whenever I switch tab, api function in onModelReady is getting called. I think my model is getting build every time when I switch tabs. Please help me to understand what I'm doing wrong.

[@FilledStacks]

Nice, great to hear that you're using it. onModel ready will be called if the widget has been re-created completelty. I'll add something like that in the app and see what's causing it.

[@yogeshbhati1359]

@@FilledStacks Thanks, I'm looking forward to it.

[@rishabhshukla6284]

Please! add a video of How to use Authentication Service in your stacked architecture.

[@FilledStacks]

Hi, I won't be doing that since it'll be 100% exactly, literally, completely, 100000% the exact same as in the firebase series.

[@jrheisler]

Hi Dane, maybe I missed it, but you did something at the end of this video in startup_view that I couldn't keep up with, and the source doesn't have. I'm wondering what I missed. Fyi, I'm 3 months into Flutter, and this is about the third time I've watched, and finally I get it. Very clean, thank you!!!

[@FilledStacks]

haha, third time lucky! The startup viewmodel at the end was just a little teaser for the ViewmodelBuilderWidget functionality but it's not important. You don't need it. I go over it in the second part of this series. Thanks for watching and commenting! I appreciate it.

[@chihuy105]

Nice work

[@FilledStacks]

Thank you! I appreciate the comment

[@softiceable]

Great stuff, I already started incorporating this in my next app. But I have 1 doubt about navigation. Isn't navigation a UI concern? In my understanding ViewModel holds the state but why would state worry about and couple with other UI screens?

[@FilledStacks]

Thankt. It definitely shouldn't couple with other UI screens. The reason why I want navigation service available to the ViewModel is because that's where the business logic it. That's where you decide where to go so I personally think that's where you should be able to navigate from.

[@brenoverissimo3846]

I've come from web development with Django and I really liked this architecture, but I really need to talk about it with someone about a few doubts that I have. For instance, as I've learned and developed my first flutter app, I've been using a structure divided in components, models, views and utils. But in this case, let's say I have a component that is a image input field or a custom checkbox field, or would a split between a service (the image picker function) and a shared ui (the client-side caller to the service)? As I typed it made a little bit more sense, but gonna leave it anyway xD Thanks!

[@FilledStacks]

Hey, I'm happy that you like it. We love it as well, use it for all of our apps, large and small. Your question doesn't make sense to me, I can't follow it properly but I'll try re ask it to see if I understand. You're asking if you have standalone widgets if they should both talk to different services? Which doesn't make sense because a widget should never interact with a service. The furthest any UI goes it to call functions on a viewmodel. Only ViewModels talk to services.

[@CalibrationExtreme]

Very much enjoying your 2-part series on Flutter architecture. I'm hoping to work through the code, but am not finding code on Github which matches videos. For example, the written article has a "view code" link, but it doesn't take me to code for that article. Instead, it takes me to ALL the code you've published. At that point, I'm faced with trying to determine what code folder matches the video. Closest I can find are "010-provider-architecture" and "012-provider-architecture-pt2". Are these correct? In these, I see a folder structure under "lib" of simply "core" and "ui". That doesn't match the videos so I'm confused. Would appreciate your shedding light on this. Another thing I'm finding confusing is the playlist for this series. Of the 5 episodes in the channels playlist for "Flutter Architecture", I'm showing two duplicates: 2 of "Complete Flutter Architecture using Provider and Stacked" and 2 of "State Management with Stacked in Flutter". The duplicate pairs have the exact same time length. The 5th episode shows "What are Services and How to use them in Flutter" which is unique. Is it possible there is an error in how this playlist was created, missing one or more videos? Or am I just missing something? Thanks for any feedback and assistance.

[@FilledStacks]

Awesome to hear. You're right, I need to update my links. The xample is here. github.com/FilledStacks/stacked-example. Playlist error just seems to be an error. I'll remove the duplicate ones now

[@shanep.7184]

This is similar to Apple’s approach with SwiftUI and the ObservableObject protocol. Nice to see I can do something similar in Flutter

[@FilledStacks]

Awesome! I did not know that, I haven't tried out swift UI for a production application but I'm happy that's the case. Sounds like you can build some readable applications in there :D

[@shanep.7184]

FilledStacks Yeah I think we can learn a lot from different platforms. SwiftUI has some really powerful features and very few boilerplate code

[@FilledStacks]

@@shanep.7184 Yes. That's something I'll also be exploring. Bringing patterns from other frameworks that will work well with Flutter and making use of that to reduce the code required to write apps.

[@PrakashIndorkar]

Brilliant Architecture for startups.. Just a request to please provide the updated code/modification that we need to do due to the upgrade of packages. It takes a bit of time to understand how to introduce the new changes on your tutorial sample code.

[@FilledStacks]

Thank you. I'd recommend checking the readmes of the packages being used since they do a better job at keeping the docs up to date.

[@wepranaga]

Architecture. so cool. so bold

[@FilledStacks]

:) Architecture is pretty cool

[@jasmeetsingh7356]

Hey Dane, this is what I was seaching from past few weeks... This video has brought new hopes into my project... You have mentioned about get for navigation in your video.. I am not able to get any video explanation for it ... Can you help me with it....

[@FilledStacks]

Hi Jasmeet, I'm very happy to hear that it has helped you. I show it in the video. I use get through the navigation service. it's in the stacked services (github.com/FilledStacks/stacked/tree/master/packages/stacked_services ) . All you have to do is set the navigation key for the application in the main file.

[@jasmeetsingh7356]

@@FilledStacks Thank you Dane, it really helped...hats off to you guruji 🙏. I am eagerly waiting for the part 2.....hope I see it soon..😊

[@FilledStacks]

I'm hoping to make it soon. Just have to finish the written then I can start the recording.

[@hemachandrang6284]

Sir, your content is so good! Looking forward to seeing a tutorial video on using dio_http_cache package! :D

[@FilledStacks]

Thank you, I appreciate it. I won't be making a tutorial using that package because I'm not using it in production :)

[@kohbee2172]

While using this with BottomNavigation I'm getting an error that model is disposed. Is there a way to avoid that?

[@FilledStacks]

Yes, set disposeViewModel to false for the ViewModelBuilder.

[@kohbee2172]

@@FilledStacks Not sure where to use this, can you give an example? Should that be a part of the dispose method in BaseView?

[@kohbee2172]

Turns out that I wasn't using Stacked. Will use it to fix this, I guess.

[@wickedgummybear3104]

Although I love this new way of setting everything apart, can you tell me how you register your shared Preferences? Because in your snippet you actually register that differently, with an instance etc.. would like to know.

[@FilledStacks]

I'm presonally registering it with injectable by adding the annotation on the class definition and running flutter pub build_runner build. But you can register it normally without injectable.

[@wickedgummybear3104]

Yea that doesnt seem to work for me. For some reason that is not doing the same as when I create an instance and register that as a singleton. When I let your service generator do that, it just doesnt work. And I cant find a file of your with a proper working model. But thats ok. This way might not be pretty but at least its working.

[@FilledStacks]

@@wickedgummybear3104 True true, if it's working then stick with it. No need to introduce broken things into the mix. Good to know you can move on with it.

[@jondoe79]

Superb content 👌

[@FilledStacks]

Thank you Kind Jon Doe

[@amonchowdhury7731]

Perfect. Please carry on!!

[@FilledStacks]

Thank you. That's my plan :)

[@amonchowdhury7731]

@@FilledStacks Advanced thanks

[@dam.s]

I am unsure if changes made to auto_router (aside form the syntax for generating the gr.dart file with a List of s within @MaterialAutoRouter) have made the following necessary, or if I missed a step or import somewhere: 16:00 "onGenerateRoute: Router().onGenerateRoute" throws error "dart(ambiguous_import)" as Router() exists in the imported router.gr.dart and within 'flutter/src/widgets/' My solution was to "import 'app/router.gr.dart' as AR;" then provide initialRoute and onGenerateRoute properties with AR.Routes.startupView and AR.Router().onGenerateRoute respectively. Crazy how quickly things can change! Maybe if I had used the same package versions as in your video, things would have progressed fine for watching the tutorial, but you do not provide versions in your pubspec. Anyways, what a great series so far. I will be following along and rebuilding my month-old app in the process. :)

[@FilledStacks]

Hey @Adam Skelton , that's the 1 thing with that flutter has against it for now. It's so young that libraries are rapidly changing. I think this changed about 2 days after the video haha. The same with my dialog video. That literally changed 1 day after when I got a PR that did a much better implementation of what I was trying to achieve. But that's how it goes for now. Thanks for watching and leaving a comment. I tend to leave out version numbers, maybe i should put it in from now on.

[@dam.s]

@@FilledStacks When I watched your second video, you did a FANTASTIC job showing yourself updating the pubspec, even describing how the version should change by the time we watch the video as you were rapidly making progress with stacked during filming. As for the other packages, a simple reminder somewhere in your video or description that this sort of thing is prone to happen wouldn't hurt. I'm new, so checking out the packages on pub.dev for changes was not my first thought when I came across troubles. You're accelerating my progress, for sure! Thanks for all your efforts on your site and channel.

[@cf92321]

Love how you make complex provider architecture amazingly simple and maintainable. Just done migrating to the new version, looking forward to the series! Question: how would you go about ensuring some services (e.g. a firestore service with various streams/futures) don't become super cluttered in more complex apps? (Also, slightly off topic, has your team been dealing with any payment/checkout services in flutter? Many of the Stripe packages seem to be of questionable quality so I'm trying to find out how checkout might currently be best accomplished for production-level flutter apps)

[@FilledStacks]

Hey Eriksson. Thank you, I try my best to keep things simple, it seems like it's working. Some people even think it's not worthy to be called an architecture. Must be very simple then haha. When it comes to my services I apply the interface segregation principle. "No client should be forced to depend on methods it does not use." The client here being your viewmodel or service. When only 50% of you're services functionality is being used in multiple places you can probably split it into two and maintain them separately. More files but less code to deal with at a time. And yes, we've done payment integration, we don't have stripe in South Africa so not with stripe. But I've integrated PayFast twice now into two different apps.

[@cf92321]

Thank you! This makes perfect sense. Have been obsessively avoiding multiple Firestore instances but putting all streams in one service was indeed pretty stupid. Feels like architecture principles for complex apps is one of the real growth areas for Flutter, so again, great with this video! Happy to hear that payments can work. I guess you rely on platform integration or url_launcher for PayFast? Was myself forced to pick Stripe to achieve marketplace-style payouts functionality while ensuring EU compliant form inputs. Still hope to avoid testing hell. Think whoever makes a thorough tutorial series on payments will be rewarded handsomely by the community 😅

[@FilledStacks]

I wish we had stripe over here! I'll be integrating it for a US client soon and I'm uber excited!

[@ajinkyax]

great video, but the only thing which I didnt lile about stacked package is that it used flutter packages as dependencies which is not good in dart as backend in monolith apps.

[@FilledStacks]

Thank you. Yes, this is built for Flutter, not dart. It's specifically for a front end application since backend I would be using a purer approach for state management to remove the viewmodel and view from the equation since there's no UI in a backend.

[@homecasfm8578]

I think this video needs updating, even so it's still great

[@FilledStacks]

I totally agree with you. I'll make a new setup video soon.

[@sahil-jx7py]

@@FilledStacks have you done it??

[@FilledStacks]

@@sahil-jx7py I have only done it for web

[@sahil-jx7py]

@@FilledStacks thanks for the reply, i'm binge reading your articles and plan on to use stack, thanks for all your awesome contributions and informative videos, love from India!

[@usmanhafeez743]

Thank you so much for this series... I have a problem, I'm using stacked, and stacked services for Navigation, the Problem is when i start the app first two routes take a delay to push maybe around 1s ... This happens only when i open app, if i pop the route and then navigate again it goes smooth... There is not any logical work... Its only UI build yet... Please help me

[@FilledStacks]

Hey, I haven't seen that. Generate a new stacked project and reproduce the issue then file an issue for it on github, we'll look at it.

[@usmanhafeez743]

@@FilledStacks okay, thank you so much

[@DguruZ]

Dude. I love your vids, keep doing

[@FilledStacks]

I will try my absolute best to keep producing videos.

[@abcd56957]

Hello, If there's an argument passed to the VIEW..... how can the VIEWMODEL retrieve that argument and process?

[@FilledStacks]

Pass it in to the viewmodel when you construct it.

[@jameshancock]

This is great! Do you have any examples for doing forms with validation without pain that doesn't induce redraws etc.? Bloc is horrible boilerplate for this and I'd love to see your ideas on forms.

[@FilledStacks]

Thank you, I have only recently introduced for form generation into the package. It's not complete so there's no clear built in validation but we update it in real time at the moment in the viewmodel through our generated listener. If you go to the stacked package readme you can search for forms and see how that looks.

[@abomohmd505]

I'm having an error when trying to navigate from the startup view to the home view, surprisingly when I change the home view to a simple scaffold without a ViewModelBuilder the navigation works, this is really confusing me!! the error : The following assertion was thrown during a scheduler callback: There are multiple heroes that share the same tag within a subtree. Within each subtree for which heroes are to be animated (i.e. a PageRoute subtree), each Hero must have a unique non-null tag. In this case, multiple heroes had the following tag: Here is the subtree for one of the offending heroes: Hero ] tag: state: _HeroState#31b64 When the exception was thrown, this was the stack #0 Hero._allHeroesFor.inviteHero. package:flutter/…/widgets/heroes.dart:266 #1 Hero._allHeroesFor.inviteHero package:flutter/…/widgets/heroes.dart:277 #2 Hero._allHeroesFor.visitor package:flutter/…/widgets/heroes.dart:296 #3 SingleChildRenderObjectElement.visitChildren package:flutter/…/widgets/framework.dart:5817 #4 Hero._allHeroesFor.visitor package:flutter/…/widgets/heroes.dart:309 ...

[@FilledStacks]

Sounds like you have multiple hero widgets, with the same key that are not related.

[@IngPedroAraujo]

Are these video series updated with the new Stacked version? thanks for sharing your knowledge.

[@FilledStacks]

It's my pleasure sharing the knowledge. The video is 3 years old it's not the latest. All the concepts are still up to date, there are some minor changes in how we bind view to viewmodel but everything in here should still work. The docs and the latest videos on the channel will have the updated info. stacked.filledstacks.com is where you can find the docs.

[@IngPedroAraujo]

@@FilledStacks Thanks you for your answer. I hope soon to enroll your flutter web course. I have limitations I'm a venezuelan in Colombia.

[@suportewambo844]

on the Navigation the @initial is returning "undefined name 'initial' used as an annotation

[@FilledStacks]

It has been removed as an annotation. Check the latest readme for auto_route.

[@aseemshrey400]

It would be great if you could also cover state changes due to data deletion or favoriting a post or some other state changing operation. However with the json placeholder api, I don't suppose that would be possible.

[@FilledStacks]

I will make it possible!! :) I'll try to incorporate that in there as well.

[@lisualcam]

It is incredible!! 😀

[@FilledStacks]

Eyoooooooooo!!! Thank you :)

[@RobertRobinson777]

We are expecting more videos using this architecture like authentication (Firebase , custom), Api services, themes,etc

[@FilledStacks]

I know :) There will be no Authentication since I've just finished my firebase series. There will be no firebase sine I've just finished a 10 episode firebase series. Nothing will change from that implementation besides the class names from the package. Other things I'll be making though :)

[@tammaibigin]

I saw the stacked package had version 2.x.x. Can you make another video that explains something new such as application setup with stacked_generator. I'm new to Flutter and greatly appreciate learning from you. Thank you!

[@FilledStacks]

There is another video for that already. kzbin.info/www/bejne/Z4i6aat-nb-pr6M

[@FilledStacks]

@@maichitam you're welcome :D

[@rabi_roshan]

looking forward for a collaboration video of @FilledStacks and @resocoder

[@FilledStacks]

Me neither. I have a great idea for a video that we can collaborate on that will definitely help the community out.

[@shubhammittal9764]

Hey brother. I want to use GetX package for State, Route, and Dependency Management in my project. Can you give some tips for setting up a robust architecture using GetX instead of Provider?

[@FilledStacks]

Hey there, yes. You can do exactly what I do but replace everything where provider is used with getx. There's a package on pub called stacked-getx which does exactly that. it's the same architecture, but uses getx instead.

[@JahirAlam]

Great to learn such a clean code. Can you tell about unnecessary rebuild ?

[@FilledStacks]

Awesome. Yes, it's in part 2 that just came out :)