カテゴリー: Android

Androidのプログラミングについての情報を取り扱っています。

Android Support LibraryのソースコードをGrepCodeを使って確認する

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Android Support LibraryのソースコードはAndroid Studioで確認することができません

例えば、android.support.v7.app.ActionBarActivityのソースコードを確認したいとしましょう。その場合、調べたいクラスをCmd+クリックすることで、対象のクラスのソースコードに自動的にジャンプできます。

Android Studioでソースコードを確認する

しかし、サポートライブラリについてはソースコードまでは見つかりません。

ActionBarActivity

ちなみにAndroid SDKのクラスであれば、SDKマネージャーでソースコードまでダウンロードしていれば確認することができます。例えばBundleクラスのソースコードは以下のように確認できます。

例:Bundleのソースコード

サポートライブラリのソースコードを確認するのは、Gitを使ってGoogleのリポジトリから拾ってくる方法もありますが、今回はWebサービスのGrepCodeを利用してみます。

GrepCodeにアクセスして、検索したいクラスを入力します。(今回の場合はandroid.support.v7.app.ActionBarActivity)

検索したいクラスを入力

すると検索結果が表示されるので、調べたいクラスのバージョンを選択します。

バージョンを選択

他のバージョンとの差異をDiffで確認できるので、バージョンアップでどこが変更されたのかを調べるのにはちょうどいいかもしれません。

他バージョンとの際はDiffで確認できる

比較するバージョンを選択

AndroidのOSバージョンとコードネームとAPIの一覧表

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

私は未だにAndroidのOSバージョンとAPIの数字とコードネームが結びついていません。最新の5.0がAPI21で、Lolipopだというのは分かるんですけどね。

ソースコードを読んでいて、JBとかICSとか出てきて「それバージョンで言うとどこ?」と混乱したのでまとめておくことにしました。

バージョン コードネーム api
5.0.1 Lolipop 21
4.4w Android L Preview
(KitKat+Wearable Extensions)
20
4.4 KitKat 19
4.3 Jelly Bean 18
4.2.x 17
4.1.x 16
4.0.3〜4.0.4 Ice Cream Sandwich 15
4.0〜4.0.2 14
3.2 Honeycomb 13
3.1 12
3.0 11
2.3.3〜2.3.7 Gingerbread 10
2.3〜2.3.2 9
2.2 Froyo 8
2.1 Eclair 7
2,0.1 6
2.0 5
1.6 Donut 4
1.5 Capcake 3
1.1 2
1.0 1

Android Studioのデフォルトでは、API10〜21をサポートするようにプロジェクトが作成されます。2.3.3までサポートするということですね。

ちなみにOSバージョンごとのシェアはAndroid DevelopersのDashbordsで公開されています。(2.2以降のバージョンのみですが)

コードネームの頭文字がAから順番につけられているので、それを押さえていれば大体どのあたりのバージョンなのか検討がつくかもしれません。

設計方法を学ぶ必要性をひしひしと感じる

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

今までプログラムの全体像を頭の中でイメージし、後は勢いでコーディングして完成させるという作り方をしてきていました。大規模なプログラムを作ることがなかったので、今まではそれで何とかなっていたのですが、最近それも限界を感じています。

Androidのアプリを作るのに、画面がどう遷移してどういう処理が必要で・・・なんていうことを頭の中だけでは把握できません。

それに勢いだけでコーディングしていると、このクラスが一体何の働きをしているのかが分からなくなってきます。作成中はまだ大丈夫なのですが、時間が経つともうわけがわからなくなります。

1分間タイマーは勢いだけで作り上げましたが、もう機能修正とか追加とかやりたくありません。どこで何やっているか自分でも訳がわからないからです。

そんなわけで、設計方法を学ぼうかななんて思って行動を始めました。

頭の中だけでプログラムをイメージするのには限界があるので、少なくとも設計図を用意したい。設計図を作るには、どういうふうにプログラムを組み上げていくのがいいのか、その手法を知る必要がある。という感じです。

とりあえずUMLの書き方さえ知らないので、UMLの入門書を読んで、ついで実践UMLという本を図書館で借りてきて読みました。

とりあえずわかったのはこんな感じですかね。

  • UMLが書けることとクラス設計ができることは別の話
  • 最初に完璧な設計書を用意するという考えは間違ってる
  • とりあえずやってみないと始まらない

