UIAlertの出力方向を制御してみる。

UIAlertの出力の向きなんて、通常はあまり意識しない。
意識しなくても、常にそれっぽい向きに出力されているからだ。

しかし、意識せざるを得ない状況は確かに存在する。

それは、UIImagePickerControllerをカメラモードで表示した場合だ。
この場合、開発者の手の届く範囲は、cameraOverlayViewが精一杯と行ったところだろう。

しかし、問題がある。
cameraOverlayViewに登録したViewのViewControllerには、

shouldAutorotateToInterfaceOrientation:の通知が来ない。

つまり、cameraOverlayViewはiPhoneの向きに合わせて回転してくれない。

これを解消するために、notificationCenterから通知を受けて、

無理くり画面を回転させる方法をとる。

事の発端はここなのかもしれないが、

こうする事で、画面は回る。回るのだが、回転するのは画面だけだ。

ここで、他アプリ通知でAlertが表示されたりすると、

画面（cameraOverlayView）は横を向いているのに,

Alertは順方向で表示される。

されてしまう。

これを解消するための方法は、ある。

まず覚えておかなければならないのは、

Alertの表示方向は、stautsBarの位置に影響される。

（statusBarの表示／非表示には関係ない）

つまり、cameraOverlayViewの回転と同時に

[UIApplication sharedApplication].statusBarOrientationを使って

statusBarの位置を調整する。

これで、Alertの向きは正しく表示される。

カメラも安心だ。

iPhone ドック自作してみた。

au版iPhoneを入手して、すでに二週間ほどたつだろうか。

ようやっと、電話機としての使い勝手の違いにも慣れてきた。
日常の中に溶け込んでくると、次に気になってくるのが、非使用時の置き場所である。

通常は、５０cm x ４０cmという猫の額ほどの座卓の天板から、
mac bookの設置面積、マウスの操作スペース、はみ出し気味のメモ帳の置き場所を引いた
１５cm四方の空間に、dockコネクタを直指ししたiPhoneが寝そべっている状態である。

しかし、この状態だとアプリの動作確認時など、画面の確認が困難だ。
そうすると欲しくなるのが、iPhone用スタンドだ。

Amazonをぐるりと一回りすると、それこそ掃いて捨てるほどの
iPhone用スタンドが並んでいるが、
選ぶ上で重要になるのが、なにを求めているのかだ。

１：iPhoneを立てた状態で、Dockコネクタ接続が可能である事。
（これが出来ないと、開発をまともに出来ない）
２：Dockコネクタがスタンドと一体化しており、iPhoneの設置、取り外しが容易である事。
（ケーブルを別途接続するとかあり得ない）
３：背もたれ状の部品が付いていて、Dockコネクタへの負担が少なそうな物。
（気休め程度）
４：もちろん、ジャケットを装着した状態で使用可能であること。
５：iPod touchも無理なく設置可能であること。
追加１：角度調整が行えるとなお可
追加２：なるべく安価である事。

この５＋２点が選ぶ上でのポイント。
ここまで、要件を定義すると一気に対象が絞り込まれるのだが、
いまいち物欲をくすぐる一品がない。

必要な物品があるのに、欲しいものがない場合、とるべき道は一つだ。
作ってしまえ。

というわけで、週末の息抜きに作ってみた。

材料は、部屋に転がっていたプラ板とプラ棒のみ、
レシピは
1.5mmプラ板がA4版で１／３程度
5mm四角棒　一本、
３ｍｍ丸棒が１／３程度
原価的にはトータルとしては、３００円未満だろう。

ただし、今回はちょっと気合いを入れて塗装までがんばってしまったため、
サフ＋つや消しホワイト＋つや消しクリアのそれぞれスプレー缶を購入した。
塗料だけで1500円程度の出費。

標準のDockコネクタを受けの部分に設置すれば、ぐらつきなくしっかりとハマった。
長めに取った背もたれは、設計通りiPhone 4SでもiPod touchでも
コネクタ部分に負荷が架からないよう、しっかりと背中を支えていた。

おおむね、設計通りだったのだが、細かい反省点は多い。
・背もたれの角度調節機構にも、塗装をしてしまったため、受けの部分が狭くなってしまい
角度調整がホイホイと出来る状態ではなくなってしまったこと。
・部材のすべてがプラ板でのフルスクラッチであるため、強度的な面で不安が残る。
・短時間で一気に仕上げてしまったために、（よく見ると）塗装にムラがある。それどころか、所々ハゲてる。

とまぁ、いろいろ問題点は抱えながらも、実用的には問題ないレベルに仕上がった。
次の目標は、剛性と定置性の確保だ。
そうすると、次に手を出すべきは部材の金属化かなぁ〜。

Storyboardってなんデスカ？

Webピペットの改修作業をしていたら、見慣れぬ項目が目についた。

それが⇩の部分

「Main Storyboard」、こんなもん前からあったかしらと、我らがグーグル先生にお伺いを立てた。
どうやら、XCode4.2から追加になった新機能らしい。

結果から言うと、これは使えそうだ！

何が出来るのかと言えば、InterfaceBuilder（？）で画面遷移の管理が出来てしまう。
今までは、IBで画面レイアウトを決め、IBActionからコードによる画面遷移が必要であったが、単純な画面遷移ならもはやテキストエディタを開く必要はない。

まだ触りたてなので、新参のこの機能がどこまで出来て、どこから出来ないのか、見極めは出来ていない。
しかし、XCode4.2で新規にプロジェクトを生成すると、基本的にStoryboardが生成されるようなでの、今後の画面デザインは、Stroyboardメイン、という事になっていくのだろうか？

しかしこれを使うと、NavigationViewとTabViewの入れ子とかも特に考えなくても出来そうだ。

なるほど、こうやってプログラマの仕事は技術の産物に駆逐されてゆくのだなぁ。

ちなみに、既存のプロジェクトにもStoryboardを追加できそうだが、これに付いても既存の画面遷移コードとの兼ね合いが必要になってくるだろうと想像できるので、まだ試してはいない。
今後のメンテナンス性を考えると、さっさと移行しておいた方が楽かもしれないが……。

参考リンク：http://youtu.be/dGdELuDMxds

iPhone4S キター

Appleさんのお披露目イベント終了と同時に、
AppleサイトのiPhoneページがiPhone4Sの紹介に切り替わった。

そして、購入についてのページにはauのオレンジバナーが！
遷移先にはiPhoneに関するこれと言った情報はないが、
予約開始は10/7からで、SBと同時。

