Jonathan Lalou's Blog

Posts Tagged ‘AndroidDev’

At KotlinConf’23, Sebastian Aigner (Developer Advocate at JetBrains) and Nikita Lipsky (Software Developer for Kotlin at JetBrains) presented an exciting overview of Compose Multiplatform, focusing on its then-Alpha support for iOS. Their session detailed how this JetBrains initiative enables developers to write their user interface once in Kotlin and deploy it across Android, iOS, desktop, and web, fostering significant code sharing and development efficiency. The official documentation for Compose Multiplatform offers further insights.

The presentation began by recapping the classic Kotlin Multiplatform (KMP) use case, which allows sharing of business logic while retaining access to platform-specific APIs. Compose Multiplatform builds upon this by providing a solution for sharing the UI layer itself, addressing scenarios where building and maintaining separate native UIs for each platform is not feasible due to time, resources, or the desire for rapid market entry. While the talk focused on iOS and Android, the speakers emphasized that Compose Multiplatform also supports desktop (stabilized in late 2021) and web targets.

Architecture and Jetpack Compose Foundations

A key point underscored by Sebastian and Nikita was that Compose Multiplatform is built upon Jetpack Compose, Google’s modern declarative UI toolkit for Android, which is 100% Kotlin. This means developers familiar with Jetpack Compose can leverage their existing knowledge and skills to build UIs for iOS and other platforms. The JetBrains team collaborates closely with Google, regularly upstreaming changes to the Jetpack Compose repositories.

Nikita Lipsky delved into the architecture, explaining that official Jetpack Compose itself is already a Kotlin Multiplatform project at its core, with its lowest levels defining Kotlin Multiplatform sources. The composable function concept is an extension to the Kotlin language requiring compiler support, and the entire Compose system is managed by the Compose Runtime. For iOS, Compose Multiplatform renders UI elements by drawing directly onto a CAPI (Canvas API) provided by Skiko, a graphics library that abstracts over Skia (for Android and desktop) and CoreGraphics (for iOS). This allows for consistent rendering across platforms.

Live Demos and iOS Integration

The session featured live demonstrations showcasing the capabilities of Compose Multiplatform on iOS. Sebastian Aigner walked through a sample application, highlighting how standard Jetpack Compose code for UI elements, state management (using remember), layouts (like Column), and modifiers can be shared and run on iOS simulators and devices. He demonstrated features like text input, button interactions, and even integration with iOS-specific functionalities like the share sheet, emphasizing the goal of seamless interoperability.

The speakers also discussed the importance of providing solid accessibility integrations and ensuring smooth performance, even on high-refresh-rate displays, which is an ongoing area of focus for the Kotlin/Native and Compose Multiplatform teams. Interoperability with existing iOS UI code (SwiftUI and UIKit) was also presented as a key feature, allowing for gradual adoption. Developers can embed Compose Multiplatform views within existing SwiftUI applications or, conversely, embed native iOS views within a Compose Multiplatform UI. This flexibility is crucial for teams looking to integrate Compose into their established projects incrementally.

Getting Started and Future Outlook

Sebastian and Nikita provided clear guidance on how developers can start experimenting with Compose Multiplatform for iOS. They pointed to project templates, sample applications available on the Compose Multiplatform GitHub repository (including to-do list apps and code viewers), and updated KMP production samples that now include branches with Compose-based UI implementations. The new memory manager in Kotlin/Native was also mentioned as a significant improvement, simplifying multi-threaded programming for all Kotlin targets, including iOS.

While acknowledging that the iOS target was in Alpha and some areas were still works in progress, the overall message was one of excitement and a call to action for the community. They encouraged developers to explore the technology, provide feedback, and contribute to its evolution. The vision is a future where developers can agree on a delightful way to write UIs for all their target platforms using Kotlin.

Links:

• Compose Multiplatform for iOS Is in Alpha (Kotlin Blog)
• Compose Multiplatform and Jetpack Compose Documentation
• JetBrains Website

Kotlin coroutines have revolutionized asynchronous programming on Android and other platforms, offering a way to write non-blocking code in a sequential style. However, as Florina Muntenescu and Manuel Vivo, both prominent Android Developer Experts then at Google, pointed out at KotlinConf 2019, the “happy path” is only part of the story. Their talk, “Coroutines! Gotta catch ’em all!” delved into the critical aspects of coroutine cancellation and exception handling, providing developers with the knowledge to build robust and resilient asynchronous applications.

Florina and Manuel highlighted a common scenario: coroutines work perfectly until an error occurs, a timeout is reached, or a coroutine needs to be cancelled. Understanding how to manage these situations—where to handle errors, how different scopes affect error propagation, and the impact of launch vs. async—is crucial for a good user experience and stable application behavior.