UMLの書き方をマスターしたからといって、それだけでは設計書を作ることはできません。個人開発で使う分には、最低限自分が分かればいいので、細かいUMLの書き方をマスターしようとするのはちょっと脱線しすぎかもしれません。

プログラムの設計図を完璧に仕上げてからコーディングをしていくというのはウォーターフォール的発想だからやめろと実践UMLには書いてありました(意訳)。オブジェクト指向開発的には、もっとフレキシブルに設計とコーディングを行き来しながら開発していくんだそうで。

確かに、どういう作りにすればいいのかと完璧な設計を求めるあまりに、プログラムが完成しなければなんのための設計なんだという話になりますもんね。まあ今の私がそうなんですけど。

実践UMLを読んで感じたのは、内容がかなり濃い&難しいので、とりあえず前半くらいの内容を利用して実際に設計→コーディングのサイクルを回していくのがいいのだろうと思いました。どう作っていけばスマートなのかを考えだすとキリがないので、とりあえずやってみなければ始まらない。

アプリの機能、要件を定義して、そこからどういうクラスが必要なのかを検討して、実際に作ってみる。上手くいかなければ設計しなおして、やり直す。もっといい作り方がないかなとか追い求めると何もできなくなってしまうので、とりあえず作る。そんな方針で進めてみようと思います。

それと並行して設計方法についても勉強したいなと思っています。何かおすすめがあれば教えていただきたいです。

ファイル名の付け方の罠 不用意にハイフンを使わない

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

レイアウトXMLのファイル名、drawableに用意する画像のファイル名、自分で作ったカスタムスタイルの名前などなど。これらの名前の中にハイフンを使うとビルドが通らないことがあります。

ハイフンを使ってもビルドをかけるまでエラーと表示されなかったり、名前にハイフンが入っているせいでレイアウトプレビューがうまく表示されなかったりすることがあります。この原因がファイル名等にハイフンを使っているせいだとはなかなか気づけません。

命名規則には、例えばレイアウトXMLのファイル名に大文字が使えないというのもありますが、これはAndroid Studioがちゃんと指摘してくれるので分かりやすいです。ファイル名なら指摘してくれるのでわかりますが、例えば独自のスタイル名については指摘してくれません。

私は普段ファイル名の区切りにハイフンをよく使うので、エラーだと直接指定されないとついついハイフンを惰性で使ってしまいます。レイアウトのレンダリングプレビューがちゃんと表示されないな、なんでだろう・・・とすごい悩んでいたのですが、原因は使用しているスタイルの名前にハイフンを使っているせいでした。

Android開発で名前をつけるのには、ファイル名にかぎらずスタイル名などでもハイフンは使わないよう気をつけましょう。

ペーパープロトタイピングをまずやろう

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

アプリを開発する上で、コーディングを始める前にペーパープロトタイプを作るといろいろなメリットを享受できます。

  • どんな画面が必要になるか検討できる
  • 作り終わってから使い勝手の悪いところに気づいて、実装をやり直す事態を未然に防げる可能性がある
  • 必要な機能の絞り込みができる
  • 作ろうとしているアプリのイメージがはっきりしてくる
  • などなど

デザインに疎いとどうしてもコーディングを優先してしまいがちです。画面設計よりシステムを作っている方が性に合ってますし。ついついデザインを後回しにしてしまいます。

しかしその作り方をすると、アプリ完成したけれど残念な見た目だったり、使い勝手が悪くて使えないアプリになってしまったりしているかもしれません。それを後から直そうとすると、せっかく実装したシステムも作りなおしになる可能性もあります。せっかく作ったコードを、使い勝手が悪いからと泣く泣く切り捨てることになったら、目も当てられません。

POP

ありがたいことに、ペーパープロトタイピングを簡単に行うことのできるツールが世の中には存在しています。

POPというアプリを利用すると、紙に書いた画面デザインにいとも簡単に動きをつけることができます。ここを押したらこの画面に移動して・・・なんていうのが簡単に作れて非常に便利です。

Android版のPOP2.0だとジェスチャーを設定する項目があるものの、設定しても動かなかったり、スマホで撮影した画面を削除しようとしたらゾンビのごとく復活してきたりと、使い勝手が微妙なところがあります。私の使ってる端末固有の問題なのかもしれませんけれども・・・。

