Talks

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 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. ...

Fragments have often been controversial, and to some, the stuff of nightmares, with the inconsistency of lifecycle events, complex UI interaction, and unexpected behaviours making many Android developers suspicious of their usage. But with the development and recent stable publication of the navigation library, it may be the right time to give them a chance. Giving Fragments a second chance is not something I’d ever thought I’d be saying, but it’s a fantastic opportunity to find a solution to sharing data across a single screen. ...