“hi18n” is an internationalization library (more specifically, translation management library) for JavaScript/TypeScript and is currently under active development in Wantedly.

GitHub - wantedly/hi18n: message internationalization meets immutability and type-safety

It roughly has the following features:

• TypeScript compiler ensures that you are using correct translation ids and translation parameters.
• Designed to match declarative paradigms such as React.
• Integrates well with existing ecosystems (such as Webpack) without extra configuration. For example, Webpack’s hot reloading and chunk splitting work out-of-the-box with hi18n. This happens just thanks to its modern architecture and requires no bundler-specific code.

We’ll describe design principles in detail in the coming blog posts. In this article, however, we provide a quick start for those interested in our library.

Setting it up

In this article, we assume you have a React + TypeScript project. First, install the following packages:

npm install @hi18n/core @hi18n/react-context @hi18n/react
npm install -D @hi18n/cli

# Or:
yarn add @hi18n/core @hi18n/react-context @hi18n/react
yarn add -D @hi18n/cli

Then create files for translation data. Depending on your preference, you can configure it in two ways: single-file or multi-files. We use the latter in this guide.

In the multi-file configuration, you have N+1 files where N is the number of languages.

// src/locale/index.ts
// (other names are fine)
// This file defines the list of translatable strings.

import { Book, Message } from "@hi18n/core";
import catalogEn from "./en";
import catalogJa from "./ja";

export type Vocabulary = {
  // "<Translation ID>": Message<{ <Parameters> }>; (or simply Message; if you don't need parameters)
  "example/greeting": Message<{ name: string }>;
};

// This is a bundle of translations for all languages (English and Japanese in this case).
export const book = new Book<Vocabulary>({
  en: catalogEn,
  ja: catalogJa,
});

// src/locale/en.ts
// (other names are fine)
// This file contains translated messages in a specific language (i.e. English).

import { Catalog, msg } from "@hi18n/core";
import type { Vocabulary } from ".";

export default new Catalog<Vocabulary>({
  // "<Translation ID>": msg(<translated message>),
  "example/greeting": msg("Hello, {name}!"),
});

// src/locale/ja.ts (in the same manner as en.ts)

import { Catalog, msg } from "@hi18n/core";
import type { Vocabulary } from ".";

export default new Catalog<Vocabulary>({
  "example/greeting": msg("こんにちは、{name}さん!"),
});

Then define a command for synchronizing translations and translation IDs:

// package.json
{
  "scripts": {
    "i18n:sync": "hi18n sync 'src/**/*.ts' 'src/**/*.tsx'"
  }
}

Then you can start using hi18n.

If you are using ESLint, we recommend our ESLint plugin. Just install the package and extend the preset called plugin:@hi18n/recommended .

Using translated messages

There are several ways to use the translated messages in your application code.

With useI18n

This is the most standard way if you are using React. To use useI18n, you first need to configure a locale (usually at the root of the tree).

// An example with explicit ReactDOM call.
// You may need to place it in a different place (like _app.ts).
import { LocaleProvider } from "@hi18n/react";

const root = ReactDOMClient.createRoot(/* ... */);
root.render(
  <LocaleProvider locales="ja">
    {/* ... */}
  </LocaleProvider>
);

Then use useI18n to start translating everywhere in the tree.

import { useI18n } from "@hi18n/react";
// You need to explicitly import the translation data (which we call a book).
import { book } from "../../locale";

const Greet: React.FC = () => {
  // It returns a function for translation using the current locale (from the context) and the book you supplied.
  const { t } = useI18n(book);
  return <>{t("example/greeting", { name: "太郎" })}</>;
};

With <Translate>

The <Translate> component is suitable for translating messages interleaved with markups or React elements.

import { Translate } from "@hi18n/react";
// You need to explicitly import the translation data (which we call a book).
import { book } from "../../locale";

const Greet: React.FC = () => {
  return <Translate book={book} id="example/greeting" name="太郎" />;
};

Special to <Translate> , you can pass a React element as a parameter to the translation:

const UnreadMessages: React.FC = () => {
  const unreadCount = 2;
  if (unreadCount === 0) return null;

  // en: "You have <link>{count,plural,one{# unread message}other{# unread messages}}</link>"
  // ja: "<link>{count,number}通の未読メッセージ</link>があります"
  return <Translate book={book} id="example/unread" count={unreadCount}>
    <a key="link" href="https://example.com/inbox" />
  </Translate>;
};

Synchronizing translations and translation IDs

Use hi18n sync command to synchronize translation IDs between the application and the translation data.

hi18n sync <globs...> [--exclude <glob>] [--check | -c]

Define a task using package.json:

// package.json
{
  "scripts": {
    "i18n:sync": "hi18n sync 'src/**/*.ts' 'src/**/*.tsx'"
  }
}

and use it to update your translations:

npm run i18n:sync

# Or:

yarn i18n:sync

Watch out for your unsaved changes to the translations; it may rewrite TypeScript/JavaScript files containing the translations.

This command does the following:

• it comments out unused translations, and
• it generates a boilerplate for translations required by the application, but not defined yet.

Sometimes translations that are still in use are accidentally commented out. This is likely caused by a mistake in the application:

• You may have used hi18n in a way that the tool cannot detect translation usages.
• Or you may have commented out some portion of the application for debugging, and forgot to uncomment them before running the sync command.

In any case, just fix the problem in the application and rerun the synchronization. Then the command undoes the comment-out.

Adding a new translatable message

To add a new message, you can follow the steps below:

First, add a message using t.todo or <Translate.Todo> instead of t or <Translate> .

t.todo("example/new");
<Translate.Todo book={book} id="example/new" />;

Then use the hi18n sync command to generate the boilerplate. Fill in the actual translations and remove .todo or .Todo .

You may also get the same result by editing everything by hand.

Other things you can do with hi18n

These things will be covered in later posts.

• Plural forms and number formats. The Intl API must be available in the browser to use them.
• t.dynamic, Translate.Dynamic , and translationId API to dynamically select messages.
• Our ESLint plugin @hi18n/eslint-plugin ensures the correct use of hi18n. It also has helper rules such as migration from Lingui.
• You can simply create multiple Books if you need to split translation data. This is useful if you need to reduce bundle size or if you need to use hi18n in a library.

Colophon

This article was originally written in Japanese and translated to English by the author.

“hi18n”, a TypeScript-first internationalization library — getting started guide was originally published in Wantedly Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since every new task is an occasion to learn something, and new features are constantly added to the web platform, I saw it as an opportunity to try a new CSS property from the CSS Containment Spec.

Introducing content-visibility

The content-visibility property is a feature introduced a little while ago that allows to specify that an element might not need to be rendered on screen immediately. Its typical use-case is to set it to off-screen elements so the browser doesn’t have to do work until the user scrolls down the page. For more info about how it works, you should consult this article on Web.dev.

My use-case was a page listing a potentially large number of items, and refactoring it for pagination was an effort we didn’t want to spend time on yet. Large pages with thousand of DOM nodes are very costly to render, to the point of making some crash. That case thus looked like an easy win with the content-visibility: auto;property: a few lines of CSS lead to a reducing the amount of time spent on layout work from 3 to 6 times on large lists! (This seems to correspond to the improvements indicated in the article linked above.) And with the magic of CSS, this is also a safe change as incompatible browsers will ignore the property.

The second step was then to set the contain-intrinsic-size to give the off-screen elements a placeholder size. This property is very important for the user experience, without it the scrollbar becomes a very unreliable indicator. Commit and ship, then go on to do other tasks.

The unexpected result

Early on, the results of this change were positive — albeit very small, but worth it for such a small change. But soon after, the page started to show up in our Search Console diagnostics as having a bad Cumulative Layout Shift (later CLS) score.

When using the Web Vitals diagnostic tool from the Chrome Dev Tools and scrolling up-and-down the page, the metric did increase despite no particular layout work being done due interactions.

I had to check all moving parts around the page in the performance profiler to see what layout operations were at the source of this issue, but none seemed to pass this investigation. It’s only by eliminating all these suspects that I was left with my last change to the page: the addition of content-visibility and contain-intrinsic-size .

When adding these, I actually made a mistake: due to the complexities of responsive webpages, the target list elements had a height that would vary depending on the device. I assumed that contain-intrinsic-size was merely used for the scrollbar and that an approximation of the final size was good enough. However that caused the browser to re-adjust the size of each element coming into the viewport as the user scrolls! This constant layout recalculations were akin to constantly setting the height property via Javascript, a very expensive task, causing subtle but constant layout jank.

Another solution I was looking forward to is to use the contain-intrinsic-size: auto $size; variant that makes the browser remember the size of previously computed elements, shipped in Chrome 98. But that only eliminates a part of the work as the browser still has to compute each element at least one, and my short experiment actually made the CLS worse.

