Cleaner Code With Use Cases - The Full Guide

hey guys and welcome back to new video in this video i will explain and show you what use cases are in android how you can use these to to make your code a cleaner place and basically yeah everything around that without making a full video about clean architecture i already do have two videos about that so feel free to check them out and see how i use use cases in practice however i will show you a practical example here otherwise you will not really understand it i think let me start with what use cases actually are i'm sure most of you will maybe have heard of these or maybe not so a use case in the end makes up one layer of clean architecture so that is just um an approach by our good old uncle bob that basically builds upon an existing architectural design pattern such as mvvm so when in mvvm we had our ui our view model which contained the business logic and the data layer now we have an additional layer which are the use cases and these use cases sit between the view model and the data layer so the the repository most of the times and the use case just describes a single thing a user can do in your app you can already see a little example here this is from my social network app that i built live on twitch so in case you you didn't watch my streams yet then check down the link below and simply follow me on twitch to not miss these streams in case you did miss these and you really want to watch these and the past streams in which i built this app you can see that is already quite a big app here with all these classes then you can also hit the join button here on youtube and for a few bucks a month you can get all the recordings from the past and in the future however let's get back to use cases here you can see that is a register use case and well i don't need to tell you what it does it actually registers a new account so it contains the logic the business logic now to register a new account which logic is that well when we want to register new account we need to validate the email the username the password and stuff like that here i use the utility class for that because we needed these functions on multiple places in our app not only in this use case but in the end that is business logic to check if something is a valid email if a field is empty maybe and if there are some errors we just return that in from of such a register result class and if not we will actually call the repository and register the new user using our api so what we initially put into the viewmodel which was this year because initially we put the business logic in the view model that's now part of the use case and we don't put this in the view model anymore so if we actually now take a look here in our register view model here in our register package here is our register view model then you will see that we will actually inject the use cases now into our viewmodel and not the repository anymore so initially the viewmodel directly accesses accessed the the repository to register new user but since now the business logic is located in the use case the use case needs to access the repository and the view model needs to access the use case so you might now wonder how many use cases does your app actually need and for which actions you really need a use case and for which you don't so let me tell you how most people actually think wrong about that they think they need a use case for every single repository function they have so for example for registration login for saving something in the database they think for all of that they need a use case and yes that's true but it's actually the other way around you have a repository function because you have a use case any use case just let me give you some more examples could for example be as we said registration it could be a login but let's scroll down here to for example our profile feature here we have a use case package and just take a look at this package we have a use case for getting posts for a specific profile we have a use case to get profile data to get the skills for profile we have a wrapper class which i will get to in a moment searching users we have setting the skills toggle follow state for user so there are there are some use cases that don't actually require the repository i think it's actually this set skill selected one for example you can see this does not need a repository but it's still a use case because it contains business logic so all this use case here does is um we basically have some kind of uh chips i think we call it an android and we can toggle this by clicking and this use case basically takes the current list of selected skills it takes the skill that we want to now toggle to select it or unselect it and then it uh yeah just contains the logic to do that important is also that a use case should only contain one single public function that is exposed to the view model so that means you don't have multiple public functions here in this use case you can have private ones which you just use as a helper functions here in this inside of this use case but only one single public function that's exposed to the viewmodel that the viewmodel will then call and you might also see a notice that i use operator functions here so we override the invoke operator here that is something i just like to do because that way we can call our use case like a function even though it's a class some people also just like to not do this and call this maybe execute or so so then that would be the public function that the view model would call then it would basically just call here uh set skill selected.execute but i like to do this because that way if we take a look in our register view model here you can see that is where we execute the register use case and even though that is a class we can treat it like a function and the function just implies that we execute something so that is why i really like the way of overriding the invoke operator i also usually like to work with this resource class here if we take a look at that you will see it's basically just a wrapper class that either can be a success state or an error state if it's an error it can contain some kind of message here and data and if it's successful it will contain data so let's see how we can make use of that here in the use case we will basically always have some kind of business logic and depending on what kind of input we get the result here will either be successful or not and if it's not not successful then we just want to provide some kind of error message to show to the user so here we just have the skill in our current list so we find the one then if if there is a skill in the list we basically just want to return a successful resource with the new list of skills so we basically just remove the the skill that we want to unselect in this case and if we already have three skills in this case selected then this should not be successful so i only want three skills to be selectable at maximum in my app so in that case we don't want to do anything and we just want to return an error instead with the information you can only have um so much top skills at a time so that's just how i take the result from a use case and forward it for to the view model in the view model i know this is now registration but it doesn't matter we can then just uh get the result of our use case and just check okay was that successful or was there an error something i also like to do is when there are a lot of use cases for a single feature like we have here for example for profile feature you can see this package is quite big then i like to have such a wrapper class that contains all use cases here because that way we just need to inject the wrapper class into our viewmodel let's take a look here for example in the profile screen profile view model here you see we only actually need to inject this profile use cases rapid class because with that wrapper class we can access all these single use cases that belong to the profile feature if we wouldn't do that we would have all these use cases and we would need to inject these um right here in our view model and you can see how quickly that actually gets messy so that is not what we want to do that is why i usually include such a wrapper class if we only have a single use case for review model then i usually inject that right away but as soon as we have two or three then i use such a wrapper class let's actually get to the reason why we do all this so i think now you understood how use cases work and how you can implement them in your project but you don't yet understand why we really use them and there are mainly three major reasons why i suggest to use use cases there is also a scenario in which i don't recommend using these which i will come to at the end of this video but let's get to the advantages first number one advantage is that it makes your business logic reusable so let's take a look here in our profile use cases we have a use case to get the profile data so that contains the profile image it contains the description and yeah just some more stuff doesn't matter here putting this in a use case makes the the code the business logic behind that reusable because you can see here we have that in our profile view model which just displays one user's profile but we also do have an edit profile view model and when we edit our profile we also need to load our profile data so we have two view models essentially and in both of these view models we want to load profile data so in both these view models we access this use case this uh get profile use case i think it was called this one but we only specify the business logic at one place and that's the use case if we wouldn't have that use case that would mean in both of our view models we would need to put in the logic to load a user's profile and that would be duplicate code and if you have more view models that actually need to need that code to load a profile then you have even more duplicate code so use cases definitely eliminate that duplicate code reason number two why you should use cases is that they lead to a screaming architecture that's a term i actually read in a blog article once and i really like the term because let's take a look at this use use case package a screaming architecture is basically in this case a set of classes that screams at you hey this is what we do so you don't need to be a chuck norris here to understand what what kind of code is inside of these classes so if you're new in a team maybe and you you first look at a big project and it's super overwhelming for you then these use cases and the naming we choose for these is actually pretty clear because you immediately know what kind of code you will find inside of these classes and reason number three why you should use use cases is that they prevent so-called guard view models a guard view model is well you can pretty much guess it it's it's a view model that contains way too much code that does everything so if you have a really complex screen that has one view model then that view model will contain all your business logic of of that single screen and that can become very big and very messy with the use cases you just take these parts and these bits of your business logic and extract them into single classes so you have multiple classes for your business logic per view model and by the way you might also ask yourself what does the view model now contain if we put the business logic in the use cases away from the view model all the viewer model really does is it will it will execute the use cases and provide the result in form of observers or observables to the ui so that can be a live data that can be a compose stage state flow so all the viewmodel does here is you can see it it maps results to to state it executes use cases and then checks okay if it's successful we use this state if it's an error we use this state so that's now the job of the view model let's get to the final point when i suggest not to use use cases and that is if you have a not so complex project because very often all use case does is just calling a repository function uh maybe we can find one here i think um probably even the get profile use case here yeah you can see all this does is it calls a repository function and in smaller projects most of your use cases will do that then this is just over architectured i would call it so for smaller projects i would just put your business logic in the viewmodel and use a repository or so but as soon as you really want a scalable project that is extendable and stuff like that i would really suggest to include that use case layer between your models and the data layer because it really really helps you to to make your code clean extendable and more understandable so i hope this was helpful for you if so please let me know below if you actually used use cases before in your app or interactors some people call it interactors and what's your experience with that so we can actually also see some other people how they liked it if you if you'd rather stick to playing mvvm or if you like clean architecture and using that use case layer between view model and repositories if you want more of such advice for free of course then feel free to subscribe to my newsletter down below then you will get a regular android kotlin architectural advice right into your email inbox for free so click the link down below subscribe to that and i'll see you back in the next video have an awesome day bye bye

Channel: Philipp Lackner

Views: 8,995

Keywords: android, tutorial, philip, philipp, filipp, filip, fillip, fillipp, phillipp, phillip, lackener, leckener, leckner, lackner, kotlin, mobile

Id: ufq3LJ-5P6s

Length: 14min 16sec (856 seconds)

Published: Wed Oct 20 2021