Structured Concurrency and Scope Management

A fundamental concept in Kotlin coroutines is structured concurrency, which ensures that coroutines operate within a defined scope, tying their lifecycle to that scope. Florina Muntenescu and Manuel Vivo emphasized the importance of choosing the right CoroutineScope for different situations. The scope dictates how coroutines are managed, particularly concerning cancellation and how exceptions are propagated.

They discussed:
* CoroutineScope: The basic building block for managing coroutines.
* Job and SupervisorJob: A Job in a coroutine’s context is responsible for its lifecycle. A key distinction is how they handle failures of child coroutines. A standard Job will cancel all its children and itself if one child fails. In contrast, a SupervisorJob allows a child coroutine to fail without cancelling its siblings or the supervisor job itself. This is critical for UI components or services where one failed task shouldn’t bring down unrelated operations. The advice often given is to use SupervisorJob when you want to isolate failures among children.
* Scope Hierarchy: How scopes can be nested and how cancellation or failure in one part of the hierarchy affects others. Understanding this is key to preventing unintended cancellations or unhandled exceptions.

Cancellation: Graceful Termination of Coroutines

Effective cancellation is vital for resource management and preventing memory leaks, especially in UI applications where operations might become irrelevant if the user navigates away. Florina and Manuel would have covered how coroutines support cooperative cancellation. This means that suspending functions in the kotlinx.coroutines library are generally cancellable; they check for cancellation requests and throw a CancellationException when one is detected.

Key points regarding cancellation included:
* Calling job.cancel() initiates the cancellation of a coroutine and its children.
* Coroutines must cooperate with cancellation by periodically checking isActive or using cancellable suspending functions. CPU-bound work in a loop that doesn’t check for cancellation might not stop as expected.
* CancellationException is considered a normal way for a coroutine to complete due to cancellation and is typically not logged as an unhandled error by default exception handlers.

Exception Handling: Catching Them All

Handling exceptions correctly in asynchronous code can be tricky. Florina and Manuel’s talk aimed to clarify how exceptions propagate in coroutines and how they can be caught.
They covered:
* launch vs. async:
* With launch, exceptions are treated like uncaught exceptions in a thread—they propagate up the job hierarchy. If not handled, they can crash the application (depending on the root scope’s context and CoroutineExceptionHandler).
* With async, exceptions are deferred. They are stored within the Deferred result and are only thrown when await() is called on that Deferred. This means if await() is never called, the exception might go unnoticed unless explicitly handled.
* CoroutineExceptionHandler: This context element can be installed in a CoroutineScope to act as a global handler for uncaught exceptions within coroutines started by launch in that scope. It allows for centralized error logging or recovery logic. They showed examples of how and where to install this handler effectively, for example, in the root coroutine or as a direct child of a SupervisorJob to catch exceptions from its children.
* try-catch blocks: Standard try-catch blocks can be used within a coroutine to handle exceptions locally, just like in synchronous code. This is often the preferred way to handle expected exceptions related to specific operations.

The speakers stressed that uncaught exceptions will always propagate, so it’s crucial to “catch ’em all” to avoid unexpected behavior or crashes. Their presentation aimed to provide clear patterns and best practices to ensure that developers could confidently manage both cancellation and exceptions, leading to more robust and user-friendly Kotlin applications.

Links:

• Florina Muntenescu on LinkedIn
• Manuel Vivo on LinkedIn

The vision of writing code once and running it across multiple platforms is a long-held dream in software development. Britt Barak, an experienced Android and Kotlin developer, and Google Developer Expert, brought this vision closer to reality for Android developers at KotlinConf 2019. Her talk, “Sharing Is Caring – Kotlin Multiplatform for Android Developers,” explored the exciting, albeit then-experimental, capabilities of Kotlin Multiplatform (KMP) and how it could revolutionize the way Android developers collaborate with teams working on iOS, backend, or JavaScript projects.

Britt Barak emphasized the common scenario where Android developers work alongside backend services or with iOS and JavaScript teams developing similar functionalities. The ability to share Kotlin code across these platforms promised significant savings in implementation time, testing effort, and overall development efficiency. Her session focused on creating a full-stack Kotlin project, demonstrating how to share code between an Android app and a backend Kotlin component, ultimately leading to more efficient and robust applications.

The Promise of Kotlin Multiplatform

Kotlin Multiplatform (KMP) allows developers to write common logic in Kotlin and compile it for various targets, including JVM (for Android and backend), JavaScript (for web frontends), and Native (for iOS and other native applications). Britt Barak highlighted the power of this approach: sharing business logic, data models, and even presentation logic (in some architectures) can drastically reduce redundancy and inconsistencies between different platform implementations.

