Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Our Journey from Java to Kotlin-first!

Our Journey from Java to Kotlin-first!

At Mapbox, it took time, sweat and tears, but we finally adopted Kotlin as the main development language for all Android based projects.

In this session, we will talk about all the bumps we ran into along the way, and describe all the reasons that led us to make the decision to move to Kotlin. We will also show the problems and findings that we encountered along the journey of converting the Mapbox Navigation SDK for Android from 0.x Java to 1.0 Kotlin-first. We will illustrate how we replaced Java tooling and coding style guidelines with Kotlin specific ones, and how we took advantage of some language features and constructs to design APIs that are great for both Kotlin and Java. All this in addition to making sure the SDK was ready for prime time i.e. with S.O.L.I.D. architecture, APIs that are hard to misuse, a low crash rate, well tested and performant.

It's been quite a ride. Do you want to know how it went? Join us!

Pablo Guardiola

December 20, 2019
Tweet

More Decks by Pablo Guardiola

Other Decks in Programming

Transcript

  1. Navigation SDK 1.0 - Kotlin-first - Modularized - Clean and

    performant APIs that are hard to misuse
  2. Benefits Developer - Intuitive - Statically typed - Type inference

    - Outstanding IDE support - Functional and object-oriented - Expressive - Concise - null safe - //.
  3. Client / User - More strongly typed than Java -

    DSLs - Modern, powerful and safe - Fewer methods, less weight Benefits
  4. YES - Still in Beta (0.x) - Young - Client

    apps in Kotlin - Excitement
  5. NO - stdlib adds binary size - Kotlin versions incompatibility

    - Extra effort to make APIs Java friendly
  6. YES - Google’s preferred language for Android - Productivity -

    New Java features adoption is slow - OkHttp (v4.x) - Concurrency - Hiring
  7. Special attention - /! - lateinit / lazy - @NotNull

    non-annotated parameters - @JvmStatic and @get: - @throws methods - Writing Java in Kotlin
  8. MockK - relaxed = true RETURNS_DEEP_STUBS - relaxedUnitFun = true

    - Kotlin idiomatic - mockkObject - mockkStatic
  9. Public APIs - Don’t expose Kotlin types - Great for

    both Java and Kotlin - Java and Kotlin examples - Master @Jvm annotations - Rest of the code internal
  10. Takeaways - El que la sigue la consigue (Keep insisting)

    - Baby steps - Test harness - Watch out null checks - Designing Good APIs is hard