The takeaway is: be careful with contain-intrinsic-size and learn how to measure your performance!

A failed experiment about CSS containment was originally published in Wantedly Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently at Wantedly, the whole DX team worked on improving the SEO score of our site. The SEO world is ever-changing, and we constantly have to adapt to the latest evolution of search engines.

During this task, focusing on the coding side rather than content, I learned a few tips that I can share with you today, mostly focusing on Google’s expectations.

Are you exceeding your Crawl Budget?

Due to the web being so huge and computing power being limited, Google’s bot limits the amount of pages it will crawl for a given site and how often it will come back for updates. This is what they call “Crawl Budget”: if you submit too many pages — notably via a sitemap — Google is likely to defer visiting those pages and will clog the backlog of pages to analyze. This may lead to long delays before your precious content is indexed and available in the search results. Google considers a site with more than 100k pages to be “large”, meaning that you should look into optimizing your crawl budget for your site(s) that pass this threshold.

As with anything SEO, this is still very dependent on the perceived quality of the content. If your pages are all well referenced and see a lot of traffic coming from various sources — such as social networks — the budget that Google will allocate to your site will be far bigger, even if you have a massive amount of pages.

When you update pages, make also sure to set a timestamp somewhere in the page — or in the sitemap — to indicate that there has been an update, saving the computing time needed to compare the page with previous versions, and signifying that your pages’ information is up-to-date

Sitemaps are recommendations, not orders

I previously mentioned that Google bots will only visit a limited number of pages on your site. Populating sitemaps is a way to signify that you consider some pages worth visiting, and inform the search engines about pages that have very few links available, thus being hard to reach.

But be aware that it still is only a recommendation of which pages to visit. Google’s crawler will very often de-prioritize those pages in favor of ones that see more external links and traffic. It is also very likely that Google does not crawl nor index some of the pages from your sitemap, if it finds them to be not relevant enough.

Note also that there is no automated way to un-submit pages from the sitemap. If pages have been added to the sitemap and the bot downloaded it already, it will likely visit that page even if you remove it from the sitemap afterwards, and thus will cause coverage errors due to pages missing. A simple example of this issue that we’ve had on Wantedly is spam accounts. There exist a way to cancel indexing of pages, but it is only through the search console interface, thus not really scalable to large amount of pages.

Google bots are smarter than you think

Or at least I thought they were.

A strange error appeared on the Coverage part of the Search Console: “Submitted URL seems to be a Soft 404.”

Google’s engines are able to analyze the contents of the page and find out that despite returning a 200 HTTP code — successful request — the page is almost empty. Thus it might as well be a 404 that does not deserve indexing. Example of where this happens on our sites: a page that list items that can be filtered by a category of some sort, but has no element for that category thus showing an empty list.

(My guess is the actual implementation of this feature probably starts by diffing that page with other ones and comparing the similar parts in the HTML that would be the application shell, menus, etc. The rest of the diff would be the actual content for that specific URL, and if it’s very short or doesn’t have any link, can be considered empty?)

But smart doesn’t mean perfect

“[Warning] Indexed, though blocked by robots.txt” told me Google, in a yellow text with scary icons. Sounds like a simple error of configuration on the robots.txt file that is used to indicate pages that should not be crawled or indexed.

Yet… this URL pattern has never been set to our robots.txt . After double-checking, trying the — not always very helpful— tools provided by Google, such as the Robots testing tool, everything looked fine.

After furiously searching on the web, I found this comment on the Help forums:

(it’s just unfortunately confusingly saying its blocked by robots.txt, but really its blocked because not an web page)

If I am to believe this user, the warning message is just a catch-all message that indicates the crawler is not able to read the contents of the page. So lesson learned: be always cautious about the automated diagnostics and learn to find the real issues on your site.

Closing words

I hope these small tips will help you find your way in the weird jungle that is SEO optimization. Remember, all Google wants is the top search results to provide pages with interesting content to its users, so that they want to use the site again. Making sure your pages are easy to parse and analyze should result in improvements!

Tips about improving SEO as a developer was originally published in Wantedly Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Wantedly Android app was first launched in 2014, which was some time ago, hence our codebase for our Android app is quite old. When I joined Wantedly 3 years ago, there were quite a few issues with the test suite that was in place. The number of test cases was low and it was not possible to produce a test coverage report. The test cases that we have were also quite flaky and difficult to maintain. Whenever we want to update or add a new test case, it required a lot of complicated setups and it was very difficult to test a single component of the app independently.

We knew that we need to improve this if we want to scale our development and improve the productivity of the Android engineers. With this post, I want to share what we did to make our Android codebase testable.

Defining the Objectives

I think it’s really important that we define what we need to implement and achieve. In our case, we created a document that outlines the goals, benefits, strategy, and conventions of writing tests. This document also served as the centerpiece of discussions for the engineers and the stakeholders so that everybody is on the same page, and can also be used for references for new members in the future. I’ll try to briefly show what our document looks like.

Goals: To create a solid framework and infrastructure to easily build, test, and release our apps with ease of mind.

Benefits: A reliable test suite allows engineers to make changes quickly and release the app confidently. It provides a shorter feedback cycle during development, making it easier to debug issues in the application. It also allows us to simulate hard-to-replicate edge cases consistently. A well-documented test suite can also be used as documentation to help in knowledge sharing.

Strategy: Structure the test suite with the testing pyramid (we’ll talk more about this in detail later). We also need each “component” in the app to be independently testable, but still can be tested together if needed. We will run the test suite on every pull request. Any pull requests to the main branch need to have added/removed test cases, and we’ll also ensure that the coverage doesn’t drop.

Conventions: Ensure that the test cases are consistent across the codebase. We will use a unified test method naming (something like givenCondition_whenAction_thenResult) to ensure consistency and make it easier to write and maintain. Consistent test method naming allows us to quickly identify which test case is failing in CI. The test cases should be small and test only 1 aspect of the code.

Our Approach to Testing

The best strategy to structure your test suite will depend on your team and codebase. Here, I will describe what our approach was in introducing testable architecture into our legacy codebase.

Testing Pyramid

Testing pyramid allows us to group tests into buckets depending on the number of components involved, execution time, and maintenance effort of each group. It also gives us an idea of how many test cases we need to write for each group. Ideally, you want to write a large number of test cases that are easy to maintain. Hence, you want a smaller number of tests as you go up the pyramid. Typically, from the top, you’ll have the end-to-end tests, then integration tests, and then finally the unit tests at the bottom of the pyramid.

Here’s how we structured our test suite using the testing pyramid:

At the top of the pyramid, we have our end-to-end testing with Firebase Robo Test. Then, we have our Fragments’ Espresso UI Tests, which are run as instrumented tests. We test the Fragments together with the ViewModel as our Fragments are tied heavily with the implementation of our ViewModel. We also replace any dependencies that are required by the ViewModel (such as repository classes) with test doubles to allow easier testing. Finally, we have repository and utility class tests that are run as local unit tests with Robolectric.

Note: Repository classes that interact with SQLite database, should be run as instrumented tests.

Test Doubles

Test doubles are replacement objects for classes that we use in production, whose behaviors can be controlled during testing. We use test doubles to create a predictable condition for our tests. They are also very important to allow us to test our components in isolation. In Wantedly, we primarily make use of 2 types of test doubles, mocks, and fakes.

Mock: a type of test double that can respond to a set of method calls whose answers have been defined. It can also check whether a method in the test double has been or has not been invoked. Some of the popular libraries that can help you create mock classes in Android are Mockito and MockK.

interface UserRepository {
  suspend fun getUser(userId: Int): User
}

// Create a mock UserRepository with MockK
val mockRepo = mockk<UserRepository>()

// Set getUser to return a fake User object every time it's called.
coEvery { mockRepo.getUser(any()) } answers {
  User(
    id = firstArg(),
    firstName = "John",
    lastName = "Smith"
  )
}

// Usage
launch {
  mockRepo.getUser(1) // Will return User(1, "John", "Smith")
}

Fake: a type of test double that uses some sort of “shortcut” implementation to act like the real class. If you use interfaces to declare your class dependencies, then creating a fake implementation is quite straightforward.

interface UserRepository {
  suspend fun getUser(userId: Int): User
}

// Create a fake implementation of a UserRepository
class FakeUserRepository : UserRepository {
  override suspend fun getUser(userId: Int): User {
    return User(
      id = userId,
      firstName = "John",
      lastName = "Smith"
    )
  }
}

Writing Tests

As I mentioned above, we introduced several conventions, such as test method naming, to ensure that the tests are consistent across the codebase. This helps us describe the scenario being tested, and also helps us quickly identify regression in our code. We also treat our test code as production code, meaning that SOLID principle still applies to the test code.