The core idea is to isolate platform-agnostic code in a “common” module. This module can then be consumed by platform-specific modules (e.g., Android, iOS, JVM backend) which implement the platform-dependent parts, such as UI or interactions with platform-specific APIs. This separation allows teams to leverage Kotlin’s strengths across their entire stack while still catering to the unique requirements of each platform. Britt’s presentation aimed to show Android developers how they could take the lead in initiating such code-sharing efforts, benefiting not only their own workflow but also that of their teammates on other platforms.

Practical Implementation and Considerations

Britt Barak’s session was hands-on, guiding attendees through the process of setting up and building a Kotlin Multiplatform project. She covered key KMP concepts such as:
* Common Modules: Where shared Kotlin code resides, free of platform-specific dependencies.
* Platform-Specific Modules: Modules targeting specific platforms (Android, JVM, JS, Native) that can depend on common modules and implement platform-specific functionalities using expect/actual declarations.
* expect and actual Keywords: A powerful mechanism in KMP that allows common code to declare an expected functionality (expect), which platform-specific modules then provide concrete implementations for (actual). This is crucial for accessing platform-specific APIs (like device sensors, file systems, or UI elements) from shared code.

She demonstrated how to structure a project to share code effectively between an Android application and a backend Kotlin component, showcasing the potential for building more cohesive and maintainable full-stack applications. This practical approach would have involved setting up the build system (Gradle), defining dependencies, and writing shared business logic that could be consumed by both the Android client and the server. The goal was to illustrate how to build “more efficient and robust applications” through strategic code sharing.

Navigating the Experimental Landscape and Community Support

At the time of KotlinConf 2019, Kotlin Multiplatform was still an experimental feature. Britt Barak acknowledged this, preparing attendees for a landscape where documentation might sometimes be a bit dated, and tooling was rapidly evolving. However, she also pointed to the strong and growing community support as a significant asset. The official Kotlin Slack and various online forums were highlighted as valuable resources for troubleshooting and learning from others’ experiences.

She shared the sentiment that KMP was gaining popularity in a positive way, with many developers interested and actively contributing to its growth. This collaborative environment was seen as a good sign for the future development and stabilization of KMP. Britt encouraged developers to embrace this journey, start experimenting with multiplatform projects, and contribute to the community by sharing their own code and experiences. Her message was clear: despite its experimental nature, Kotlin Multiplatform offered a powerful and awesome way to achieve cross-platform code sharing, and it was a “really good time to jump on on the ride”.

Links:

• Britt Barak on LinkedIn

Learning a new programming language, especially one as rich and expressive as Kotlin, often comes with the temptation to use every new feature and syntactic sugar—the “golden hammer”—everywhere. Huyen Tue Dao, a prominent Android developer then known for her work at Trello and her insightful contributions to the Kotlin community, addressed this phenomenon at KotlinConf 2019. Her talk, “Putting Down the Golden Hammer,” shared valuable lessons learned from nearly three years of full-time Kotlin development, emphasizing the importance of pragmatism, readability, and maintainability over merely clever code. Huyen’s insights can often be found on her blog, randomlytyping.com.

Huyen began by acknowledging the allure of Kotlin’s advanced features. While these constructs can be powerful and lead to concise code, she cautioned that their overuse or misuse can sometimes negatively impact code clarity and long-term maintainability. The journey of a developer learning Kotlin often involves an initial phase of enthusiasm for these new tools, followed by a more mature understanding of when and how to apply them judiciously.

The Evolution of a Kotlin Developer’s Approach

Huyen Tue Dao shared her personal evolution in approaching various Kotlin features. She reflected on how code written early in her Kotlin journey might look different from her current practices, shaped by experience, trial, and error. This evolution is natural and signifies a deeper understanding of the language’s nuances and the trade-offs involved in different coding styles.

One key area she touched upon (common in such discussions) is the balance between conciseness and readability. Kotlin allows for very compact code, but sometimes a slightly more verbose approach can be easier for others (and one’s future self) to understand and maintain. She stressed that while Kotlin’s features are designed to make developers more productive, this productivity should not come at the expense of creating code that is difficult to reason about or debug. The goal should be to write “better Kotlin,” which implies code that is not only functionally correct and efficient but also clear, pragmatic, and maintainable.

Pragmatism in Feature Usage: Scope Functions, Nullability, and More

Huyen Tue Dao delved into specific Kotlin features and utilities, discussing both their “fun and shiny” aspects and how they can be overused or even abused. For instance, scope functions (let, run, with, apply, also) are powerful tools for executing a block of code within the context of an object. However, excessive nesting or unclear usage can lead to code that is hard to follow. Huyen advocated for intentionality: choosing the right scope function for the task and ensuring its use enhances clarity rather than obscuring it.