噂になっていたiPhone5はどうやら、カタスカシだった？？

発売は10/14。

まさかauも同時発売とは．．．

Application failed codesign verification.

AppStore登録用のアプリを用意していたところ下記のエラーに阻まれた。
初めてのエラーではないが、すっかり対処方法を忘れていてしまっていたので、メモ代わりに投稿しておく。

エラーはこれ。
Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate.(-19011)
Google先生にお伺いを立てると、いろいろな方がいろいろな解決方法を記載されているが、いずれも今回のエラーには有効な対処とはならなかった。

まず前提条件、
・各種provisioning profileはきっちり導入済み。
・code signingには、Debug/Release/Distribution毎に設定はおk
・コンパイルエラー／ワーニングは出ていない。

あとは、Archiveして、オーガナイザでValidate → Submitの流れだが、Validateの段階で上記エラーが発生した。
いろいろ調べた結果、下記の対処で解決した。

チェックする箇所は１カ所。
EditSchemeで出てくるサブウィンドウの左ペイン、一番下のArchiveの項目が、きっちりDistributionになっているか？
ここが、ReleaseやDebugになっているとイカンらしい。
ここをDistributionに変更して、今回のエラーはケリがついた。

よかったよかった。

XCode 4.2 リベンジ

iPhone 5 の噂もいろいろと耳にするようになってきたこのごろ、そろそろiOS5対応も考えにゃならんね。
という事で、　XCode4.2 Beta7をインストールしてみた。

少々使ってみた感じは、
さすがにBeta7ともなると、いろいろコナレて来てますね。
と言ったところ。

特に、エディタ上での二本指左右スワイプによるファイルの切り替えはちょっと便利。
（4.0の頃にあった、３本指上スワイプで.h <-> .m 切り替えには及ばないが…）

その他、使っていて気になる部分はほとんどない。
重かったり、落ちたりする事も頻度的には今まで（4.1）と大差ない。

うんうん、このまま置き換えていいんじゃね？

と思っていた矢先、公開済みのアプリにちょっと気になる部分を発見。
早速修正、ヴァージョンアップですしようか。
と思ったところ、でつまずいた。

今回は、妙チクリンなワーニングは出ない。
コンパイルは正常に完了。アーカイブも問題無し。
しかし、オーガナイザでのValidate時に下記のエラーが発生した。
「Apple not currently accepting applications built with this version of the sdk」

ようするに、「このバージョンのSDKで作ったアプリはお呼びじゃねーんだよ」世言う事らしい。

うんうん、たしかに、BaseSDKはlatest(iOS5)になっていた。
これをiOS4.3に変更し、再度コンパイル、アーカイブ、Validate…………orz
どうやら、XCodeがbeta版なのがそもそもの問題らしい。

つまり、XCode 4.2では、現状AppStoreに登録できるアプリは作成できないということか。
またしてもハヤマッタ。

というわけで、おとなしくXCode4.1 を再インストールだ。
とほほ。

WebピペットLite始めました。

Webピペットの無料版、Webピペットの無料版の配布を始めました。

無印とLiteの差異は、下記の通り。
・画面下部に広告が表示されます。
・ダウンロード済み項目は５個まで。
→ ５個を超える場合は、ダウンロード待ちリストで待機となります。

その他機能については、無印との機能差異はありません。

有料版で二の足を踏んでいた方は、ぜひ無料版をご利用になってみてください。

サコッシュ 型紙作成

早速、サコッシュの型紙を起こしてみた。

とはいえ、型紙用の紙とか型紙の書き方とか、
大昔の家庭科の授業のキオクがすっぽりなくなっている身としては、結構ハードルが高い。
だがしかし、べつに誰に見せるわけでもないので、作法がどうのというのは、この際目をつぶる。
この型紙を元に現物を作成するために、必要な情報が漏らさず記載できれていればオッケーだろう。

ちゃんとした型紙がいったいいくらするのかわからないが、そもそも売っている場所もわからないので、
型紙の代わりに文房具屋で買ってきた1mm方眼紙を投入、チャコペーパーで転写できる程度の厚みの紙なら何でもいいだろう。たぶん。

要件定義にそって形を起こすと、
最終的なサイズは縦横１５センチ、底の部分のマチが財布のサイズから５センチ、あとは、開口部を少し工夫した為に、布地の縦の長さは４０センチを超えた。
型紙はでかい。

横幅は１５センチだが、縫いシロに何センチ（ミリ）とればいいのかわからないため、現状、型紙の切り出しは行っていない。
だが、ずいぶんを形になってきた。
あとは、小物の型紙を作って切り出せば、盆休み前の作業は一段落だ。

サコッシュの要件定義

盆休みが目前に迫ってきて、公私ともになんだかとっても慌ただしい。

が、盆休みにはヤラネバならない事がある。
サコッシュ作成だ。
この一大事の前に、仕事の忙しさなんざ、優先順位は推して知るべしである。



けっして宣言しっぱなしで忘れていたわけではない。
水面下では、ちゃんと進めていたのだ。
ナニを進めていたかというと、
まず、実際に売っている現物を確認してきた。

行った先は某アウトドア用品メーカーのアウトレットショップ。
値段は５０００円弱、高い。
確かにモノはしっかりしていそうだったが、ワタシの欲しいサイズとは少しずれていた。
やはり、欲しい物は自作するに限るのだ。

もひとつ進捗。
とりあえず生地を確保した。
１m四方の端切れとして投げ売りしていた、横方向にのみ多少の伸縮性のある生地。
お値段３００円。
軽さや伸縮性もさることながら、その安さがとっても魅力的。
何しろ初めてなので、失敗する可能性は低くない。
労力は次への学習の対価となるが、材料費はそのまま飲まざるを得ないので、
安いに越した事はない。

そして、頼れるミシン要員たる嫁をパフェで一本釣りして協力を確約させた。
「型紙は作れ、布の裁断はしろ。あとは縫ってやる」
と、オットコ前なお言葉をいただいて、スタンバっていただいている。

ここまで来たら、あとには引けない。
作成に向かって、具体像を詰めていかねばならない。
これを怠けて惰性で作ると、なんだか分けのわからない物が出来上がってしまうというのは、本業でよくある現象だ。

ではザックリ要求定義。

・財布、携帯、その他小物が収納できる容量があること。
・収納物が落ちニクいこと。
・キーホルダー取り付け用のループを備えるとこ。
・キーホルダーが暴れないように外ポケットを備えること。
・肩ひもは、伸縮もしくは調整できること。