Other than that, we also use other third-party libraries to help us write test cases more easily. For example, we are using Kakao, a Kotlin DSL wrapper for Espresso, to write our UI test as we find the DSL is much more readable. We also wrote a library to create fake objects using reflection to help generate fake data for testing.

Since most of the components that we’re testing are similar to each other (Fragments, ViewModels, etc). We created a few JUnit rules to make setting up those tests easier. For example, we have a FragmentTestRule that contains several other JUnit rules such as InstantTaskExecutorRule, TaskSchedulerRule, and DataBindingIdlingResourceRule to ensure that the Fragment tests are deterministic and not flaky.

Our approach was UI testing to test UI logic, not the appearance of the UI element. Checking whether a Button is displayed correctly in a specific color or size with Espresso is difficult, however, you can easily check whether that button has the correct label or whether it is clickable. If you want to test the appearance of a Button, I’d suggest you take a look at screenshot testing instead.

Testing Components in Isolation

The ability to test components independently is important to ensure that we can focus on writing the test cases for each specific component. To achieve that, we make use of dependency injection such as Dagger and constructor parameters to pass in the required dependencies for each class. This allows us to easily replace those dependencies with test doubles during testing. Consider the following example:

interface UserApi {
  suspend fun getUser(userId: Int): User
}

interface UserRepository {
  suspend fun getUser(userId: Int): Flow<User>
}

class UserRepositoryImpl(
  val userApi: UserApi, 
  val userDb: UserDB
) : UserRepository {
  
  override fun getUser(userId: Int): Flow<User> { 
    // Fetches user data from UserAPI and store it 
    // in the local DB if necessary.
    ... 
  }
}

class UserViewModel(
  private val userId: Int,
  private val userRepository: UserRepository
) : ViewModel() {

  private val _user: MutableLiveData<User> = MutableLiveData()
  val user: LiveData<User> = _user
  
  init {
    viewModelScope.launch {
      // Observe changes from UserRepository.
      userRepository.getUser(userId).collect { user ->
        _user.value = user
      }
    }
  }
}

class UserFragment : Fragment() {
  
  // Assume that UserViewModel is injected through Dagger.
  @Inject
  lateinit var viewModel: UserViewModel
  
  override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    ...

    // Observe state changes from LiveData.
    viewModel.user.observe { ... }
 
    someButton.setOnClickListener {
      // Use Navigation Component to handle navigation events.
      findNavController().navigate(R.id.to_other_destination)
    }
  }
}

When testing UserRepository, we can replace the implementation of UserApi like so:

@RunWith(AndroidJUnit4::class)
class UserRepositoryTest {
  @JvmField
  @Rule
  val repositoryTestRule = RepositoryTestRule()
  
  @MockK
  lateinit var userApi: UserApi
  
  @Before
  fun setUp() {
    MockKAnnotations.init(this)
  }  
  
  @Test
  fun givenUserApiReturnsUser_ThenEmitUser() = runBlockingTest {
    
    // Set up mocked UserApi to return a fake user.
    coEvery { userApi.getUser(any()) } answers { 
      User(
        id = firstArg(),
        firstName = "John",
        lastName = "Smith"
      )
    }    
    
    // Replace the dependencies of UserRepository with mocks.
    val userRepository = UserRepositoryImpl(
      userApi, 
      repositoryTestRule.db
    )
    
    // Assert that repository emits the fake user.
    val user = userRepository.getUser().single()
    assertEquals("John", user.firstName)
    assertEquals("Smith", user.lastName)
  }
  ...
}

When testing UserViewModel, we only need to replace the UserRepository implementation:

@RunWith(AndroidJUnit4::class)
class UserViewModelTest {
  @JvmField
  @Rule
  val viewModelTestRule = ViewModelTestRule()
 
  @MockK
  lateinit var userRepository: UserRepository

  @Before
  fun setUp() {
    MockKAnnotations.init(this)
  }
  
  @Test
  fun givenUserRepostiroyEmitsUser_ThenUserLiveDataIsUpdated() {
    
    // Set user repository to emit a fake user.
    coEvery { userRepository.getUser(any()) } answers { 
      flowOf(
        User(
          id = firstArg(),
          firstName = "John",
          lastName = "Smith"
        )
      )
    }
    
    // Replace the dependencies of UserViewModel with mocks.
    val viewModel = UserViewModel(1, userRepository)
    
    // Assert that user LiveData emits the fake user.
    val user = viewModel.user.getOrAwaitValue()
    assertEquals("John", user.firstName)
    assertEquals("Smith", user.lastName)
  }
}

You can find getOrAwaitValue extension here.

As I mentioned before, we usually test our Fragment and ViewModel together, hence here’s how we test UserFragment:

@RunWith(AndroidJUnit4::class)
class UserFragmentTest {
  @JvmField
  @Rule
  val fragmentTestRule = FragmentTestRule()
 
  @MockK
  lateinit var navController: NavController
 
  @MockK
  lateinit var userRepository: UserRepository  
  
  @Before
  fun setUp() {
    MockKAnnotations.init(this)
  }
  
  // Launch the fragment using FragmentScenario.
  private fun launchFragment(): FragmentScenario<UserFragment> {
    return launchFragmentInContainer {
      
      // Create the Fragment manually and replace any
      // dependencies as needed. 
      UserFragment().also { userFragment ->
        userFragment.viewModel = UserViewModel(1, userRepository)

        fragmentTestRule.dataBindingIdlingResourceRule
          .setFragment(userFragment)
      }
    
    }.onFragment { userFragment ->
      
      // Replace the NavController with a mocked NavController
      // to test UserFragment in isolation.
      Navigation.setViewNavController(
        it.requireView(), 
        navController
      )
    
    }
  } 
  
  @Test
  fun givenUser_ThenDisplayUserDetails() {
    
    // Set fake user similar to ViewModel.
    coEvery { userRepository.getUser(any()) } answers { 
      flowOf(
        User(
          id = firstArg(),
          firstName = "John",
          lastName = "Smith"
        )
      )
    }
    
    launchFragment()
        
    // Assert views with Kakao.
    onScreen<UserScreen> {
      firstNameTextView.hasText("John")
      lastNameTextView.hasText("Smith")
    }  
  }
  
  @Test
  fun whenClickSomeButton_ThenNavigateToOtherDetailsFragment() {
    launchFragment() 
    
    // Trigger UI interactions with Kakao.
    onScreen<UserScreen>{ 
      someButton.click()
    }
    
    // Verify navigation events using the mocked NavController.
    verify { navController.navigate(R.id.to_other_destination) }
  }
}

You can also use TestNavHostController as a replacement for your NavController.

This kind of setup also allows us to easily combine components during integration tests. For example, we can use Dagger to replace only the UserApi with a mock API client during testing, and keep the rest of the dependency with the real implementation.

Pull Requests and Coverage

We run our test suite for each pull request on our CI server and this allows us to measure the code coverage of each branch. However, we don’t use the coverage percentage to guide us on how many test cases we have to write. We believe that we need to focus on the most critical path of the codebase, rather than the number of test cases.

Given that we are dealing with legacy code, we need to introduce the test suite gradually. It’s impossible to refactor the whole application at once because, with that approach, we will not be able to develop any feature in parallel. Without parallel development, we will not be able to deliver any updates or fixes to our users. Thus, we decided to write test cases for components that we’re are currently working or refactoring on, and track our overall progress using code coverage.

Code coverage report allows us to easily find out which components have been or have not been tested. In addition, we also introduce a minimum coverage threshold and increase that threshold gradually to ensure that we don’t add more code that has not been tested into the codebase.

Issues that we Encountered

The whole journey towards a testable app was not all smooth. Here are several issues that we encounter during the refactoring and how we dealt with these issues.

