us進出でのandroid開発inメルカリ mercari us app development
Post on 07-Jul-2015
16.226 Views
Preview:
DESCRIPTION
TRANSCRIPT
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エンジニア募集中!
top related