2015年02月22日

ローカライズが反映されない (2)

昨日のはXcodeの問題でしたが、意外とあるのが自分のミスでローカライズが反映されないこと。

開発の初期とにかく動くか確認しながら実装する時に、「仮」実装のつもりで文字列をソースコード中に埋め込んで置く。そして本格的に実装する時に、NSLocalizedString()で書き換えるのだが、それを忘れることがある。

はじめからNSLocalizedString()でローカライズする準備が出来ている文字列は、Localizable.stringsファイルに入っているので忘れずに各国語に翻訳できるが、それをしなかった文字列は忘れられる。実際に動作させて確認するときにも、テストケースが各文字列リソースが正しく表示されているかどうかという視点で作ると、そのテストケースに入らなかった文字列は確認できない。ちゃんと全画面、全機能を全言語に対して実行しなければならない。

同じような間違いだが、GUI上のUILabelの文字列をコードで設定するようにしていた。これはカスタムのUITextFieldCellでラベル部分の文字列は当然行によって違うのでコードで設定するしかない。

ところが、試しに実装してみようと思ってやっぱりNSLocalizedString()を使わずに、ソースコード中に直接表示する文字列を書いてしまった。だが、実装を進めるうちにそのセルは1回しか使わない。他の行ではまた別のカスタムセルを使うことになったのだ。

実装が終わって、国際化するときにカスタムセルは1箇所でしかつかっていないので最初に外部から文字列を設定するという設計を忘れてしまい。xibファイルを国際化してしまう。そして作られた.stringsファイルを翻訳。だが、全然表示が変わらない。昨日書いた方法でクリーンビルドしても変わらない。おかしいなあ、おかしいなあ。と思っていると、直接UILabelに文字列を設定しているコードを見つけるというわけだ。

途中で設計や実装方針が変わったせいもあるが、結局のところ仮実装だろうがなんだろうが、GUIやファイルなど外部に出力する可能性のある文字列をプログラムコード中に各場合には手を抜かず必ずNSLocalizedString()を経由する。後で忘れてしまう可能性があるし、全体を探す手間もあるし。これを徹底すれば今回のような翻訳し忘れは起こらない。

これにつきる。

Localizable.stringsにも転記する手間を考えたら、2カ所入力する手間がかかると思うかもしれないが、NSLocalizedString()はもしLocalizable.stringsファイルに対応する文字列がなければ第一引数そのものを返すので、場合によってはLocalizable.stringsファイルへは何も書く必要がない。

翻訳し忘れるかも?NSLocalizedString()関数が使われている箇所を抽出することはそれほど難しくないので、忘れた文字列があるかどうかはすぐに見つけ出せる。

Appleが提供している genstrings というコマンドを使うとソースコードから簡単に.stringsファイルを作成できる。

$ genstrings *.m


上記コマンドはカレントディレクトリにあるObjective-Cソースコード中のNSLocalizedString()から文字列を抽出して、カレントディレクトリにLocalized.stringsというファイルを作って書き出してくれる。

なお、私は時々

NSString *aString;
if ( flag ) {
aString = @"on";
} else {
aString = @"off";
}
return NSLocalizedString(aString, nil);


みたいなコードを書いてしまうことがあるのだが、こういうのは抽出できない。それにコメントもちゃんと書いておかないと抽出したファイルでの文字列の用途がわからないので翻訳を他の人に依頼する場合などに困ってしまう。だから上記例のnilもよくない。
posted by 永遠製作所 at 16:29| 東京 ☁| Comment(0) | TrackBack(0) | iPhone/iPod touch | このブログの読者になる | 更新情報をチェックする

2015年02月21日

ローカライズが反映されない


アプリケーションの初期開発時。UI実装は1言語でのみ行いある程度実装が終わってから、他言語対応をすると思います。

xibまたはstoryboardを国際化して、ローカライズstringsファイルの文字列を翻訳。そしてビルドして実行。ところが、なぜかローカライズ文字列が反映されないことがあります。

シミュレータなどのデバッグ用のビルドでは、コンパイルしたあとオブジェクトファイルを中間作業フォルダからアプリケーションバンドル内に複製するときにアプリケーションバンドル内にあるファイルに上書きする形で複製している。

このため、国際化したxibまたはstroyboardファイルと、国際化していない同じファイルが別々に存在してしまう。アプリケーション実行時にこの国際化していない古いGUIファイルを読み込んでしまうため、ローカライズしたものを使ってくれない。

この場合の対処方法は、いったんクリーンビルドすること。そして再度ビルド&実行。これでいけるはずなんだけど、シミュレータに複製するときにも上書きコピーするようなので、シミュレータ内のアプリも削除しておくことが必要。
ラベル:IOS デバッグ Xcode
posted by 永遠製作所 at 15:59| 東京 ☀| Comment(0) | TrackBack(0) | iPhone/iPod touch | このブログの読者になる | 更新情報をチェックする

2015年02月15日

[iOS] Unable to run app in Simulator

開発中に突然エラーに遭遇。


Unable to run app in Simulator

An error was encountered while running (Domain = FBSOpenApplicationErrorDomain, Code = 4)


error1.png

Xcodeでビルドに成功しているし、前日までは普通に実行できているのにシミュレータでの実行に失敗するようになってしまった。原因がわからないが、とりあえずクリーン(Product > Clean)してみたが、結果は同じ。

