Flutter TDD Clean Architecture Course [1] – Explanation & Project Structure

keeping your code clean and tested are the two most important development practices in flatter this is even more true than with other frameworks because on one hand it's nice to hack a quick app together on the other hand larger projects start falling apart when you mix the business logic everywhere which is so simple to do with flutter because even the UI is written in the same programming language in which you write the actual logic even state management patterns like block are not sufficient in themselves to allow for easily extensible code base and this is where we can employ clean architecture and test-driven development as proposed by our friendly uncle Bob Robert Cecil Martin we should all strive to separate our code into independent layers and that's precisely what you are going to learn how to do in flutter in this course Oh [Music] welcome to resew coder where you're getting prepared for real app development by building better faster more stable apps so subscribe and hit the bell if you want to grow your coding skills and learn about clean architecture in flutter let's start out with the completely finished app which you will have built by the end of this course we're gonna build a number trivia app because believe it or not there is actually a numbers API which provides some nice trivia about numbers so we can input a number here for example 1 2 3 and then search for the trivia let's search for it another number for example 42 right and we can also get random trivia this is another endpoint on the API and then also this app will cache the gotten number trivia from the API so that if we should not have internet connection so if we enable airplane mode here and come back to the app and get random trivia it's not going to get us any new trivia is going to display the lastly gotten cashed trivia of course once we enable internet we'll be able to again get new trivia just like before this app has all of the core components which you will be working within your own apps on day to day basis such as getting data from API local cache error handling for example if we input ABC with a keyboard you can do that so input that it says invalid input the number must be a positive integer or 0 it has like input validation and all that good stuff which you should have in production apps and as for state management we're gonna use block but you do not have to use block because as you will see later on in this course as we progress it will become apparent that the state management which you choose is really almost inconsequential because everything will be handled in different layers so the bottom line is do not worry if you do not want to use block in your apps you do not have to clean architecture works with any kind of state management pattern even something like simple change notifier with a provider will be just fine and be sure to check out the written tutorial from the link in the description if you want to really go through this at your own pace because this first part will be more about theory behind clean architecture because we cannot progress forward in this course without first understanding the core concepts of clean architecture and why it's actually useful and why does things the way it does them and in the written post accompanying this first part you have all of that available and you can go through it at your own pace so let's first take a look at the clean architecture as it was proposed by Uncle Bob so it looks something like this and really it doesn't tell us much when it comes to full adder because like what is a controller what is presenter gateway what is all of that it just spits out a bunch of abstractions in our face and all in all it's a bit tract pun intended also well the essence of clean architecture remains the same for every framework the devil definitely lies in the details and we will have to adapt this general clean architecture to flatter so lo and behold because now I will introduce to you the reso coders flatter clean architecture proposal yes it's an official thing now which will demonstrate something should I say more important than just some dependency flow and the onion it will show you the data and call flow it may seem like there's a lot to comprehend here but do I worry we are going to get through this slowly one by one so the core thing here is that the whole app or or should I say every core feature of an app like for example getting number trivia will be divided into three parts three layers presentation domain and data and actually the app we are building this number trivia app will have only one feature because it's a simple app the only thing we do here is to get number trivia so we'll have only one such division into folders so let's actually create these presentation domain and data folders right now so let's open up vs code we are starting off with a completely new project here and I will enlarge this so you can see the folders even better so inside the lake folder we are going to start off with creating a features folder because every feature as I said will have its own folder which will be divided into presentation domain and that so let's just create the folders and then I will explain everything more in depth so the feature name will be simply numbered trivia you can have feature like login or registration or something like that you can have feature settings and so on if you have those things in your app we have just one screen number trivia and that's it in here we want to create domain then another folder will be data and the final one will be presentation and with this we have the basic structure the most high-level structure of our app created of course just having features is not in now because what if for example you have something which can be used across multiple features let's just say that you have also settings feature and even over there you want to do input validation well input validation for example just checking if the inputted text doesn't contain any numbers that's not really feature specific it can be shared across number three we are settings whatever that kind of functionality will go into the core folder alright now that we have the basic folder structure let's continue on with this awesome diagram let's take a closer look at the presentation layer which is actually what you are already used to in flutter if you've done any kind of a flutter development before so presentation is comprised of widgets so this is where all of the pages live for example number trivia page and this is also where you will have your own custom widgets and then it also has something called presentation logic holders which is either a block a change notifier or really anything which you would classify as state management you can even go the good old stateful widget route but I would really recommend you to at least go for a change notifier but I really think that block is the best state management option for flutter out there but really presentation logic holders they're not all that important which you choose we are going to choose block for this app and as opposed to what you may be used to these presentation logic holders so block or change notifier will really not do much by themselves they will only delegate all of their work down to use cases to the domain layer and so on blocks or change modifiers will be really only in classes they will not have a lot of logic at most you will do some really basic input validation inside of them and that's it everything else will be delegated to the next layer which are use cases or the domain layer before we continue with the next layer let's just jump into vs code and let's create the structure of the presentation folder right now so we're going to create a new folder under that it's gonna be called block again you can use anything you want and then pages and finally widgets which will be just widgets which we do not want to have directly inside the page because it which is clutter up the UI code the next layer we're gonna take a look at is the domain layer as you can see in this call flow arrow the call flow will happen from the upward layers so presentation down so this presentation logic holder for example a block will delegate its work and call use cases which are from the domain layer so what is actually the domain layer this is the inner layer which should not be susceptible to the whims of changing data sources or porting our app to angular Dart it should be really platform independent and actually independent of anything else inside the app it will contain only the core business logic which will be executed inside use cases and then also be these objects which we are going to call entities and by the way use cases are classes which encapsulate all the business logic of a particular use case of the app so for example we will have use cases for getting concrete number trivia right here which will be executed whenever we press the Search button here so this is get concrete number trivia use case and then another use case in our app is get random trivia so those will be two classes get concrete number trivia and get random number trivia of course in our app we will not have a lot of business logic and even the entity which will hold the number trivia actually they're gonna be pretty lean classes because we are not doing much in this example app but in your own projects when you are building something more substantial the domain layer is where the bulk of the code will be located and if you've been listening to me carefully I've said that the domain layer should be completely independent of every other layer well I know that you probably cannot tell not just from this diagram but it seems that the domain layer is independent of the presentation layer but here it gets kind of fancy looking because the repository is seemingly inside the domain layer and also in the data layer right so what's up with that half of the repository is domain and half is in daraa note that's not how it works well this nice fancy gradient under repository signifies is dead the repository class is on the edge between data and domain layers and to allow for the independence of the domain layer we are going to do something called dependency in version so what is dependency inversion I know that you may be getting some goosebumps because there are just scary words dependency inversion is in essence very very simple and straightforward it's just a fancy way of saying there we create an abstract class repository which will define a contract of what the repository must do so for example in our app we will have a repository which must provide us with random trivia and concrete number trivia those are the two things which the repository gist must do and that goes into the domain layer the domain layer does not care how the number trivia will be gotten it just cares that it will be gotten right this is all possible with an interface or because dart does not support interfaces we have to use abstract classes and then the other side of the coin or in this case repository is inside the data layer the data layer will define how the data will be gotten and managed and all of that we're gonna get to that in just a short while but the important thing is that the repository in the data layer will implement the abstract class so it will have to conform to the so-called contract so that domain can really not care what's going on behind the scenes it just knows what kind of data it will always receive from the repository in this case it will be the random number trivia and concrete number trivia so let's create a folder structure shall we inside vs col the domain layer will have three subfolders entities which will be the number trivia entity which will simply hold the text of the trivia and the number of the number trivia then we will have also another subfolder repositories this is where the contract or the abstract class of a repository will go and then also the last folder is use cases so use cases or get concrete number trivia and as you can see there was some server failure now so error handling works correctly but I don't know why there was a server failure but anyway now we have 42 so this is the concrete or get concrete use case and we also have the random use case and let's now move on to the data layer as you already know it contains repositories which implement the abstract classes from the domain so that they will have to just fulfill the contract defined by domain and then it also contains remote data sources local data sources any kind of data sources obviously go into the data layer usually you have one data source for getting remote data from the API and then you also have another one for getting local data in our case we will use shared preferences to cache the data locally and local data sources are also where you would have your for example GPS location code and all of that good stuff data sources do not have to just operate with data bases they can also operate with the underlying platform or device and the repository is the brains of the data layer because this repository will decide when to cache what to cache when to get data from the remote data source when to get error from local data source so for example if there is no internet connection we definitely want to get data the cached data from local data sources and you may notice that repositories output entities which kind of makes sense and again entity is just the number and the text of the number trivia really simple in our case but data sources do not output entities they deal with something called models and this nomenclature is really not all that important it doesn't matter how you call these things it's just that you know what those names mean and the reason behind having models is they're transforming raw Veda which is for example json requires some conversion logic because we cannot work with json in our app we have to convert it to dart objects but now let's think about this we definitely do not want to put our JSON conversion logic so to json and from json as we are all used to for example from built value or json serializable we do not want to put those conversion methods into entities and why is that well entities should be completely platform and data layer independent so for example if we switch from JSON to xml or to some binary data craziness we do not want to change the domain layer at all we only want to change the data layer when something data related changes but the domain should remain untouched therefore these models will be simple classes which extend entities and add some functionality on top of them and because they are subclasses of entities we can then simply cast them into entities and the repository will output the entity which does not have any additional functionality or fields added on top of it in the number trivia absence we do not have anything really difficult to do models will have only to JSON and from json methods but if you are storing something locally in an SQLite database and for some reason you have to have the ID inside the database stored inside the model you can also add some custom fields to the model not just methods in our app the remote data source will perform an HTTP GET request to numbers api which is simply numbers API comm and all of these links in all of that which I'm explaining here is also available from the written tutorial so definitely check that out but here his numbers API comm this is the API we will be using so as you can see we can get random trivia right this is what we are doing from within the app so this is what the remote data source will do it will perform and get requests and then we have also local data source which will simply cache data using the shared preferences package and then these two data sources will be combined sort of in the repository which in the case of the number trivia app it will do just a simple thing it will check whether or not the user is connected to the internet if there is internet connection it will always prefer to get fresh data from the remote data source if there is no internet it will get the cached data and it will also have a simple caching logic which is that we always cache everything as soon as it's gotten from the API so that if there is no internet connection it will always return the cached data the last cached diet to be precise all right so let's now create the folder structure even for the data layer because the things below are not actually a part of our app these are some external things we do not care about them it's not a part of our code base and the data layer will be comprised of data sources models and finally implementations of repositories so the repositories folder in data will hold the implementations and the repositories folder in domain will hold the abstract or interfaces which are the contracts which the repositories implemented in daraa must fulfill and again this abstraction is necessary so that the domain layer can be completely independent of every other layer all right so this first part of this test driven development clean architecture Flattr course was really theory heavy that's because something like clean architecture requires a lot of explanation because after all you cannot just start building a house without first planning how the house will look like you have to have at least some basic structure some basic drawings in place and these drawings were laid down in this first part so in the next parts we are going to actually get coding and doing test-driven development and we're going to start off with this domain layer so if you do not want to miss that tutorial and more other tutorials like this definitely subscribe to this channel and also join the notification squad by hitting the bell button to make sure you grow your flutter skills because here on reso coder I am determined to provide you with the best app development tutorials and resources out there also make sure to check out the written tutorial available from the link in the video description to go through all of this at your own pace you will highly benefit from reading the written tutorial if you want to learn the most about clean architecture which I'm sure you want to do if this video helped you with clearing the concepts of clean architecture give it a like and also share it with our developers who will surely benefit from this to follow me on Instagram I go under the name reso coder everywhere leave a comment if you have anything to say any suggestions or questions stay tuned for the next part in which we are going to finally start writing code doing human development and see you in the mix [Music]

Channel: Reso Coder

Views: 136,549

Keywords: resocoder, tutorial, programming, code, programming tutorial, clean architecture, software development, flutter clean ui, flutter clean architecture, flutter clean code, flutter testing tutorial, flutter tdd, flutter test driven development, flutter crash course, flutter course, flutter, flutter tutorial, flutter dependency injection, flutter state management, flutter bloc library, flutter unit test, flutter mvvm, flutter mvp

Id: KjE2IDphA_U

Length: 24min 36sec (1476 seconds)

Published: Tue Aug 27 2019

Reddit Comments

[u/sherlock_beard]

Happy cake day