I think one advantage there would be typechecking, which I don't believe you would get with a typealias. What I mean by this is that IIUC using a typealias, a parameter of type "PhotoAlias" would actually accept any String (or whatever the primitive type is). With an inline value class, it's actually a new type, rather than an alias. Inline value classes also offer constructors/initializers for additional semantics, validation etc. In most cases, this is achieved without any overhead, meaning as with a typealias, at runtime you really just have a String (in this example, or whatever primitive type). So tl;dr it's a more robust, powerful and flexible option, and there shouldn't be any performance penalty, so I don't really see any reason NOT to use an Inline Value Class over a typealias, unless I'm missing something (which is quite possible 😅). Happy to learn by being corrected if I'm wrong or missing something. Inline value classes are new and TBH I haven't actually used them yet, but I think they're a great feature and I'm looking forward to using them shortly in a personal project where they are quite applicable. kotlinlang.org/docs/inline-classes.html
@@GrahamFirst typealiases, to me, should only be used locally (so i wouldn't rely on them for the scenario Philipp shows, i tend to agree with you in that sense). i find them great mostly for resolving occasional naming conflicts - eg. you are using kotlin.Result and some custom Result type alongside, and you don't want to always write the fully qualified kotlin.Result or com.myapplication.utils.Result to distinguish between them. creating an inline value class just for that purpose would be an overkill. so - to me - they're not interchangeable. it's apples and oranges. they serve different purposes and aren't meant as replacements for eachother. speaking of kotlin.Result, Result.success is actually an inline value class. so if you've got a failure, it's a specific class, but if you've got Result.success(true) (for example), it's actually just "true" coated with syntax sugar. there are some edge cases where it can lead to surprising results, eg. if you're using Mockito, you're not mocking some kotlin.Result property (so it stays null), but the compiler actually "thinks" it's a success, because it will treat it as Result.success(null).
Hey Philipp, excellent work. I've been learning a lot from your videos, the explanation and implementation is great. I am relatively a beginner and now I am gonna learn network, APis and stuff. I came across your tutorials about Retrofit and Rest API but they are 2 years old now. So are they still relevant?
Hack #1 & #2 : Some programmers will do ANYTHING to avoid properly documenting their code. Sigh. Hack #3: Is this *really* easier than using the standard sharedPreferences? Perhaps it IS if you're doing lots and lots of sharedPrefs reading and writing. But wait--why are you doing lots of sharedPrefs reading and writing? That alone is quite inefficient--code that should be re-thought. This has all the code smell of someone showing off all their esoteric knowledge of hidden details of kotlin instead of someone who truly wants their code to be understood by the next batch of programmers to look at it (and as usual, they are almost always the people with the least experience and the least ability to follow such subtle code tricks).
destructuring declarations are nice, but relying on Pairs a lot is probably an anti-pattern in its own right. eg. if you have two values like (name, id), and if you implement it as a class, then you can always look for all the usages of "ThisClass.name" in the codebase. but if you're using a Pair, you cannot, because it will only find you the occurrences of Pair.first or Pair.second, and that might include lots of unrelated results from irrelevant contexts. or if you've got a Pair to represent name and id, and both are Strings, but then you realize you actually need to revert the order of name and id (id should be "first", name should be "second", because of some Map conversion), you've got no type safety when refactoring. you may forget about some place where it should be reversed, because both are of String type. so the code that will mistakenly use id as a name and vice versa is going to run and compile without any issues. this wouldn't happen if you had a normal class with expliitly named properties.
In Hack 3, I would remove the "val" from context so you don't hold onto it and bring in a memory leak, since context is only used to create the SharedPreferences object. Also, I would maybe put the Context extension function in a companion object of the delegate, but that is probably stylistic.
Hey man! Great suggestions, but I got one question regarding the third hack. Following your example, if I used this property delegate for a shared preference inside a view model for example, how would we test this view model? How could we mock the property delegate so the test is unit and we can avoid using roboelectric or something similar?
a ViewModel shouldn't deal with shared preferences directly AT ALL, because they are an Android concept, tied to the platform. they require access to Context. ideally a ViewModel should be unaware and independent of Android SDK.
I don't think the setter and getter can be a suspend function which would be needed for that. You could keep a runBlocking in that property delegate, but it's not ideal IMO since that would not make it clear that it's a blocking call and should be executed on a thread
Hello bro, I used to watch your video from very early. I did a lot of research but still i am not able to find a solution to my query. I found a strechable ui in some of the professional app. For example consider the new playconsole app , it includes q strchable ui which make user feel that this is end of the screen. I saw this behaviour as defult after android 12 but in android 9 or 8 it does not. But still the app shows that strechable ui in android 9. Can you help me how to get so . Is this happening because playconsole is made using flutter ??? Hope you answer my question 😊
Don't forget to mention: when you use "by" keyword, compose compiler will recognize state as written, thus function will recompose, even if it just pass state to inner compose function
or naming conflicts, like if you have to use two classes which happen to have the same name, but come from different packages, in the same file/class. typealias is a nicer alternative to using a fully qualified name (including a possibly lengthy package path).
Sir, Could you please tell me, how long it takes to build an app by learning from scratch using Kotlin and Jetpack compose ?.........Just tell me the time please!....
Typealiases are cool, however, the reader may think PhotoUrl is another class and get confused. Another approach using typealias that I'd prefer is explicitly making PhotoUrl is a typealias of string by PhotoUrl to PhotoUrlStr or better off, write a wrapper class that; data class PhotoUrl(value: String) // You can use another naming for value property tho Of course, those are my opinions
Hello Philipp, i got something that i find weird with Unit Tests and Jacoco, using the Result API does not cover me the 100% for some reason (a path o branch to test, but unclear) anyone or you could have an idea why, and maybe explain this?
@@GrahamFirstbecause exceptions are for exceptional circumstances. Inability to upload a photo is not an exceptional occurrence. Failure is just an alternative success.
Typealiases are great, but I think using inline value classes would be a better approach
Could You elaborate on that?
I agree
I think one advantage there would be typechecking, which I don't believe you would get with a typealias.
What I mean by this is that IIUC using a typealias, a parameter of type "PhotoAlias" would actually accept any String (or whatever the primitive type is). With an inline value class, it's actually a new type, rather than an alias.
Inline value classes also offer constructors/initializers for additional semantics, validation etc.
In most cases, this is achieved without any overhead, meaning as with a typealias, at runtime you really just have a String (in this example, or whatever primitive type).
So tl;dr it's a more robust, powerful and flexible option, and there shouldn't be any performance penalty, so I don't really see any reason NOT to use an Inline Value Class over a typealias, unless I'm missing something (which is quite possible 😅).
Happy to learn by being corrected if I'm wrong or missing something. Inline value classes are new and TBH I haven't actually used them yet, but I think they're a great feature and I'm looking forward to using them shortly in a personal project where they are quite applicable.
kotlinlang.org/docs/inline-classes.html
@@GrahamFirst typealiases, to me, should only be used locally (so i wouldn't rely on them for the scenario Philipp shows, i tend to agree with you in that sense).
i find them great mostly for resolving occasional naming conflicts - eg. you are using kotlin.Result and some custom Result type alongside, and you don't want to always write the fully qualified kotlin.Result or com.myapplication.utils.Result to distinguish between them.
creating an inline value class just for that purpose would be an overkill.
so - to me - they're not interchangeable. it's apples and oranges. they serve different purposes and aren't meant as replacements for eachother.
speaking of kotlin.Result, Result.success is actually an inline value class. so if you've got a failure, it's a specific class, but if you've got Result.success(true) (for example), it's actually just "true" coated with syntax sugar. there are some edge cases where it can lead to surprising results, eg. if you're using Mockito, you're not mocking some kotlin.Result property (so it stays null), but the compiler actually "thinks" it's a success, because it will treat it as Result.success(null).
@@GrahamFirstgreat explanation!
Hey Philipp, excellent work. I've been learning a lot from your videos, the explanation and implementation is great. I am relatively a beginner and now I am gonna learn network, APis and stuff. I came across your tutorials about Retrofit and Rest API but they are 2 years old now. So are they still relevant?
@sackhaarspalter Ohh alright, I was actually confused which one to learn, thanks for help.
@sackhaarspalteryes ktor for multi platform, and retrofit for classic android
nice video
the third is a great one
thanks for sharing!
Can we get a video about uploading a photo to the back end and returning a url?
Hack #1 & #2 : Some programmers will do ANYTHING to avoid properly documenting their code. Sigh.
Hack #3: Is this *really* easier than using the standard sharedPreferences? Perhaps it IS if you're doing lots and lots of sharedPrefs reading and writing. But wait--why are you doing lots of sharedPrefs reading and writing? That alone is quite inefficient--code that should be re-thought.
This has all the code smell of someone showing off all their esoteric knowledge of hidden details of kotlin instead of someone who truly wants their code to be understood by the next batch of programmers to look at it (and as usual, they are almost always the people with the least experience and the least ability to follow such subtle code tricks).
The hack 2 was really helpful! I'm really relying most on Pairs, than creating another data class for it. Now it will be more readable
Agreed! And keep in mind you could use even more specific names than key/value for even greater readability.
destructuring declarations are nice, but relying on Pairs a lot is probably an anti-pattern in its own right.
eg. if you have two values like (name, id), and if you implement it as a class, then you can always look for all the usages of "ThisClass.name" in the codebase.
but if you're using a Pair, you cannot, because it will only find you the occurrences of Pair.first or Pair.second, and that might include lots of unrelated results from irrelevant contexts.
or if you've got a Pair to represent name and id, and both are Strings, but then you realize you actually need to revert the order of name and id (id should be "first", name should be "second", because of some Map conversion), you've got no type safety when refactoring. you may forget about some place where it should be reversed, because both are of String type.
so the code that will mistakenly use id as a name and vice versa is going to run and compile without any issues. this wouldn't happen if you had a normal class with expliitly named properties.
i dont like the 2nd hack. it can be achieved in a better way with a simple if else
Didn't know about the partition function, pretty cool, thank you!
1. Typealias
2. Destructing
3. Delegates
thank you for useful video. I have reduced a bunch of code in my project by only change sharedpreference
Philipp plz build music player with content resolver and clean arch. If anyone think that will be so cool then like my comment 😄😄😄
what theme are you using for android studio? looks super clean and that logcat cat is cuteeee
Humble brag, I knew all of these hacks.
How about if return type of first example is an uri?
Lol, this hacks exploded my mind, excellent video, thank you!
Hack 1 is useless, better to use a separate data class
In Hack 3, I would remove the "val" from context so you don't hold onto it and bring in a memory leak, since context is only used to create the SharedPreferences object. Also, I would maybe put the Context extension function in a companion object of the delegate, but that is probably stylistic.
Hello, this video is really instructive. Would you mind to do one video going deeper abaout the 'delegates'?
Your channel is awesome, thank you!
Wow!!! typealias is very useful!!!!!
good tips, thanks
Hey man! Great suggestions, but I got one question regarding the third hack.
Following your example, if I used this property delegate for a shared preference inside a view model for example, how would we test this view model? How could we mock the property delegate so the test is unit and we can avoid using roboelectric or something similar?
Either way, you'd have a separate class which implements your preferences. That class is injected in your VM and can be replaced for testing there
a ViewModel shouldn't deal with shared preferences directly AT ALL, because they are an Android concept, tied to the platform.
they require access to Context.
ideally a ViewModel should be unaware and independent of Android SDK.
What about datastore ? Can we do like this with datastore?
I don't think the setter and getter can be a suspend function which would be needed for that. You could keep a runBlocking in that property delegate, but it's not ideal IMO since that would not make it clear that it's a blocking call and should be executed on a thread
I liked it bro！！！
awesome tips
Can we get data from firebase synchronizely in kotlin.can you make videos on it
Hello bro, I used to watch your video from very early. I did a lot of research but still i am not able to find a solution to my query.
I found a strechable ui in some of the professional app. For example consider the new playconsole app , it includes q strchable ui which make user feel that this is end of the screen. I saw this behaviour as defult after android 12 but in android 9 or 8 it does not.
But still the app shows that strechable ui in android 9. Can you help me how to get so .
Is this happening because playconsole is made using flutter ???
Hope you answer my question 😊
amazing
Cool!
Thanks
Muito bom !
are you spying on me or something?
your videos always point to the exact problems I keep facing in my work.
that's awesome.
It really blown my mind. I thought I've known everything. Thank you! 🎉
Don't forget to mention: when you use "by" keyword, compose compiler will recognize state as written, thus function will recompose, even if it just pass state to inner compose function
Amazing background, Phillip.
only use typealias for long java class names like : class ProjectContractChargingPeriodAccountReferenceVM :D :D
or naming conflicts, like if you have to use two classes which happen to have the same name, but come from different packages, in the same file/class.
typealias is a nicer alternative to using a fully qualified name (including a possibly lengthy package path).
Bitte, bitte - mehr davon. Diese Art von Content ist großartig! (Please, please - more of the same. This kind of content is great)!
Excellent. Greetings from Brazil.
not bad not bad cool tricks. improved readibility
Sir, Could you please tell me, how long it takes to build an app by learning from scratch using Kotlin and Jetpack compose
?.........Just tell me the time please!....
it takes 64 days.
hey philipp what happened to your newsletter? i suddenly stopped getting emails from you
You are amazing, loved the hack3
All of them were good hacks. I liked the Getter and Setter idea.
Typealiases are cool, however, the reader may think PhotoUrl is another class and get confused. Another approach using typealias that I'd prefer is explicitly making PhotoUrl is a typealias of string by PhotoUrl to PhotoUrlStr or better off, write a wrapper class that;
data class PhotoUrl(value: String) // You can use another naming for value property tho
Of course, those are my opinions
Inline classes fall somewhere in between those two
btw it should be val value: String actually ; ) (i know you're just illustrating the idea)
Hello Philipp, i got something that i find weird with Unit Tests and Jacoco, using the Result API does not cover me the 100% for some reason (a path o branch to test, but unclear) anyone or you could have an idea why, and maybe explain this?
Doctor, my tummy is aching for some reason, do you have any idea why?
Another great video. Thanks.
code push in git
very good, it's very amazing!!!!!!!!!
Thank you! Would like to see more!
Loved this one. Thanks again Philipp!
Wow, thanks a lot for these tips
Third one was helpful
Thank you Philipp 🤩
It's very helpful
Delegate example is so useful 👌
Great hacks!
Love from INDIA ❤
great stuff!
Why return a Result rather than just a String (in the first example)?
Because Result allows you to return an error if the operation fails.
@@vibovitold Why not just throw an exception?
@@GrahamFirstbecause exceptions are for exceptional circumstances. Inability to upload a photo is not an exceptional occurrence. Failure is just an alternative success.
nice hack3
goat