iPhoneローカライズのメモ

いろんなところに情報があるけど、自分でやった分のメモ。

まず、何も考えずにアプリを作る。
だいたい形ができたところで、文字列 (@"～")を指定している部分は

NSLocalizedString(@"～", @"")

とする。
その後おもむろに、コンソールを立ち上げて

genstring (.mファイル)

とすると、カレントディレクトリに Localizable.String ファイルができるので、en/ なり ja/ なりコピーする。
これでソース中でたとえば、

NSLog(@"Connection failure!!");

なんて書いてる場所を

NSLog( NSLocalizedString(@"Connection Failure!!", @"") );

として、ja/Localizable.Strting に

"Connection Failure!!" = "接続できませんよ！"

なんて書くと、端末の言語設定が日本語になっていれば、"接続できませんよ！"とログに吐きだされる。
注意点としては、 genstring の挙動で、Localizable.String が既にあっても上書きしちゃってマージしてくれないので、Localizableファイルを作成するのは遅ければ遅い方が楽ってこと。
Localizableファイルがなければ、NSLocalizedString はそのままの文字列を出力してくれるので、問題は起きない。

以上。

iPhoneで撮影した画像をライブラリに保存する

情報がなかなか見つからんかった。
http://iphone.longearth.net/2009/02/15/%E3%80%90iphone%E3%80%91%E7%94%BB%E5%83%8F%E3%82%92%E3%83%95%E3%82%A9%E3%83%88%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%81%AB%E4%BF%9D%E5%AD%98%E3%81%99%E3%82%8B/

ここに書いてます。
撮影して加工するのは色々サンプルあるけど、それをサーバーに送るとか、WebViewを通してアップロードするとか、ライブラリに保存するとか、そういう点について説明してるサイトが少ないね。
まぁいいけど。

iPhoneアプリ

わからんなりに進めております。
基本的には、WEBサイトを独自のアプリで表示させて、機能的に足りない部分をアプリ側で補っていく感じにしようかと。
で、問題は、写真を撮ってそのままフォームで送信、とかしたいのね。
手間を省くために、基本的にアプリの表示画面は UIWebView で拵えようと思っているので、どうしたもんかと小一時間。

結局、以下のような雰囲気で実装することにしました。
・HTMLの画像に特殊なリンクをはる
・アプリ側でリンクのタップをフェッチ
・特殊なURLのリクエストであれば、アプリ側に制御をもらってカメラを起動する
・カメラなりライブラリなりから取得した画像をencodeしてjavascriptでHTMLに渡す
これで、たぶんサーバーにカメラ画像が送信できるはず。

Viewのコントロールがめんどくさくて時間かかるのが問題だな。何かバグが出たときに対応できる自信がない・・・

iPhone

あるアプリの製作を依頼されたので、これからiPhoneのアプリ製作を始めるわけですが、ここ数年ヌルいphpにどっぷりハマってしまっているので、対応できるかしら？

なんて思いながら、xcodeを立ち上げて触ってみる。

さっぱりワカランｗｗｗｗｗｗ
ん？え？outlet？？
はぁ？Delegate？？

日本語でおｋ。



っていうか、世の中に存在する優れた言語の体系、それを使って拡張してんだったら、命名を世の中の流れに合わせようよ？
ねぇ、Appleさん？

傲慢すぎるObjective-C の仕様に早速やる気なくしたぞ。

Geohash いまさらながら衝撃を受けました

iPhoneで four squareのような事をしたいと思って、手軽にGPS座標を扱える仕組みを考えていたところ、こういうのにぶち当たりました。

geohash.org

仕組みを読んで納得。これはすげぇ。
メカニズムについては、他の人が詳しく書いてるので、そちらを参照頂くとして、リンク置いときます。

GPS座標を短い文字列で扱えるGeoHashが面白い
Geohashのアルゴリズム
GeoHashのdecodeのアルゴリズムの解説します

下にいくほど詳細な説明になります。
これは、久しぶりに頭をハンマーで殴られたような衝撃ですね。
GPSの座標は、いわゆる座標として計算したりするのが当たり前だと思ってたんですが、そうじゃなかった。
地球を、南北に -90°～0と0～+90°、東西に-180°～0と0～+180°に分割して目的のエリアがそれぞれどちらに含まれるかを、0か1の2ビットで表現する。
それをどんどん繰り返して、最終的には 2cm×3cmのエリアにまで絞り切るわけです。
まぁそこまで絞り込んでも、必要となるデータ量が60bitっていうのも、なんだ。アレだ。エコですわ。

これから座標使うときはコレで決まりですね。
別にGPS座標じゃなくても同じアルゴリズムでいろんな情報のパッケージ化できそうだし。

ちょっと楽しい。

配布されているphp用のライブラリには、近隣エリアのgeohashを求める関数がなかったので、作りました。
ダウンロード

PEAR Spreadsheet::Excel::Writer で印刷範囲を設定

PEARのドキュメントが不親切すぎて、何度 PHPExcel に乗り換えようと思ったことか。
でも PHPExcel は php 5.2 以上じゃないとダメなんだって。
運用中のサーバーで phpのバージョン上げるなんてできるわけもなく、泣く泣く Spreadsheet::Excel::Writer でちゃんと印刷できるような設定の仕方を模索します。

結論から書くと、

// A4指定
$sheet->setPaper(9);
// 出力方向：横向き
$sheet->setLandscape();
// 改ページ指定（テスト）
$sheet->setHPageBreaks(array(35,51,84,115));
// 印刷倍率
$sheet->setPrintScale(63);
// 出力範囲の指定
$sheet->printArea(0,0,144,32);

こんな感じ。
ちょっと横に広くて、縦にも何行あるか良くわからんようなデータの出力で使いました。
縦がどんだけの行数になろうが、横幅をA4横の1ページに収めるための倍率っていうのは、だいたい一意に決まるもので、これはページごとに違うけど、いちいち計算で出すよりは、ページごとに固定の定数で持つのが、たぶん現実的な回答。

んで、あと問題になりそうなのは、setHPageBreaks() の挿入位置。
ある程度定型のシート出力なら、固定で持ってもいいんだろうけど、あいにく、表の行数は変動するし、どこで切ればいいかなんて、あらかじめわかるもんではない。

なので、セルを書き込むときに、ある程度、「この表の下で改ページ」っていうのを決めておくか、「○行出力したら改ページ」みたいにしとくべきかと。

出来上がったワークブックは客に見せるので、縦に合わせて印刷倍率を変えるような事は絶対できない。横は紙いっぱいに印刷したいしね。

最後の printArea() は、全体の、出力する範囲を決める関数。その中に何ページ含まれるかなんてことは関係ない。
最初、この関数で範囲指定すれば、そこが1ページとして出力されるのかと思って、ちょこっとハマりました。

出力しては、エクセルで表示、ってのを繰り返して、これ以外ないだろう、っていう最終形です。

参考までに。

analyticsの仕様が少しわかってきた

ここ とか ここ とか。

っていうのは、ちょっとしたリンクのテストで。
Analyticsは基本的にページに埋め込まれたjavascriptでどこから来たかとかいろんな情報をgoogleに送るわけですが、

あとは、phpのバージョンが 5.1 なので、PHPExcelが使えない事が判明。
PEARのExcelWriterでなんとか印刷範囲の設定を行います。


後は明日かきます。