今回からプログラム的な事も書いてみようと、まずは第一回。

Mac OS Xは言語別にアプリケーションを用意しなくても、１つのパッケージで多言語に対応している。対応していると言うか、作り手が対応させるのだけれど、例えばホームページなどで日本語、英語などのサポートページを用意している場合、起動している言語でジャンプさせるURLを指定させたいと思う。

まず頭に浮かぶのが、ローカライズしたNibファイル別にアクション先を変更。例えば、

- (IBAction)goHomePage_ja:(id)sender{


　日本語ページへ


}


- (IBAction)goHomePage_en:(id)sender{


　英語ページへ


}

これだとスマートじゃ無いし、接続が面倒なので、このようにする。

- (IBAction)goHomePage:(id)sender{


    NSURL *url;


    NSUserDefaults *def = [NSUserDefaults standardUserDefaults];


    NSArray *languages = [def objectForKey:@"AppleLanguages"];


    NSString *prefLang = [languages objectAtIndex:0];


    if ([prefLang isEqualToString:@"ja"]){


        url = [NSURL URLWithString:@"日本語ページURL"];


    }else{


        url = [NSURL URLWithString:@"英語ページURL"];


    }


    [[NSWorkspace sharedWorkspace] openURL:url];


}

これで１つのアクションメソッドで、日本語以外は英語ページへジャンプするようになる。

新しく言語を追加したら、

}else if ([prefLang isEqualToString:@"fr"]){


    url = [NSURL URLWithString:@"フランス語ページURL"];


}


とすればOK。

さっきからなんかガクブルするなぁ・・・と思ってたら、冷房つけてた(笑)

書きかけの記事が有ったのでこの際そのまま投稿してみる。

NSDictionaryをdescriptionでプロパティ形式の文字列に変換して、ファイルに書き出し、NSStringのpropertyListで元に戻そうとしてたけど時々エラーが返ってくる。ちなみにiPhone。
OS Xアプリの方でも同じ処理で書き出したり、読み込んだりしているけど、問題が無い。なので、半分パニック。

パースの所でエラーになっているので、[(NSString *) propertyList]を @try @catch でエラー内容をNSLogに書き出した所、NSDictionaryをdesctiptionした文字列の、最初の「 { 」と最後の「 } 」が問題箇所らしい。Old-styleがどうとか...

とりあえずdesctiptionした後に、1行目と最後の行を削除して保存するようにした。
これでパースエラーはおこらなくなったけど良いのかな...

今日、Twitterの @iphone_dev_jp にローカライズの質問が上がっていたので、そういや急に対応してと言われた時に、確認するの面倒だったなぁと思い出したので備忘録を。

da : デンマーク語
Dutch : オランダ語
English : 英語
fi : フィンランド語
French : フランス語
German : ドイツ語
Italian : イタリア語
Japanese : 日本語
ko : 韓国語
no : ノルウェー語
pl : ポーランド
pt_PT : ルーマニア語
pt : ポルトガル語
ru : ロシア語
Spanish : スペイン語
sv : スウェーデン語
zh_CN : 中国語
zh_TW : 台湾語

pt_BR : ブラジル系ポルトガル語 (追記 2011/04/24)

Appleのリファレンスによると、ここに従っているようです。

上の一覧は、Finder.appの中を漁って調べたものです。
まあ、これだけ有れば普通は十分かと。

そして追加方法ですが、Xcodeのローカリゼーション追加の項目にはデフォルトで4言語(English, Japanese, French, German) しかリストに出てきません。

なので、自分で入力します。

そしてでき上がったファイルには元の言語がコピーされているので、そこを修正するだけです。

nib、xib のローカライズは作ってしまった後では、元のGUIを変更した時に自動で変更されないのでかなり面倒。
iOSでは、xibをユーザーの方がローカライズして送ってくる事はまず無いので、xibをローカライズせずにラベルなどアウトレットで繋いでLocalizable.stringsでViewの生成時に変更するようにすると楽になります。(あまり多いと時間が掛かるので注意)

Sparkle、物凄く便利なのですが、１回組み込むとフレームワークのバージョンを上げるだけの作業になるので、新しいアプリケーションを作った時に導入方法を忘れてしまったりします。
今回は自作ソフトで、ソフトウェアの自動アップデートを可能にするフレームワーク、Sparkleの導入の仕方を忘備録がわりに。

まず、 http://sparkle.andymatuschak.org/ の "Get Sparkle 1.5 b6" をダウンロードします。(現時点では1.5 b6ですが、新しいバージョンをダウンロードします)
ダウンロードしたZipファイルを解凍すると、ドキュメントなどが入っていると思います。
軽くドキュメントに目を通しておきます。

この中で、必要なのは、"Extras" と "Sparkle.framework" です。

"Sparkle.framework" をプロジェクトのディレクトリの中にコピーします。(Frameworkフォルダを作ったり)

続いて、Framework フォルダに追加した Sparkle.framework を Xcode のプロジェクトに追加します。

