@culturalrice.bsky.social
Definitely not what I was expecting, but I was too lazy to run some benchmarks, so thanks for the heads-up. A quick search lead me to this: github.com/Kotlin/kotli...
January 5, 2025 at 9:44 PM
Definitely not what I was expecting, but I was too lazy to run some benchmarks, so thanks for the heads-up. A quick search lead me to this: github.com/Kotlin/kotli...
I'm doing something similar, but with kotlinlang.org/api/kotlinx.... to use `ResponseBody.source()` directly, which I expect to be (a tiny bit) more efficient.
January 5, 2025 at 9:19 PM
I'm doing something similar, but with kotlinlang.org/api/kotlinx.... to use `ResponseBody.source()` directly, which I expect to be (a tiny bit) more efficient.
I was hoping that any of you knew what they meant with "so that adding new fields minimizes disruption of C++ version", because reading the comment makes me think that is the reason why this is done. It all started here apparently: cs.android.com/android/_/an...
December 20, 2024 at 6:30 PM
I was hoping that any of you knew what they meant with "so that adding new fields minimizes disruption of C++ version", because reading the comment makes me think that is the reason why this is done. It all started here apparently: cs.android.com/android/_/an...
I got curious and looked around. Could it be this? cs.android.com/android/plat...
Search and explore code
cs.android.com
December 20, 2024 at 6:11 PM
I got curious and looked around. Could it be this? cs.android.com/android/plat...
I initially wrote the check to save state more efficiently. It bothers me that things such as `java.time.Instant` could be saved as two "tiny" longs, but it is instead saved as a raw object.
I'm just sad this is still broken: issuetracker.google.com/issues/35684...
I'm just sad this is still broken: issuetracker.google.com/issues/35684...
Google Issue Tracker
issuetracker.google.com
December 5, 2024 at 8:30 PM
I initially wrote the check to save state more efficiently. It bothers me that things such as `java.time.Instant` could be saved as two "tiny" longs, but it is instead saved as a raw object.
I'm just sad this is still broken: issuetracker.google.com/issues/35684...
I'm just sad this is still broken: issuetracker.google.com/issues/35684...
I recently wrote a lint check to outright ban whatever would rely on `Parcel.writeSerializable()`, but I'm still undecided on what to do with it. This is one more good reason to enable it.
December 5, 2024 at 8:29 PM
I recently wrote a lint check to outright ban whatever would rely on `Parcel.writeSerializable()`, but I'm still undecided on what to do with it. This is one more good reason to enable it.
But, ever since strong skipping mode became a thing I really stopped obsessing over making everything stable. I just structure state classes in such a way that updates affect mostly what needs to be recomposed. In a sense, the state is kind of structured like the UI.
December 3, 2024 at 6:23 PM
But, ever since strong skipping mode became a thing I really stopped obsessing over making everything stable. I just structure state classes in such a way that updates affect mostly what needs to be recomposed. In a sense, the state is kind of structured like the UI.
There really aren't many options, so it depends: developer.android.com/develop/ui/c....
If I own the class, I annotate it. If I don't, I wrap it. If I don't own it and it is a very common type (e.g. stdlib), I add it to a the stability config file.
If I own the class, I annotate it. If I don't, I wrap it. If I don't own it and it is a very common type (e.g. stdlib), I add it to a the stability config file.
December 3, 2024 at 6:23 PM
There really aren't many options, so it depends: developer.android.com/develop/ui/c....
If I own the class, I annotate it. If I don't, I wrap it. If I don't own it and it is a very common type (e.g. stdlib), I add it to a the stability config file.
If I own the class, I annotate it. If I don't, I wrap it. If I don't own it and it is a very common type (e.g. stdlib), I add it to a the stability config file.
I think it only affects R8, D8 is probably not demanding enough to be treated in a special way.
December 3, 2024 at 7:29 AM
I think it only affects R8, D8 is probably not demanding enough to be treated in a special way.
That note on Groovy is more than a year old, it should just work now.
December 3, 2024 at 7:25 AM
That note on Groovy is more than a year old, it should just work now.
R8 is already limited to 1 worker, you have to use android.r8.maxWorkers for more. I had memory related issues a while back and I solved them with `runInSeparateProcess` (developer.android.com/build/releas...), which allowed me to give R8 a fixed amount of memory.
December 2, 2024 at 1:18 PM
R8 is already limited to 1 worker, you have to use android.r8.maxWorkers for more. I had memory related issues a while back and I solved them with `runInSeparateProcess` (developer.android.com/build/releas...), which allowed me to give R8 a fixed amount of memory.
And if you use "@Parcelize", be *really* careful. I had to write a lint check to stop others from doing that.
I have to admit that I find them handy for some things in Compose, but in that case I'm probably using the data modifier just to skip recompositions.
I have to admit that I find them handy for some things in Compose, but in that case I'm probably using the data modifier just to skip recompositions.
November 28, 2024 at 10:38 PM
And if you use "@Parcelize", be *really* careful. I had to write a lint check to stop others from doing that.
I have to admit that I find them handy for some things in Compose, but in that case I'm probably using the data modifier just to skip recompositions.
I have to admit that I find them handy for some things in Compose, but in that case I'm probably using the data modifier just to skip recompositions.
I always wonder why it's always `let` and not `also`, which doesn't have that "returns null" problem.
I try to use these scoping functions only if I do not need an else branch and I'm too lazy to declare a local variable to get smart casting work on immutable classes declared in other modules.
I try to use these scoping functions only if I do not need an else branch and I'm too lazy to declare a local variable to get smart casting work on immutable classes declared in other modules.
November 27, 2024 at 10:38 PM
I always wonder why it's always `let` and not `also`, which doesn't have that "returns null" problem.
I try to use these scoping functions only if I do not need an else branch and I'm too lazy to declare a local variable to get smart casting work on immutable classes declared in other modules.
I try to use these scoping functions only if I do not need an else branch and I'm too lazy to declare a local variable to get smart casting work on immutable classes declared in other modules.
A quick test revealed I was wrong. That's good to know.
November 26, 2024 at 2:41 PM
A quick test revealed I was wrong. That's good to know.
I thought Dispatchers.IO did not really reuse threads and that every launch() would get its own thread (up to 64 concurrent threads). That made sense to me, since it's primarily intended for non-suspendable code. The same is not true for Dispatchers.Default, which shares threads.
November 26, 2024 at 2:37 PM
I thought Dispatchers.IO did not really reuse threads and that every launch() would get its own thread (up to 64 concurrent threads). That made sense to me, since it's primarily intended for non-suspendable code. The same is not true for Dispatchers.Default, which shares threads.
Yeah, wrapping suspend functions that do IO in Dispatchers.IO is something I've seen in different codebases for some reason. In this particular case you end up with 2 blocked threads for every network call, one from Dispatchers.IO and one from OkHttp, which is kind of a waste.
November 26, 2024 at 2:08 PM
Yeah, wrapping suspend functions that do IO in Dispatchers.IO is something I've seen in different codebases for some reason. In this particular case you end up with 2 blocked threads for every network call, one from Dispatchers.IO and one from OkHttp, which is kind of a waste.
If you already do everything from Dispatchers.IO then you are not affected by it. You can easily verify this by placing a breakpoint where convert() is called. The debugger will tell you which is the current thread, or you could even call `Thread.currentThread()`.
November 26, 2024 at 1:48 PM
If you already do everything from Dispatchers.IO then you are not affected by it. You can easily verify this by placing a breakpoint where convert() is called. The debugger will tell you which is the current thread, or you could even call `Thread.currentThread()`.
Whoops, I replied to the wrong message.
November 26, 2024 at 1:44 PM
Whoops, I replied to the wrong message.
You can create a sort of Convert.Factory wrapper that simply retrieves the next Converter with Retrofit.nextRequestBodyConverter() to then call its convert() method lazily. I guess this is what @bladecoder.bsky.social had in mind.
November 26, 2024 at 1:43 PM
You can create a sort of Convert.Factory wrapper that simply retrieves the next Converter with Retrofit.nextRequestBodyConverter() to then call its convert() method lazily. I guess this is what @bladecoder.bsky.social had in mind.
It's a nice abstraction that let's me write generic Composables without too many overloads. In some places I may favor rememberAsyncImagePainter() from Coil, in some other rememberVectorPainter(), in others painterResource() etc...
November 25, 2024 at 7:47 PM
It's a nice abstraction that let's me write generic Composables without too many overloads. In some places I may favor rememberAsyncImagePainter() from Coil, in some other rememberVectorPainter(), in others painterResource() etc...
I'd say it depends on the specific Painter implementation, but I really doubt the "standard" ones would break with something like this, that would be really weird.
The wrapper should also be unnecessary with strong skipping mode enabled, Painter instances are usually remembered.
The wrapper should also be unnecessary with strong skipping mode enabled, Painter instances are usually remembered.
November 25, 2024 at 6:56 PM
I'd say it depends on the specific Painter implementation, but I really doubt the "standard" ones would break with something like this, that would be really weird.
The wrapper should also be unnecessary with strong skipping mode enabled, Painter instances are usually remembered.
The wrapper should also be unnecessary with strong skipping mode enabled, Painter instances are usually remembered.
Sure, no problem.
November 25, 2024 at 3:26 PM
Sure, no problem.
Pretty much, yeah. Then you can set it as shown here, using your own renderer: github.com/googlemaps/a...
I actually don't even import maps-compose-utils, which is just a two files lib and re-implemented the few bit I needed.
I actually don't even import maps-compose-utils, which is just a two files lib and re-implemented the few bit I needed.
android-maps-compose/maps-compose-utils/src/main/java/com/google/maps/android/compose/clustering/Clustering.kt at 3ba3831dc4d332f981cfee438ac760a2dc8f3651 · googlemaps/android-maps-compose
Jetpack Compose composables for the Maps SDK for Android - googlemaps/android-maps-compose
github.com
November 25, 2024 at 3:22 PM
Pretty much, yeah. Then you can set it as shown here, using your own renderer: github.com/googlemaps/a...
I actually don't even import maps-compose-utils, which is just a two files lib and re-implemented the few bit I needed.
I actually don't even import maps-compose-utils, which is just a two files lib and re-implemented the few bit I needed.
There is this: github.com/googlemaps/a...
I simply wrote my own implementation of DefaultClusterRenderer so that I can render markers and clusters efficiently while still using compose-maps for everything else. My markers are all assets, so I don't really care about using Compose for them.
I simply wrote my own implementation of DefaultClusterRenderer so that I can render markers and clusters efficiently while still using compose-maps for everything else. My markers are all assets, so I don't really care about using Compose for them.
Issues · googlemaps/android-maps-compose
Jetpack Compose composables for the Maps SDK for Android - Issues · googlemaps/android-maps-compose
github.com
November 25, 2024 at 2:59 PM
There is this: github.com/googlemaps/a...
I simply wrote my own implementation of DefaultClusterRenderer so that I can render markers and clusters efficiently while still using compose-maps for everything else. My markers are all assets, so I don't really care about using Compose for them.
I simply wrote my own implementation of DefaultClusterRenderer so that I can render markers and clusters efficiently while still using compose-maps for everything else. My markers are all assets, so I don't really care about using Compose for them.
I use ktlint, simply because it's a standalone tool that I could configure in such a way that code reformatted with it is accepted by the IDE (with no plugins) and vice versa.
November 25, 2024 at 2:30 PM
I use ktlint, simply because it's a standalone tool that I could configure in such a way that code reformatted with it is accepted by the IDE (with no plugins) and vice versa.