The two most important things are to 1. Have a plan on what you want to do beforehand so you can 2. Organise your code in a way that makes sense and is easily extendible.
Very useful information... If you have a time please make a series for cracking clean Architecture for Android Development. It will be great series for all of us 🙏🏻
Might look like just another topic. But this is really one of those topics which most developers have no idea about even though they use all these all the time. From my personal experience, this video will save u from embarrassment while attending android interviews. Thanks phlip.
Dammnnnn phillip, right now I’m doing a test app because I’m applying for an android developer job… and that builder pattern just saved me the day. You don’t know how many hours I was trying to do something in an adapter and this builder pattern was the perfect way to do that. Thank you very much for this video, It came in divine timing
Excellent video, I learned quite a bit about both the patterns in kotlin and gained insight into better ways. Thanks Phillipp! I learned these all in Java many years ago... it's so refreshing to see the idiomatic Kotlin versions as well as gain some further insight into each.
So a note about the Kotlin way of doing builder, it isn't actually the builder pattern, b/c it doesn't hide the concrete implementation details from the end user. A proper builder pattern can have constructor parameters of the built class change name/order/etc. and not be visible to the end user. However, in the kotlin methodology, you are directly exposing the constructor to the end user. Even with parameter naming, you have an easier chance of making compile breaking changes if you do this vs hiding the details inside the builder.
Builder pattern doesn't necessarily have to hide, alias, abstract or simplify the object's API. It sure CAN, and it may be pretty useful... but that' becomes more of a Builder + Factory / Facade combo. The main point of a Builder is just that it allows to construct an object step by step (which includes the possibility of passing a Builder elswhere, so that some other code can finish what we started). Just because some Builder does "naively" reflect the constructor signature 1-to-1 doesn't mean it's not a "proper Builder patten".
It was really helpful! I'm learning to develop for android but this topic isn't so talked in many courses or even when happen is to much superficial, so could you say when should a beginner student as me start to study it?
Having a constructor with default values isn't the best example of a Builder pattern. A typical Builder should force you to, for example, provide arguments or dependencies in a specific order or a user defined order, or perhaps dissallow a dependency if a previously specified dependency was of a restrictive kind or allow an argument to be given more than once. In other words, a Builder allows you to restrict argument requirements or give more flexible arguments or a combination of both. The Modifier is the best example of this. Don't be fooled by it not having this final build() call.
can you create a video for "keyboard productive hacks in android sudio"? i know few of them I like: 1. ctrl + Alt + Shift + up/down to go the edited location in the same page 2. double shift to search anything.
I'd like to express to some of the less experienced viewers why one of your comments on builder patterns in Kotlin is a bit inaccurate. Not wrong though. I'm referring to using named args to simulate a builder pattern. While this can be very useful and is likely a good idea in some builders. The builder pattern is used to create complex objects. The point of it is that you don't always have everything you need at the time you call a constructor. With your way the developer has to make sure all required dependencies are before calling the constructor as the object is meant to be immutable (or very close to it) once created. This is why a builder object is made. The values can change and be set after the builder objects creation. This builder can be passed around to configuration classes. That or the creation of a dependency can happen, then the builder set function is called, then you create the next dependency and so on. One other benefit to the builder object is that it can throw an error for objects that aren't configured correctly. Usually the Builder constructor has the minimum requirements for the .build() function to work but this isn't always true. The androidx biometric library has a good example of the builder throwing an exception for improperly configured builders. If you try to set the prompt cancellation button text while also trying to set device credential as an option for the prompt then these two states can't exist at the same time as they occupy the same space on the biometric prompt. So an error is thrown. In my eyes this is poor design so that leads into my next paragraph. Where I agree with your approach is that the builder to me (purely opinion at this point) is a bit of an anti pattern. It lets you get away with bad design. If you can't create the dependencies before calling the constructor then maybe you need to refactor some stuff or maybe the object is a bit too complex and doing too much. As with everything in programming it is knowing your requirements and which tool (pattern in this case) to get a job done. There is no one solution and that is why I am not saying you are wrong for your Kotlin approach to builders. Just wanted newer devs to understand the use of the Builder object.
"One other benefit to the builder object is that it can throw an error for objects that aren't configured correctly." The same can be done by the object's constructor (or its factory function). Your other points are valid, but this one feels unconvincing to me.
Hey Philipp, i've got a question regarding the patterns introduced by you. You start with singletons. For what I know, they are considered being an anti-pattern, which shouldn't be used due to tight coupling, etc. So, why using them at all?
I don't know what Philipp thinks about it, but here's my take on it. Singletons aren't always bad, that's a generalization. The main problems with singletons are: 1. Singletons tend to obfuscate dependencies. If a class Frobnicator is a singleton, it can be accessed from everywhere, which leads to poor code design, and you can't dictate by code design which classes are legitimate and intended users of Frobnicator. You don't have to worry about propagating it, which makes things easy in the short run, but may lead to sloppy and lazy code design. (Case in point: event buses, which were a popular Android anti-pattern for quite a while). 2. Singletons can be used to hold global state, and global state is usually a bad idea, for reasons related to #1. It also gets in the way of testability, since it's hard to replace a singleton for the sake of unit testing. You either have to resort to tricks such as mocking statics, or your tests have to reset the state of the singleton... and every time you forget about resetting, there goes the isolation (because the tests are no longer independent - one test can contaminate the state of the singleton, with an impact on subsequent tests). However: a) Singletons can be stateless, and this resolves the problem of global state. Sometimes stateless singletons are just redundant in Kotiln (no need for a CollectionUtils singleton, just define extension functions, since Kotlin supports standalone functiions). But eg. android.util.Log is a singleton, and it's generally not a big deal. b) It's preferable to define a singleton via your DI framework. They typically support singletons (@Singleton annotation in Dagger 2, singleton in Koin etc.). So you can have the framework guarantee that some class will be functionally a singleton - there will only ever be one instance of it - but you don't define it as an object, you just define it as a class. This makes it easy to subtitute it in tests, and to keep the dependencies transparent, mitigating the main problems associated with the use of singletons. So the problems have solutions, and while caution is advised, there is still proper use for singletons. The default mindset, however, should be "why yes?" instead of "why not?", whenever you are tempted to define something as a singleton.
If singleton pattern is just an object in kotlin, why we create room database class singleton like java singletons (using @syncronized and private Instance)?
Hey Philipp can you make a video about data structures you use the most in Kotlin and in what cases, like for example Hashmaps. Great video like always btw.
Hello sir , your doing great 🔥 , I will start android dev , from next week , can tell start android with XML or jetpack compose , I am good with flutter nd been doing from last 8 months
I think it got too abstract at some point, maybe some bigger examples would be more useful for understanding each pattern, but thx for the video anyway
Hey Philipp, thank you for the excellent video - your explanations are really nice to watch and I like that small errors are left in (such as in the return statement in the 'factory' example), however I really, really, REALLY struggle with dependency injection. I just can't understand how I would implement it or how I would change my app to use this pattern.. I hope I am not alone! I would therefore really appreciate it if you would do a video where you start with a simple existing design that you convert to use dependency injection to show the benefits of this methodology.. thank you!! (you did ask for suggestions!). Oh and I work in Kotlin so I'm happy I can avoid the builder pattern!!
Eg. every mapper converting an object from - say - an API response to an object your business logic uses. (Because you don't want your business logic to get updated everywhere every time a json structure changes; that's not good separation of concerns). So you may have a type like UserResponse (which reflects how user data is represented in the json returned by some API endpoint, and is used for deserialization of these responses), but then you've got an Adapter which translates those UserResponse objects into User classes that your app actually deals with. Thanks to this, if a structure of UserResponse ever changes (eg. they've renamed a field, or the "badges" collection is now nested under "attributes" etc., whatever), the impact of that change is contained. You're just updating your Adapter, but all your business logic can remain unchanged. I'm aware that your question is 2 years old, but someone else may be reading it just the same, possibly wondering the same thing.
Thanks Phillip for this useful video. please make a complete series for design patterns and best practices for Android developer, one more please make a series for memory management in Android. Thanks
U are awesome bro.. please grow your beard.. you look damn handsome in that look. Apart from this, your biggest fan. You teach and explain things in different level. Love it bro . 😊
It can hide dependencies, plus when it's misconfigured (eg. some dependency is not defined), there's a risk you will only find out by a runtime error instead of a compile-time error. It's about trade-offs though. Koin is a service locator, and it's not bad 0 especially if your project isn't very big; in that case the simplicity of Koin may be worth it.
There is no such thing as a singleton. You will always have 1 instance for production and 1 instance for testing. Singleton is better enforced through dependency injection by convention.
Awesome info. Is there a way to use binding in persistant bottom sheet? If we dont use kotlin synthetics.. We could use binding for normal dialogs, acticities, fragments to acess the views easily. But for persisten bottom sheet it doesn't seem to work? Any idea how to use it?
How to do Configuration for debug app and for release app. Like how to remove/hide log or classes or default values that you don't need in production app but needed for debug app
![Coheed and Cambria - Searching for Tomorrow [Official Video]](http://i.ytimg.com/vi/hDsYGLbmadg/mqdefault.jpg)
0:49 Singleton
2:46 Factory
5:04 Builder
8:31 Facade
9:44 Dependency Injection
12:30 Adapter
Can you create a video for something like 'Best practices for big apps or advanced apps' to keep them easily readable and updatable with time ?? 🤔🤔
cool idea, will think about it
@@PhilippLackner clean architecture. wow, cant wait! Hope it also support for REST API, login, token, handle expired token
I'm looking exactly for the same thing. Still can't find a good video/series for advanced practices for developing big and scalable apps
good idea
The two most important things are to 1. Have a plan on what you want to do beforehand so you can 2. Organise your code in a way that makes sense and is easily extendible.
Excellent. Interview prep material.
Decorator - Modifying an object during runtime.
Eg: Recycler view item decorator
Feeling overwhelmed when getting a love for my comment from the creator who is 1000s of miles apart. Thanks to the technology.
Very useful information... If you have a time please make a series for cracking clean Architecture for Android Development. It will be great series for all of us 🙏🏻
You are the best Android and Kotlin teacher I have encountered!! Thank you Phillip...you are literally saving careers out here💯💯💯
Might look like just another topic. But this is really one of those topics which most developers have no idea about even though they use all these all the time. From my personal experience, this video will save u from embarrassment while attending android interviews. Thanks phlip.
Dammnnnn phillip, right now I’m doing a test app because I’m applying for an android developer job… and that builder pattern just saved me the day. You don’t know how many hours I was trying to do something in an adapter and this builder pattern was the perfect way to do that. Thank you very much for this video, It came in divine timing
Excellent video, I learned quite a bit about both the patterns in kotlin and gained insight into better ways.
Thanks Phillipp!
I learned these all in Java many years ago... it's so refreshing to see the idiomatic Kotlin versions as well as gain some further insight into each.
Glad you enjoyed it
So a note about the Kotlin way of doing builder, it isn't actually the builder pattern, b/c it doesn't hide the concrete implementation details from the end user. A proper builder pattern can have constructor parameters of the built class change name/order/etc. and not be visible to the end user. However, in the kotlin methodology, you are directly exposing the constructor to the end user. Even with parameter naming, you have an easier chance of making compile breaking changes if you do this vs hiding the details inside the builder.
Builder pattern doesn't necessarily have to hide, alias, abstract or simplify the object's API.
It sure CAN, and it may be pretty useful... but that' becomes more of a Builder + Factory / Facade combo.
The main point of a Builder is just that it allows to construct an object step by step (which includes the possibility of passing a Builder elswhere, so that some other code can finish what we started).
Just because some Builder does "naively" reflect the constructor signature 1-to-1 doesn't mean it's not a "proper Builder patten".
It was really helpful! I'm learning to develop for android but this topic isn't so talked in many courses or even when happen is to much superficial, so could you say when should a beginner student as me start to study it?
As always great videos Phillip! Do a tutorial on clean architecture or mvi
Great job. Please make an e-commerce or Video calling app tutorial 😊
Can you create a video for webrtc for Android?
You have made them super easy for us to understand. Thanks man.👍
Having a constructor with default values isn't the best example of a Builder pattern.
A typical Builder should force you to, for example, provide arguments or dependencies in a specific order or a user defined order, or perhaps dissallow a dependency if a previously specified dependency was of a restrictive kind or allow an argument to be given more than once.
In other words, a Builder allows you to restrict argument requirements or give more flexible arguments or a combination of both.
The Modifier is the best example of this. Don't be fooled by it not having this final build() call.
Simplied and to the point. Good work Philipp 👏
As always, unique content.
Thanks man ❤
My pleasure!
can you create a video for "keyboard productive hacks in android sudio"?
i know few of them I like:
1. ctrl + Alt + Shift + up/down to go the edited location in the same page
2. double shift to search anything.
the best time i spend on youtube is seeing your videos
Thanks Philipp , I think some other patterns like Object Pool, Flyweight, Decorator, Observer, Strategy and Proxy has useful in a project
Great video!!
Can you create a video about how we can organize a Gradle in a big app o maybe how use tasks. For example a Jacoco task to use in sonar
Thank you so much bro! I recently discovered your channel and it's super helpful! Great content!
Loved it! I like how easy is to understand from what you explain.
please make a video over page object model pattern for testing with kotlin!
I like the way you teach, so cool. I learnt a lot from you. thanks bro
you're welcome
I'd like to express to some of the less experienced viewers why one of your comments on builder patterns in Kotlin is a bit inaccurate. Not wrong though. I'm referring to using named args to simulate a builder pattern. While this can be very useful and is likely a good idea in some builders. The builder pattern is used to create complex objects. The point of it is that you don't always have everything you need at the time you call a constructor. With your way the developer has to make sure all required dependencies are before calling the constructor as the object is meant to be immutable (or very close to it) once created. This is why a builder object is made. The values can change and be set after the builder objects creation. This builder can be passed around to configuration classes. That or the creation of a dependency can happen, then the builder set function is called, then you create the next dependency and so on. One other benefit to the builder object is that it can throw an error for objects that aren't configured correctly. Usually the Builder constructor has the minimum requirements for the .build() function to work but this isn't always true. The androidx biometric library has a good example of the builder throwing an exception for improperly configured builders. If you try to set the prompt cancellation button text while also trying to set device credential as an option for the prompt then these two states can't exist at the same time as they occupy the same space on the biometric prompt. So an error is thrown. In my eyes this is poor design so that leads into my next paragraph.
Where I agree with your approach is that the builder to me (purely opinion at this point) is a bit of an anti pattern. It lets you get away with bad design. If you can't create the dependencies before calling the constructor then maybe you need to refactor some stuff or maybe the object is a bit too complex and doing too much.
As with everything in programming it is knowing your requirements and which tool (pattern in this case) to get a job done. There is no one solution and that is why I am not saying you are wrong for your Kotlin approach to builders. Just wanted newer devs to understand the use of the Builder object.
"One other benefit to the builder object is that it can throw an error for objects that aren't configured correctly."
The same can be done by the object's constructor (or its factory function). Your other points are valid, but this one feels unconvincing to me.
Yeah just re read my comment and I may have missed some context or something out as I agree that didn't really make much sense.
Podrias explicarme mas detalladamente como implementar el patron Factory en mi proyecto porfavor ?
Another great video Philipp! Thanks for handling some of the advanced topics...
thanks!
thanks philipp. btw have you ever made a video about rxjava ?
Hey Philipp,
i've got a question regarding the patterns introduced by you. You start with singletons. For what I know, they are considered being an anti-pattern, which shouldn't be used due to tight coupling, etc. So, why using them at all?
I don't know what Philipp thinks about it, but here's my take on it.
Singletons aren't always bad, that's a generalization.
The main problems with singletons are:
1. Singletons tend to obfuscate dependencies. If a class Frobnicator is a singleton, it can be accessed from everywhere, which leads to poor code design, and you can't dictate by code design which classes are legitimate and intended users of Frobnicator. You don't have to worry about propagating it, which makes things easy in the short run, but may lead to sloppy and lazy code design. (Case in point: event buses, which were a popular Android anti-pattern for quite a while).
2. Singletons can be used to hold global state, and global state is usually a bad idea, for reasons related to #1.
It also gets in the way of testability, since it's hard to replace a singleton for the sake of unit testing. You either have to resort to tricks such as mocking statics, or your tests have to reset the state of the singleton... and every time you forget about resetting, there goes the isolation (because the tests are no longer independent - one test can contaminate the state of the singleton, with an impact on subsequent tests).
However:
a) Singletons can be stateless, and this resolves the problem of global state. Sometimes stateless singletons are just redundant in Kotiln (no need for a CollectionUtils singleton, just define extension functions, since Kotlin supports standalone functiions). But eg. android.util.Log is a singleton, and it's generally not a big deal.
b) It's preferable to define a singleton via your DI framework. They typically support singletons (@Singleton annotation in Dagger 2, singleton in Koin etc.). So you can have the framework guarantee that some class will be functionally a singleton - there will only ever be one instance of it - but you don't define it as an object, you just define it as a class.
This makes it easy to subtitute it in tests, and to keep the dependencies transparent, mitigating the main problems associated with the use of singletons.
So the problems have solutions, and while caution is advised, there is still proper use for singletons.
The default mindset, however, should be "why yes?" instead of "why not?", whenever you are tempted to define something as a singleton.
Make video for Android Google interviews
Please continue to make more videos on these topics !
Hi, Philipp Great job. can you create a video on app performance for big apps?
Great and lovely video... Kindly make tutorials on dagger. Thank you boss..
Thank you for this video, please keep making those kind of videos :D. I suggest one about gradle
Is Observer one of them and very used in Android too? Or im wrong?
great information it's help full for me great effort bro
If singleton pattern is just an object in kotlin, why we create room database class singleton like java singletons (using @syncronized and private Instance)?
Very useful Phillip. Great content as always 👏👏👏
Hey Philipp can you make a video about data structures you use the most in Kotlin and in what cases, like for example Hashmaps. Great video like always btw.
A great video as always, Ty.
Hello sir , your doing great 🔥 , I will start android dev , from next week , can tell start android with XML or jetpack compose , I am good with flutter nd been doing from last 8 months
Thanx man this was very very helpful 😊
I think it got too abstract at some point, maybe some bigger examples would be more useful for understanding each pattern, but thx for the video anyway
Hey Philipp, thank you for the excellent video - your explanations are really nice to watch and I like that small errors are left in (such as in the return statement in the 'factory' example), however I really, really, REALLY struggle with dependency injection.
I just can't understand how I would implement it or how I would change my app to use this pattern.. I hope I am not alone! I would therefore really appreciate it if you would do a video where you start with a simple existing design that you convert to use dependency injection to show the benefits of this methodology.. thank you!! (you did ask for suggestions!). Oh and I work in Kotlin so I'm happy I can avoid the builder pattern!!
Excellent video Phil!!
Glad you enjoyed it
Great video.. Pl. make a project on Forum App or Polling App
Yeah! 2 of 6 I don't even heard before ❤️
stupid question
In frontend web dev why we need to learn design patterns because I am learning react and never saw this things....
it's awesome, thank you so much
Can you please show some examples of adapter pattern other than recycler view adapter. Literally i couldn't adapt the adapter pattern :P
Eg. every mapper converting an object from - say - an API response to an object your business logic uses.
(Because you don't want your business logic to get updated everywhere every time a json structure changes; that's not good separation of concerns).
So you may have a type like UserResponse (which reflects how user data is represented in the json returned by some API endpoint, and is used for deserialization of these responses), but then you've got an Adapter which translates those UserResponse objects into User classes that your app actually deals with.
Thanks to this, if a structure of UserResponse ever changes (eg. they've renamed a field, or the "badges" collection is now nested under "attributes" etc., whatever), the impact of that change is contained.
You're just updating your Adapter, but all your business logic can remain unchanged.
I'm aware that your question is 2 years old, but someone else may be reading it just the same, possibly wondering the same thing.
As always, unique content and easy to watch
Can you please make video about anti pattens in Android?
Cool idea 👍
soo that's how they call Builder pattern and tutorial to make it. Man you best! But I don't know when I will make Builder pattern with Kotlin.
Thanks Phillip for this useful video. please make a complete series for design patterns and best practices for Android developer, one more please make a series for memory management in Android. Thanks
Amazing. Do you have any discord channels?
U are awesome bro.. please grow your beard.. you look damn handsome in that look. Apart from this, your biggest fan. You teach and explain things in different level. Love it bro . 😊
GOD I Needed this video...
FUCKIN LOVE YOU PHILIP❤❤
Thanks for good video, we would more videos about Jetpack compose, especially architecture of these apps
He's already done 3 playlists on compose, some advanced dev stuff is welcomed.
Can we get a video like 'Testings made esay with dagger', which will demonstrate the fake repository pattern that you just explained in this video
I have a whole playlist on testing with dagger hilt and stuff like that
@@PhilippLackner thanks a lot, I have gone through that playlist and it was really helpful!
@@PhilippLackner
How about a video for: "The best to secure keys for production apps"
Hey man it was really helpful
Could you explain why or how service locator pattern is called an anti pattern ?
It can hide dependencies, plus when it's misconfigured (eg. some dependency is not defined), there's a risk you will only find out by a runtime error instead of a compile-time error.
It's about trade-offs though. Koin is a service locator, and it's not bad 0 especially if your project isn't very big; in that case the simplicity of Koin may be worth it.
Developers may know, but Google Android managers have no idea that DSF and DFF are audio files too.
Please make a free tutorial for Ktor
Perfect as always.
you are the man of God💖💖💖💖
Thank you bro.
Great video ☺️
Thank you!! 😊
Saw this video (AMAZING) 2 years ago and now Android has also lift us of that horrible recycler views adapters thanks to Compose xD
facade is like mcdonalds i dont want to see how the bigmac is made
Excellent video as always
Thanks again!
Thanks Philipp for the video ❣️
My pleasure!
Practice make perfect
true
There is no such thing as a singleton. You will always have 1 instance for production and 1 instance for testing. Singleton is better enforced through dependency injection by convention.
Why do you always have one instance for anything? The moment you create an instance in a ViewModel or Activity, it's by definition not a singleton
Nice Video. Could you find time and do a tutorial on app modularization?? Would really appreciate.
Awesome info. Is there a way to use binding in persistant bottom sheet? If we dont use kotlin synthetics.. We could use binding for normal dialogs, acticities, fragments to acess the views easily. But for persisten bottom sheet it doesn't seem to work? Any idea how to use it?
More videos!
❤️❤️❤️👌👌 perfect
Nice!
Are you copying Ahmad Kazimi's article or is he copying from you?
Looking at the publish date of each, that should be clear 😂
How to do Configuration for debug app and for release app.
Like how to remove/hide log or classes or default values that you don't need in production app but needed for debug app
perfact
Nice
Thank you!
You're welcome!
Thanks lot Brother
Welcome
Just give me my freakin hamburgers!
Thank you
most of it went over my head but alright
awsome
Shit I missed the Live 😭
Good an quastion how to use service and inside it state flow in mvvm?
You missed repository pattern 😛
Sure, there are more, observer would also be a common one. But somewhere I need to draw a line 😁
😃
Singleton 🤮
Hi, Philipp,
I've sent you a message in Instagram.
Could you please check it!
P.s. thanks for the great videos!👍🏻👍🏻👍🏻