ターゲットのアプリ名を右クリックして、「追加」「新規ビルドフェーズ」「新規コピーファイル」選択します。

情報ウインドウの、デスティネーションをフレームワークにして閉じます。

「ファイルをコピー」が出来たら、Linked Framework から Sparkle.framework をドラッグアンドドロップして追加します。

ここまで出来たら、次は Window などが有る xib(nib) を開きます。
Library から Object を 追加して Class を SUUpdater にします。

Windowへボタンを配置し、先ほど作った Updater(Object) へ Action を繋げIBは閉じます。

次はXcodeを離れてFinderで作業します。
ダウンロードして解凍したフォルダの Extras→Signing Tools を開きます。
Terminal.appを起動して、ruby と入力し、スペースを入力した後、
Signing Toolsフォルダの中にある、"generate_keys.rb" をTerminal.appへドラッグアンドドロップしてreturnキーを押します。

If you lose it, your users will be unable to upgrade!　が表示され、プロンプトが表示されたら、ホームディレクトリに移動し、"dsa_priv.pem" と "dsa_pub.pem" が出来ている事を確認します。
(この二つは無くすと後々厄介ですので、 忘れないように保存しておきます。)

続いて、" dsa_pub.pem" を プロジェクトのディレクトリのResourcesフォルダへコピーし、Xcode の Resources にも追加します。

追加出来たら、Info.plist へ必要な情報を追加します。
追加する内容は、Keyが「SUPublicDSAKeyFile」 Valueが「dsa_pub.pem」と Key が 「SUFeedURL」Valueが「 web上へ置くxmlのアドレス」です。

InfoPlist.strings を開き、SUFeedURL = "web上へ置くxmlのアドレス";　を追加します。
(例：SUFeedURL = "http://www.hoge.jp/AppName/Updates/en/AppName.xml";

これでアプリケーション側は終わりです。後は xml と表示する html を作成し、Webへアップロードして終わりです。

最後に、アプリケーションのアップデートの際は "dsaSignature" を新しくする必要があります。
ビルド後にZip圧縮したら、ターミナルで
ruby[S]Extras/Signing Tools/sign_update.rb[S]zipのPath[S]保存している dsa_priv.pem
で dsaSignature を作成しWeb上のxmlを変更します。
※[S]はスペース

Xcodeのバージョンが上がったり、Sparkleで大きな変更が有った場合は、記述通りにいかないかもしれませんので、ご注意を。
また、今回の組み込み方法はデジタル署名を使用した例です。

タイトル通りなのですが、もしかすると自分だけかもしれません。

aLaunch 4.2.3のリリース直後に発覚したのですが、ユニバーサルアプリではなく、Intel CPUオンリーのアプリケーションを気付かずリリースしていました。

対応OSなどの調整意外は特に触らない部分なので、メールを頂いた時はビックリ。

恐らくXcode 3.2.6にする前のバージョンでは普通にユニバーサルアプリをリリースしているので、Xcode 3.2.6からだと思われます。

自分の他のプロジェクトを見ると、全てのプロジェクトがリセットされているみたいなので、忘れないうちに変更しておきました。

下の設定は対応OSが10.5 以降で、Universal, 32bit/64bit アプリケーションの例です。

アーキテクチャの値をクリックし、「その他」を選択して追加していきます。

ちなみにこれはリリースビルド例で、デバッグビルドはIntelオンリーで設定します。
Xcodeのバージョン上げた時は次回からはきちんと確認しないと駄目ですね。

新しいアプリケーションを、Mac App Store に提出しました。
無事審査に通れば良いのですが。

その話は置いといて、Mac App Store に アプリケーションを Submit 後、「PPCバイナリを含めてはいけませんと」即メールが来て即リジェクトされました。
4回も(笑) お恥ずかしい...

メールの文を見る限りでは、ビルド設定を見直し、アーキテクチャを 32bit Intel と 64bit Intel にしなさいとの事。
設定見てもスタンダードの 32/64 bit Intel になってるし、これを別けたりしながら4回も Submit しちゃいました。結果4回とも同じリジェクト。

メールの文面の一部でグーグルさんに聞いてもこれと言って解決するページはあらず、イライラしてたのですが、冷静になって考えると、Growl のフレームワークを追加してたのを思い出し、アーキテクチャを見ると Universal になってました(当たり前ですが)

そして再度検索すると、ドンピシャなのがありました！ここ

実は3月にリリースした QuickCopy mini も Growl のフレームワークを使用しています。
その時は今回のような事は無かったので、余計に混乱しました。
4月以降にチェック関係が変わったのだと思われます。

理由が解れば対処は簡単、上記ページに有るように、ターミナルを開き、

lipo -remove ppc (Growl.framework のパス ドラッグ&ドロップでOK) -output Growl

で Intel バイナリのみの Growl を書きだし、元のファイルと入れ替えるだけです。

無事、レビューを待てになりました。