想像しているサイズはかなり小い物である。
用途は近所のポタリングや、徒歩での買い物用であるので、通気性だの撥水性能はこの際気にしない。
腰巻き、肩掛けの両対応が望ましいが、最初からそんなにハードル上げるか？　という気分でもある。
紐については、本体と同一の生地から作成するか、肩ひもだけ別途調達するかは、もう少し考えないといけない。

・ 生地に余裕があれば、Ａ４ファイルケースを収納できる程度の大きめのモノも欲しい。
（こっちはおまけ的な位置づけで、嫁の機嫌次第という条件もつく）

これである程度、サコッシュの具体像が想像できるので、次は型紙を起こそう。

タイムリミットは、あと３日！

Webピペット バージョンアップしました。

ご盛況いただいておりますWebピペットをバージョンアップしました。

「1.0.0」→ 「1.0.1」へのマイナーどころか、リビジョンアップで
機能的にはほとんど変更はありませんが、
UIのレイアウトを変更して、使い勝手を少しだけ改善しております。

詳しいアップデート内容はApp Storeの該当ページを参照ください。

ではでは、よいiPhoneライフを

XCode 4.1.0 インストールした。

Lionさんの導入で、XCode 4.0.2が起動しなくなったので、

XCode 4.1.0にアップデートした。

その際、一点引っかかったので、情報展開。

きっと今後のアップデートの時も同じ問題が出てくるのではないかと思う。

今回、Lionさん導入後、ソフトウェアアップデートをかけつつ、App StoreからダウンロードしたXCode 4.1.0をインストール！

なりの変わったインストーラーだが、順調にインストールは進んだ。

注）インストール先の選択（フォルダの選択）の手順が変わっていたらしく、変更し損なった。どうせ、古い環境は起動できないので、大きな問題はないが……。

で、引っかかったのはその先。

XCodeインストール中にはよくお目にかかる。

「関連アプリを終了させてね。特にiTunes」的なダイアログ。

これが今回も表示された。

だが、Dock上のiTunesアイコンには起動している気配はない。

一度立ち上げて、終了してみるがダメ。

どうやら、インストーラのチェックに引っかかっているのは、

iTunes本体ではなくiTunesHelperなる常駐アプリらしい。

こいつを終了させるためには、アクティビティモニタで直接プロセスを終了させるのが、良さそうだ。

で、めでたくiTunesHelperを終了させたところ、XCodeのインストールは完了した。

このプロセスがいつから常駐していたモノかはわからないが、この前XCodeを4.2→4.0.2へ戻したときは、こんなところで引っかからなかったと思うので、

ひょっとしたらLionさんのワナの一つなのかもしれない。

そして、ちょっとだけXCode 4.1にさわってみた感触。

フルスクリーンモードはマルチディスプレイ殺しだ。

Lionさんを手なずけ……られるのか？

遅ればせながら、Mac OS X 10.7 Lionを導入した。

DLは滞り無く完了。
インストールも特に問題なく３０分ほどで完了。
10.6のときの環境もほぼそのまま移行されているようだ。

App Storeのコメントに古いアプリケーションが動かないといった
報告があがっていたので、懸念していたGIMPの起動は、無事起動確認ができた。
これでデザイン系の作業に支障は出ない。

しかし、本丸であるXCodeが動かない！
LionさんではXCode4.1.0を落としてこい。とツレナイお言葉をいただいた。
なるほど、iOS5用のBeta環境が4.2.0だったのはこの絡みかと、納得。

というわけで、XCode 4.1.0をダウンロードしている間に、
Lionさんを少しさわってみた。

まず、AppStoreで賛否両論のスクロール方向の変更について、
一言で言うと、慣れないうちは使いにくい。
ホイールマウスの出現以来のスクロール操作方向が逆転してしまったのだ、この混乱は当面続くだろうと思う。
そして、ますますWindowsとの両刀使いは、激しいギャップに苦しむ事になりそうだ。

そして、フルスクリーンモード。
うーん、いいのかね？画面が広く使えるのは確かにありがたいのだけれど、
サファリは専用のWindowを作ってそこで実行されるので、
マルチディスプレイ環境では、サブディスプレイがスッカラカンになって、なんだかもったいない。
普段使いのChromeの場合、サブディスプレイいっぱいに表示されるので、なかなかいいように思ったのだが、タブが隠されてしまうので、頻繁にタブを切り替える場合にはちょっと待たされる。
ひょっとしたら、ジェスチャーでその辺ウマく操作できるのかもしれないが……。

次にそのジェスチャーについて、
一番痛いのは、二本指スワイプによるブラウザの「戻る」「進む」ができない点。
特にフルスクリーンモードでツールバーが表示されないChromeでは、もはや致命傷といいもいいかもしれない。
こ、これもジェスチャーの設定でなんとかなるもんスカね？

あとはデスクトップ環境がいろいろ統合されて、使い勝手が変わったとか。細かい変更は結構多い。
こりゃ、慣れないうちはちょっと混乱しそうだ。

しかし慣れてしまえば、それまでの話なので、バンバン使ってさっさと慣れてしまうのが吉だろう。

Webピペット はじめました。

URL抽出型ダウンロードアプリ、「Webピペット 1.0.0」の提供を開始しました。

インターネット上の動画や音楽。
流れの速いネットの世界では、動画や音楽も一期一会。
見つけたときが見時です。

でも、iOSではFlashコンテンツの再生はできません。
家に帰って見ようとしても、もう探せないかもしれません。

そんな時のために、このアプリがあります。
Flashアプリによって再生される動画や音楽を、iPhoneにダウンロード。
ダウンロードしたファイルは任意の名前を付けて保存する事ができます。
また、ダウンロードしたファイルは、iTunes経由で母艦（PC／Mac）に取り込み、
ゆっくり鑑賞する事ができます。

ダウンロードはこちらからどうぞ。

注意１：第三者の著作物を無断でダウンロードする事は違法ですの、そのような行為には使用しないでください。
注意２：スクリプトで動的に生成されるURLは本アプリでは抽出できません。
コンテンツによっては正常にURLを解析できない場合もあります。

便利な使い方などは、追々追加していこうと思います。

要望、不具合の報告は、このブログへのコメント、メールで受け付けております。

では皆様、よいiPhoneライフを。

XCode4.2は遅効性の毒ですか？

本記事XCode4.2とは、XCode4.2 Beta版のことです。(2011/10/22 追記)

