Hatena::Groupiphone-dev

勢いでMacを買っちゃったんで iPhoneアプリ頑張って開発する

2010-06-22

Viewが表示されなかった時のチェック項目

| 21:20


Viewが表示されない原因には「Viewそのものにあるケース」、「ViewControllerにあるケース」、「その他」がある。

ここに書いたのはViewに原因があるケースを想定した、いわゆるポカミス用のチェックリスト。

分かってしまえば単純だが、チェック箇所が多いので見落としのないようにしたい。

※なお、ここではIBを利用せずにアプリを作っているケースを想定している。(IBを使った場合には、ソースファイル以外の場所を色々チェックしなくてはいけないのでバグつぶしで心が折れる。私には無理っぽい)

対象のSubViewそのものに原因がある場合

  1. インスタンスが作成されているか。
  2. frameを設定しているか。
    • layoutSubviews など他のメソッドでframeを設定する処理になっている場合には、そちらのメソッドが呼び出されているか。
    • frameに与える値が適当か、NSLogでチェック。(Viewの表示位置が正しくないケースなので、下記はレイアウト崩れにも共通して言える)
      • 親viewのboundsを元に対象viewの表示位置を算出している場合、親viewの座標に誤りがあれば、その子にも連鎖する。UIScreen mainScreen] bounds];なら確実。
      • viewのboundsは小刻みに変動するケースがあるので注意。デバイスの回転などで起きる自動レイアウト変更の影響による。
      • 加えて言えば、シミュレータのバグにも注意。デバイス回転を繰り返すと、挙動が怪しくなり、誤った値を返すことがある。(怪しいと思ったら、実機でテスト)
  3. 適切なViewにaddSubViewをしているか。
    • 親のViewが表示されているか。表示されていなければ、(対象Viewではなく)その親Viewに原因あり。

SubView:その他のチェック項目

  1. Viewのライフサイクルは正常に管理されているか。(一般的なメモリ管理のチェック項目。単純だが数が多いので注意)
    • SubViewには多くの簡易コンストラクタ(alloc ではなく、hogeWith~など)が用意されている。誤って手動でreleaseしていないか。
    • 手動retain、もしくはプロパティによる保持が行われているか。
    • 【プロパティによる保持】self.hogeButton = fugaButton; と書くべきところを、hogeButton = fugaButton;と書いてしまうケース。ドット演算子を利用しない場合にはインスタンス変数と解釈され、プロパティ経由でアクセッサが利用されず、retainが施されない。

親Viewに問題がある場合

ここでは、windowに直接addSubViewされる大元のViewに問題がある場合のチェック項目を羅列する。

  1. インスタンスが作成されているか。(上と同じ)
  2. frameを設定しているか。(上と同じ)
  3. windowにaddSubViewされているか。[window addSubView:hogeView];が必要。
  4. 対象Viewが他Viewの後ろに隠れていないか。[window bringSubviewToFront:hogeView];が必要。

View以外に原因

  1. Windowに原因
    • Windowが makeKeyAndVisible されているか。
  2. ViewControllerに原因
    • ViewController側で余計なこと(通知をフックして放置するなど)をしていないか。
    • 原因の切り分け、詳細状況の把握のために、強制的に描画イベントを発生させて(windowに対して addSubViewが行われたとき。画面のRotateが発生した。setNeedsDisplayメソッドあたり?)挙動を確かめる手もある。

2010-06-13

iPhone/iPadアプリ開発で実機テストができなくなった時のチェック項目一覧

| 00:45


一度は出来ていたのに、アプリが実機で走らなくなってしまった。

そんな時の確認項目一覧。