• Mismatches between actual implementation and the testing document. When we first created our test document, there were a lot of unknowns. What we ended up implementing is quite different from what we initially wanted. Hence, we needed to iterate on the testing document. We needed to adapt to technical changes and adjust our approach accordingly. For example, we wanted to make use of gherkin syntax with Spek to help us structure our test suite. However, Spek does not currently support instrumented tests for Android. Given that we want to maintain consistencies between our local unit test and instrumented test (as we were hoping for Project Nitrogen), we decided not to use Spek.
• Writing and maintaining an automated test suite requires a lot of time investment. Implementing proper test cases will inevitably require a lot more time. We as engineers need to communicate that to the stakeholders and manage their expectations. However, I believe that in the long run, writing automated tests is a good investment to make since most of the manual tests are quite repetitive and can be automated. Investing in an automated test suite also allowed us to make changes to our code faster.
• Execution time gets longer as the test suite grows. The number and type of tests in the test suite will heavily impact the execution time of the testing pipeline. If there’s a large number of UI tests, the execution time can be very long and it can slow down the development. For us, we have about 1000 unit tests and 300 UI/ integration tests. Running our test suite on our CI server takes about 5 minutes for unit tests and 15 minutes for UI tests. Executing UI tests takes a lot of time even after we introduced Flank to shard our tests. If you have a bigger test suite, you might want to take a look at Dropbox’s approach to selectively run the test suite for code that changed or that could have been affected by the change.
• Generating code coverage with Jacoco can be difficult. Even though support for Jacoco comes out of the box with Android Gradle Plugin. Setting it up can be quite difficult, especially when upgrading AGP’s version. In our experience, Jacoco will often throw compilation errors or show incorrect coverage reports when AGP is updated. As you can see in our branch coverage graph, we encountered a big dip in the coverage due to this issue when we updated AGP to 4.2. There are also other issues that you have to pay attention to, such as this, this, and this.

Wrap up

While it took a lot of time to see the benefit and result of our effort to implement a testable app, I believe that the testing setup for our Android app has improved significantly in the last 2 years. Of course, we can’t just stop here because there’s still a lot of room for improvement. Creating a testable app needs consistent efforts from everybody, and it’s very important to get buy-in from your team members and stakeholders before starting your journey in implementing a testable architecture. Writing automated tests should be an integral part of your development process and it should not slow down the pace of the development.

An automated test suite can help you quickly identify regression during development. However, I don’t think you can 100% rely on an automated test suite because there are problems that a manual QA process can find more easily, such as animation issues, UI or layout issues, incorrect use of test doubles, or unhandled edge cases, etc. So, it’s still important to have a manual test in your development cycle.

Thank you for reading this article. I hope it can give you some ideas on how to implement a testable architecture in your Android app.

Our Journey Towards a Testable Android App was originally published in Wantedly Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

With Kotlin Multiplatform for Mobile (KMM), you can share code between Android and iOS projects. When setting up a new KMM project, if you follow the KMM sample setup, you’ll have iOS, Android, and KMM shared code located in a single repository. However, when integrating KMM into existing apps, most likely your Android and iOS apps are located in separate repositories, with their own dedicated tooling and CI/CD pipeline.

Sharing KMM code with existing Android projects is pretty simple as you can easily upload your KMM into a Maven repository, but when it comes to iOS, it’s not that straightforward. In this article, I will show you different methods to distribute your KMM code so that it can be consumed in your iOS project.

This article is written based on Kotlin 1.4.20 and is not an exhaustive list of distribution methods for a KMM module. The Gradle build scripts in this article are all written in Kotlin.

CocoaPods Gradle plugin and git submodule

native.cocoapods is an official Gradle plugin from JetBrains that adds CocoaPods integration into a KMM project. To make use of this plugin, simply apply the native.cocoapods Gradle plugin in the build.gradle file of your KMM project and set up the necessary CocoaPods parameters. This plugin will add the necessary Gradle tasks to generate a podspec file for your KMM project. If you notice, the generated podspec file has a script_phase attribute that will automatically execute a Gradle task to compile the KMM module into a native framework when you run/build from XCode.

In this approach, you need to ensure that the generated .podspec file is pushed into the remote git repository, and then in your iOS repository, create a git submodule that points to the latest branch/release of your KMM project. Then, simply add the dependency to the podspec file in your iOS project’s Podfile.

target 'MyIosApp' do
 // other dependencies. 
 pod 'MyKmmModule', :path => '/path/to/kmm/submodule'
end

There’s one more step to add before you can run pod install. Since the KMM module dependency is introduced as a vendored framework, CocoaPods needs to have access to the framework file during the pod install process to be able to configure the framework correctly. However, since the real framework file is only going to be generated when we run build in XCode, we need to run the following Gradle task before running the pod install command.

/path/to/kmm/submodule/gradlew generateDummyFramework

Now, you should be able to run pod install in your iOS project and then use the KMM shared code in XCode.

The current Gradle plugin only supports Debug and Release configuration for iOS projects. If you’re using custom configurations, you can add a custom Gradle task to add additional xcconfig settings and override the default configuration.

val podspec by tasks.existing(PodspecTask::class) {
  doLast {
    val outputFile = outputs.files.singleFile
    val text = outputFile.readText()
    val newText = text
      // Workaround: https://youtrack.jetbrains.com/issue/KT-42023
      .replace("spec.pod_target_xcconfig = {",
        """
          spec.pod_target_xcconfig = {
            'KOTLIN_CONFIGURATION' => 'Release',
            'KOTLIN_CONFIGURATION[config=Debug]' => 'Debug',
        """.trimIndent()
      )
      .replace("\$CONFIGURATION", "\$KOTLIN_CONFIGURATION")
    outputFile.writeText(newText)
  }
}

Pros

• native.cocoapods is officially developed by JetBrains, and you can expect improvements in the future.
• There’s little to no additional maintenance or work necessary to set up and share KMM code with iOS.

Cons

• Your XCode build might be slow since it needs to download the Gradle dependencies and execute Gradle build, especially for a clean build.
• Managing versioning with git submodule is not easy.

Generate and distribute universal (fat) frameworks

With the above CocoaPods and git submodule approach, XCode will execute a Gradle task to build the KMM module’s framework file whenever you run build in XCode. This task can be cached by Gradle, so if there are no changes in your KMM code, it should be pretty fast. But in a CI environment, you might have issues with slow build time.

Fortunately, as your KMM project is located in a separate repository, the KMM code itself should not change very often, hence, you can actually create a final native binary to be consumed in the iOS project. Moreover, since this can be delegated to the release pipeline of the KMM module’s CI/CD system, this would have a minimal impact on your XCode build.

You can create custom Gradle tasks in your Gradle build script to generate the universal (fat) frameworks for your KMM module:

kotlin {
  val iosX64 = iosX64("iosX64") {
    binaries {
      framework {
        baseName = "MyKmmModule"
        embedBitcode("disable")
      }
    }
  }
  val iosArm64 = iosArm64("iosArm64") {
    binaries {
      framework { 
        baseName = "MyKmmModule"
        embedBitcode("bitcode")
      }
    }
  }

  // Create a debug framework for both X64 and Arm64 architecture.
  task.register<FatFrameworkTask>("debugFatFramework") {
    baseName = "MyKmmModule"
    destinationDir = file("$buildDir/fat-framework/debug")
    from(
      iosX64.binaries.getFramework("DEBUG"),
      iosArm64.binaries.getFramework("DEBUG")
    )
  }

  // Create a release framework for Arm64 architecture.
  task.register<FatFrameworkTask>("releaseFatFramework") {
    baseName = "MyKmmModule"
    destinationDir = file("$buildDir/fat-framework/release") 
    from(
      iosArm64.binaries.getFramework("RELEASE")
    )
  }
}

Once you have the framework files built, it’s up to you and your iOS team to decide on how to share and consume these framework files.

Pros

• Building framework files can be delegated on the KMM module’s release pipeline in your CI/CD infrastructure, hence, there will be minimal impact on build time on your XCode build.
• No dependency on Gradle and Maven for your iOS project.

Cons

• You need to maintain the Gradle scripts for building these framework files.
• Depending on how you decide to distribute the framework files, you might need additional work around the distribution pipeline and authentication around it.

Using transitive dependencies with Gradle

The other approach that you can use to consume KMM code from your iOS project is to create a separate Kotlin multiplatform project inside the iOS repository, add the dependencies to the KMM module using Gradle dependencies, and then expose that dependency using transitive dependencies. With this setup, managing the dependencies and version update should be much easier than using a git submodule approach. On top of it, we can also use native.cocoapods Gradle plugin to expose the KMM module to iOS.

To make sure that the headers for KMM modules are correctly exported, you need to enable transitiveDependency flag in the Gradle build script. Additionally, you can also include multiple KMM modules dependencies, effectively creating an umbrella framework for multiple KMM modules.

plugins {
  kotlin("multiplatform") version "1.4.20"
  kotlin("native.cocoapods") version "1.4.20"
}

kotlin {
  ios {
    // native.cocoapods Gradle plugin will declare 
    // the binary framework creation.
    // Since, duplicate binary name is not supported, 
    // we need to configure the binary settings declared by 
    // native.cocoapods plugin to mark the dependency as an
    // exported dependency.
    binaries
      .filterIsInstance<Framework>()
      .forEach {
        it.transitiveExport = true
        it.export("com.my.kmm:module:1.0.0")
    }
  }
  sourceSets {
    getByName("iosMain") {
      dependencies {
        api("com.my.kmm:module:1.0.0")
      }
    }
  }
  cocoapods {
    // Set up cocoapods parameters.
  }
}