Null safety is another cornerstone of Kotlin, designed to prevent NullPointerExceptions. Huyen discussed the importance of being deliberate about nullability. While Kotlin’s type system helps manage nulls effectively, developers still need to make conscious decisions about whether a type should be nullable and handle nullable types appropriately, without resorting to excessive safe calls (?.) or non-null asserted calls (!!) that might hide underlying design issues. She emphasized being clear about why something is nullable and documenting such decisions when necessary, especially when assumptions about nullability change or when interacting with APIs where null safety guarantees might be different.

Towards Readable and Maintainable Kotlin

Ultimately, Huyen Tue Dao’s message was a call for mindful Kotlin development. She encouraged the audience to revel in Kotlin’s wonderful syntax and features but to always keep readability, maintainability, and pragmatism at the forefront. Understanding the underlying implementation of certain features can also be crucial to avoid potential performance issues.

The aim is not to write code that merely feels “sexy and Kotlin-y” but to craft solutions that are robust, easy for a team to work with, and stand the test of time. Recognizing the potential pitfalls of overusing certain constructs and consciously choosing simpler, clearer alternatives when appropriate leads to what Huyen termed “even better and even more fun Kotlin”. Her talk served as a valuable reminder that true mastery of a language lies not just in knowing its features, but in knowing when and how to use them wisely.

Links:

• Huyen Tue Dao on LinkedIn
• Huyen Tue Dao’s Blog (Randomly Typing)

Lecturers

Maria Neumayer is an Android developer at Deliveroo, specializing in UI since 2010. Originally from Austria, she has worked in London at Citymapper, Path, Saffron Digital, and Rummble. Amal Kakaiya, also an Android engineer at Deliveroo, has coded professionally since 2012. A Glasgow native, he is a triathlete based in East London. Relevant links: Deliveroo Tech Blog (publications); Maria Neumayer’s LinkedIn; Amal Kakaiya’s LinkedIn (professional pages).

Abstract

This article examines Maria Neumayer and Amal Kakaiya’s insights on adopting Kotlin collaboratively within Deliveroo’s Android team. Set against the backdrop of transitioning to Kotlin in production, it explores methodologies like dedicated learning hours and enhanced code reviews. The analysis highlights innovations in fostering openness, combating imposter syndrome, and improving engineering culture, with implications for team dynamics and code quality.

Introduction and Context

At KotlinConf 2018, Maria Neumayer and Amal Kakaiya shared their team’s journey of adopting Kotlin for Deliveroo’s consumer Android app. About one and a half years prior, the team embraced Kotlin, recognizing its learning curve as an opportunity for collective growth. This narrative unfolds in a context where individual learning styles vary, yet collaborative approaches can unify teams, enhance code quality, and nurture a culture of inquiry and knowledge-sharing.

Methodological Approaches to Team Learning

The team implemented structured learning strategies. They allocated weekly Kotlin hours for hands-on practice, encouraging experimentation with features like coroutines. Code reviews shifted from mere correctness checks to learning platforms, where developers shared insights on Kotlin idioms. Pair programming and mob sessions facilitated real-time knowledge exchange, while attending cross-disciplinary talks (e.g., backend conferences) broadened perspectives. They also created forums like “Kotlin Era” to discuss and upskill, ensuring inclusivity.

Analysis of Innovations and Features

The innovation lies in treating learning as a team endeavor, not an individual task. Structured Kotlin hours fostered experimentation, reducing fear of failure. Code reviews as learning tools encouraged constructive feedback, leveraging Kotlin’s concise syntax to highlight best practices. Cross-disciplinary exposure added diverse insights, unlike traditional siloed learning. Compared to solo learning, this approach mitigated imposter syndrome by normalizing questions. Challenges included balancing learning with delivery and ensuring all team members engaged equally.

Implications and Consequences

This collaborative model implies stronger team cohesion and faster Kotlin adoption. By sharing knowledge, teams produce idiomatic, maintainable code, enhancing app quality. The cultural shift toward openness reduces psychological barriers, fostering inclusivity. Consequences include improved processes, though maintaining momentum requires sustained effort and leadership support.

Conclusion

Neumayer and Kakaiya’s approach demonstrates that collaborative learning accelerates Kotlin adoption while strengthening engineering culture. By learning together, teams create not only better code but also a supportive, innovative environment.

Links

• Lecture video: https://www.youtube.com/watch?v=RUz8bCaAU_E
• Lecturers’ X/Twitter: @mneug (Maria); @amalkakaiya (Amal)
• Lecturers’ LinkedIn: Maria Neumayer; Amal Kakaiya
• Organization’s X/Twitter: @DeliverooEng
• Organization’s LinkedIn: Deliveroo