Chris Banes
@chrisbanes.me
🕸️ https://chrisbanes.me
👨💻 Senior Staff Software Engineer
👨💻 Senior Staff Software Engineer
Who needs great wallpapers when you can create your own with ‘Emoji Workshop’ 🙃
October 17, 2025 at 8:40 PM
Who needs great wallpapers when you can create your own with ‘Emoji Workshop’ 🙃
Yeah I agree, just found it funny.
September 29, 2025 at 12:18 PM
Yeah I agree, just found it funny.
If I ask ChatGPT, it knows it is ChatGPT 5.
September 29, 2025 at 11:28 AM
If I ask ChatGPT, it knows it is ChatGPT 5.
Amazing news! Congrats 🎉
September 1, 2025 at 9:21 AM
Amazing news! Congrats 🎉
You could probably build this yourself with a custom KSP processor.
Annotate the function, then generate the class (copy the injectable params to the ctor), generate the DI bindings.
We do something similar (although we don’t annotate functions)
Annotate the function, then generate the class (copy the injectable params to the ctor), generate the DI bindings.
We do something similar (although we don’t annotate functions)
August 30, 2025 at 3:37 PM
You could probably build this yourself with a custom KSP processor.
Annotate the function, then generate the class (copy the injectable params to the ctor), generate the DI bindings.
We do something similar (although we don’t annotate functions)
Annotate the function, then generate the class (copy the injectable params to the ctor), generate the DI bindings.
We do something similar (although we don’t annotate functions)
kotlin-inject has a sort of functional injection, but honestly… I really don’t like it.
You’ll always be coupling code together, as there’s no way to create any indirection.
Good bye build speed, when your small change in a leaf module invalidates all modules which call the function.
You’ll always be coupling code together, as there’s no way to create any indirection.
Good bye build speed, when your small change in a leaf module invalidates all modules which call the function.
August 29, 2025 at 9:42 PM
kotlin-inject has a sort of functional injection, but honestly… I really don’t like it.
You’ll always be coupling code together, as there’s no way to create any indirection.
Good bye build speed, when your small change in a leaf module invalidates all modules which call the function.
You’ll always be coupling code together, as there’s no way to create any indirection.
Good bye build speed, when your small change in a leaf module invalidates all modules which call the function.
Nice. What’s the backend stack look like?
August 1, 2025 at 8:32 AM
Nice. What’s the backend stack look like?
Nice summary! I didn’t know about the R8 prop
July 31, 2025 at 1:55 PM
Nice summary! I didn’t know about the R8 prop
I don’t know about banks in France, so can’t comment. Most of the ‘app’ banks in the UK are great (Monzo, Starling, etc).
For forex I now use Wise, and have had zero problems.
For forex I now use Wise, and have had zero problems.
July 26, 2025 at 9:10 PM
I don’t know about banks in France, so can’t comment. Most of the ‘app’ banks in the UK are great (Monzo, Starling, etc).
For forex I now use Wise, and have had zero problems.
For forex I now use Wise, and have had zero problems.
I seriously do *not* recommend Revolut for any serious amount of money.
Used to use them for large sums from the US (RSUs). One got triggered by some automated check, and my money was held for 2 months whilst they ‘investigated’. Customer services were useless and didn’t help.
Used to use them for large sums from the US (RSUs). One got triggered by some automated check, and my money was held for 2 months whilst they ‘investigated’. Customer services were useless and didn’t help.
July 26, 2025 at 9:01 PM
I seriously do *not* recommend Revolut for any serious amount of money.
Used to use them for large sums from the US (RSUs). One got triggered by some automated check, and my money was held for 2 months whilst they ‘investigated’. Customer services were useless and didn’t help.
Used to use them for large sums from the US (RSUs). One got triggered by some automated check, and my money was held for 2 months whilst they ‘investigated’. Customer services were useless and didn’t help.
I like Cloudflare. It hosts my DNS anyway so makes everything very simple.
It’s also cost price, so cheap.
It’s also cost price, so cheap.
July 24, 2025 at 7:18 PM
I like Cloudflare. It hosts my DNS anyway so makes everything very simple.
It’s also cost price, so cheap.
It’s also cost price, so cheap.
It shouldn’t matter. Zen syncs with Firefox Sync, although I don’t use FF Mobile so can’t say for sure that it works.
July 21, 2025 at 6:44 AM
It shouldn’t matter. Zen syncs with Firefox Sync, although I don’t use FF Mobile so can’t say for sure that it works.
Nice post!
I've migrated to Zen Browser (zen-browser.app) for simplicity from Arc. Highly recommended!
I've migrated to Zen Browser (zen-browser.app) for simplicity from Arc. Highly recommended!
Zen Browser
Beautifully designed, privacy-focused, and packed with features.
zen-browser.app
July 20, 2025 at 8:20 AM
Nice post!
I've migrated to Zen Browser (zen-browser.app) for simplicity from Arc. Highly recommended!
I've migrated to Zen Browser (zen-browser.app) for simplicity from Arc. Highly recommended!
There was an example in one of the many splinter threads.
Either way, I’d still argue that the defaults are the safest option for all.
If you want something else, you could code-gen bindings (which we do a lot of for convenience purposes).
Either way, I’d still argue that the defaults are the safest option for all.
If you want something else, you could code-gen bindings (which we do a lot of for convenience purposes).
July 19, 2025 at 10:30 AM
There was an example in one of the many splinter threads.
Either way, I’d still argue that the defaults are the safest option for all.
If you want something else, you could code-gen bindings (which we do a lot of for convenience purposes).
Either way, I’d still argue that the defaults are the safest option for all.
If you want something else, you could code-gen bindings (which we do a lot of for convenience purposes).
I think that this is very codebase specific. If anything, having singletons everywhere feels like a warning sign to me.
Why are view specific things heavy enough to warrant being created only once?
IMO scoping is for controlling lifecycle, and nothing else.
Why are view specific things heavy enough to warrant being created only once?
IMO scoping is for controlling lifecycle, and nothing else.
July 19, 2025 at 7:19 AM
I think that this is very codebase specific. If anything, having singletons everywhere feels like a warning sign to me.
Why are view specific things heavy enough to warrant being created only once?
IMO scoping is for controlling lifecycle, and nothing else.
Why are view specific things heavy enough to warrant being created only once?
IMO scoping is for controlling lifecycle, and nothing else.
Ah true true, I forgot that it was an optional experimental feature :skeletor_mirror:
July 6, 2025 at 4:15 PM
Ah true true, I forgot that it was an optional experimental feature :skeletor_mirror:
Have you found a way to enforce the usage of path dependencies?
I wonder if there’s a way for a `check` like task could inspect the dependencies across all configurations.
I wonder if there’s a way for a `check` like task could inspect the dependencies across all configurations.
July 6, 2025 at 8:27 AM
Have you found a way to enforce the usage of path dependencies?
I wonder if there’s a way for a `check` like task could inspect the dependencies across all configurations.
I wonder if there’s a way for a `check` like task could inspect the dependencies across all configurations.
From a Compose point of view I think it’s better to talk about GraphicsLayers, rather than RNs.
RNs are cool, but they’re an Android-only implementation for a GraphicsLayer. In fact, GLs on older versions of Android use a View (since RN wasn’t public then). On CMP, GLs use a SkPicture.
RNs are cool, but they’re an Android-only implementation for a GraphicsLayer. In fact, GLs on older versions of Android use a View (since RN wasn’t public then). On CMP, GLs use a SkPicture.
July 5, 2025 at 2:40 PM
From a Compose point of view I think it’s better to talk about GraphicsLayers, rather than RNs.
RNs are cool, but they’re an Android-only implementation for a GraphicsLayer. In fact, GLs on older versions of Android use a View (since RN wasn’t public then). On CMP, GLs use a SkPicture.
RNs are cool, but they’re an Android-only implementation for a GraphicsLayer. In fact, GLs on older versions of Android use a View (since RN wasn’t public then). On CMP, GLs use a SkPicture.
302 bar would have a terrible business plan
July 3, 2025 at 7:09 AM
302 bar would have a terrible business plan
I’m not sure how they really could fix it. They’d need to split the compilation somehow, but you’d then lose the automatic ability to reference any `projects.foo` from any module.
July 2, 2025 at 7:26 AM
I’m not sure how they really could fix it. They’d need to split the compilation somehow, but you’d then lose the automatic ability to reference any `projects.foo` from any module.