Similar to the git submodule approach, you need to run gradlew podspec task from the Kotlin multiplatform project to generate the latest podspec file. Then, add the dependency to the generatedpodspec file in your iOS project’s Podfile and run gradlew generateDummyFramework and pod install and you should now be able to invoke KMM functions inside your iOS project.

Pros

• Allows you to import multiple KMM modules.
• Dependencies are declared in a Gradle build file which is easier to manage.

Cons

• You need to maintain a separate KMM project inside the iOS project.
• Build time is similar to CocoaPods with git submodule approach because you still need to download and execute Gradle build for KMM modules.
• Needs to ensure gradlew podspec is executed when a dependency is updated.

Swift Packages

Swift Package is a new format introduced by Apple to share reusable components between projects. There is a great article written by John O’ Reilly on how to use Swift Package Manager to consume KMM module in an iOS project. If you’re interested, you can find the article here: https://johnoreilly.dev/posts/kotlinmultiplatform-swift-package/

Summary

The approaches that I’ve shared above are by no means exhaustive. There are other methods that you can use to consume a KMM module from your iOS project. Also, the pros and cons of each approach that I’ve written might not apply to your project and team. It’s up to you to decide what works best for your configuration. However, I hope this can give you some ideas on some of the possibilities.

For us at Wantedly, we decided to use native.cocoapods Gradle plugin with Git submodule approach. Mainly because it’s one of the official Gradle plugins developed by JetBrains and we feel like the additional build time is a good trade-off for additional work necessary to create a custom solution to consume KMM module from our iOS project. Also, if you look at the result of the Kotlin Multiplatform survey published recently by JetBrains, there seem to be some improvements that we can expect in this area.

Thank you so much for reading this article, I hope you found it useful!

Different Approaches in Consuming KMM Modules in iOS was originally published in Wantedly Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kotlin 1.4 Online Event, as the name suggests, is a 4-day online event (from 12 Oct to 15 Oct 2020) that focuses on talking about new features that are introduced in the Kotlin 1.4. This event was live-streamed on YouTube, so it’s free for everyone, and they also have recorded sessions and slides available on the event’s page. Most of the speakers are people from JetBrains who are directly involved with the development of the Kotlin language and libraries.

Viewers were able to interact with the live-stream in multiple ways. They can ask questions about the talk using YouTube chat, Q&A forms, and a Twitter hashtag of #kotlin14ask, and these questions will then be answered during the live stream. Then, there’s also QuizQuest, a series of mini-tests to check what we’ve learned from the talks. There are different prizes to be won and some of the prize categories are active until 26 Oct 2020. There’s also a virtual booth where you can have a discussion with people from the JetBrains team, though this has limited availability.

This year, we were able to participate in the Kotlin 1.4 Online Event and in this article we want to talk about our summary of the event. There were a lot of good sessions, and summarizing them will be difficult. There will be a lot of important points that are not covered, so we encourage you to watch the recorded sessions if you’re interested. We will also include the YouTube link for each talk.

Talks from Day 1 - General Overview

Opening Keynote

The Kotlin Team

The first event of the day is the opening keynote from Andrey Breslav, the project lead of Kotlin language, and the Kotlin team. They talked about the journey of Kotlin, the announcement of the new release cadence, the current state of Kotlin and the recent 1.4 updates to the language on performance and quality improvements. He also talked about the current focus of the Kotlin team, the new Kotlin compilers, their effort on server-side kotlin, and their vision of Kotlin Multiplatform.

Staying in Touch

Egor Tolstoy

The next session talked about how we can contribute to the Kotlin language. The community can contribute by submitting Pull Requests on GitHub, reporting issues through YouTrack, sharing feedbacks of EAP, participating in user reviews through kotl.in/interview, answering questions in StackOverflow, and many others (see: kotl.in/contribute). Egor also mentioned that we can enable sharing of anonymous usage statistics to help JetBrains analyze and prioritize features, which currently is only enabled by 8% of all developers who’re using IntelliJ. He also outlined how important community feedback is when prioritizing features in Kotlin language.

New Language Features in Kotlin 1.4

Svetlana Isakova

This session talked about the new language features that were introduced to 1.4 updates, the content of this talk is very similar to language features and improvements section of What’s New in 1.4 updates. In this session, Svetlana also mentioned the new type inference algorithm that is available due to the new compiler included in 1.4, unified exception type for null checks, and also new modes for generating default methods in interfaces when targeting Kotlin/JVM.

Quality and Performance — Kotlin 1.4 in IntelliJ IDEs

Anton Yalyshev

In this session, Anton Yalyshev talked about the performance and quality improvement of Kotlin 1.4 plugin. Majority of developers downtime is due to UI lags (31%) and indexing (28%) and Kotlin 1.4 plugin fixed a lot of UI freezes, deadlocks, and improved the CPU/Memory consumption to make development smoother. Kotlin 1.4 plugin also reduced plugin exceptions by 1.5–2x, improved the stability of the debugger, formatter, and refactoring, and also introduced a new debugger for coroutines. He further touched on the future improvements to the plugin. Lastly, he announced that Kotlin IntelliJ plugin repository will be moved into the IntelliJ platform repository for a faster development cycle.

A Look Into the Future

Roman Elizarov

In our opinion, this is the most interesting session of the day. Roman’s talk about the future of Kotlin is divided into 2 broad sections, near future and distant future. Near future section addressed KMM and JetBrains commitment to support newer Java APIs like Java Records and Sealed classes. While distant future section showed previews of how Kotlin language might evolve in the future with new operators and language features like namespace extension, multiple receivers and decorators for functions, private/public property type, immutability, and inline classes. He also discussed how JetBrains evaluated Kotlin language APIs design and features.

Talks from Day 2 - Libraries

Coroutines Update

Vsevolod Tolstopyatov

Day 2 opened with a talk on updates to coroutines by Vsevolod Tolstopyatov. He touched on the new coroutines debugger and simplified coroutines stack trace in IntelliJ IDEA. Then, he talked about various updates to Kotlin Flow since 1.3, the introduction of StateFlow and SharedFlow, and the background behind these classes, and JetBrains’ philosophy on adding new operators to Flow. The new coroutine updates also benefit Android projects (with 30% reduced DEX size, better start time and memory/CPU consumption) and Java projects (with integration with blocking calls, BlockHound, and JDK 9 java.util.concurrent.Flow). Lastly, he touched on their plan for the future of coroutines, like the stability of certain features, and time-specific operators such as debounce or throttle, and more.

kotlinx.serialization 1.0

Leonid Startsev

The next talk is “kotlinx.serialization 1.0” by Leonid Startsev. In this session, he discussed why JetBrains created kotlinx.serialization and how it differs from other JSON parsing libraries, and then showed how serialization APIs in kotlinx.serialization looks like. Then, he also talked about the stable features in 1.0 like @Serializable annotation and polymorphic serialization, and features that are experimental in 1.0, such as custom serial formats and protobuf serialization. He also mentioned new features that are new to 1.0 release, and what are their plans for kotlinx.serialization library. Finally, he showed how we can integrate kotlinx.serialization into our projects, and how to upgrade from previous versions of kotlinx.serialization.

News From the Kotlin Standard Library

Svetlana Isakova

Svetlana talked about the new functionalities and changes to the Kotlin standard library. In Kotlin 1.4, the Kotlin team tried to make the naming of functions to be more consistent, for example, by adhering to naming conventions, such as running*, *orNull, *Indexed, *IndexedOrNull. 1.4 also introduced a new collection type ArrayDeque (a double-ended queue implemented with a circular buffer) and a couple of new functions for optimised bit manipulation. She also mentioned a couple of changes that make working with the standard library in multiplatform projects easier, such as stack trace and exception handling. Then, she also talked about new experimental functionalities like collection builders and time measurement APIs, and how @OptIn and @RequiresOptIn annotations behave.

Introducing DateTime

Ilya Gorbunov

In this session, Ilya Gorbunov introduced kotlinx.datetime library, an official library from JetBrains to work with date and time in Kotlin. In this library, there are 2 flavours of time, Instant and LocalDate (and LocalDateTime), and depending on your purpose you’ll prefer one over the other. He also talked about how they differ and example use cases, such as preserving timezone data or daylight saving issues. Then, he gave a few examples of how Kotlin APIs have influenced the APIs of the library. Finally, he also touched on its interoperability with each platform’s date-time implementation, their plans with kotlinx.datetime, and the importance of the community feedback in shaping this library.

Talks from Day 3 - Android and Multiplatform

State of Kotlin in Android

Florina Muntenescu

