6 Design Patterns Every Android Developer Must Know

Simplied and to the point. Good work Philipp 👏

facade is like mcdonalds i dont want to see how the bigmac is made

Also there is Observer pattern that we will use it all the time if we use LiveData in ViewModel

Thanks for the videos. With your help I'm learning android developing and English at the same time :))

Podrias explicarme mas detalladamente como implementar el patron Factory en mi proyecto porfavor ?

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

Are you copying Ahmad Kazimi's article or is he copying from you?

Developers may know, but Google Android managers have no idea that DSF and DFF are audio files too.

Well.. I don't find this video is easy to understand. How come that others can understand? After watching singleton it's ... I donno I wish that you could do examples how exacly singleton should look like.

please make a video over page object model pattern for testing with kotlin!

most of it went over my head but alright

A great video as always, Ty.

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'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.

Nice

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.

Loved it! I like how easy is to understand from what you explain.

Is Observer one of them and very used in Android too? Or im wrong?

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.

Thank you bro.

great information it's help full for me great effort bro

stupid question
In frontend web dev why we need to learn design patterns because I am learning react and never saw this things....

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 . 😊

Can you please show some examples of adapter pattern other than recycler view adapter. Literally i couldn't adapt the adapter pattern :P

😃

Just give me my freakin hamburgers!
Thank you

perfact

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

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!!

it's awesome, thank you so much

Thank you so much bro! I recently discovered your channel and it's super helpful! Great content!

Hi, Philipp Great job. can you create a video on app performance for big apps?

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?

Excellent video Phil!!

awsome

Thanx man this was very very helpful 😊

Yeah! 2 of 6 I don't even heard before ❤️

Hey man it was really helpful

If singleton pattern is just an object in kotlin, why we create room database class singleton like java singletons (using @syncronized and private Instance)?

As always, unique content and easy to watch
Can you please make video about anti pattens in Android?

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

You are the best Android and Kotlin teacher I have encountered!! Thank you Phillip...you are literally saving careers out here💯💯💯

Thank you for this video, please keep making those kind of videos :D. I suggest one about gradle

Great video.. Pl. make a project on Forum App or Polling App

Please continue to make more videos on these topics !

Please make a free tutorial for Ktor

As always great videos Phillip! Do a tutorial on clean architecture or mvi

Hi, Philipp,
I've sent you a message in Instagram.
Could you please check it!

P.s. thanks for the great videos!👍🏻👍🏻👍🏻