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. By taking the stance that every piece of code we write is an API we can build more versatile and scalable applications. ...

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. By taking the stance that every piece of code we write is an API we can build more versatile and scalable applications. ...

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. By taking the stance that every piece of code we write is an API we can build more versatile and scalable applications. ...

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. By taking the stance that every piece of code we write is an API we can build more versatile and scalable applications. ...

It’s a common age-old adage, the ongoing war between Software Engineer and QA Engineer, the eternal struggle between the bright-eyed, and those tasked with enforcing practical reality. I mean not to demonise either party here, this is exactly the picture that can be seen if both are performing their roles adequately. It is very important to understand, at least from a Software Engineering perspective, that QA Engineers, not out to make your life difficult, and often will be happy to help you work out the kinks… mostly. ...

It’s a familiar story, it’s Monday morning, and you’re ready to start on the latest feature to solve all your user woes! You’re excited! You’re engaged! But then you see the design, your joyous smile fades, your world turns dark once more. Why? Another iOS carbon copy… It doesn’t need to be this way. Learn how to share the joy of Material Design with your colleagues, and pitch the benefits of a truly native design with user affordance, effective navigation patterns, and usable usability. ...

It’s a familiar story, it’s a Monday morning, and your PM gathers the team together, ready to brief you all on the new, latest and greatest feature to grace your app, solve all your user woes, and bring in countless five-star reviews! You get excited! Why wouldn’t you? This is why we got into this in the first place right? To build exciting and shiny new things, and feel pride when we see our users enjoying the fruits of our labours. ...

It’s a familiar story, it’s a Monday morning, and your PM gathers the team together, ready to brief you all on the new, latest and greatest feature to grace your app, solve all your user woes, and bring in countless five-star reviews! You get excited! Why wouldn’t you? This is why we got into this in the first place right? To build exciting and shiny new things, and feel pride when we see our users enjoying the fruits of our labours. ...

Dagger has become one of the most widely used libraries in Android development, and is often one of the first to be thought of when bootstrapping a new project, but there are still many nuances and caveats that often get overlooked! Many questions arose after the adoption of Kotlin on how to continue following best practices from Java, so whether you’re using dagger-android or vanilla Dagger, I’ll go through some tips and tricks to make sure you’re using Dagger to its best capacity. ...