rdotm - Resource access code generator for Objective-C

Qiitaにも投稿しましたが、
iOSアプリ開発でもAndroidのR.javaのような仕組みでリソースに安全にアクセスする仕組みを作りました。
rdotm - GitHub

R.mというファイルを自動生成し、XMLに定義した文字列を「文字列ではなくコードで」アクセスできるようにします。

“R.java iOS”などと検索すると、
以下のように海外でも探している人がいるようなので(3年前ですけどね…)
Equivalent to R in iOS - Stackoverflow
試しに英語でも書いておこうと思います。

---

Recently, I developed the tool rdotm(R.m) for iOS app development.

What’s this tool?

rdotm(R.m) is the Objective-C resource definition generator like Android app’s R.java.
See the following demo especially auto-completion of string_*.

Objective-Cコードのフォーマットチェック

Objective-CにはLintツールとして既にOCLintがあるが、
OS Xでなくても手軽にチェックできる仕組みが
欲しいと考えて作ってみた。
fint

以前にRun Scriptを利用して簡単なチェックができる
というエントリを書いたが、これをツールとして整備したもの。

例えば以下のように、普通のビルドエラーと同じように表示できる。

ちなみにツールはGo言語製。
Go言語環境をセットアップしてあれば、以下でインストールできる。

go get github.com/ksoichiro/fint

lint用のTARGETを追加し、Build Phaseを追加してRun Scriptにfintを
呼び出す設定を記述する。
以下は、設定例。

コマンドラインからも実行可能。

[iOS][Xcode] Xcodeで簡易フォーマットチェック

前回のOCLintでXcode5プロジェクトのObjective-Cソースコードを静的解析で、コマンドの出力を整形すればソースコード上に警告表示できることを知ったので、簡単なフォーマットチェックができないか試してみました。

作業はXcode 5.0.2で行なっています。

まず、Targetを追加します。
iOS > Other > Aggregateで作成します。

このTargetに、メニューのEditor > Add Build Phase > Add Run Script Build PhaseでScriptを追加します。
Scriptには以下のようなものを記述します。
ここでは、elseと括弧の間にスペースを入れる、という簡単なチェックをしてみます。

[iOS][Xcode] OCLintでXcode5プロジェクトのObjective-Cソースコードを静的解析

Xcodeでは標準でもAnalyzeでClangによる静的解析ができますが、OCLintというツールでさらに多くのチェックができます。
http://oclint.org/

Xcode 5.0.2で試したところ、上記サイトで説明されている手順では導入できず苦戦したので、うまくいった手順を記録しておきます。

まず、環境です。
マシン：Mac Book Air
OS：OS X 10.9.1
Xcode：Xcode 5.0.2

以下を導入していきます。
（このうち自分の環境で元から入っていたものの導入手順は割愛します）
OCLint：0.8
xctool：0.1.14
CMake：2.8.12.2

Python：2.7.5

Git：1.8.3.4

Subversion：1.7.6

では、導入手順です。

[iOS] APNs証明書の更新手順

今さらブログに書くまでもないかもしれませんが、
少し前にAPNsの証明書をアップデートする方法について調べた手順です。
誰かの参考になれば幸いです。
ただし、あくまで検証した時のメモですので、各自の責任でご利用ください。
(現に、これを調べてからここに公開するまでの間に若干動きが変わっていますので…)

[Inkscape][Android][iOS][Mac] 全サイズのアイコンファイル生成ツール

MacでInkscapeを使ってSVGのアイコンを作り、AndroidとiOSアプリを開発している人向けのツールを作りました。
タイトルの通り、1つのファイルから全サイズのアイコンファイルを一括生成します。
(使う人いるでしょうか…もしいればコメントなど頂けると嬉しいです。)
https://github.com/ksoichiro/export_icons

Illustratorとaiファイルや、Photoshopとpsdファイルではありません。

Inkscapeとsvgファイルです。

(GIMPとxcfファイルでもありません。)

毎回個別のサイズを入力しながらエクスポートして用途ごとにリネームしている、という方には役立つと思います。

実行するにはMac OS XとInkscapeが必要です。
InkscapeでSVG形式のアイコンファイルを用意し、ターミナルで

    export_icons -i Icon.svg -o output

と実行するとoutputディレクトリへAndroid用iOS用のアイコンを一括で作ります。
AndroidとiOSでは違うSVGを使ってる、という場合は

    export_icons -i ic_launcher.svg -o output -t Android

    export_icons -i Icon.svg -o output -t iOS

とすると個別に生成できます。

詳しくは以下のREADMEをご覧下さい。 https://github.com/ksoichiro/export_icons/blob/master/README.ja.md

iOS: UIScrollViewをStoryboardで使うときのスクロールのさせ方