アプリ公開準備を進めているが、XCode 4.2がヨクワカラナイワーニングを吐いてくれる。
公開用のコードはきれいな身体でアーカイブしたいので、ちょっとこれはなんとかしたい。

と思って、試行錯誤してみたがどうもうまく行かない。
正式版のXCodeの再インストールや、別ディレクトリへのインストールも試してみたが、どういう事かXcode 4.2が出しゃばってきて、古い版のXCode 4が起動しない。（XCode 3.x.xは起動するのに）

おいおい。

ちなみに、ワーニングの内容は下記。
warning: iPhone apps with a deployment target lower than 4.3 should include an armv6 architecture (current IPHONEOS_DEPLOYMENT_TARGET = "4.0", ARCHS = "armv7").
これに付随するワーニングがあと２つ。

一応の解決をみたので、方法だけ簡単に記載する。

まず、XCode 4.2を完全に除去するべく、下記コマンドをコンソールから実行する。
sudo /Developer/Library/uninstall-devtools -mode=all
必ず、XCode 4.2インストール先を指定する事。

実行すると、macの管理者パスワードを要求してくるので、おとなしく入力。
しばらく放置。

コンソールにプロンプトが戻ってきたら、macちゃんを再起動、その後、お好みのXCodeをインストールしなおす。

これで、めでたくワーニングは消えた。

さーて、公開準備を進めよう。

多言語化の手順メモ（XCode4向け）

アプリ公開に先立って、やっておきたい作業の中に、多言語化がある。
可能な限り文字ではなく、アイコン化を行ってもどうしても文字での説明が必要な部分というのは、なくならない。

だから、広く薄くアプリをばらまこうと思うと、多言語化は必須の作業だと言える。

ここからはワタシの多言語化の手順をまとめておく。

１．アプリを作る。
　これが無くては始まりません。
　とにかく、公開できる直前（スプラッシュなどのオオモノ画像とかは多言語化後に用意する事が多いので、この段階では必須ではない）のアプリまで仕上げる。

２．InterfaceBuilderで作ったxib(nib)ファイルの日本語を含む部分をviewDidLoadで動的に設定するように変更する。
　nibファイルを言語毎に用意する方法もあるが、あまり好きではないので、この方法で。

３．コード中の文字列をNSLocalizedString()の関数に置き換える。
　このとき、第二引数のコメントに、元の文字列を入れておくと、第二、第三言語を設定するときにちょっと楽。

４．Localizable.stringsファイルを生成する。
　コンソール上で、プロジェクトのディレクトリまで移動し、下記のコマンドを実行する。
　　genstrings -a $(find . -name "*.m")
　これで、コード中のNSlocalizedString()関数を元にLocalizableS.stringsファイルが生成される。
　
５．言語を追加する。
　Project -> Info -> Localizations -> "+" -> 言語を追加する。
　このとき、nibファイルの多言語版が生成される事があるので、右ペイン、左端のファイルっぽいアイコンのLocalizationから、主言語以外の言語を削除しておく。

６．Localizable.stringsの登録。
　プロジェクトに４．で生成したLocalizable.striongsを追加する。
　この時点で、Localizable.striongsをXCodeで開くと、文字列がバケバケの焦るが落ち着く事。
　右ペインを開き、左端のファイルっぽいアイコンを選択。
　Localizationに、対応する言語を「＋」で追加してゆく。
　ここまでくると、ファイルの中身がちゃんと見える。ハズ。

７．言語毎に文言を修正。
　６．の言語を追加すると、対応する言語版のLocalizable.stringsファイルが生成されるので、文字列を各国語に置き換える。
　とにかくがんばって翻訳して置き換える。
　血反吐を吐きながらでも、翻訳する。

８．完了
　コンパイルして、iPhone側の言語設定を替えながら、表示文字が正しく置き換わっている事を確かめる。

おまけ．
　各言語毎にアプリの表示名を変更する場合、infoPlist.stringsに下記の１行を追加する。
　　CFBundleDisplayName = "表示名称";

これで、多言語化は完了。

サコッシュが欲しい。

サコッシュが欲しい。

ハンドルのブルホーン化が完了して、一旦は物欲に歯止めがかかったかなぁ〜などと思っていたが、どうやら甘かったらしい。
ワタシの物欲はとどまる事を知らないよ。（Amazonさんの欲しいモノリストは増加傾向）
唯一のブレーキは財布の中身のみ。
危ないよ。ものすごく危ないよ。

で、最近暑くなってきた事もあって、バックパックを背負っての自転車が億劫になってきた。特に背中発で！
すこーし遠出しようモノなら、ちょっと人様の前でバックパックを降ろせない身体になってしまっている。
こりゃヤバい。
そこで白羽の矢がたったのが「サコッシュ」。
必要最低限の荷物を、必要最低限の袋に詰めて持ち歩く。うん、無駄が無くてイイッ！
前々から気になってはいたが、なかなか手が出なかった。というか、ほかに欲しいものがありすぎて資金が回らなかった。
で、今、資金のめどは相変わらず立っていないが、実質的な要求から非常に欲しい。

早速、google先生にお伺いを立ててみると、サコッシュの自作をされている方が結構いらっしゃる。
考えてみれば、サコッシュなんざただの小袋です。
ちょっとがんばれば、作れるんとちゃいますか？
つまり「お金がないなら自分で作ってしまえばいいじゃない」とそういう事か。

という訳で、サコッシュを作ってゆこうかと思います。
二番煎じどころか、出がらしもいいところだが納得のいくものを作ってゆきたい。

ただ、今の住居にはミシンやら裁縫道具やらが全く無い。その手の作業は夏期休暇の８月半ばをメドに行うとして、それまでに下準備を整えたい。

とりあえず、要件を定義しよう。それからモックアップ（型紙）作り。

「iPhoneアプリ開発からの現実逃避なんかじゃナインダカラネ」

ルートラボいいね。

しまなみ海道縦走計画は、遅々として進んでいないが、
MY自転車はいつの間にかバーハンドルからブルホーンへと換装された。
ので、どこかへ走りにいきたい。行きたいったら行きたいのだ。

たまたま会社の人が、「有馬温泉いってきたー」とかなんとか。
調べてみると、意外と近い。
直線距離で２０kmちょっと。

実経路は、３０km弱、山越えが入って数値以上にしんどそうだけど、
行けない数字じゃないなぁ〜

ルートラボで調べたルート。

が、ここ数週間、天気との折り合いがつかずに、のびのびになっていた。
昨日も結局一日雨で、予報では今日も一日雨のはずだった。

