Hi, I’m ha1f, the iOS development engineer for LINE Creators Studio here at LINE Fukuoka. I’ll be giving you a firsthand report of the “LINE Developer Meetup in Fukuoka #18” that took place here in Fukuoka on July 19.
LINE Creators Studio Android with Kotlin / Dave
This session was led by Dave, who has been with the company for two years and until recently was the Android development engineer for LINE Creators Studio. Modern languages / frameworks like Kotlin, Anko, and RxBinding are being used in the development of the Android version of Creators Studio. Dave talked about their advantages and the reasons they were adopted while manipulating code snippets.
When Creators Studio development began, not many in-house services used Kotlin, but the Creators Studio team decided to try it out since it is 100% interoperable with Java; this means that even if something went wrong, the team could always fall back to developing with Java. After actually using it, Dave felt that its advantages were the safety of its null checks and its minimal code volume.
Anko is a library that allows developers to build layouts with code. While its disadvantages are its high learning cost (since it is a Domain-Specific Language) and the fact that it doesn’t support data binding, its advantages include:
Dave particularly emphasized the separation from business logic. Please refer to the slides for details.
Firebase Test Lab
Since Creators Studio supports Android ver. 4.1 and newer, device or OS-specific bugs are likely to occur, but it is difficult to test on many different devices. That’s why the team adopted Firebase Test Lab, which runs tests automatically on a wide variety of devices and OSs.
However, since writing test code for every screen would be too much work, and tests accompanying screen changes would require revision and ultimately be too costly in terms of maintenance, Dave spoke about the importance of determining priority. Specifically, priority was given to screens relating to money, those on which bugs frequently came up, or whose UI could potentially change depending on their status.
The Story of Adopting RxSwift into Our Team / Ukitaka
The Creators Studio (iOS) development team has adopted RxSwift. In doing so, however, it seems that there were high learning costs and a lot of difficulties. Ukitaka didn’t go into detail about the technology itself, and rather talked about the pros and cons of adopting RxSwift into the team, and what others should consider before adopting it.
Why RxSwift was Adopted
While comparing it to other asynchronous processing (e.g. GCD, delegate, Future / Promise, etc.) or MVVM methods (e.g. KVO, observer, bond, etc.), Ukitaka brought up as an advantage the fact that RxSwift can handle:
in a unified manner.
In addition, he gave specific examples of why the team was glad that they had adopted it, including its repository, validations, screen transitions, etc. Please refer to the slides for details.
How it was Adopted (in the Team)
Since RxSwift is still new and unusual compared to ordinary coding and programming paradigms, its learning cost was high, and apparently, it was difficult to convince the team members to use it. However, Ukitaka spoke about the pros of actually using RxSwift as well as things he wish we would have done.
A couple of the pros that Ukitaka brought up included “code review and pair programming after first having members that could use RxSwift actually write something that others could refer to.” He said that this helped him quite a lot when he was actually assigned an RxSwift task, and felt that it was a good way of adopting the technology since there was so many new things to remember about RxSwift.
Finally, Ukitaka talked about the fact that while RxSwift allows programmers to code conveniently and simply, adopting it into the team was difficult, and readability did not particularly increase. Furthermore, he emphasized that careful consideration is needed before adoption, since it is high highly likely that memory leaks if it isn’t used properly.
API Development for Easily Selling Stickers with Apps / Adam
Adam’s session was about the Creators Studio app’s server side APIs. While the development of the Creators Studio app was a new project, the LINE Creators Market system existed. However, its review, statistical, and other such frameworks were complicated, so APIs were added to the existing perl servers just as they were.
Adam introduced how the actual specifications were changed, as well as about the implementation of RESTful APIs that returned JSON and development/testing that used amon2, plack, prmd, etc.
Adam introduced examples of actual code and implementations of appropriate HTTP status codes (such as 200, 400, and 422). Please refer to the slides for details.
The Creators Studio app uses an OAuth2 framework in authentication.
Performing LINE’s authentication via the app allows users to avoid the hassle of entering their password, but requires the querying of the LINE server itself. Adam used a chart to simply explain this flow.
In this project, documents were automatically generated in markdown format from the JSON schema definition file described with YAML using prmd. However, the drawback to defining the JSON Schema is that when code is updated, the schema needs to be updated at the same time, meaning that there is a possibility that only one or the other may be updated. By using a convenient tool called “JSV::validator” at this stage, the team was able to test whether an API complied to specifications, ensuring consistency!
After another successful meetup, we had a mixer where everyone enjoyed sushi, pizza, and beer! Participants and employees alike had a great time socializing until the very last moments of the event. I think there were a lot of student participants at this meetup; I actually joined the company as a new graduate, and all of my classmates found work in Tokyo, so I’m always happy when young people express an interest in LINE Fukuoka!
LINE Fukuoka is looking for engineers!
・LINE Fukuoka Official Corporate Site (Careers page)