ただこれがあるだけでも画面の動きのイメージがつきます。この画面遷移は使いづらいとか、こういう画面も用意しないといけないなというのが簡単に分かります。このアプリ、便利なのは間違いありません。

Androidからだけでなく、パソコンのブラウザやiPhoneなどからも使うことができるので、ブラウザで編集してスマホで動作を確認するなんて使い方ができます。

POPブラウザからアクセス

テンプレート

紙にアプリのデザインを書くのに、さり気なくネックなのが画面を描画するところです。画面の外枠です。私はこれが面倒くさくて、画面を紙に書けないでいました。

枠を決めるのが難しいのであれば、最初から用意されているものを利用すればいい。そこで私は、iPhone5のワイヤーフレームに使えるアイデアシートをイラレで作りましたさんで公開されているアイデアシートを利用させていただきました。

現在はリンク切れで見れなくなってますね・・・。

iPhone5向けのテンプレートではありますが、画面の比率はAndroidとそう大差ありません。画面の外枠が決まっているだけでも、やりやすさが段違いです。

どう実装するかはとりあえず考えない

とりあえず考えるのは、ボタンをどこに置いて、どの画面に移動するのかだけに絞った方がいいと思います。できるだけシンプルに考えるのが大事です。どうやってコーディングしようかと考えだすと、何も書けなくなってしまいます。

実装方法を考えながらやってしまうと、実装しやすさを優先するあまりに使い勝手が犠牲になるのが悲しいです。とりあえずアイデアシートを印刷して、どしどし書くべしです。書いていればいいアイデアが浮かんだりします。紙に書くだけなのでやり直しも簡単ですしね。

せっかくアプリを作るのであれば、多くの人に使ってもらいたいです。そのためにも、せめて使い勝手がよくなるような努力はしておきたいですよね。

ProGuard適用前

ProGuardによる難読化って具体的にはどうなってるのだろう

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

確認方法

手順としては、ProGuardを適用していないapkファイルと、適用したapkファイルの2つを用意しました。そしてリバースエンジニアリングを行い、apkファイルからソースコードの抽出を行い確認を行いました。

ProGuard適用前

ProGuard適用前

こちらがProGuard適用前のソースコードです。ほぼ自分で作ったソースコードのままで、Android Studioで作り上げたソースコードと大差ありません。

ProGuard適用後

ProGuard適用後

こちらはProGuardを適用した後のソースコードです。一部の変数名やクラス名、メソッドなどがa,bといった意味のない文字列に置き換えられています。

全てが書き換わっているわけではなく、forやifなどの命令文はそのままですし、解読しようとしてできないレベルではありません。

ProGuardのお仕事

私は難読化というからには、もっと複雑な変換が行われているのだとばかり思っていましたが、意外にシンプルな難読化でした。確かに読みづらくはなっていますが、解析しようと思えばやってできないレベルではありません

ProGuard適用前後の比較

変数名やメソッド名等は、一部意味のない文字列に置き換えられているものの、処理の流れなどはそのままであるため、アルゴリズムの解析は比較的しやすそうです

よく考えてみれば、解析不可能なほどに難読化が行われると、今度はプログラムとして動作しなくなるので本末転倒になってしまうのでしょう。そのためProGuardによる難読化は、変換をしてもプログラムの動作に影響のない範囲で難読化が行われているようです。

注意点

まずはProGuardによる難読化はあくまで気休めレベルであるということを認識しなければなりません。私も実際にこうやって中身を確認するまでは、ProGuardを適用していればソースコードの盗用などは防げるものだとばかり思っていました。

またソースコードの書き換えが行われるため、以下の様なことに注意が必要です。

別途動作確認が必要

ProGuardはメソッド名やクラス名を書き換えてしまうため、プログラムによってはProGuardを適用することにより誤動作を起こす可能性があります

私はまだそのようなプログラムを作ったことはありませんが、クラス名やメソッド名を文字列等を使って参照するようなプログラムは動作しなくなるでしょう。そのため、ProGuardを適用したapkファイルを用いた動作確認を別途行う必要があります。これはちょっと面倒臭いですね・・・。

文字列リテラルの中身は変換されない

ProGuardは文字列リテラルの中身の変換は行いません。ここを変換すると、プログラム実行時に表示される内容や動作に影響が出てしまうからです。ここは逆に変換されないということに注意が必要です。

