US進出でのAndroid開発 in メルカリ

Mercari Inc. 今井智章

自己紹介• 株式会社メルカリ Android エンジニア(2014.3~)

!

!

!

!

!

!

• 以前はSIerでインフラ系DBエンジニア(たまにjava開発)2

twitter: tomoaki_imai github: tomoima525 qiita: tomoima525

フリマアプリの機能開発、USアプリ開発

Agenda

• 言語対応の罠

• デザインの罠

• 開発環境作りの罠

3

本日はメルカリUS版リリースにおけるAndroid開発で はまった罠について話します

メルカリUS進出• 2014年9月中旬にUSローンチ(C2Cとしては初)

• クライアント開発期間 - 1ヶ月半(2014年7月末から着手)

• 前提 - iOS版, Apiは先行して開発 - One Source Multiple Products - 開発環境は Eclipse

4

Android開発でのUS対応

• 言語対応

• デザインリニューアル

• US, JP並行開発環境の整備

5

old new

言語対応の罠

そもそもAndroidは言語対応に強いよね?

リソースフォルダ/res/values-XX で何カ国でも対応できるし…

そんな風に考えている時期が 俺にもありました

言語対応は甘くない• ①表記の国、文化的違い

- 値段 小数点有りドル $ 1,200.00 - 日付 JP 2014/12/05 -> 12/14/2014

- マイナス表記 ☓ - $12 ◯ ($12)

- バリデーション関連 (zipcode等)　etc

!

• ②翻訳チームとの協業 - strings.xml操作にgithubはハードル高い - エンジニアの翻訳取込負担も上げたくない

9

①表記の国、文化的違いへの対応• ヘルパー関数の実装

10

public abstract class StringFormatHelper { public abstract String formatPrice(int price); //JP,USで実装が異なるものはabstract public static final StringFormatHelper getInstance(){ StringFormatHelper sfh; switch (Config.LOCALE_ID) { case Const.LOCALE_JP: sfh = new StringFormatHelperJP(); break; case Const.LOCALE_US: sfh = new StringFormatHelperUS(); break; default: sfh = new StringFormatHelperJP(); break; } return sfh; } }

インスタンス化の際にクラスを呼び分ける

• ヘルパー関数の実装

11

US,JPの各Helperクラスでそれぞれの処理を実装public class StringFormatHelperUS extends StringFormatHelper { private static NumberFormat COMMA_FORMAT 　　　　　　　　　= new DecimalFormat("$#,###.##;($#,###.##)"); @Override public String formatPrice(int price) { 　//USで必要な処理を実装 } }

StringFormatHelper sfh = StringFormatHelper.getInstance(); String currentSalesStr = sfh.formatPrice(currentSales);

利用時はインスタンスを生成して利用

Android Studio ならGradleのflavorを使う手もある 共通メソッドを1クラスで書けるメリットはあり

①表記の国、文化的違いへの対応

②翻訳チームとの協業• Transifexの利用

- ローカライゼーションサービス - 翻訳者がソースコードに触れることなく翻訳できる - コマンドラインで翻訳を取込む事が可能

12

github

engineer

translator

string.xml *.json

コマンドラインでupload, download $ cd .tx $ tx pull -$a -f GUIで操作

②翻訳チームとの協業• 良いところ

13

<!̶- value/strings.xml ̶> <string name=“format_address”>住所1: %1$s 住所2: %2$s</string> <!̶- value-en/strings.xml ̶> <string name=“format_address"> Address1:%1$s %2$s </string> //%2$sが不要でも必須

• もうちょっとなところ - strings.xmlのformat数をUS,JPで合わせないとエラーがでる

- 変換に十分対応していないファイル形式(json等)がある

- 翻訳を当て込む作業が自動化され、ミスが軽減

- 訳した内容をその場で実機確認できる

続いて、デザインの罠

iOSファーストで開発しているから、デザインはそれほど

考慮ないよね?

iOSのデザインをそのままxmlで 組めばいいんでしょ…

そんな風に考えている時期が 俺にもありました

Androidのデザインガイドライン を考慮する

17

• ユーザーは各OSでのUXに慣れている。異なるUXで惑わせない

!

!

!

• 社内のiOS比率が高い場合は注意。ユーザー目線、ガイドラインを武器に戦うべし

- テキスト入力 - アクション(戻るボタンを置かない等) - iconデザイン etc. - Design: Pure Android等を参考にするhttps://developer.android.com/design/patterns/pure-android.html

18

トータルなデザインを踏まえ、ガイドラインに沿っていない部分もある

メルカリデザイン比較例

Android iOS Android iOS

出品画面 購入画面

続いて、開発環境作りの罠

US, JPの開発は担当を分けた方が効率的？

リソース切替って結構面倒だし…

そんな風に考えている時期が 俺にもありました

並行開発で気づいたこと

• 開発中も容易にUS - JP切り替えられるの超大事 - 開発する機能の多くは共通 - 常にUS, JP両方を確認できれば、後戻りが減る

• Eclipseで柔軟な環境切替は面倒

• が、全部のリソースを切替える必要はない

22

並行開発環境を整備する• 切替が必要なリソースファイルを属性で分けて、さくっと確認できるようにする

23

属性 リソースファイル 対応

ローカル開発中に環境を切替えるためのファイル

- Config(APIの向先)関連のjavaファイル

- マスターデータ(json)

コマンドラインで切替できる シェルスクリプト実装

apk作成時に切替える ためのファイル

- AndroidManifest.xml - analytics.xml - authkeys - res/values

ビルド時にファイルを総入れ 替えし、ビルド後は元に戻す

スクリプト実装

更に気軽に切替できるように試みた• デバッグモードでロケール切替の仕組み

- アプリ起動中にJP-USが切替えられる

24

public class ThisApplication extends Application { private int mLocale = Const.LOCALE_JP; public void setAppLocale(int locale){ mLocale = locale; Locale l; switch(locale){ case Const.LOCALE_JP: l = Locale.JAPAN; break; case Const.LOCALE_US: l = Locale.US; break; } Locale.setDefault(l); Configuration config = new Configuration(); config.locale = l; getResources().updateConfiguration(config, null); } }

Application内で言語設定を切替える仕組み

が、これは失敗…

• アプリがExceptionを出すと、OSの言語設定が適用されてしまう !

• JP, USでApiの向き先が異なるため、クライアント内のユーザー情報に不整合が起きる

25

こうして、試行錯誤の日々は続く…

まとめ:US進出で得た知見• 言語周りは

26

• デザインは、ガイドラインに沿ったデザインを心がける

• 開発環境は柔軟に多言語へ切替えられる仕組みを作る

- 異なる表記を柔軟に受け入れられる実装を作る - 翻訳チームがスムーズに開発に参入できる仕組みを作る

メルカリではAndroid/iOSエンジニア募集中！