The first session of day 3, from Florina Muntenescu, talked about the impact of Kotlin language on Android apps development. She shared statistics of how android app has improved since adopting Kotlin and also explained what the recent Kotlin 1.4 update brought; like improved tooling performance (incremental annotation processor, IDE performance, instant execution) and features for library authors (explicit API mode, KSP, and R8 support for Kotlin metadata). She highlighted that coroutines are the recommended solution for asynchronous programming and they integrate nicely with JetPack libraries. She also mentioned how Google is committed to develop and push Kotlin forward, from adopting a Kotlin-first approach on Android, working on open source projects (like gRPC and Protobuf), adoption of Kotlin in Google’s apps, improved documentation and learning resources, etc.

It’s Time for Kotlin Multiplatform Mobile

Ekaterina Petrova

Ekaterina Petrova talked about the current frameworks that we can use for cross-platform programming (Rect Native, Xamarin, etc) and explained how KMM is different from those frameworks. Kotlin multiplatform allows developers to share parts of the code between iOS and Android, such as data/business logic. She presented some illustrations of how we can share code through sample architecture and layers, and she also gave sample build files that we can use in a typical KMM project. She also showcased the available toolings around KMM, such as Android Studio plugin, CocoaPods integration, etc. Then, she also showed how KMM works seamlessly in the iOS ecosystem, from interoperability with Objective-C/Swift, integration with Cocoapods, to running and debugging iOS application in Android Studio. Finally, she also shared a few resources to learn more about KMM: kotl.in/kmm, kotl.in/kmm-doc, kotl.in/kmm-cases, and kotl.in/kmm-plugin.

Kotlin/JS in 1.4 and Beyond

Sebastian Aigner

In this session, Sebastien Aigner talked about the state of Kotlin/JS in 1.4. He introduced the new Gradle plugin for Kotlin/JS and multiplatform projects, and the deprecation of previous kotlin2js and kotlin-dce-js plugins. This new plugin includes a fully managed local yarn installation to allow working with npm dependencies, and also adds support for Webpack bundles. Kotlin 1.4 also improved the interoperability with other web technologies, such as TypeScript, decoupling of browser APIs from Kotlin releases, and accessing Node.js APIs through kotlin-nodejs. Then, he presented the future of Kotlin/JS with the new alpha IR compiler for reduced bundle size, support for ES6 modules, better interoperability with @JSExport annotation, and auto-generated TypeScript definitions. Finally, he briefly gave an update on the state of Kotlin and WebAssembly.

Diving into Kotlin Multiplatform

Dmitry Savvinov

One of the most technical talks of the event, “Diving into Kotlin Multiplatform” by Dimitry Savvinov talked about the internal workings of multiplatform library publishing in 1.3 and how Kotlin 1.4 uses intermediate source sets to allow the new multiplatform library publishing format and hierarchical project structure. He also described the .klib format and .kotlin_metadata files, how Gradle metadata helps with Kotlin project’s dependency management, and how Kotlin toolchain automatically infers common code in native dependencies. Most of the contents in this talk are internal APIs, so it can change without prior notice and we are not supposed to rely on its implementation. If we do want to rely on these internal APIs implementations, we should let JetBrains know of our use case.

Talks from Day 4 - Kotlin for Server-Side

Server-side Development with Kotlin

Anton Arhipov