これは、例えばソースコード中にパスワードを記述してしまうと、そのまま見えてしまうということです。まぁ、そもそもソースコード中にパスワードを平文で書くこと自体が悪手ですけれども。

難読化以外の効果

ここまで難読化について書いてきましたが、ProGuardは難読化と一緒にソースコードの最適化も行っています。

例えばapkファイルの軽量化です。これは変数名等を短い文字列に変換することも寄与しているでしょう。今回使ったapkファイルであれば、ProGuardを適用することにより、適用していないapkファイルと比較して、ファイルサイズが600kb削減されていました。

その他にも処理の最適化を行ったりするようで、基本的にはProGuardを適用した方がいいのだと思います。ただ、難読化のために適用するという観点では「適用したほうがマシだ」というレベルであって、完全なものではないということを念頭に置いたほうがいいでしょう。

むしろ余計なデバッグの手間をかけるくらいなら、最初からProGuardを使わないという選択肢もありなのかもしれません。

新旧1分間タイマーの変化

デザインを考える

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

ださいデザインからの脱却

1分間タイマーは、最初のバージョンでは文字とボタンだけが表示されている、非常にダサいアプリでした。それに比べると現在の見た目はだいぶましになったように思います。あくまで最初の頃よりはましになったなというだけで、カッコイイ見た目にするにはどうすればいいのかよく分かりません。

ただ、見た目をかっこ良くするという観点からのアプローチは難しくとも、使いやすくするという観点からのアプローチであれば、少し突破口が見えるような気がします。私がSmashing Android UI レスポンシブUIとデザインパターンという本を読んで、1分間タイマーに加えた変更を例にしてみましょう。

開始ボタンを押しやすくする

1分間タイマーを自分で使っていてとても不便だったのが、タイマーの開始ボタンが押しづらいことでした

1分間タイマーの当初のバージョンでは、デフォルトのButtonを開始ボタンとして利用していました。私はタイマーを開始させたらすぐに紙に向かって文字を書き出していきたいため、アプリの開始ボタンは横目で見ながら押すような感じで使っていました。しかし以前のバージョンの四角い小さなボタンでは、開始させたつもりが押せていないということがよくあってテンポが悪かったのです。

ボタンを大きくすれば使い勝手はかなり向上します。

新旧1分間タイマーの変化

残り時間の表示方法

ボタンの巨大化にともなって、残り秒数の表現方法も変えることにしました。開始ボタンを円形にしたので、その周りにバーのような感じで残り秒数が分かればスマートかなと考えました。

以前は単に文字で残り秒数を表示していました。しかし自分で使っていて、あと何秒残っているかを文字で読み取ることはいままで一度もありませんでした。そもそも音声による通知もあるので、残り秒数を文字で把握する必要性はありません。

円形のバーであれば視覚的に横目であとどれくらい残っているかが分かるので、文字で表示されるよりもマシだと思います。

ただ、このバーの動きがカクカクしているのが残念なところです。スムーズに動くように見せることができれば、見た目もよくなるのですが、実装方法が分かりませんでした。いずれやり方を調べて実装できたらいいなぁと思っています。

アプリ終了時の確認ダイアログをなくした

以前のバージョンでは、バックボタンを押した時に「終了しますか?」という確認ダイアログを表示していました。この終了するかどうか確認をとるアプリは、世の中にまだまだ多く存在しています。

みなさんは、アプリを使っていて終了時に確認ダイアログが出ることについてどう考えていますか?

「そんな確認はいらないんでさっさと終了しろよ」派でしょうか、「わざわざ確認してくれて親切やね、ありがとう」派でしょうか。

Smashing Android UI レスポンシブUIとデザインパターンでは、この終了時に確認ダイアログを出すのは、多くの場合開発者の都合によってつけられているものであると断じていました。

確認ダイアログは悪である

終了時に限らず、何らかの操作を行う際に確認ダイアログを表示するのは、取り返しの付かないことを実行する場合にユーザーに責任を転嫁させるため、開発者の都合で使われている悪しきものだとバッサリでした。

確認ダイアログを出したところでユーザーがちゃんと確認するかどうかは分かりません。操作ミスを恐れて確認ダイアログを表示させるという考え方もあるかもしれませんが、そのダイアログのボタンを操作ミスしないとは言い切れないはずです。

