Posts Tagged ‘KotlinConf2019’
[KotlinConf2019] Exploring the Power of Kotlin/JS
Sebastian Aigner, a developer advocate at JetBrains, captivated KotlinConf2019 with his deep dive into Kotlin/JS, the JavaScript target for Kotlin. With a passion for web development, Sebastian showcased how recent advancements make Kotlin/JS a compelling choice for building web applications. From streamlined tooling to seamless JavaScript interoperability, he outlined the current state and future potential of Kotlin/JS, inspiring both newcomers and seasoned developers to leverage Kotlin’s paradigms in the browser.
Simplifying Development with the New Gradle Plugin
Kotlin/JS has evolved significantly, with the new Kotlin/JS Gradle plugin emerging as the cornerstone for browser and Node.js development. Sebastian explained that this plugin unifies previously fragmented approaches, replacing deprecated plugins like kotlin2js and kotlin-frontend. Its uniform Gradle DSL simplifies project setup, offering sensible defaults for Webpack bundling without requiring extensive configuration. For developers transitioning to multi-platform projects, the plugin’s compatibility with the Kotlin multi-platform DSL minimizes changes, enabling seamless integration of additional targets. By automating JavaScript environment setup, including yarn and package.json, the plugin empowers Kotlin developers to focus on coding rather than managing complex JavaScript tooling.
Mastering Dependency Management with npm
The JavaScript ecosystem, with over a million npm packages, offers unparalleled flexibility, and Kotlin/JS integrates effortlessly with this vast library. Sebastian highlighted how the Gradle plugin manages npm dependencies directly, automatically updating package.json when dependencies like React or styled-components are added. This eliminates the need for separate JavaScript environment setup, saving time, especially on non-standard platforms like Windows. Developers can import Kotlin libraries (e.g., coroutines, serialization) alongside JavaScript packages, with Gradle handling the JavaScript-specific versions. This unified approach bridges the gap between Kotlin’s structured ecosystem and JavaScript’s dynamic world, making dependency management intuitive even for those new to JavaScript.
Bridging Kotlin and TypeScript with Dukat
Interoperating with JavaScript’s dynamic typing can be challenging, but Sebastian introduced Dukat, an experimental tool that converts TypeScript declaration files into Kotlin external declarations. By leveraging TypeScript’s de facto standard for type definitions, Dukat enables type-safe access to npm packages, such as left-pad or react-minimal-pie-chart. While manual external declarations require tedious annotation, Dukat automates this process, generating headers for packages with TypeScript support or community-contributed definitions. Sebastian encouraged early adoption to provide feedback, noting that Dukat already powers browser and Node.js API wrappers. This tool promises to simplify integration with JavaScript libraries, reducing the friction of crossing the static-dynamic typing divide.
Enhancing Testing and Debugging with Source Maps
Testing and debugging are critical for robust applications, and Kotlin/JS delivers with integrated tools. Sebastian demonstrated how the Gradle plugin supports platform-specific test runners like Karma, allowing tests to run across browsers (e.g., Firefox, headless Chrome). Source maps, automatically generated since Kotlin 1.3.60, provide detailed stack traces for Node.js and interactive debugging in browser DevTools. Developers can set breakpoints in Kotlin code, inspect variables, and trace errors directly in Chrome’s console, as shown in Sebastian’s pong game demo. Gradle test reports further enhance diagnostics, offering HTML-based insights into test failures, making Kotlin/JS development as robust as its JVM counterpart.
Optimizing with the IR Backend
The upcoming Intermediate Representation (IR) backend marks a significant leap for Kotlin/JS. Sebastian outlined its benefits, including aggressive code size optimizations through dead code elimination. Unlike the current backend, which may ship the entire standard library, the IR backend, combined with Google Closure Compiler, reduces zipped file sizes dramatically—down to 30 KB from 3.9 MB in some cases. Faster compilation speeds, especially for incremental builds, enhance developer productivity, particularly in continuous build scenarios with Webpack’s dev server. The IR backend also supports platform-agnostic compiler plugins, simplifying multi-platform development. Sebastian noted that pre-alpha IR support in Kotlin 1.3.70 requires manual exports due to its closed-world assumption, urging developers to explore early releases.
Looking Ahead: WebAssembly and Framework Support
Sebastian concluded with a glimpse into Kotlin/JS’s future, highlighting potential support for ECMAScript 6 modules and frameworks like Angular and Vue.js. While JetBrains provides React wrappers, extending first-class support to other frameworks requires addressing their unique tooling and compilers. The IR backend also opens doors to WebAssembly, enabling Kotlin to target browsers more efficiently. Though no timelines were promised, these explorations reflect JetBrains’ commitment to aligning Kotlin/JS with modern web trends. Sebastian’s call to action—trying the Code Quiz app at the Kotlin booth and contributing to Dukat—emphasized community involvement in shaping Kotlin/JS’s evolution.
Links:
[KotlinConf2019] Simplifying Async APIs with Kotlin Coroutines
Tom Hanley, a senior software engineer at Toast, enthralled KotlinConf2019 with a case study on using Kotlin coroutines to tame a complex asynchronous API for an Android card reader. Drawing from his work integrating a third-party USB-connected card reader, Tom shared how coroutines transformed callback-heavy code into clean, sequential logic. His practical insights on error handling, debugging, and testing offered a roadmap for developers grappling with legacy async APIs.
Escaping Callback Hell
Asynchronous APIs often lead to callback hell, where nested callbacks make code unreadable and error-prone. Tom described the challenge of working with a third-party Android SDK for a card reader, which relied on void methods and listener interfaces for data retrieval. A naive implementation to fetch device info involved mutable variables and blocking loops, risking infinite loops and thread-safety issues. Such approaches, common with legacy APIs, complicate maintenance and scalability. Tom emphasized that coroutines offer a lifeline, allowing developers to wrap messy APIs in a clean, non-blocking interface that reads like sequential code, preserving the benefits of asynchrony.
Wrapping the Card Reader API with Coroutines
To streamline the card reader API, Tom developed a Kotlin extension that replaced callback-based interactions with suspend functions. The original API required a controller to send commands and a listener to receive asynchronous responses, such as device info or errors. By introducing a suspend getDeviceInfo function, Tom enabled callers to await results directly. This extension ensured referential transparency, where functions clearly return their results, and allowed callers to control asynchrony—waiting for completion or running tasks concurrently. The approach also enforced sequential execution for dependent operations, critical for the card reader’s connection and transaction workflows.
Communicating with Channels
Effective inter-thread communication was key to the extension’s success. Rather than relying on shared mutable variables, Tom used Kotlin channels to pass events and errors between coroutines. When the listener received device info, it sent the data to a public channel; errors were handled similarly. The controller extension used a select expression to await the first event from either the device info or error channel, throwing errors or returning results as needed. Channels, with their suspending send and receive operations, provided a thread-safe alternative to blocking queues. Despite their experimental status in Kotlin 1.3, Tom found them production-ready, supported by smooth IDE migration paths.
Mastering Exception Handling
Exception handling in coroutines requires careful design, as Tom learned through structured concurrency introduced in Kotlin 1.3. This feature enforces a parent-child relationship, where canceling a parent coroutine cancels its children. However, Tom discovered that a child’s failure propagates upward, potentially crashing the app in launch coroutines if uncaught. For async coroutines, exceptions are deferred until await is called, allowing try-catch blocks to handle them. To isolate failures, Tom used supervisorJob to prevent child cancellations from affecting siblings and coroutineScope blocks to group all-or-nothing operations, ensuring robust error recovery for the card reader’s unreliable USB connection.
Debugging and Testing Coroutines
Debugging coroutines posed initial challenges, but Tom leveraged powerful tools to simplify the process. Enabling debug mode via system properties assigns unique names to coroutines, appending them to thread names and enhancing stack traces with creation details. The debug agent, a JVM tool released post-project, tracks live coroutines and dumps their state, aiding deadlock diagnosis. For testing, Tom wrapped suspend functions in runBlocking blocks, enabling straightforward unit tests. He advised using launch and async only when concurrency is needed, marking functions as suspend to simplify testing by allowing callers to control execution context.
Moving Beyond Exceptions with Sealed Classes
Reflecting on exception handling’s complexity, Tom shifted to sealed classes for error handling. Initially, errors from the card reader were wrapped in exceptions, but frequent USB failures made catching them cumbersome. Exceptions also obscured control flow and hindered functional purity. Inspired by arguments likening exceptions to goto statements, Tom adopted domain-specific sealed classes (e.g., Success, Failure, Timeout) for each controller command’s result. This approach enforced explicit error handling via when statements, improved readability, and allowed result types to evolve independently, aligning with the card reader’s diverse error scenarios.
Links:
[KotlinConf2019] Kotlin Coroutines: Mastering Cancellation and Exceptions with Florina Muntenescu & Manuel Vivo
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:
[KotlinConf2019] Kotless: A Kotlin-Native Approach to Serverless with Vladislav Tankov
Serverless computing has revolutionized how applications are deployed and scaled, but it often comes with its own set of complexities, including managing deployment DSLs like Terraform or CloudFormation. Vladislav Tankov, then a Software Developer at JetBrains, introduced Kotless at KotlinConf 2019 as a Kotlin Serverless Framework designed to simplify this landscape. Kotless aims to eliminate the need for external deployment DSLs by allowing developers to define serverless applications—including REST APIs and event handling—directly within their Kotlin code using familiar annotations. The project can be found on GitHub at github.com/JetBrains/kotless.
Vladislav’s presentation provided an overview of the Kotless Client API, demonstrated its use with a simple example, and delved into the architecture and design concepts behind its code-to-deployment pipeline. The core promise of Kotless is to make serverless computations easily understandable for anyone familiar with event-based architectures, particularly those comfortable with JAX-RS-like annotations.
Simplifying Serverless Deployment with Kotlin Annotations
The primary innovation of Kotless, as highlighted by Vladislav Tankov, is its ability to interpret Kotlin code and annotations to automatically generate the necessary deployment configurations for cloud providers like AWS (initially). Instead of writing separate configuration files in YAML or other DSLs, developers can define their serverless functions, API gateways, permissions, and scheduled events using Kotlin annotations directly on their functions and classes.
For example, creating a REST API endpoint could be as simple as annotating a Kotlin function with @Get("/mypath"). Kotless then parses these annotations during the build process and generates the required infrastructure definitions, deploys the lambdas, and configures the API Gateway. This approach significantly reduces boilerplate and the cognitive load associated with learning and maintaining separate infrastructure-as-code tools. Vladislav emphasized that a developer only needs familiarity with these annotations to create and deploy a serverless REST API application.
Architecture and Code-to-Deployment Pipeline
Vladislav Tankov provided insights into the inner workings of Kotless, explaining its architecture and the pipeline that transforms Kotlin code into a deployed serverless application. This process generally involves:
1. Annotation Processing: During compilation, Kotless processes the special annotations in the Kotlin code to understand the desired serverless architecture (e.g., API routes, event triggers, scheduled tasks).
2. Terraform Generation (Initially): Kotless then generates the necessary infrastructure-as-code configurations (initially using Terraform as a backend for AWS) based on these processed annotations. This includes defining Lambda functions, API Gateway resources, IAM roles, and event source mappings.
3. Deployment: Kotless handles the deployment of these generated configurations and the application code to the target cloud provider.
He also touched upon optimizations built into Kotless, such as “outer warming” of lambdas to reduce cold starts and optimizing lambdas by size. This focus on performance and ease of use is central to Kotless’s philosophy. The framework aims to abstract away the underlying complexities of serverless platforms, allowing developers to concentrate on their application logic.
Future Directions and Multiplatform Aspirations
Looking ahead, Vladislav Tankov discussed the future roadmap for Kotless, including ambitious plans for supporting Kotlin Multiplatform Projects (MPP). This would allow developers to choose different runtimes for their lambdas—JVM, JavaScript, or even Kotlin/Native—depending on the task and performance requirements. Supporting JavaScript lambdas, for example, could open up compatibility with platforms like Google Cloud Platform more broadly, which at the time had better support for JavaScript runtimes than JVM for serverless functions.
Other planned enhancements included extended event handling for custom events on AWS and other platforms, and continued work on performance optimizations. The vision for Kotless was to provide a comprehensive and flexible serverless solution for Kotlin developers, empowering them to build efficient and scalable cloud-native applications with minimal friction. Vladislav encouraged attendees to try Kotless and contribute to its development, positioning it as a community-driven effort to improve the Kotlin serverless experience.
Links:
[KotlinConf2019] Desktop Development with TornadoFX: Kotlinizing JavaFX with Liz Keogh
JavaFX, the successor to Swing for creating rich client applications in Java, offers a modern approach to desktop UI development with a cleaner separation of function and style. However, working directly with JavaFX can sometimes involve verbosity and untyped stylesheets. Liz Keogh, a renowned Lean and Agile consultant and a core member of the BDD community, presented a compelling alternative at KotlinConf 2019: TornadoFX. Her talk explored how TornadoFX, a Kotlin wrapper around JavaFX, simplifies desktop development with type-safe builders, stylesheets, and the syntactic sugar Kotlin developers appreciate. Liz Keogh’s consultancy work can often be found via lunivore.com.
TornadoFX aims to make JavaFX development more idiomatic and enjoyable for Kotlin developers. It leverages Kotlin’s powerful features to reduce boilerplate and introduce modern development patterns like dependency-injected MVC/MVP. The official website for the framework is tornadofx.io.
Simplifying JavaFX with Kotlin’s Elegance
Liz Keogh’s session highlighted how TornadoFX enhances the JavaFX experience. Key advantages include:
* Type-Safe Builders: Instead of manually instantiating and configuring UI components in JavaFX, TornadoFX provides type-safe builders. This allows for a more declarative and concise way to define UI layouts, reducing the chance of runtime errors and improving code readability.
* Type-Safe Stylesheets: JavaFX typically uses CSS for styling, which is not type-safe and can be cumbersome. TornadoFX introduces type-safe CSS, allowing styles to be defined directly in Kotlin code with autocompletion and compile-time checking. This makes styling more robust and easier to manage.
* Dependency Injection and Architectural Patterns: TornadoFX incorporates support for architectural patterns like Model-View-Controller (MVC) and Model-View-Presenter (MVP) with built-in dependency injection. This helps in structuring desktop applications in a clean, maintainable, and testable way.
* Kotlin’s Syntactic Sugar: The framework makes full use of Kotlin’s features, such as extension functions, lambdas, and DSL capabilities, to create a fluent and expressive API for building UIs.
Liz demonstrated these features through practical examples, showing how quickly developers can create sophisticated desktop applications with significantly less code compared to plain JavaFX.
Practical Application: Building a Desktop Game
To illustrate the power and ease of use of TornadoFX, Liz Keogh built a desktop version of the game “Don’t Get Mad!” (a variant of Ludo/Pachisi) live during her presentation. This hands-on approach allowed attendees to see TornadoFX in action, from setting up the project to building the UI, implementing game logic, and handling user interactions.
She showcased how to:
* Define views and components using TornadoFX’s builders.
* Apply styles using type-safe CSS.
* Manage application state and events.
* Integrate game logic written in Kotlin.
While focusing on TornadoFX, Liz also touched upon broader software development principles, such as the importance of automated testing. She candidly mentioned her preference for unit tests and the need for more in her demo project due to deadline constraints, reminding attendees about the test pyramid. This practical demonstration of building a game provided a tangible example of what’s possible with TornadoFX and how it can accelerate desktop development.
TornadoFX and the Kotlin Ecosystem
Liz Keogh’s presentation positioned TornadoFX as a valuable addition to the Kotlin ecosystem, particularly for developers looking to build desktop applications. By providing a more Kotlin-idiomatic layer over JavaFX, TornadoFX lowers the barrier to entry for desktop development and makes it a more attractive option for the Kotlin community.
She also mentioned another personal project, “K Golf” (Kotlin Game of Life), a JavaFX application she uses for teaching Kotlin, hinting at her passion for both Kotlin and creating engaging learning experiences. Her talk inspired many Kotlin developers to explore TornadoFX for their desktop application needs, showcasing it as a productive and enjoyable way to leverage their Kotlin skills in a new domain. The session underscored the theme of Kotlin’s versatility, extending its reach effectively into desktop development.
Links:
[KotlinConf2019] Kotlin Multiplatform Programming: Present and Future with Dmitry Savvinov and Liliia Abdulina
Kotlin Multiplatform Programming (MPP) has been a significant focus for JetBrains, aiming to extend Kotlin’s reach beyond traditional JVM and Android development. At KotlinConf 2019, Dmitry Savvinov and Liliia Abdulina, both from the Kotlin team at JetBrains, delivered an insightful overview of MPP’s capabilities in version 1.3.X and offered a glimpse into its future direction. Dmitry Savvinov, a key contributor to Kotlin Contracts and heavily involved in MPP, brought his compiler expertise to the discussion. The official Kotlin language website, the central hub for MPP information, is kotlinlang.org.
Their talk was structured to cover the fundamentals of multiplatform projects, illustrate these basics with examples, provide guidelines for designing first multiplatform projects, and showcase a production-like application to demonstrate design principles in action. This comprehensive approach aimed to equip developers with the knowledge needed to start leveraging MPP effectively.
Core Concepts of Kotlin Multiplatform
Dmitry Savvinov and Liliia Abdulina began by explaining the core building blocks of Kotlin Multiplatform projects. These foundational concepts are crucial for understanding how code can be shared and specialized across different platforms:
* Source Sets: The fundamental unit of code organization in MPP. A project is typically structured with a commonMain source set containing platform-agnostic Kotlin code. Platform-specific source sets (e.g., jvmMain, jsMain, iosMain) contain code tailored for each target and can depend on commonMain.
* Targets: These define the platforms the project will compile for, such as JVM, Android, JavaScript, iOS (Native), Linux, Windows, and macOS. Each target has its own compilations.
* Compilations: A compilation process for a specific target that produces the appropriate artifacts (e.g., JVM bytecode, JavaScript files, native executables).
* expect and actual Declarations: This powerful mechanism allows common code in commonMain to declare an expect class, function, or property. Platform-specific source sets must then provide an actual implementation for that declaration, bridging the gap between shared logic and platform-specific APIs. For example, a common module might expect a function to generate a UUID, and the JVM and Native modules would provide actual implementations using their respective platform libraries.
These concepts enable developers to write shared business logic, data models, and algorithms once in commonMain and then reuse them across multiple platforms, significantly reducing code duplication and improving consistency.
Designing and Implementing Multiplatform Projects
Beyond the basic syntax, Dmitry and Liliia provided guidance on how to approach the design of a multiplatform project. This involved discussing strategies for identifying what code can and should be shared, how to structure modules for optimal maintainability, and best practices for using expect/actual effectively.
They used toy examples to illustrate these basics in a clear and understandable manner, helping attendees grasp how these pieces fit together in a real project. The presentation then progressed to showcase a “more or less production-like application”. This larger example would have served to demonstrate how the design principles discussed could be applied to build a substantial, real-world multiplatform application, highlighting how to manage dependencies, handle platform-specific interactions, and structure a scalable MPP architecture. The focus was on providing practical insights that developers could apply to their own projects, whether starting from scratch or integrating MPP into existing applications.
The Trajectory of Kotlin Multiplatform: Beyond 1.3.X
While detailing the state of MPP in Kotlin 1.3.X, Dmitry Savvinov and Liliia Abdulina also looked towards its future development. At KotlinConf 2019, MPP was still evolving, with ongoing improvements to tooling, library support, and the overall developer experience. Their talk touched upon the roadmap for MPP, including planned enhancements to areas like Kotlin/Native (for performance and interoperability), library ecosystem growth, and further refinements to the build system and IDE support within IntelliJ IDEA and Android Studio.
The vision presented was one of Kotlin as a truly universal language, enabling developers to target a wide array of platforms with a unified codebase and skillset. The commitment from JetBrains to invest heavily in MPP was clear, with the aim of making it a robust and production-ready solution for cross-platform development. The session would have encouraged developers to explore MPP, provide feedback, and contribute to its growing ecosystem, reinforcing the community-driven aspect of Kotlin’s development.
Links:
[KotlinConf2019] Ktor for Mobile Developers: Conquering the Server with Dan Kim
For many mobile developers, the thought of venturing into server-side development can be daunting, often perceived as a realm of unfamiliar languages, complex frameworks, and different programming paradigms. Dan Kim, an experienced developer, aimed to demystify this process at KotlinConf 2019 with his talk, “Ktor for Mobile Developers: Fear the server no more!”. He showcased Ktor, a Kotlin-based framework for building asynchronous servers and clients, as an accessible and powerful tool for mobile developers looking to create backend components for their applications. The official website for Ktor is ktor.io.
Dan Kim’s session was designed to demonstrate how existing Kotlin knowledge could be leveraged to easily build server-side applications with Ktor. He promised a practical, real-world example, walking attendees through everything needed to get a server up and running: authentication, data retrieval, data posting, and deployment, ultimately aiming to give mobile developers the confidence to build their own backend services.
Introducing Ktor: Simplicity and Power in Kotlin
Ktor is a framework built by JetBrains, designed from the ground up with Kotlin and coroutines in mind, making it inherently asynchronous and well-suited for building scalable network applications. Dan Kim introduced Ktor’s core concepts, such as its flexible pipeline architecture, routing capabilities, and features for handling HTTP requests and responses. A key appeal of Ktor for mobile developers is that it allows them to stay within the Kotlin ecosystem, using a language and paradigms they are already familiar with from Android development.
The presentation would have highlighted Ktor’s ease of use and minimal boilerplate. Unlike some larger, more opinionated server-side frameworks, Ktor offers a more unopinionated and lightweight approach, allowing developers to choose and configure only the features they need. This can include functionalities like authentication, content negotiation (e.g., for JSON or XML), templating engines, and session management, all installable as “features” or plugins within a Ktor application.
Building a Real-World Server-Side Component
The core of Dan Kim’s talk was a hands-on demonstration of building a server-side component. He aimed to build a RESTful API and a web application, complete with authentication, and deploy it to Google Cloud, all within an impressively small amount of code (around 350 lines, as he mentioned). This practical example would have covered essential aspects of backend development:
* Routing: Defining endpoints to handle different HTTP methods (GET, POST, etc.) and URL paths.
* Request Handling: Processing incoming requests, extracting parameters, and validating data.
* Authentication: Implementing mechanisms to secure endpoints and manage user identity, possibly integrating with external services.
* Data Interaction: Showing how to get data from and post data to other services or a database (though the specifics of database interaction might vary).
* Deployment: Walking through the process of deploying the Ktor application to a cloud platform like Google Cloud, making the backend accessible to mobile clients.
By tackling these common server-side tasks using Ktor and Kotlin, Dan aimed to alleviate the fears mobile developers might have about backend development and demonstrate that they already possess many of the necessary skills.
Empowering Mobile Developers to Go Full-Stack
The overarching message of Dan Kim’s presentation was one of empowerment. He sought to show that with Ktor, mobile developers no longer need to “fear the server”. The framework provides a gentle learning curve and a productive environment for building robust and efficient backend services. This capability is increasingly valuable as mobile applications become more sophisticated and often require custom backend logic to support their features.
Dan Kim’s practical demonstration, from basic Ktor setup to cloud deployment, was intended to give attendees a clear understanding of how to connect their own server-side components to virtually any API. By simplifying the backend development process, Ktor enables mobile developers to potentially take on more full-stack responsibilities, leading to greater control over their application’s entire architecture and a faster development cycle for new features. He hoped his session would provide the confidence needed for mobile developers to start building their own server-side solutions with Kotlin and Ktor.
Links:
[KotlinConf2019] Building Progressive Web Apps in Kotlin: A New Frontier with Erik Hellman
The landscape of web development has traditionally been dominated by JavaScript and its ecosystem of tools and frameworks. However, with Kotlin’s growing versatility, particularly its Kotlin/JS capabilities, new avenues are opening up for developers who prefer Kotlin’s syntax and features. Erik Hellman, an experienced software consultant with a deep background in various programming languages, explored this exciting intersection at KotlinConf 2019. His session, “Building Progressive Web Apps in Kotlin,” introduced how Kotlin, combined with its JavaScript support, could be used to create modern web applications, also known as Progressive Web Apps (PWAs).
Erik Hellman’s talk aimed to show developers how they could leverage their Kotlin knowledge to build PWAs, potentially using popular JavaScript frameworks like React, Vue.js, or LitElement through Kotlin wrappers or directly with Kotlin/JS. This approach offers an alternative for those who find Kotlin more aligned with their development style than TypeScript or plain JavaScript, or for teams looking to unify their technology stack around Kotlin.
Kotlin/JS: Bridging Kotlin to the Web
At the heart of building web applications with Kotlin is Kotlin/JS, which allows Kotlin code to be compiled (or “transpiled”) into JavaScript. Erik Hellman explained the fundamentals of Kotlin/JS, including how it maps Kotlin concepts to their JavaScript equivalents and enables interoperability with existing JavaScript libraries and browser APIs. This capability is crucial, as it allows Kotlin developers to tap into the vast JavaScript ecosystem while writing code in a language they are comfortable and productive with.
The session would have covered how to set up a Kotlin/JS project, manage dependencies, and structure code for web development. Erik might have also discussed the benefits of using Kotlin for web development, such as its strong type system, null safety, and conciseness, which can lead to more robust and maintainable web applications compared to traditional JavaScript development. The focus was on providing a pathway for Kotlin enthusiasts to extend their skills into the PWA domain.
Progressive Web Apps: Enhancing the Web Experience
Progressive Web Apps (PWAs) represent an evolution of web applications, aiming to provide a user experience similar to native mobile apps. Key features of PWAs include offline capabilities (through service workers), installability on user devices, push notifications, and fast performance. Erik Hellman’s talk would have explored how these PWA characteristics can be implemented using Kotlin/JS.
A significant part of building PWAs involves working with service workers for caching and offline support, and web app manifests for installability. Erik demonstrated how to write service worker logic in Kotlin and manage the manifest file within a Kotlin/JS project. He might have also touched upon techniques for optimizing performance and ensuring a smooth user experience, which are critical aspects of successful PWAs. The overall goal was to equip Kotlin developers with the knowledge to build modern, engaging web experiences that leverage the latest web platform features.
Current State and Future Promise
During his 2019 presentation, Erik Hellman acknowledged that while Kotlin/JS was powerful, the tooling and ecosystem were still maturing, particularly around areas like code splitting for service workers. He noted that finding help and up-to-date information sometimes required tapping into the Kotlin community, such as the official Slack channel.
Despite these challenges, he conveyed a sense of optimism, stating that Kotlin/JS looked “really really promising” as an alternative for web development, especially for projects where Kotlin was already in use for other components (like backend or mobile). He suggested that for many use cases, Kotlin/JS was already a viable option. His talk concluded by pointing towards the continued development and improvement of Kotlin/JS, anticipating it would become an even more compelling choice for building PWAs in the future, offering a robust and enjoyable development experience for Kotlin aficionados venturing into the web.
Links:
[KotlinConf2019] Sharing Is Caring: Kotlin Multiplatform for Android Developers with Britt Barak
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:
[KotlinConf2019] Putting Down the Golden Hammer: Pragmatic Kotlin with Huyen Tue Dao
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.