5 Android Dev Mistakes I've Done in the Past (PLEASE AVOID!)

hey guys welcome back to a new video in this video i will show you five mistakes regarding android development that i actually did in the past and that that you shouldn't do in the future so i will help you prevent these mistakes because i have already done this so let's actually get straight into it number one is actually not using view lifecycle owner in fragments for the life cycle so i've prepared a little little fragment here and that is an app essentially that just consists of two fragments and we can navigate from fragment one to fragment two nothing really special you can see we have a button and uh i assign an on click listener to navigate to the next fragment and then here we also have a flow which basically just delays for five seconds and that emits a value which we collect here in a curtain that we launched in lifecycle scope that looks correct but it actually isn't and that's a mistake i i've done for a while that i did it like that because let's actually take a look at this app if we relaunch this then after five seconds we should actually see the emission of our flow here and it will just show this toast here saying emission so if we take a look here and then wait for five seconds we will see a toast that says emission so far so good if we actually relaunch this then click next without actually waiting for five seconds then you think okay the the creatine should actually be cancelled because we use lifecycle scope it is bound to the fragment lifecycle so we shouldn't actually see this toast that says emission and we don't if we take a look we don't see a toast but if we now go back you see we immediately see the toast and if we now wait for five more seconds we see another toast so we have a duplicate emission here which is usually not what you want let's think about why this actually happens so what happens if we click next here and navigate to the next fragment well the fragment lifecycle of our first fragment isn't actually fully finished but if we use lifecycle scope here and use basically this as a life cycle so the life cycle of the current fragment then this will stay active when you actually navigate away so we won't collect in the in the same time but when we when we actually navigate back this will immediately fire off and that is usually not what you want what people instead want and often don't use because they don't know that is that they should use something called the view lifecycle owner so we should explicitly say vue lifecycle owner that lifecyclescope that launched when started because that now does not refer to the fragment life cycle instead it refers to the to the view life cycle of the fragment so when the view is destroyed this curtain will be cancelled and the view is destroyed when we actually navigate away so let me relaunch this app using this real view live cycle owner taking a look here if we now click next without actually seeing the the toast before and then navigate back we don't see it toast immediately we have to wait five more seconds to actually see the toast and we don't we don't get a duplicate emission here which is which is exactly what we want let's get to mistake number two that i did in the past and that is actually not using r8 for release apps for release builds of my app if you don't know what r8 is it's basically a tool that is built into yeah kind of android studio and that it helps you to optimize your app your apk for the release build so if you really want to publish your app then you should use r8 because it will optimize the apk make it a lot smaller obfuscate the code so that reverse engineering is a lot harder and all that cool stuff by default however this is not enabled if we take a look in our build.gradle app file and scroll down to release then we will see minifi enable is set to false if we set this to true then by doing that we actually enable r8 and that will obfuscate our code make the code a lot smaller and decrease your app size you would also like to have shrink resources set to true that will basically eliminate unused resources which often also can take a lot of space in your in your final apk and if you do that your app your final apk will become a lot smaller that's often some some megabytes and that really makes a difference and since it's not enabled by default many beginners don't use that alright let's get to mistake number three that i made in the past and that is not properly saving api keys and that's also a very common question i get basically how do you save api keys how do you make sure that attackers can't get an api key that you might use in your app in the past i used the the most simple the most simple version of storing an api key which is just a constant file here we have an api key and whatever that is however what many beginners are not aware of is that if someone gets your apk which is really not difficult if if you have access to google play and it's uploaded there then they can simply reverse engineer your app so that means they they try to take your apk and extract back the source code which you actually put into it and then they can take the source code and read the api key and even if you obfuscate your code with r8 which i just mentioned that will basically rename all your classes files and functions and stuff like that and also variables like this one here with small and not understandable names which makes it harder to find the api key but the actual key won't be changed because of course your app needs needs that key somehow to attach it to your network requests so even if you enable this obfuscation this won't secure your app from api keys now also tell you there is no 100 secure way to save your api keys because in the end if you put your key into your app and you upload your app to google play and someone gets that apk your api key must be somewhere in that apk file because otherwise your your app wouldn't know it so a better way to do this is that you can that you use build config to save your api key there i won't go into the details here it's basically a gradle plugin that will that will make sure that it includes your api key in the final apk this is not entirely safe either so that can be found as well as i said there is no 100 secure way instead if you really want to secure your api key there are two ways how you can do that the best on the one hand that is just making sure to restrict your api key server side so that you you could say that only the app with your specific signature is allowed to use that api key and if if anybody changes your app or uses the a it uses the api key in another program then that won't work because the signature doesn't match however not all apis offer this functionality of restriction the other option would be that you implement your own backend with your own way of authentication so that users might need to be logged in to actually use your api key and the api key would then be stored on your own server so not in your apk that way your app can actually talk to your backend server and the backend server would then talk to the api that would also be a pretty safe way to use that let's get to number four of the mistakes i've done in the past and that is using business logic in your ui layer that is something you definitely want to avoid so here you see a little example i'm using jetpack compose here i'm having a list and when i click on a button here then i filter that list and filtering a list is just business logic if you don't know what business logic is it's it's just stuff like validating inputs filtering a list searching in a list basically all all types of logic that you would usually have in your app problem if you put this in your ui layer so that could also be your activity or fragment which i have done in the past um then that's not so optimal because then you you mix up your ui code and your ui logic with the actual business logic and that makes your code super messy because you don't have that strict separation of concerns that makes it super hard testable and you also find stuff much harder you will quickly end up with these typical god activities and god fragments which just contain everything your whole source code and i'm sure you've encountered this in the past if you've done this mistake that your code will become very unreadable the solution is very simple you just take all of that business logic here like filtering a list and you do that in your view model that's the place where business logic belongs if you stick to clean architecture then it does not belong in the view model then you would create a use case for that in in this case here for filtering this list and the use case would then forward the result of that to your viewmodel which maps that to a state and provides it for you ui let's get to the final mistake mistake number five that i have made in the past and that is using initials with jetpack compose so what i mean with initials is that we provide initial values here as a parameter that is something i didn't fully understand when i started learning jetpack compose that's something you should do so you see i have a counter composable and i want to provide an initial count so just a number at which this counter starts then i pass this initial count to my count state which is maintained by this counter composable and every time we click on this text we increase the count so what is the problem with this the problem is that if you use that composable somewhere in your code you have absolutely no influence on how that counter works so you have no influence after you actually assign that initial count how the counter works because all it will do is it will increase the count and that logic is hard coded into this counter so let's say you also want to have a button somewhere in your app where you want to reset that count to zero that's not possible with this code right now because for that you would need to use a state that you would simply reset to zero but if you assign the state for the initial account it doesn't affect this code because all this initial account does is it's used to initially set the state that's maintained by this counter so instead what you should do is instead of providing the initial count you should provide the final count so the counter logic of increasing it should actually be stored outside of the counter composable and then you can say okay the the actual initial amount is we could say zero here but we actually want to take the state out of this composable the composable should maintain the state and instead it should just have this count and display it here in the text so we can see it what happens if we click on this count to increase it well we also want to to keep that flexible so what we do is we provide a callback so we say on counter click and that's just a normal partner number function here that we can call when we actually click on that and that way we can actually have the logic of this counter here and this yeah just deciding what this count variable is we can have that outside of this counter composable and we can also flexibly decide what happens if we click on this counter so we we can have our own counter logic outside of this and i i think that makes sense now so those were my five mistakes that i did in the past and i hope you actually learned something from that and you maybe spotted some mistake that you also did and that you will prevent in future that'll be cool i would also love to know which mistakes you did in the past so let me know down in the comments in case you actually want to learn more about android kotlin and architectural style clean code and stuff like that for free you really want to subscribe to my email newsletter clicking the link down below just entering your email address that's it clicking subscribe then you will get regular tips right into your inbox on usually a weekly basis thanks a lot for watching i wish you an excellent day and i'll see you back in the next video bye

Channel: Philipp Lackner

Views: 11,768

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

Id: dHNZJAPfZ3c

Length: 12min 45sec (765 seconds)

Published: Sat Oct 23 2021