そこで確認ダイアログを使うくらいなら、操作を実行した後にそれを取り消すための手段をユーザーに提供することこそが、真のユーザーフレンドリーであるとこの本には書いてありました。ごもっともだと思いました。

終了時の確認で言えば、一度終了してしまうと起動するのに膨大な時間がかかってしまうため、操作ミスによる終了を防止する意味で出すというのはありかもしれません。起動するのに1分かかるゲームアプリで、やっと起動したと思った時に手が滑ってバックボタンを押してしまった。そういう場合であれば、確認ダイアログを表示する方が親切かもしれません。

ですが、その確認ダイアログは必要なのかと自問することが大切です。終了前の操作状態を復元することで対処できないか、いつ終了されてもデータが保存されるように作ればすむ話ではないか。そう考えることで使い勝手が向上していくのです。

アプリのデザインは難しい

デザインといえば見た目の話だけだと思っていましたが、使い勝手に関わるすべてのものがデザインです。アプリの開発と一口に言っても、プログラムのことだけではなく、使い勝手のことについても考えなければなりません。実際にやってみると奥が深いなぁとつくづく思います。

今まで「デザイン」というと見た目をカッコよくすることだと思っていましたが、考えることはそれだけではないのだということが分かりました。見た目をカッコよくするのは難しくても、使いやすくすることであれば考えれば何とかなりそうです

そんな見た目がおしゃれなデザインの話より、使い勝手を重視したデザインの話がいっぱいなSmashing Android UI レスポンシブUIとデザインパターン。読んでいるといろんな発見があると思います。

データベースのデバッグ adb shellでDBの内容を確認する

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

アプリでデータベースを利用する場合、動作確認のためにその中身を確認したい時があります。

データベースへの書き込みを行ってみたものの、ちゃんと保存されているのか確認したい・・・よくあると思います。そんな場合に、adb shellを利用します。

adb shell

Androidアプリを開発するなら簡単なadbコマンドは知っておいたほうがいいと思います。ちなみにadb shellで端末やエミュレータにアクセスする手順は必ずしも以下のとおりでなくてもいいです。

まずはAndroid Studioからエミュレータを起動します。起動したらAndroid StudioのTerminalツールウィンドウを開きます。

Terminalツールウィンドウを開く

adb shellと入力すると、端末にログインできます。

データベースは特別な指定をしていない限り、/data/data/パッケージ名/databases/データベースファイル名に作成されています。

この例の場合は/data/data/jp.gcreate.sample.sampledatabase.app/databases/Sample.dbとなっています。

データベースファイルの場所

これがSQLiteのデータベースファイルになるので、ローカルにコピーしてツールを使って確認するなりしましょう。今回は中身を確認するだけなので、そのままターミナルからsqlite3コマンドを使ってみます。

sqlite3コマンド

sqlite3 データベースファイル名でSQLiteコマンドが実行されます。

sqlite3コマンド

このモードではSQLを使っていろいろできます。私が最初戸惑ったのはこんなかんじです。

  • 基本的に全てSQL文であると判断される
  • エンターでコマンドが実行されるわけではない
  • SQL文は最後に;つけない限り改行だと判断される
  • SQLiteのシステムコマンドを使いたい場合は最初にドットをつける