そこで今度はシミュレータのほうをリセット(iOS Simulator > Reset Content and Settings...)する。

error2.png

これでなんとか実行できるようになった。

シミュレータ内部のデータに不整合ができてしまって実行できなくなっていたよう。シミュレータのリセットをすると、それまでアプリで使ったデータが消えるなど影響があるが、シミュレータ内にあるのでデバッグ中のデータなのでいつ消えても大丈夫なようになっている。
ラベル:IOS デバッグ
posted by 永遠製作所 at 17:34| 東京 ☀| Comment(0) | TrackBack(0) | iPhone/iPod touch | このブログの読者になる | 更新情報をチェックする

2015年02月08日

バイナリ形式プロパティリストを読むために

Xcodeではソースコードの他に、nibファイルや設定ファイルもコンパイルされてバイナリ形式のファイルに変換されてしまう。

実行形式のアプリケーションの中身が適切なものになっているかどうか確認する必要があるとき実装時のテキスト形式のままであればテキストエディタで開いて中を見ればそれだけですむので楽なのだが、コンパイルされてしまっているのでちょっと工夫が必要。

ターミナルで実行できるコマンドがある。plutilだ。


$ plutil -convert xml1 Localizable.strings
$ plutil -convert binary1 Localizable.strings


上でバイナリ形式のファイルをXML形式に変換。下で元に戻している。

注意事項としてこのコマンドは上記の方法だと対象とするファイルを直接書き換える。だからファイルを変更したくないときにはファイルを別の場所に複製して行うか、下記のように出力ファイルを指定する。


$ plutil -convert xml1 Localizable.strings -o Localizable.xml


なお変換可能な形式は

  • XML形式…xml1

  • バイナリ形式…binary1

  • JSON形式…json


の三つ。

上記のように確認したかったのはstringsファイルなので本当はstringsファイル形式のほうがよかったのだけど、ないので仕方なくXMLバージョン1形式に変換した。

他のProperty Listでももちろん使用可能。
posted by 永遠製作所 at 20:20| 東京 🌁| Comment(0) | TrackBack(0) | iPhone/iPod touch | このブログの読者になる | 更新情報をチェックする

2014年12月23日

【書籍】「レベルアップ Objective-C iOS7/Xcode5対応」沼田 哲史



本書のはじめにには「Xcodeを使ってiOSまたはOS X用の簡単なアプリケーションをいくつか書いたことのあるObjective-Cプログラミング中級者以上の方々を対象としております」と書かれているが、中級者というのは本書に書かれているようなことができる人のことだと思うのです。

が、言葉の定義は別としてある程度アプリの開発ができるようになった人が、より効率良く、また品質の高いアプリケーションの開発をするためにObjective-C的なコードを書き、開発ツールを使いこなすために知っておくといい内容をまとめている本だというのは間違いない。

Xcodeの効率的な使い方は知っているようでいて使いこなせていない人も多いだろう。Xcodeの機能は本書で書かれているのはほんのさわり。もっと豊富で開発効率を高めるのに役立つ機能はまだまだもっと沢山あるのだ。それでもここに書かれている程度のことは使えるようになると開発効率は高まる。興味のある人は自分でメニューを色々触ってみてもいい。Xcodeの解説本はXcode5向けで少し違う部分もあるが複数出版されているので参照してみてください。

その他、デバッグの手法、バージョン管理、テスト駆動開発の手順、リファクタリングや、メモリ管理、マルチスレッドなど。知っておくべき基本的な事柄がならぶ。メモリ管理やマルチスレッド(ブロック記法、GCD、オペレーションキューなど)は現代的アプリケーションの開発ではなくてはならない手法だ。どれもさわりだけの記述だが、こういうことを知っていれば実際に使ってみる機会ができてより深く知りたければそのトピックについて調べることもできる。

ただ闇雲に動くプログラムを作る段階から、このような手法を使えるようになれば開発効率も高まり、より高度なアプリケーションの開発もできるようになるのではないだろうか。

ところで、本書ではデータ管理手法として、Core DataとiCloudに一章を割き多くのページ数使って解説している。それぞれサンプルアプリもステップバイステップで開発して細かく使用方法を述べている。だが、これらは特定のフレームワークの使い方であり本書の他の部分で記述されている内容とは異なる内容のようで違和感がある。

著者の意図としては、データの永続化は少し大きなアプリケーションでは当然重要なことになるし、iOS的なアプリケーション開発では、単純に保存するだけではなく多様な方法を考えるべきということなのかもしれない。特にiCloudについては様々な機器の連携が必要なiOSアプリでは重要な選択肢なのかもしれない。

なお、本書はiOS7/Xcode5対応となっており、現在のiOS8/Xcode6よりは古いバージョン向けのものになっています。ですが、述べられている内容は基本的なことがらばかりで決して古い内容ではなく現在でもなんら変わりなく使える技術です。Xcodeのメニューなどの位置は少し変わっているかもしれませんが、4から5ほどの違いはないはずです。

ちなみにここ最近紹介している本は1年前頃に出版された本だと気がついているでしょうか?そう昨年の年末年始あるいは春休み時期に時間をとって勉強しようとしていた本です。1年前はやり気だけあって時間がとれなかったものを今頃になって時間ができたので読み進めている次第です。
posted by 永遠製作所 at 15:05| 東京 ☀| Comment(0) | TrackBack(0) | iPhone/iPod touch | このブログの読者になる | 更新情報をチェックする