Hello, this is KATABUCHI from Smart Device Group.

This article has been posted on the day of the 19th on the Advent Calendar 2014 by Recruit Technologies.

On the previous day, @ainoya wrote an article about the dynamic switching of the API backend server, which bothered the developers in a mobile application development.

This time I’ll try to address what technologies the Android engineers use for development at Smart Device Group which I belong to.

Organization

Smart Device Group at Recruit Technologies has a mission to develop comparatively big applications in scale among the business in Recruit such as zexy, SUUMO, etc.

Over a hundred people belong to the group, and the Android engineers make up about 30 of them. The rest are the iOS engineers about 30 and the QA members about 30 also.

Technologies

IDE

Talking about Android, development environment is important. We recommend using Android Studio as a general rule.

Since Android Studio was released in version 1.0 and the development of the ADT Plugin has already been announced to be suspended. There will no merit to use Eclipse in the future as long as applications do not use NDK a lot.

Having said that, as using the updates of the channel give us a feeling of fear, we make sure to use dev-channel.

We do not have a special rule about installation of plugin, but we use those. We especially use Eclipse Code Formatter which comes in handy in the migration from Eclipse.

Build System

We want to say that Gradle is the only choice, but there are many projects using Maven in the company.

Because we have already did build automation since the Android Gradle Plugin was released, which Marven had more than 100 applications installed, we cannot pay the cost for the migration all at once.

We find that it will cost less for management to migrate to Gradle in the future, so we pushed strongly ahead with the migration.

Even with Maven, something like Build variants can be achieved by fully using the profile, and maven-android-plugin, using aar development is possible. I talked about the know-how at the study group before.

I personally feel that when I develop a library, we can use the optional dependence of the dependency and we can also automate the release workings with the maven-release-plugin, which gives me a lot of convenience.

I was greatly shocked from hearing that in Android Studio the support for Maven was brought to an end.

Jenkins

The application and library build are automated by Jenkins, which allow the apk to be passed out to engineers and QA members just by pressing the build button. This is something you already knew, right?

Library

We got used to using the library developed by the company before, but we recommend switching one to the one in open source. Although we frequently use the following libraries, as a general rule we try to use the one functionally equivalent to the Android SDK:

We develop the in-house system such as clash detection and push distribution controller, and we install them by preparing the special Android SDK.

More details about the push distribution controllers are available at @IT’s articles.

Challenge

Not talking about R&D, we try to catch information about the new features of Android as soon as possible. For example, we implemented App Indexing at a high pace to be ready for Google IO 2014. Currently, these applications support App Indexing.

Now, we’ve started verification of the Android TV. We always aim to think about something fun to try at Recruit.

Other

Other tools we use include:

  • Task management: Redmine
  • Source code management: GitLab
  • Knowledge sharing: Qiita:Team
  • Chat: Hipchat

Something we care about

I wrote a lot, but what we think is important is to make the Android-like applications along the philosophy of Pure Android.

Although it is sometimes hard as there are some limitations of business, of course, we try to implement things along the philosophy as close as possible.

I am very much sure that you will find it very useful to see the following video about Android UI anti-pattern.

At last

I have been writing about how we approach Android in my company so far. We have not only good things but also problems like these.

  • We cannot migrate the system to Gradle smoothly.
  • There are few people who understand the best practice of Android in the company, which keeps us using iOS.
  • In the first place, we are overwhelmingly lacking of Android engineers.

If there is someone who wants to make our Android applications the best, come and join us!