とりあえず以下のコマンドを知っていればなんとかなると思います。

  • .helpコマンドでヘルプが見れます。
  • .exitコマンドで脱出できます。
  • .schemaコマンドで、データベースファイル内のテーブル構造なんかが確認できます。
  • .tablesコマンドで、データベースファイル内にどんなテーブルがあるか確認できます。
  • SELECT * from テーブル名;で、テーブル内のデータを確認できます。`

実際に実行してみると以下の様な感じで確認できます。

sqlite3コマンドでのデータベース内の確認

SQLite version 3.7.11 2012-03-20 11:35:50
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .schema
CREATE TABLE Sample(_id integer primary key autoincrement , InputText text not null , InputDate text not null );
CREATE TABLE android_metadata (locale TEXT);
sqlite> .tables
Sample            android_metadata
sqlite> SELECT * from Sample;
1|abc|2014/09/10 12:42:22
2|welcome to JAPAN!|2014/09/10 12:42:40
3|this is test|2014/09/10 12:42:50
4|aaa|2014/09/10 12:43:04
sqlite> 

私はドットインストールでSQLiteを勉強しました。AndroidのSQLiteは簡易版なので、使えないプロパティとかもあったりしますが、基本的なところはこれでなんとかなると思います。

実機の場合はうまくいかない

ちなみにこの方法は、実機では使えない手段です。データのパーミッションの関係でファイルを取得することもできず、そもそもsqlite3コマンドが利用できない場合があるからです。

実機をルート化しているとか、デバッグ用のアプリ(AndroidManifest.xmlのdebuggableがtrueになっている)であるとかなら何とかなりますが、基本的にこの方法はエミュレータを前提とした話です。

@Overrideってなに?

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Androidアプリを作成していてよく目にする「@Override」ですが、私はこれがなんなのかよく分かりませんでした。メソッドによってついていたりついていなかったりで、いまいち基準が分からなくて気持ち悪かったですが、あまり深く考えずにサンプルコードをコピペしていました。

Overrideってなに?

結論から言うと、この@Overrideはアノテーションの一種です。別に書かなくてもプログラムは動きます。

ではなぜ書いているのかというと、IDEやビルドツールに対して、「このメソッドはオーバーライドしたメソッドだぞ」と伝えるために書いているのです。

例えばAndroidでよく出てくるonStart()というメソッドをオーバーライドする際に、間違えてonStrat()と打ち間違えていたとします。仮に@Overrideのアノテーションをつけていなかったら、打ち間違えたメソッドでもエラーなくビルドできてしまいます。そしてアプリを実行すると・・・「想定通りに動かない。なんでだ!」となってしまいます。

プログラムを書いている本人は、メソッドをオーバーライドしているつもりで書いていても、それはIDEやビルドツールには分かりません。本人はonStart()をオーバーライドしているつもりでも、ビルドツールは独自のonStrat()メソッドだと解釈して処理してしまいます。@Overrideはそんなプログラマーの気持ちを彼らに伝え、しょうもないミスで時間を浪費しないようにするためのものなのです。

ちなみにアノテーションには、@Override以外にもいろんな種類があります。Java標準のアノテーションからはじまり、ライブラリ特有で利用するものもあります(Junit4で使う@Testなど)。ソースコードを簡略化するために使われたりもしています。

多言語に対応する

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

アプリ内で利用する文字列は、直接文字列を書き込む方法と、リソースファイルを参照する方法と2種類あります。基本的にはリソースファイルを参照する方法が推奨されます。

それはなぜかというと、主に多言語対応を簡単に行うためです。そのためにわざわざstrings.xmlへ文字列を書き出します。

Android Studio 0.8.8からTranslation Editorが追加され、この多言語対応が比較的簡単に行えるようになりました。といっても、まだ開発中の機能のため、操作性に難があります(執筆時利用バージョン0.8.9)。エクセルみたいな感じで編集できると便利なんだけどなぁ・・・と使っていて思いました。

具体的にはどうやっているか

ディレクトリ例

 └app
  ├res
   ├values ←デフォルトで利用されるリソース
   ├values-ja ←日本語環境で利用されるリソース
   ├values-en ←英語環境で利用されるリソース
   :

多言語対応ディレクトリ例

こんな感じでディレクトリを作成してそれぞれのリソースファイルを用意します。

日本語環境で利用していれば、values-jaに用意されているstrings.xmlの中身が使用されます。英語環境ならvalues-enのもの、それ以外の環境ならvaluesのものが適用されます。

多言語に対応できるのは何もstrings.xmlだけに限りません。文字を書き込んだ画像の多言語対応のために、drawableを同じように用意してやることもできます。

ソースコードから出力する文字列はどうするのか

ここは私の疑問なんですよね・・・。

とりあえずプログラムで端末のデフォルトロケールを取得して振り分ける処理をしてごまかしました。

if(Locale.getDefault().equals(Locale.JAPAN)){
    //日本語の場合の文字列
}else{
    //それ以外の場合の文字列
}

後から修正が大変になる駄目なパターンだと思いつつ、間に合わせで処理しました。

私がこうやって処理した部分は年月を表示する部分でした。例えば2014年9月と出力する部分です。日本語以外の環境で日本語が出てくるのはおかしいので振り分けてみました。

そもそもソースコードから直接文字列を出力するような実装が間違っているのかもしれません。一番いいのは20149とそれぞれ分割してViewで表示するようにしてやるのがいいのかもしれませんね。

ただそれだけでは対応できないところもあると思うので、ベストプラクティスが何なのか知りたいところです。