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.
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!!
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 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 :)
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!
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.
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.
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.
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
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.
@@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.
@@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.
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!
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.
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.
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.
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
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.
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.
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 :)
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.
@@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 :)
@@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.
@@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.
@@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!
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.
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(), ); } }
3. And then in the generated locator.config.dart: Replaced {String? environment, _i2.EnvironmentFilter? environmentFilter}) { by {String environment, _i2.EnvironmentFilter environmentFilter}) {
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
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...
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.
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!
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!
@@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.
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'.
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
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!
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
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
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! :)
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!
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.
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 👍
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
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.
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.
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.
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!
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.
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
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.
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.
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.
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.
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.
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.
@@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.
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...
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 !!
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.
@@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 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.
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.
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.
@@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.
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.
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
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 :)
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.
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/
@@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?
@@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.
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!
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.
@@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
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.
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.
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?
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.
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 😍😍😂
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!
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.
@@FilledStacks Sería estupendo tener traducido tan fantásticos tutoriales ^^ y seguro, que al igual que yo, hay muchas personas que lo agradecerían ^^.
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.
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
@@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.
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.
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
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)
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.
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!
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.
@@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!
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!!!
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.
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 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.
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.
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.
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.
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!
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.
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.
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.
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....
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.
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?
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.
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 ...
Suppose if I want user data in all the screens and if i have option to edit profile how could i notify those changes through out the app ? I am following your provider architecture and my base viewmodel has the get current user function.
i would call notifylisteners in my user service (if it's a reactive service) which will force all the listening viewmodels that are still alive to update their UI.
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.
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
I love this Architecture but how can we use two or more viewModels in one View .. like in provider management we could use provider.of in build method .. and can listen to any we want.. how can we achieve this using stacked ?? :3
It's made so that you don't do that because you would never have to. ViewModels should not know about each other. One per view, if you want to share data use a service that's injected into both viewmodels.
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
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. :)
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.
@@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.
BIG PROBLEM HERE DANE!! Seems like the MultipleStreamViewModel is calling the stream every single time it gets a new item, leading to many many reads on something like firestore. not sure if this is the package or some how i have made a code error but maybe double check with some print statements. my stream is getting called multiple times
@PostMaloy the ViewModel doesn't call the stream at all. It only listens to it :) It will rebuild the ViewModels attached UI EVERYTIME a new value is emitted. That's the intended behaviour.
At the moment we use reactive service so when we call notify listeners in the the service (inherited from ReactiveService mixin) then it rebuilds the viewmodel.
Isn't it the same as MVC design pattern used for the past 20 years in software engineering? And IoT have been present in Spring framework for Java since 2004/2005 ....
It's probably very similar. This architecture is actually based on MVVM, but MVVM explicitly has 2 way binding so this doesn't qualify as MVVM. In MVC the controller actually has access to the view to allow for the UI updates, in this architecture the ViewModel should have no reference to any of the UI files, or types. So it's basically a frankenstein of MVVM, MVC and service location over dependency injection :)
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?
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.
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.
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.
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.
@@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.
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)
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.
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 😅