☆は、意外にこれで回復することってあるね という項目。

  • 確認作業
    • Xcode上の設定に誤りはないか確認
      • Xcode上で確認すべき項目は後述。
    • 原因追求のため、hello worldのプロジェクトを作ってみる。
      • 新規プロジェクトではiPad用のWindow-based Application。IBでは、Main WindowにHello Worldのlabelのみを貼りつけたものあたり。
      • もちろん、シミュレータ上で正常動作することを確認すること。
    • Xcodeのオーガナイザーから全てのprovirioningを削除し、Provisioning Portalから再度ダウンしたProfileデータをXcodeのオーガナイザーで設定する。
      • 期限切れによるProfileデータ入れ替えタイミングでトラブルが起きた時に、シミュレータでは動くけど実機では…という状況に陥るケースがあるようです。
    • Provisioning PortalでProfileデータを新規作成して、Xcodeのオーガナイザーで設定する。
  • 確認すべきXcode側の設定項目
    • 「プロジェクトの設定画面」
      • ターゲットデバイスがiPadになっていることを確認。
      • ProfileをiPad用に作成したものになっていることを確認。
    • 「info.plist」
      • Identifier codeがProfileで宣言したものと等しくなっていることを確認。
        • hoge.fuga.appnameと言った名前を指定していることが多い。
        • Profileで宣言しているIdentifier codeを知りたい場合には、iPadを接続した状態でXcodeのオーガナイザーを起動し、左メニューのiPadの項目を選択すると、画面右にIdentifier が表示される。

上記の他に私が経験した例では、下記のパターンがあった。

トラブルと言うより、実機テストの仕様を私が知らなかっただけのような気がするのだが、一応ご参考まで。

  • 番外編
    • iPadをつないだ状態で、Xcodeのオーガナイザーを開く。
    • iPadの項目を開き、Summaryの下段、Applicationの項目を見る。
    • 自分の作成したアプリのプロジェクト名が入っており、編集可能の状態になっている。
    • これを指定し、マイナスボタン(削除)を押下。アプリがアンインストールされる。
    • すると、新しいテストアプリがインストール可能になる。

2010-06-11

シミュレータを信用してはいけないケース - もんたメソッド開発(その3)

| 12:21

画面の回転に対応するための処理を書いていたが、シミュレータの挙動がおかしい。

Ctrl+→キー(画面を時計まわりに回転)、 Ctrl+←キー(画面を反時計まわりに回転)を何度か押していると、シミュレータは"どの方向を向いてますよ"の値を間違えて返すようになる。

不思議に思い実機でテストしたら、何も問題なし。きちんと見た通りの画面の向きを返してくれた。

色々なところで言われているが、シミュレータの挙動は参考程度に留めておいた方が良い。

2010-06-02

もんたメソッド for iPadの開発(その2)

| 03:30

構成

構成はWebViewの上に文字とシールをHTMLCSSで表現する方向でひとまず決定。

テキストとグラフィックで実装する場合に比べて表現力が劣ってしまうがここはHTMLのチカラを信じることにする。

画面プロトタイプ作成 「プレゼン実演画面」

プレゼン実演画面とはあらかじめ作成したプレゼン原稿をお披露目する画面のこと。

初日の数時間ほどで、原稿からシールを剥がすインタラクションを完成させる。久々のObjective-Cだが、WebViewを使ったおかげでリッチテキストの扱いは簡単、完璧。


画面プロトタイプ作成 「プレゼン原稿作成画面」

問題となる原稿作成画面のプロトタイプ作成へと移った。

……JavaScript弱いんだよなぁぁぁ。

以来、オライリー2冊とのにらめっこを続けている。

2010-05-30

もんたメソッド for iPadの開発(その1)

| 04:18

先日、出席したiPhone西東京勉強会

iPadを持参している人がとても多かったのだが、国内販売から2日目ということもあり、(私を含め)まだまだ使い方を模索している方が多かった印象を受けた。

iPadをTV番組のパネルボードみたいに使ったら面白くない?」

「会議、勉強会に出席したときに、自己紹介用のボードとして使えたら意外に便利じゃない?」

思いついてしまったので、速攻で作ってみようと思う。