The Android community is a fast evolving society of excellent people who passionately involve themselves in their ecosystem. This means the progress of developments can be fast, blazingly fast! Inspired by other content creators and newsletters that keep us informed about the most recent events, I decided to document news, events, and releases every week for a year. Starting from the end of Droidcon Berlin, the world’s best Android developer conference....

Ever wondered what it would take to combine all the experimental features of a language you love (Spoilers… It’s Kotlin!) into one big bundle? I’m a lover of new and shiny stuff, so let me share with you my experience of using everything shiny, and new, in my pet project, to show you how to not do all the things you might want to do with yours! JetBrains Compose for Desktop, Unstable Coroutines APIs, version catalogues, Gradle composite builds, multiplatform navigation support, multiplatform paging, GraphQl, Firebase Cloud Functions, Molecule, Mosaic, what could go wrong?...

Molecule is a library for turning Composables into Flows. But how does that happen? And why would you want to do such a thing? And why not? In this talk, Ash and Bill will dive a bit into how Molecule does what it does, and help you understand where, when, and how you should use it.

Molecule is a library for turning Composables into Flows. But how does that happen? And why would you want to do such a thing? And why not? In this talk, Ash and Bill will dive a bit into how Molecule does what it does, and help you understand where, when, and how you should use it.

Molecule is a library for turning Composables into Flows. But how does that happen? And why would you want to do such a thing? And why not? In this talk, Ash and Bill will dive a bit into how Molecule does what it does, and help you understand where, when, and how you should use it. various social media embeds.

When creating a new app module, or modularising an existing one, it becomes easy to forget who might be consuming it. It becomes easy to forget that every decision you make will affect how it is used, or in the worst case, abused. We’re told that code should document itself, but how do these design decisions reflect in the understanding of intended use? Just because we might not be exposing a module as a public or open-sourced library, doesn’t mean we can’t benefit from making good decisions towards an effective and sensible API....

Ever wondered what it would take to combine all the experimental features of a language you love (Spoilers… It’s Kotlin!) into one big bundle? I’m a lover of new and shiny stuff, so let me share with you my experience of using everything shiny, and new, in my pet project, to show you how to not do all the things you might want to do with yours! JetBrains Compose for Desktop, Unstable Coroutines APIs, version catalogues, Gradle composite builds, multiplatform navigation support, multiplatform paging, GraphQl, Firebase Cloud Functions, Molecule, Mosaic, what could go wrong?...

When creating a new app module, or modularising an existing one, it becomes easy to forget who might be consuming it. It becomes easy to forget that every decision you make will affect how it is used, or in the worst case, abused. We’re told that code should document itself, but how do these design decisions reflect in the understanding of intended use? Just because we might not be exposing a module as a public or open-sourced library, doesn’t mean we can’t benefit from making good decisions towards an effective and sensible API....

When creating a new app module, or modularising an existing one, it becomes easy to forget who might be consuming it. It becomes easy to forget that every decision you make will affect how it is used, or in the worst case, abused. We’re told that code should document itself, but how do these design decisions reflect in the understanding of intended use? Just because we might not be exposing a module as a public or open-sourced library, doesn’t mean we can’t benefit from making good decisions towards an effective and sensible API....

When creating a new app module, or modularising an existing one, it becomes easy to forget who might be consuming it. It becomes easy to forget that every decision you make will affect how it is used, or in the worst case, abused. We’re told that code should document itself, but how do these design decisions reflect in the understanding of intended use? Just because we might not be exposing a module as a public or open-sourced library, doesn’t mean we can’t benefit from making good decisions towards an effective and sensible API....