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

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

In this session, you’ll learn how to get started with Kotlin in your projects, tips and tricks on how to preserve your version control history, some pitfalls when migrating from Java, and what new technologies you can make use of in your journey with Kotlin.

Legacy code can be quite the challenge to manage, often resulting from untested scenarios, quick fixes, or less than successful initiatives. With few developers wanting to deal with it, it can end up with little remaining knowledge of its inner workings. We can take many learnings from Michael Feathers book on “Working Effectively with Legacy Code”, but we can also use Kotlin migration as an effective tool to leverage the management, reduction, and removal of legacy code in our 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. ...