基本的なことかと思いますが、しばらく分からず時間を費やしてしまったのでメモします。
UIScrollViewを使って何となくStoryboardでパーツをドラッグ＆ドロップするだけで作っていったところ、スクロールしませんでした。
以下の構造を想定します。

UIView
└UIScrollView
　└// 実際に表示する部品

以下はStoryboardでのイメージです。

サイズにフォーカスしてStoryboardの内容を掲載します。

iOS App Store用とAd Hoc用のプロビジョニングプロファイル

常識なのか分かりませんが、iOSアプリ開発でのプロビジョニングプロファイルの管理と使い分けに関するメモです。

プロビジョニングプロファイルには大きく分けて

• Development
• Distribution

の2種類があります。(2013/4/24現在のiOS Dev Center仕様)
DistributionにはさらにApp Store用とAd Hoc用があります。
自分の理解では

• Developmentは、MacにiPhoneを接続して直接インストールする際の署名に使用するプロファイル
• DistributionのうちApp Store用のものは、App Storeに提出するバイナリ用のプロファイル
• DistributionのうちAd Hoc用のものは、Ad Hoc配信する場合のバイナリ用のプロファイル

という程度のものでしたので、ビルド設定までをバージョン管理しておくとすると

• リポジトリのmasterブランチではApp Store用のプロファイルで署名する設定で常に管理
• 開発・デバッグ・テスト時は一時的にDevelopment/Ad Hocに切り替えてビルド。App Store用でReleaseビルドすると実機に直接インストールはできないし、Ad Hocでインストールしようとすると失敗するし(端末のID情報がないので)。。。
• 一時的に切り替えとはいえ、テストしたときの状態を完全に再現できる状態にしておきたいので、(Developmentはともかく)Ad Hocに切り替えたものを仕方なく別のブランチを作って残しておく
• 結局App Storeに提出するバイナリファイルはテストの完了後に作るしかなく、App Store申請前にテストしておくのは無理？App Storeにリリースされて初めて動かせるなんて恐すぎる…

と思っていました。
が、App Store用のプロビジョニングプロファイルを指定してビルド/アーカイブし、アーカイブの一覧からAd Hoc用にDistributeするときに Ad Hoc用のプロビジョニングプロファイルを指定する(端末のID情報が入っていればDevelopmentでも良い？)、ということができるのですね・・。
なので、少なくとも配布に関する情報の差異があるとはいえ、アプリの本体部分はそのままApp Storeに提出できる状態の、限りなく本番に近いものを事前テストできる訳です。 />
アプリの仕様によっては接続先のサービスが本番用/テスト用などの使い分けがあり、必ずしもバージョン管理下のもの全てを 本番と同じにしてテストする訳にはいかないと思いますが、最終確認としてそうしたテストができるのが分かったのは 自分の中では大きな発見なのでした。

Androidの場合は、署名さえ同じであれば良いので事前に動かしたAPKファイルをそのままストアに登録できるので、AppleのApp Storeの仕組みが非常に厄介に思えてしまいました。
Androidアプリを開発してきてiOSに取り組むと、言語の違いよりもこうした仕組みの差の方が 馴染むのに時間がかかるかもしれません。。。

iOS ステータスバーの扱い

「EverForm for iOS」をiPad対応にした際に躓いたポイントです。

iPhoneでは起動画面(Default.png)にステータスバーの高さが含まれています。
(320 x 480 / 640 x 960 / 640 x 1136)

しかし、iPadでは含まれていません。(768 x 1004 / 1536 x 2008)

これは画像のサイズだけの問題ではなく表示位置にも影響します。

iPhoneではスクリーンサイズの起動画面画像を用意しますがステータスバーの分は隠れてしまいます。
一方でiPadはステータスバーの高さを除いた画像なので、ステータスバーの下から画像が表示されます。
単に起動画面を表示する場合は問題になりませんが、その後の画面とうまく繋げようとすると この差が重要になります。

実際やろうとしたことは以下の二つです。
[1] 起動画面の後、画像の一部を重ねてログイン画面を表示する。
[2] ログインした場合は起動画面をフェードアウトして別画面へ遷移させる。

[1]を実現するには起動画面の画像と、ログイン画面に表示させる画像で、重ねたい部分を同じ位置に描画すれば良いと考えると思います。
iPhoneではうまくいくのですが、前述の通りステータスバーの高さが含まれないiPadではうまく行きません。 合わせるためには、iPad用起動画面(Default-Portrait~ipad.pngなど)の重ねたい部分をステータスバーの高さだけ下にずらします。
(iPad mini用画像(Default-Portrait~ipad.png)なら20px、iPad(Retina)用(Default-Portrait@2x~ipad.png)なら40px)
ログイン画面の画像を修正する方法もありますが、こちらは特に合わせようとしなくてもiPhone/iPad同じレイアウトになるので変更しない方が良いでしょう。