Day 4 talks are a bit different as most of the talks were actually live instead of recorded. The first talk is an update on server-side development with Kotlin, where Anton Arhipov listed out most popular frameworks that we can use to build server-side apps with Kotlin. Included in this list are the very popular Spring framework, a framework by JetBrains called Ktor, and many other polyglot frameworks (a full list of frameworks is available at https://kotlin.link/). He also shared multiple companies that are currently using Kotlin for their back-end and how it impacted their development, like JetBrains Space, Atlassian Jira, Expedia Group, Adobe, and many more. Then he also touched on how Kotlin is enabling cloud-native application using serverless technologies like Kotless.

The State of Kotlin Support in Spring

Sébastien Deleuze

In the next session, Sébastien Deleuze talked about the recent updates in Spring framework that allows better compatibility with Kotlin language. He mentioned that Spring initialzr now supports setting up a new project with Kotlin, and the sample code in Spring framework documentation is now also available in Kotlin. He also explained the differences between Spring frameworks and programming model (annotations vs Kotlin DSL) that are available in Spring, first-class support for coroutines, Kotlin multiplatform support, RSocket supports, and null safety. He later continued with a discussion of GraalVM and did a quick demo of Spring 2.4 running on GraalVM. He also briefly touched on future topics like functional Spring with KoFu and JaFu.

Ktor - Past, Present, and Future

Hadi Hariri

In this talk, Hadi Hariri talked about Ktor, a multiplatform framework by JetBrains for creating web applications. He explained how Ktor came about and what are the inspirations for Ktor. Currently, JetBrains is investing quite a lot in Ktor, with more developers, better site, blog, and documentation. JetBrains is also committing to 3 major/minor releases yearly and monthly patch releases, and proper deprecation cycle. He then also gave an example of how the structure of a Ktor application on the server-side looks like and then continued with a live demo of using different features inside Ktor. Lastly, he gave a glimpse of how Ktor will evolve in the future, such as improved onboarding and developer experience, better feature parity between client and server components, and increased performance.

Serverless Development with Kotlin and Kotless

Vladislav Tankov

In the last talk of the event, Vladislav Tankov talked about Kotless, a serverless framework for Kotlin. He started by discussing the pros and cons of a serverless framework, and how Kotless deal with these drawbacks. He later described features that are included in Kotless, different supported frameworks (Ktor, Spring, and Kotless’ DSL), cloud platforms (AWS, with support for GCP and Azure in the works), runtimes (Kotlin/JVM and GraalVM, with Kotlin/JS in development), and also a feature to help local development using local cloud emulation. He later explained how kotless works in general and how it integrates with different cloud technologies, like AWS DynamoDB, and then continued with a short demo of Kotless in action, and finally discussed what are their plans with Kotless. However, he mentioned in the Q&A session that Kotless is currently not ready for production use.

Summary

This year is the first time that this event is held fully online due to the ongoing global pandemic and we would like to commend JetBrains for the successful event. We also think that the interactions on YouTube live and chat, and the way questions are selected during the Q&A sessions brought up a lot of interesting and insightful discussions.

Since we are using Kotlin only for Android and Multiplatform Mobile, not for JS and backend, our summary on JS and server-side events might be slightly off. However, we can say that we enjoyed all the talks and our personal favourites are “Looking into the Future”, “Coroutines Updates”, and “It’s time for Kotlin Multiplatform Mobile”.

Through this event, we learnt that the community plays a big part in shaping the language, and Kotlin’s conciseness and expressiveness made a lot of developers try (and stay with) the language. We hope that there will be more events like this in the future and maybe we can attend those events in person.

Kotlin 1.4 Online Event Recap was originally published in Wantedly Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article was originally written in Japanese by my colleague 久保出雅俊 . You can find the original article at https://www.wantedly.com/companies/wantedly/post_articles/282562

In this article, we are going to talk about the reasoning behind our decision to adopt, and move away from React Native, and why we decided to adopt Kotlin Multiplatform in our mobile apps.

Why we adopted React Native in the first place

In 2018, we decided to do a full rewrite of our iOS application. This required a huge amount of effort and time that involves almost everybody in the mobile app team.

In parallel with the iOS app rewrite, we also wanted to introduce a new feature called “Discover”, where users can find various interesting contents inside our platform. However, since most of the mobile engineers were focusing on rewriting the application, we decided to introduce React Native to allow web engineers to work on this feature separately. “Discover” feature was initially introduced in the old version of our iOS app and our data showed that it performed admirably, hence we decided to bring it into the new iOS app as well.

Subsequently, we introduced “Discover” to our Android app, and our apps’ architecture roughly looked like this:

Our issues with React Native

This list of issues were issues that are specific to us and do not represent issues with React Native as a whole.

Lack of active maintainers

Once the “Discover” feature was stable, the web engineers that were originally involved with the React Native development went back to work on the web platform, and nobody was actively maintaining the React Native repository.

Updating Xcode or other build tools became an issue because most of the time we need to update React Native toolings first. These updates sometimes were not straightforward and ended up costing us a lot more effort than necessary. This process of updating the build tools quickly became a major pain point for mobile engineers.

Differences in technology

Even when the mobile engineers decided to maintain the React Native repository themselves, they lack the skill and knowledge of the inner workings of React Native, and learning these skills is not cheap.

Also with the subsequent introduction of React Native component into our Android app, it’s hard to work with React Native without the knowledge of both iOS and Android platform, as each OS works differently.

Discrepancies in the UI/UX

There were some elements that only work on the iOS platform, and when we decided to integrate “Discover” feature into our Android app, we had to add a condition to hide or remove said elements. This created a discrepancy of feature between both apps.

There were also some minor differences between native UI elements and React Native UI elements. Hence, UI elements that exist in both native and React Native might look similar but have some disparity (e.g., touch feedback on touchable elements in Android app).

Productivity issues

With the increase of build tools around the app, build time became excessively slow and complicated.

Removing React Native

For quite some time, these issues remained unsolved. But recently, we got an opportunity to work on the React Native component itself, thus we decided to also evaluate the current implementation and plan the future of our app. While it is true that React Native has really nice features such as hot reload and easy to implement UI framework, we think that our current issues outweigh its benefits and potential, hence, we decided to quit React Native altogether.

Kotlin Multiplatform

With regards to the engineers’ productivity of the mobile platform as a whole, duplicate implementations (like network API calls) that are required on both iOS and Android are very costly, and sometimes, can have subtle differences. We wanted to tackle these issues and we thought cross-platform technology might be a good fit, so we decided to evaluate Kotlin Multiplatform and introduce it into our app.

Kotlin Multiplatform (Kotlin MPP), is a Kotlin language feature that allows you to share code that is written in Kotlin between multiple platforms.

• Code that is written using Common Kotlin will be recompiled to native code on each target platform.
• Allows you to write native code of each platform in Kotlin.
• Access platform-specific APIs using the expected/actual declarations.

Kotlin Multiplatform Mobile (KMM) is an official site that showcases usages of MPP for mobile applications, and in it, there’s an example on how we can make use of MPP to share business logic between different platforms but still makes use of the native UI elements. We decided to follow this example and implement our MPP architecture as such.

MPP architecture

In our iOS App, we make use of ReactorKit, a flux-like Swift application framework. As for Android, we also make use of a similar flux-like framework that we built internally with Android’s ViewModel. Naturally, in the case of our MPP implementation, we wanted to adopt a similar model with ReactorKit and flux-like architecture in an effort to reduce the cost of learning and implementing a new architecture.

To achieve that we make use of the following libraries:

• Kotlinx Coroutines.
• Ktor Client.
• Kotlinx Serialization.
• SQLDelight for application’s single source of truth.

… and a few other libraries. It has a remarkably similar architecture to KaMPKit implementation that is showcased inside KMM.

Mobile app architecture

At the time of this writing, we just finished removing React Native component from our Android app and this is the current architecture of both of the apps.

With the implementation of MPP and native UI element, we saw a tremendous PV improvement of 46% on one of our screen that was originally implemented with a WebView. Furthermore, it has a 50% smaller app download size.

iOS adoption of MPP is currently underway, and in the future, we hope to broaden the application of MPP to improve the overall productivity of all mobile engineers in the company.

Pros and cons of MPP

Here are the pros and cons that we encountered when working with the current iteration of MPP.

Pros

• From the point of view of an Android app, MPP module is just like another Kotlin module, and introducing an MPP module to an existing Android project was very smooth. We didn’t notice any difference when moving the business logic from Android to MPP.
• When the interface of an MPP component has been decided, implementing UI in Android and business logic in MPP can be done in parallel by 2 different engineers.
• Since there is no “UI” element in MPP, you are forced to write unit tests to validate your code. This naturally yields a high code coverage.

Cons

• MPP is still an experimental feature. It works, but you still have to take account of that fact.
• Different memory management model in iOS (Kotlin/Native). In Kotlin/Native code, there’s a concept of immutability that does not apply to Kotlin/JVM code. When working with coroutines, you’ll often encounter InvalidMutabilityException if you’re not careful. There are plans to change this model, but in the meantime, you have to be careful of which thread your code is invoked in.
• From the point of view of an iOS app, MPP doesn’t look very different from React Native implementation. However, UI components, which usually requires a deep knowledge of each platform to implement, will not be shared and you won’t expect differences as drastic as React Native. There’s also an official guide on how to prepare your team for MPP, as long as you follow this guide, you should be able to create a component that is easy to maintain for all engineers.

Summary

We have talked about why we adopted and quit React Native implementation in our mobile app, and also why we decided to adopt Kotlin Multiplatform. There is still some work to be done to remove React Native completely from our apps, but we hope that with our experience and learnings with React Native, we can continue to examine different new cross-platform technologies, such as MPP.

Moving from React Native to Kotlin Multiplatform was originally published in Wantedly Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of my recent projects was to try to identify unused pieces of code and remove them safely. This can be quite a difficult task in Ruby, as there is little way to be certain what calls what.

A solution to this problem of identifying such code is to record all calls for a relatively long period on your production server, and then see what hasn’t been called. For this purpose, we developed a custom solution on top of the oneshot_coverage gem; but after taking a step back, I think I would recommend the coverband gem for this purpose (it has a polished UI, is maintained, based on standard tools such as Redis, etc.).

Assuming you now have a list of suspiciously unused methods, you can either be satisfied with that (you should probably not), delete them at once, and move on; or try to dig a bit more. This is the topic I would like to cover in this post, and by reading it, I hope you will learn more about this process and the tools I used to follow said process.

If you have numerous tests and excellent test coverage, this whole process might seem excessive to you, as you would simply say that if the tests continue passing after deleting the code, then everything is good. You would be right, but things are not always as simple!

I will try to use a real example from our application to illustrate my point. Here, I found a method called related_posts in our PostArticle model that seemed to be unused for a while on our production platform.

Current references

The very first action you should do, before deleting the method blindly, is checking if the method name appears anywhere else in your code or potential dependents of your code. For a simple project, you can just search the method’s name in your favourite IDE, you can also use ripgrep in a folder containing your project and its dependents. This first check is fundamental because your method could simply be called by some other code but is not for some understandable reasons (very rarely used feature, randomness, code specific to some platform, code not actively used yet, problem in the coverage tool, etc.).

One thing you want to be aware of at this point is because there could be some meta-programming calling your method, you might want to check for some sub-string of your method name. Usually in these cases, your method would have some kind of resemblance pattern with other methods declared close by, so you would want to search for the discriminatory part of the method name. For example, if you have two methods process_carrots and process_potatoes , you might have somewhere a code calling .send("process_#{food_item}") inside some sort of iteration over the food items. In that case, you would like to know whether a particular food item is still called or not, and thus you would search for that name (i.e: carrots or potatoes respectively).

In my case, there are many matches, so I need to check manually for each of them if they are related, and while most of them are not, I noticed another model (that inherit from the same base model) that has a method with the same name. I checked with our coverage tool, and as suspected it is also apparently unused.

Note that in this case, checking for dependent projects is not necessary as our models are not used outside of our project. For the sake of completeness, here is the command assuming you are in a folder containing all your relevant projects.

rg "related_posts"

The method’s origin

The second thing you should ask yourself is when was the method implemented, and were there any hints towards how it was used then. It will give you other hints of code you might want to delete (that is linked to the feature, but that the production-code-coverage tools cannot detect because it is outside of its scope, for example: views, styles, JS, scripts, configurations, etc.). It might also give you more information on how the code is called and ultimately make yourself confident that you are deleting something that is indeed unused.

To do this, I like using the GitLense extension for VSCode, which gives me a link to the commit on GitHub, but you can also do a normal git blame on your file. If the methods you are looking at have been modified since they have been introduced you might need to chain git blames for finding their original commit (You could also use git log at this point).

git blame app/models/post_article.rb -L 54,54

If I have a "commit hash" from running command-line git commande, I usually just copy it, insert it in a GitHub URL to show commits, and from there retrieve the PR, but there might be better approaches depending on the tools you use.

In this case, the method was not originally introduced by this commit but was transferred from the parent model to the child models with a slightly different implementation. At this point there are two things I need to do:

• Check the original branch where the code was introduced, and see how it was called.
• Check the branch where the method was split between models and see if the calling code was also changed.

In this case, the code was only originally used in one place, and this calling code was changed in the “split branch” at the same time as the related_posts method itself.*

One additional thing that should be checked is whether there could be some additional resources (JS, CSS, etc.) to delete: resources that were introduced at the same time than these prior modifications that might also not be used anymore. In the present case, there were none I could think of while reading the original code.

Tracking the calling code

Now that we know how the code was introduced, I would like to know more about how the calling code was changed for the related_posts method which seems not to be called anymore. Was it changed to meta-programming at some point? Was the code just removed and the underlying method forgotten? Is this code still called, but somehow I missed it with my checks so far?

By checking the “splitting branch” code changes, I know that the method I want to delete was called in a file called _post_footer.haml.html . But unfortunately, this file does not exist any more. To know when the code was removed from that file I use the following command (note that this also works if the files still exists)

git log -S "related_posts" -- app/views/post_articles/_post_footer.html.haml

I have seen this command fail a few times for deleted files. In that case, I fallback to a broader command that will give all commits to the file from the most recent commit. Usually, it is then quite fast to find the commit that removed the call to the code you want to delete.

git log -p -- app/views/post_articles/_post_footer.html.haml

By looking at the branch where the commit 995ed4d7 happened (same process as when we got the commit hash before), I can see that the related feature was in fact refactored: the implementation was changed and the original method was simply not deleted.

In this particular case, I found out that another call to the original method was deleted at the same time in that last “refactoring branch”, so I get a bit suspicious (but not too much!), check quickly when it was introduced again and ensure there were no other calls that were left unchecked. And finally, I am quite confident deleting this code is now safe*.

To sum up, in this archaeological journey we understood:

• That the code appears not to be used.
• For what reasons it was introduced and modified at some point.
• When it was not called any more and by what it was replaced.

So we can create a “delete commit” for this code, create a PR where we sum-up our findings, and have/display the confidence* that it is a safe/legitimate change.

*NB: This is by no mean a way to be absolutely certain that your code is not called somewhere by some weird meta-programming. It is always possible that such a meta-programming code to be introduced in between the creation/use of the method and it’s apparent “un-call”; I do not believe there is a way to be absolutely sure about this. Even if you would git log the whole repository with a discriminatory part of the method name, it could still be possible not to find something that you are about to break. In the end, this is a compromise: with the help of automated testing, reviews, production code coverage, etc, to be fairly confident the deletion is safe.

I hope you have learned a bit more about ruby and git tools you can use to try deleting your old code in a confident manner. Some might argue that this is too complex and time-consuming to just delete some old unused code, and they might be right, but establishing this process can save your company some time: during the review process for example, if you show that you did investigate the matter thoughtfully and thus the reviewer can check it easily without spending too much of their own time. Also, being able to detect additional potential code/resources that can be deleted can save you time in the long run.

As for me, during the course of my code-deletion project, I have successfully deleted thousands of lines of ruby (and other thousands of JS, CSS, translations, configuration) by following this method without breaking anything (so far!), so I wanted to share this method as I haven’t seen much literature on the subject. 🤗

Deleting unused code with Ruby-on-Rails and Git was originally published in Wantedly Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

You know Ruby 2.7.0-rc1 has been released? It’s awesome!

However, there’s an annoying thing I face every time a new version of Ruby is released: I had to wait for several days to get an up-to-date distro version of ruby-build. Especially, homebrew users will probably agree with me.

I’ve recently found a clever solution to this: manually downloading a manifest.

In ruby-build, we simply have one manifest per one version, and we can list them on GitHub. Download the version you want from there:

wget 'https://raw.githubusercontent.com/rbenv/ruby-build/master/share/ruby-build/2.7.0-rc1'

# Alternatively, with curl
curl -O 'https://raw.githubusercontent.com/rbenv/ruby-build/master/share/ruby-build/2.7.0-rc1'

You can pass a filename to rbenv install, which just looks like a normal way of specifying a version:

rbenv install 2.7.0-rc1  # points to a file called ./2.7.0-rc1 

Getting up-to-date Ruby versions with distro’s rbenv was originally published in Wantedly Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lately, more and more teams are adopting a multi-module setup for their Android projects. The number of modules for each project can vary, and some projects can even have more than a hundred modules. Managing these modules involves a lot of copying and sharing common settings and codes between build.gradle files. Some teams use separate Gradle files and apply from: statements to try to solve this issue. However, it is not very scalable once you exceed a certain number of files.

In this post, I will introduce how we can make use of a custom Gradle plugin to help us manage Android project modules. We will also provide some customizability into our plugin so that each module can customize the build parameters. Then we will also see how we can integrate other plugins, e.g., Jacoco, from our multi-module plugin. This is how our build.gradle.kts file will roughly look like at the end.

Compare this with a typical build.gradle file that roughly achieves the same thing:

This implementation is made using Android plugin 3.6.0-beta04 and Gradle 6.0.1

Gradle Plugin with Kotlin

Let’s look at some examples of what the plugin can do for each module:

• Applies important and required plugins, such as kotlin-android and kotlin-android-extensions.
• Configures common android module settings for a module (minSdkVersion, targetSdkVersion, etc.) but still allows each module to override any settings.
• Specifies the default proguard files.
• Enables supported Java 8 features across all modules.
• Adds required dependencies to a module, such as kotlin-stdlib
• Configures Jacoco for each module and allow custom configuration block that supports both kotlin and groovy script.

Now, before creating the Gradle plugin, first, we need to create a buildSrc/build.gradle.kts file in the root folder and add the required dependencies.

Since we declared the dependency to both android-gradle-plugin and kotlin-gradle-plugin in this file, we can remove the classpath dependencies to both artifacts from our root/build.gradle.

And then in buildSrc/src/main/kotlin, we will create the plugin class that implements the Plugin interface.

The apply method will be invoked in the project evaluation step of Gradle build lifecycle and it will be the entry point into our plugin.

Apply Other Plugins

Since we want our plugin to automatically apply kotlin-android and kotlin-android-extensions to our modules, we simply add apply plugin statements to our project like so:

Configure Common Android Settings

There are many settings that can be shared between an application, library, test, and feature module. Since we want this plugin to manage the configuration between all type of modules, we are going to make use of a class named BaseExtension from the Android Gradle plugin.

You can also apply custom configuration for a specific type of module by using the respective extension type, e.g., AppExtension for an application module.

Default Proguard Files

We also want the plugin to automatically pick-up the correct proguard files for each module’s release configuration, be it for an application or a library module.

Enable Supported Java 8 Features

To enable Java 8 features for each module, we need to set the sourceCompatibility, targetCompability, and kotlinOptions.jvmTarget. Setting the jvmTarget for Kotlin is not that straightforward, but it’s not that difficult either.

Adding Required Dependencies

Sometimes, there are libraries that we need across different modules. Some libraries that come to mind arekotlin-std-lib, androidx-core, and testing libraries. Adding the dependencies to them through the plugin is very simple:

Jacoco and Custom Settings Through Extension

Setting up a Jacoco task for each module can be quite complicated since you have to write and register the task on each module. Our plugin provides a good opportunity to set-up a simple and unified way to introduce coverage report for each module. As an example, let’s say we want to have the following settings that we want each module to specify:

1. Whether to generate the coverage report for this module.
2. File pattern for classes to be excluded from each module’s coverage report.

android { ... }

myOptions {
  jacoco {
    isEnabled = true
    excludes(
      "file/pattern/to**Exclude**"
    )
  }
}

To allow custom configuration for the plugin, we first need to create an extension class that declares the configurable parameters.

For it to work with Gradle API, we need to make our classes and members open. Also, we’re going to use Action class from Gradle API so that it will play nicely with Groovy scripts. It is a good idea to initialize the extensions and options to some sane defaults in order to minimize the required configurations in each module. For example here, code coverage is enabled by default on all modules, but each individual module can disable it through its build.gradle file.

We will then register the extension in our plugin to make the configuration block available in the build script:

And to read the configuration values that have been set by each module, we will have to use Project.afterEvaluate block since the values are set during the evaluation step of our modules.

If everything is set up correctly, we will now be able to invoke :module:jacocoDebugReport (or jacocoFlavorDebugReport) Gradle task that will run the unit tests and then generate a coverage report for us.

Final Steps

Now that the Gradle plugin is completed, we can then register the plugin using gradlePlugin block in buildSrc/build.gradle.kts so that it is available in our module’s build.gradle file.

Finally, we apply the plugin into each module and add overrides or custom configurations as we see fit.

Other Benefits of Using Gradle Plugin

With this Gradle plugin approach, our build scripts are now relatively shorter and easier to migrate to Kotlin DSL. Also, Gradle plugin can be applied to both Groovy and Kotlin DSL, allowing us to migrate our build scripts module by module based on our needs instead of converting all of them at once.

After the build.gradle files have been migrated into kts, we can make use of extension functions (declared in buildSrc/src/main/kotlin) to simplify our build files even further, like so:

Managing a multi-module project with a custom Gradle plugin is good for common Gradle script configurations that need to be applied across different modules, making build.gradle scripts simpler and more maintainable. It also provides a single location where we can define and manage common parameters like targetSdkVersion and minimumSdkVersion while also allowing each module to define its own overrides.

Custom Gradle plugin also provides an opportunity for us to extend the capability of a Gradle script through custom extensions and Kotlin DSL. Allowing us to create a more complex build configuration while still keeping it easy to read. Moreover, with Kotlin DSL, we can further simplify our build script with extension functions.

You can find the sample implementation of this plugin in the following repository:

malvinstn/gradle-plugin-android-multi-module

Thank you for reading this post. I hope you found it useful!

Managing Android Multi-module Project with Gradle Plugin and Kotlin was originally published in Wantedly Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.