だが、今日起きてみると、なんだか空が明るい。
少なくとも雨の雰囲気は無い。
カーテンの外は、いつ降り出してもおかしく無いような雲行きではあったが、
天気予報は出発地／目的地の天気ともに、一日中曇りが表示されていた。

ならばこれは行くしかあるまい。
というわけで、本日朝から、ついさっきまで須磨ー有馬温泉日帰り旅行を敢行して来た（一人で）。

行きの山越えでは何度か引き返そうかと思ったが、なんとか目的地に到着することができた。
温泉にも入ったし、久々に気合いを入れて自転車に乗ったし、
いやー、久々に充実した週末だった。

ブルホーン化の詳細と、この旅行に向けて購入した物品のレポートは、後日。

XCode4.2 フォント選択できず。

iOS5 Betaが出て、当然のように対応iTunesとXCodeが配布されている。（Developerのみ）

早速、iOS5を導入し、XCode4.2も導入してみた。
既存のプロジェクトをビルドすると、ワーニングがわんさか出た。
どうやら、サポートしなくなったフォントがあるらしい。

ならフォントをかえましょうかと、Inspectorを操作すると、XCodeがCrashした。
じゃあどうやって、フォントの修正をすればいいんですか？

しばらくすれば、この辺のバグは修正されるんですかねAppleさん。

Not祝、初リジェクト

iPhoneアプリ２本目にして、くらってしまった。

作成当初からちょっとヤバいかな〜と思わないでも無かったので、
想定の範囲内といえば、範囲内。

リジェクト理由は、「22.4: Apps that enable illegal file sharing will be rejected」
違法なファイル共有を有効にするアプリはリジェクト
だそうだ。

申請したアプリはちょっと強力なダウンローダーだったので、
まぁ、そんなものかと思わなくもない。

しかし、ここ１ヶ月の開発に投じた時間を考えると、

ちょっと割り切れないものがあるなぁ〜。

いろいろ皮算用もしていたというのに……

とまぁ腐っていても、始まらないので、次のアプリの作成に取りかかりましょう。

ネタだけはそれなりに溜まっているので、

じゃんじゃん作って、じゃんじゃん申請をしてゆきたい。

iPhoneアプリで必要になるイメージのサイズ一覧

iPhone/iPod touch用アプリを作成するにあたって、必要になるイメージのサイズをまとめる。

1. アプリアイコン
• 114x114　：　Retina用アプリアイコン（png）
• 57x57　　 ：　アプリアイコン（png）
2. アートワーク
• 512x512　：　iTunes用アプリアイコン（jpg）
3. UITabBar
• 60x60　　：　Retina用アイコン（png）
• 30x30　　：　アイコン（png）
4. NavigationBar/ToolBarアイコン
• 40x40　　：　Retina用アイコン（png）
• 20x20　　：　アイコン（png）

とりあえず、こんなものか？

詳しくは下記

http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/IconsImages/IconsImages.html#//apple_ref/doc/uid/TP40006556-CH14-SW1

UINavigationController いん UITabBarController

TabController内にNavigateController を内包させる方法（非IB）。

IBを使って同じ事をさせているサンプルはネット上に多数あったが、いまいちウマくいなかったので、結局IBでの実装をあきらめ、手動で実装した。
Viewの構成を忘れないうちにまとめておく。

Window
↓
UITabController
(UIViewController.h/m/nibを変更してTabController化)
＋ーーーーーーーーーーー＋・・・　（setViewControllers:でtabにViewを割当）
↓　　　　　　　　　　　↓
UINavigationController　UIViewControllerなど
↓
UiViewController（initWithRootViewControllerあたりで設定）
↓（以降 pushでバンバン追加）


UITabControllerのでっち上げ方。

①すの状態

②TabBarControllerを追加

③不要になったViewを削除

④ViewControllerとnibのマッピング＋α

projectの作成時に、View-base Applicationで作成。
ViewControllerをTabControllerに切り替えると、割とらくにできる。

後はよしなに。

リファクタリングの罠

ほんの軽い気持ちで行ったリファクタリングが原因でちょっとハマってしまったので、備忘録として記載しておく。

現在作成中のアプリに機能追加をしている最中、ViewControllerのクラス名（ファイル名も同名）にTypoを見つけた。

Nibファイルと同時に作成したViewControllerだ。

早速、XCode4のRefactor機能を使って修正した。

しばらく実装中の機能を仕上げて、さて動作確認をするかと動かしてみると、なぜか今まで動いていた機能が動かない。

調べてみると、ViewControllerのviewDidLoadの段階で、InterfaceBuilderを使ってNibファイルにマッピングされたはずのメンバのポインタが軒並み0x0を指していた。

つまり、Nibファイルへのマッピングが外れていた。

この現象の原因は、クラス名のリファクタリングを行った際、XCodeは関連するシンボルを検索して置き換えを行ってくれるが、同時に作成したNibファイルのファイル名は置き換え対象になっていないらしい。

（File'sOwnerのクラス名は書き換えているらしい）

さらに、InterfaceBuilderを使用する場合だけかもしれないが、Nibファイルのファイル名は該当ViewControllerのクラス名と一致している必要があるようだ。

なにわともあれ、コードの変更中に、何かのついでにリファクタリングをかけるのは避けよう。

副作用に気づかないままリファクタリングをかけた事を忘れて、貴重な時間を無駄にしかねない。

iOS 4.3.3は開発環境の提供無し？

iOS4.3.3の提供が開始された。
早速、手持ちのiPod touchをアップデートしてみた。
連休中の忙しいこの時期に、XCodeの再インストールかよ。とぼやきながら、
iOS Dev Centerを開く。

あれ？

XCode4のPosted Dateが４月のままだ。
ひょっとして、開発環境の提供は今回は無しですか？
XCode4.0.2を起動してみると、案の定、オーガナイザーが「知らないOSだぜ」と不平を漏らした。
同時に、こんなコーションが表示された。

ここで「Collect」を押下すれば、OKらしい。

少しさわった限りでは今のところ問題なくiOS4.3.3のデバイスに対して、アプリのインストール／デバッグが可能だ。

iOSのアップデートの度に、４G超のファイルをダウンローダさせられていてはたまったもんではないので、この方式は非常に助かる。
今後も、この方法で開発環境のアップデートはしていってください＞＞Appleさん

NSURLRequest ~ NSURLConnectionのひながた