[2]を実現する場合には、単に起動画面の画像をアルファ値を0にするようなアニメーションで表示すれば良いですが、やはりiPadの場合は画像の表示位置をステータスバーの分だけずらす必要があります。

ということで、まとめると以下のような感じです。

• iPad用起動画面(Default.png)はステータスバーの高さが含まれないので、iPhone用の画像を基準にするなら上の20px(Retina用は40px)が欠けたような画像にする。
• 起動画面を別の箇所で表示させる場合は、iPhone/iPadで表示開始位置(frame.origin.y)をステータスバーの分だけずらす。

iOS ローカライズが失敗してNSLocalizedStringのキーが表示される

致命的なミスです。
先日リリースした「EverForm for iOS」ですが、英語のローカライズに失敗した状態でリリースしてしまいました。
アップデート版は先ほど申請しました。

何が問題かというと、NSLocalizedStringの第1引数に与えたキーがそのまま表示されてしまいます。 同じ問題にぶつかった人が検索しやすいように、キーワードを挙げておくと… NSLocalizedStringのkeyが表示される、ラベルのまま表示される、使われない、といったところでしょうか。

EverForm for iOSの場合、言語をEnglishにしてビルド、実行すると発生しました。

最初はAppStore用のプロビジョニングプロファイルを使用した場合でのみ発生する事象なのかと疑ったのですが、通常のビルドでも発生しました。
実は開発中にローカライズの確認をしていたときも何度か発生していたのですが、 2回ビルドして実行すると解消されたため、Cleanするだけでは前回の結果が消えないものがあるのだと思いあまり気にしていませんでした。 結果的に、原因はLocalizable.stringsがプロジェクト内に複数あったことでした。

原因が分かったきっかけは、あれこれ調べた結果以下のコメントを見つけたことです。

Check if you have more than one Localizable.strings in your project. Merging them into one solved it for me.
http://stackoverflow.com/questions/6709350/xcode-localized-string-not-loaded

それから「2回ビルドすると解決する」という事実、
JapaneseとEnglishのローカライズされたファイル数が違う、
ということでした。
ローカライズされたファイル数はプロジェクト(XXX.xcodeproj)の「PROJECT」＞「INFO」＞「Localizations」で確認できますが、英語の方が1つ多かったのでした。
それが何かというと、使用しているEvernote SDKのライブラリ内に存在している英語のLocalaizable.stringsです。
ビルドすると、このファイルとメインの(元々自分で用意した)en.lproj/Localizable.stringsが交互で適用されるようで、マージはされません。
そのため、ビルドした1回目はNSLocalizedStringのキーがそのまま表示され、2回目は正常に表示されます。
開発中は日本語でデバッグし、英語ではローカライズ文字列の確認をする程度だったため、同じコードのまま3回以上ビルドすることがなく気付かなかったのですが、試しに3回以上ビルドしてみると、ローカライズ失敗、成功、失敗、…と繰り返されました(つまり確かに二つのLocalizable.stringsが交互に適用されています)。

ちなみにXcodeのバージョンは4.6(4H127)です。

国際化のための常識なのかもしれませんが、普通に書籍を数冊読んだだけでは知らない知識でした。。。

もしかするとこういった状態になるのはさらに条件があるのかもしれませんが、
同じような事象に遭遇された方の参考になれば幸いです。

EverForm for iOS

iPhoneアプリ『EverForm for iOS』をリリースしました。
https://itunes.apple.com/jp/app/id630680690
Android版を既にリリースしていますが、今回はそのiOS版です。

EverFormは、Evernoteでよく使うノートの形式をフォームとして管理するアプリです。
Evernoteの使い方は様々だと思いますが、Webのクリップだけではなく、毎日何かの記録をするのに使っている人もいるのではないでしょうか。 EverFormは、そんな人におすすめできるアプリです。

• ノートの書式(見出しなど)を保存しておく
• ノートの作成時に作成日時を自動的に埋め込む
• ノートの作成時の保存先ノートブックを指定しておく(*)
• ノートの作成時に付けるタグを指定しておく(*)
• チェックボックスを埋め込んでおく(*)

といったことができます。

(*)実は、前述のAndroid版ではまだ対応できていないのですが、近々対応する予定です。

なお、ご利用になるにはEvernoteのアカウントが必要です。

iOS UINavigationBarとステータスバーの高さを除いた画面サイズ

UINavigationBarの高さとステータスバーの高さを除いた、実際にコンテンツとして表示できる領域を取得する方法のメモです。 ViewControllerの中に書いています。

availableWidth, availableHeightがちゃんと取れているかどうか、確かめるために少し余白を加えて背景色をつけたUITextViewを表示してみました(iPhone4S)。