6 Design Patterns Every Android Developer Must Know 

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.

Feeling overwhelmed when getting a love for my comment from the creator who is 1000s of miles apart. Thanks to the technology.

Glad you enjoyed it

My pleasure!

thanks!

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

you're welcome

Glad you enjoyed it

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

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.

Cool idea 👍

He's already done 3 playlists on compose, some advanced dev stuff is welcomed.

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.

Thank you!! 😊

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.

Thanks again!

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"

My pleasure!

Looking at the publish date of each, that should be clear 😂

Welcome

You're welcome!

true

Sure, there are more, observer would also be a common one. But somewhere I need to draw a line 😁