HTTPでファイルを取得する方法を調べていたら、
少し混乱したので、整理もかねてひな形を保存しておく。

まずはひな形、基本これをコピーして、URLの入力の部分をゴニョゴニョすれば、
一連のDelegateが発火する……ハズ。


// アクション契機のURLリクエスト開始処理
- (IBAction)urlRequest:(id)sender {
NSString* urlStr = urlField.text;
if ( [urlStr length] <= 0 ) {
return;
}


NSURL* url = [NSURL URLWithString:urlStr];
NSURLRequest* request = [NSURLRequest requestWithURL:url];
[NSURLConnection connectionWithRequest:request delegate:self];
}




#pragma mark NSURLConnection delegate implementations
// Request送るよ。
- (NSURLRequest *)connection:(NSURLConnection *)connection willSendRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse *)response {
return request;
}


// 応答受信
- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response {
}


// データ受信
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data {
}


// キャッシュがするよ
- (NSCachedURLResponse *)connection:(NSURLConnection *)connection willCacheResponse:(NSCachedURLResponse *)cachedResponse {
return nil;
}


// 読み込み完了
- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
}


// エラー
- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error {
}


この実装の気に入らないところは、NSURLConnectionに対してDelegateを設定しているというのに、selfのクラス宣言で、プロトコルの実装宣言が要らないところだ。

要らないなら、手間が省けるじゃないかとう意見もあるが、少数の例外が存在するというのは、いろいろ疑う余地が増えてくるので、気持ちのいいものではない。

とわ言え、動くものは動く、とりあえずはソレでヨシとする。

UITableViewのひながた。

UITableViewは便利だ。
普通に使うぶんにはレイアウトはFrameWorkにお任せでOK。
こっちは内部の動きに専念できる。

だが、Delegateの実装が必須になる、これをいちいち覚えておくのは面倒クサイ。
なので、必要最低限のひな形を載せておく。
ただし、ヘッダー側にもそれ用の宣言が必要になる。

以下、ひな形

#pragma mark UITableViewDataSource Implementation
// tableのsection数
-(NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return 1;
}


// section中の行数
-(NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
return 1;
}


// Cell表示
-(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
return nil;
}


// sectionヘッダタイトル
-(NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section {
return nil;
}


#pragma mark UITableViewDelegate Implementation
// 行選択
-(void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
}

UnlockMe 1.1.0 アップデートしました。

だいたい1月前に公開を開始したiPhone/iPod touch向けゲーム
UnlockMeのバージョンアップ版が本日アップルの審査を通過、


UnlockMe 1.1.0の公開を開始しました。


アップデート箇所は下記。
・ダイヤルの動きをより鈍くして、ホンモノのダイヤルキーに近い、
渋い動きを再現しました。
・操作に伴う効果音を追加しました。
もちろん設定画面で効果音の無効も選択できます。

ではでは、ダウンロードはこちらから。

UITableViewCellのいろいろ

UITableViewを使おうと思うと、どうしても避けて通れないのが「UITableViewCell」
凝った事をしようと思うと、自分でゴリゴリとCellをデザインする必要が出てくる。

だが、まずはSDKで提供されている機能の中でどこまでできるか試してみる。
用意したコードは下記、Cellリサイクル方法が、これでいいのかはいささか不安だが、
そこは今回の検証範囲ではないので黙殺。

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 UITableViewCell* cell = nil;
 switch ( indexPath.row ) {
  case 0:
   cell = [tableView dequeueReusableCellWithIdentifier:@"Goal0"];
   if ( cell == nil ) {
    cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Goal0"];
   }
   cell.textLabel.text = @"StyleDefault";
   break;
  case 1:
   cell = [tableView dequeueReusableCellWithIdentifier:@"Goal1"];
   if ( cell == nil ) {
    cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:@"Goal1"];
   }
   cell.textLabel.text = @"StyleSubtitle";
   break;
  case 2:
   cell = [tableView dequeueReusableCellWithIdentifier:@"Goal2"];
   if ( cell == nil ) {
    cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleValue1 reuseIdentifier:@"Goal2"];
   }
   cell.textLabel.text = @"StyleValue1";
   break;
  case 3:
   cell = [tableView dequeueReusableCellWithIdentifier:@"Goal0"];
   if ( cell == nil ) {
    cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleValue2 reuseIdentifier:@"Goal3"];
   }
   cell.textLabel.text = @"StyleValue2";
   break;
  default:
   break;
 }
 cell.detailTextLabel.text = @"detailTextLabel";
 cell.accessoryType = UITableViewCellAccessoryDetailDisclosureButton;
 cell.imageView.image = [UIImage imageNamed:@"hoge.png"];
 return cell;
}

上記のコードは、Section:1 Row:4のUITableViewを想定したコード。

で、出てきたテーブルはこういうものである。

【補足】UserLocationには障るべからず

先日投稿した、MKMapViewのPinを削除するコードが、

ウマく動かない場合があるようなので補足。

for ( id<MKAnnotation> annotation in mapView.annotations ) {

  if ( [annotation isKindOfClass:[MKUserLocation class]] )continue;

  [mapView removeAnnotation:annotation];

}

先日投稿したコードは上記。

しかしこのコード、iOS4.3.1のiPod touchでは動いたのだが、

iOS4.1のiPhoneではExceptionが発生して動作しなかった。

いわれてみれば、このコードには致命的な欠陥がある。

mapView上のannotationリストでループを回しながら、当のannotationを削除してゆこうという、しかも、順番はframeworkにお任せと………。

回し方によっては、これ以上にないくらい致命傷だ。

どうやら、この辺のロジックが最新のframeworkではお利口さんになっているらしく、問題が隠蔽されていたらしい。

何も考えずに書いていると、こういう地雷的なコードが出来上がってしまう事があるので、注意したい。

対応方法をかんがえないとなぁ〜

UserLocationには障るべからず

MKMapViewにピンを刺して遊んでいると、
刺しすぎたピンを削除したい衝動に駆られる事がある。
それこそちゃぶ台返しのごとく、一気に全部ひっくり返したいほど。

そんなときは、以下のコードが有効だ。


[mapView removeAnnotations:mapView.annotations]; (1)

これでMKMapViewの上から邪魔っけなピンは一掃される。
めでたしメデタシ……ではない。

このときもし、[mapView setShowUserLocation:YES]; (2)を実行済みであった場合、
ちょっと面倒な事が発生したので、備忘録として記載する。

まず、結論から言うと、（1）を実行した場合、現在位置の青点は、以降MKMapView上に表示されない。
消えたものは、もう一度設定してやればいいだろうと、
再度、(2)を実行しても、MKMapViewはヘソを曲げてしまって現在地は表示されなかった。

最初の対処は、mapView.annotationsの中から、userLocationを司るインスタンスを取り出して、再度[mapView addAnnotation:userLocation];で登録し直す方法。
だが、一度削除されたUserLocationはどうやら地図上への再表示がウマく行かないらしい。

ならば、(1)を展開し、以下のコードで実行したところ、
ウマく行った。

for ( id<MKAnnotation> annotation in mapView.annotations ) {

  if ( [annotation isKindOfClass:[MKUserLocation class]] )continue;

  [mapView removeAnnotation:annotation];

}

要はUserLocationは削除しないというだけ。

実際は削除したUserLocationを復活させる方法があるのかもしれないが、
そもそも自分が登録した訳でもないインスタンスを勝手に削除してしまうというのは、
ちょっとイタダケナイので、この方法でとりあえずは納得しておく。

しまなみ海道縦走計画（物欲一覧）

しまなみ海道の縦走にあたり現在のマイ自転車の装備では、
ちょっと足りない部分がある事が判ってきた。

基本、通勤の足＋休日のポタリング用の装備なのだが、
それではちょっと足りない装備がある。

まず、安全装備であるところのヘルメットが無い。
車道を走るのが基本である自転車では、これは一歩間違えると命取りである。
自分が間違えなくても、車側でちょいと間違えただけで、エライ目にあうのは自転車側だ。

次に、各種修理セットだ。
長距離ライドの場合は必須なのだが、今まではアパートを中心に行動していたために、
「いざとなれば、引きずってでも帰れる」という気分で、
予備のチューブや、工具一式は部屋に置きっぱなしである。
おまけに、スプロケ外しとかは持っているくせに、タイヤレバーは持っていない（汗
遠出するとなれば、最低限、対パンク用装備一式サドルバックにでも詰め込んでく必要がある。
もちろんサドルバッグも未装備だ。

さらに、アパートから起点となる尾道まで、公共交通機関を使用する事が必要になる。
このため輪行バッグが必須になってくる。

この時点で、足りない装備は
・ヘルメット
・サングラス
・タイヤレバー
・パンク修理キット
・サドルバッグ
・輪行バッグ
・輪行バッグ使用時の保護具

うっ、概算だけで諭吉さんが何人か旅立ってゆく…
できれば、現在のフラットバーのハンドル周りを、ブルホーン化したいし、
長距離を走るのであれば、最低限パッド入りのインナーは買っておかないと、
後半死んでしまうのが目に見えている。

これに、交通費＋宿泊費（今治にて一泊予定）を含めると………
冷静に考えだすと、計画が頓挫しそうなので、金勘定はこの辺にしておく。

しまなみ海道が呼んでいる

サイクリング雑誌を読んでいると、しばしば目にするのが記者おすすめのサイクリングコースの記事。
大半は首都圏近圏を中心にした記事で、地方にすんでいるワタシは指をくわえて眺めるだけ…。
しかし、そんな中にサンゼンと輝く記事がっ！
それが「しまなみ海道」。

本州四国連絡橋の最も九州よりの橋。
そこには自動車道に併設された自”転”車道があるとか。
幸いワタシは今、近畿在住。広島なら遠くない（！）

ならば、いくしか無いでしょう。しまなみ海道。

だがしかし、思い立ってもすぐにはいけない。

何しろ、しまなみ海道の本州側の起点「尾道」までの足。
全行程７０km、高低差６０〜７０mを安全に走りきる装備。
（何しろ海の上に架かっている橋だから、船舶との干渉をさけるために、無駄に高いところにかかっている。）
そして、四国側の起点、今治からの帰りの算段。

これらをクリアにする必要がある。
今後は、息抜きがてら本格的な夏がくる前になんとか、実行に移せるように計画を練っていく。

UnlockMe 1.0.0 リリースしました。

iPhone/iPod touch向けパズルゲーム、
UnlockMe 1.0.0 をリリースしました。

ダイヤルを一つづつ回して、鍵が外れるか試していきましょう。
暗証番号の桁数は　２〜６桁まで変更可能。
どうしてもだめな場合は、ヒントを最大二桁まで表示可能です。

がんばって、チェーンロックを外しましょう。

XCode4 移行 備忘録

XCode4に乗り換えて、もうそろそろ一週間。

レイアウトや設定の変更に戸惑いながらも、なんとか少しづつなれて来た…とおもうので、ここらで備忘録としてXCode３→4をに移行するにあたって戸惑った点を軽くまとめておく。

１.Debug/Release（構成）の切り替え
Debug/Releaseだけでなく、(XCode3でいうところの)構成の変更方法はちょっと深い所に移動していた。
ToolBarのSchemeプルダウン、下の方の「Edit Scheme ...」を選択。
「Run XXX.app」を選択、「Info」タブ下の「Build Configuration」の値を変更すれば、対応するコンパイルオプションでビルドを実行できる。

２．では、どうやって「Build Configuration」の値を追加（もしくは削除）するか？
これまた、ずいぶんを深い場所に移動している。
「Navigators」の「Project」を表示し、プロジェクトアイコンを選択する。
開いた「Project Editor」の「PROJECT」を選択し、「Info」タブ下の「Configurations」の「+」「-」ボタンで構成の追加／削除が可能。
追加には、コピーもとをドレにするか選択が必要になるので、よしなに。

補足：
「Navigators」の「Project」を表示し、プロジェクトアイコンを選択した状態で、
メニューバーの「Editor」を選択すると、「Add Configuration」で、構成を追加できる。
（削除はできない。）

それにしても、XCode4日本語化しないかな。

「In Review」っていつまでですか？

東北地方の地震があったり、自宅近くでも地震があったりと、
落ち着かない週末を過ごしていたら、
iTune Connectからメールが来ているのを見逃していた。

内容は
「申請中のアプリのステータスがアップデートされたよ」
という事で、今まで
「Waiting For Review」だったものが、「in Review」に変わった。

いままでもちょっとドキドキしていたのだが、
どうやら、これからが本番らしい。

とはいえ、今更ナニができるわけでもないので、
こっちはこっちで粛々と次のアプリの仕込みを
すすめましょう。

ドキドキ

XCode4 frameworkの追加方法

XCode4でのframeworkの追加方法が判明したので、
簡単にまとめる。

下の画像の(1)〜(5)の順に選択して、お望みのframeworkを追加すればOK。
（丸付き文字は機種依存の恐れがあるので、ここでは括弧表記）

(3)は「Build Phases」
(4)は「Link Binary With Libraries (n items) 」

なんだか疲れたので、今日はこれにて打ち止め。

XCode4 がやってきた。

仕事から帰ってきてみれば iOS 4.3がリリースされたいた。
予定では、3/11と聴いていたので１日前倒しということだろうか？

ということは、同時に開発環境であるXCodeもバージョンアップしたということで、
XCode3.2.6 and iOS SDK 4.3 が正式リリースだなぁ〜♪
などと、我らがiOS Dev Centerへおもむいていてみた。

だが、そこで待っていたのは、
「XCode 4 and iOS SDK 4.3」の文字……
XCode4がベータ提供されていたのは知っていたが、
まさかこのタイミングで正式版がリリースされるとは！
iOS 5あたりと一緒にリリースかと思っていましたよAppleさん。
（根拠はないですが……）

早速、iTunesとiOS4.3をアップデートしつつ、
XCode 4をダウンロード。
４ギガが落ちてくるのを飯を食いながら待ち、
インストール中に風呂を済ませる。

こざっぱりしたところで、XCode4さんとご対面だ、
噂では、ずいぶんとUIが変わっているらしいですが……

な、何ですかこれは…………

確かにXCode3の面影はあるが、これは全く別物だ。
interface BuilderがXCode内に取り込まれた事なんて些末なことだ。
そもそも昨日まで使っていた、そろそろなじんできたXCode3.x.xのUIは
所々に面影を残す程度しかない。（しかも中途半端にorz）


いやいや、見た目で判断してはいけない、
まずは触ってみなければっ。

手始めに、小規模なテストアプリを組んでみる。
ちょっと勉強がてら、GameKitを触ってみようかしらん、
などとプロジェクトを新規作成、
プロジェクトの作成は、今までと違和感は少ない。
強いていうなら、UnitTestsを最初からプロジェクトに含ませることができるようになっている点か？

プロジェクトを開始し、まずはframeworkを追加せにゃぁ〜
とframeworkのグループを触ってみるが、
frameworkの追加はどうするんだ？
Ctrl＋クリックのメニューにそれらしい文言が無い。
片っ端から当たってみても、どれもはずれだ。
まさかこんなところでつまづくとは思わなかった。

現在も触っているが、frameworkの追加の方法は未だに不明(T-T)

いろいろ触っている最中だが、
なんだかこのツールで開発できる気がしないのは、
単に慣れていないせいだと思いたい。

そしてなにより、このXCode4メモりをバカ食いするようだ、
気がつけばmacの動きが重い気がして確認してみると、XCode4だけで700Mもメモリを喰っていた。
3の頃は体感として重いと思ったことはなかったので、これほど喰ってはいなかったのだろう。

はぁ〜〜

渋々だが、今後を考えると、
今のうちにXCode4に慣れておいた方が良さそうなので、
このまましばらく使ってみる事にする。


そうそう、XCode3.2.6は無かった事になった訳ではないらしい。
XCode4のダウンロードボタンの下にひっそりと、
「XCode 3」のダウンロードリンクが存在している。
どうしても気に入らなければ、こっちに戻る事も考えつつ、
標準２Gのメモリを４Gに増強した方が、いろいろと幸せか？ と思案中。

アプリ登録までのハマりどころ。

アプリケーションのアップロードまで、
いくつかハマりそうな箇所があったので、
記載しておく。


ただし、これは2011/03/09時点での情報であり、
時間経過とともに、劣化することがある。
正しい情報は、iTune Connectのドキュメントを参照のこと。
（懇切丁寧に、日本語版もある）


ハマりどころ。

・EULAとは何ぞや？

・release版アプリのワーニングの消し方。

・iTune Connectへのアプリのアップロード方法

１．

まず「EULA」とは… google先生にお伺いをたてるのが吉。

iTune Connectでは、標準のEULAに独自の文言を追加できるらしい。

今回は、難しいことは何もしていないので、標準EULAのみで登録。

２．

次に、release版でコンパイルすると現れる下記のワーニング。

Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate. (-19011)


せっかく登録するアプリなら、きれいな身体で送り出したい。
だが、このワーニングはコード上でナニをドウしても消えない。
なぜなら、プロビジョニングファイルの問題だからだ。
通常、開発過程では、developer権限のプロビジョニングファイルを使用しているが、
配布時にはそうはいかない。
Distribution権限のプロビジョニングファイルが必要である。
入手先は、我らが「iOS Dev Center」の「Provisioning Portal」
開発過程でお世話になっているのは、「Development」のタブだが、
その隣に「Distribution」のタブが存在する。
ここの「New Profile」でDistribution権限のプロビジョニングファイルを作成する。
作成方法はDeveloperとほぼ同じなのでカツアイ。


後は、DownloadしてXCodeに認識させ、
「プロジェクト」のコード署名IDを設定してやれば、解決するはず。


３．
iTune Connectへのアプリケーションファイルのアップロードは、
専用のソフト「Application Loader」を用いて行う。
ただし、このソフトはAppleからダウンロードできない。
3.2以降の場合、SDK内に同梱されている。
XCodeの標準的なインストール先であれば、
「/Developer/Applications/Utilities/」に
appファイルが格納されている。


あとはApplication Loaderにお任せ。
ただし、このとき、iTune Connectの
登録しようとしているアプリの状態（「Status History」のリンク先）が
「Waiting For Upload」になっていることが必要。


ついでに、この「Application Loader」
生のappファイルは送信ファイルとして選択できない。
release版のappファイルをzipで固めたものが必要になる。
これで準備完了、最後に「Send」ボタンを押せば、
「Status History」に「Upload Received」と「Waiting For Review」が追加され
無事Appleの審査にかけられることになる。


さてさて、あとはリジェクトを食らわないことを祈りつつ、
次のアプリに着手ちゃくしゅ。

アプリサポート用のWebページは必須です。

mac bookを購入して１ヶ月。

ようやくアプリらしいアプリが一本仕上がったので、

早速 iTune Connectに申請をかけようと思ったら、

「アプリサポート用のWebページは必須です」

とツレナイお言葉をいただいた。

大慌てで、このブログを立ち上げる。

今後は、開発したアプリのサポート、iPhoneアプリ開発のメモ、

日々のいろいろをアップしてゆく場になるだろう。

なるべくマメに更新してゆきたい。