NSNotificationCenterが便利

iOSのアプリの挙動の中には、ユーザーが操作して変化のトリガーになる場合と、アプリケーションの状態を監視して、変化のトリガーにする場合があります。

ユーザー操作の場合はUI-Kitの中に色々と記述してやれば大抵の事はフォロー出来ますが、アプリケーション側からのアクションは取得する方法が色々あって、殆どケースバイなので、結構めんどいです。おおよそ先に見通して変数化してどこかのトリガーで引っ掛けるんですが、中には取得しにくいパラメーターもあります。

具体例として、音楽プレーヤーの再生ボタンをトグルにしておいて、
・停止中
・再生中
・一時停止中
の３つの状態を持たせたいとします。このうち、再生中と一時停止中に関してはユーザーからのアクションなので問題無いですが、曲の終了時にボタンが停止状態にならなくて困っておりました。これってどこでトリガー取ればいいのかな、と。

で、調べてみるとNSNotificationCenterにブチ当ります。
これが調べてみると中々の優れもので、クラスのinitの際に初期化しておくと、指定したバラメーターの変化のタイミングで指定したセレクタを呼んでくれます。


初期化 viewDidLoadとか。

    MPMusicPlayerController* musicPlayer=[MPMusicPlayerController applicationMusicPlayer];
    NSNotificationCenter *notificationCenter = [NSNotificationCenter defaultCenter];
    [notificationCenter addObserver:self
                           selector:@selector(notificationPlayer)
                               name:MPMusicPlayerControllerPlaybackStateDidChangeNotification
                             object:musicPlayer];
    [musicPlayer beginGeneratingPlaybackNotifications];

んで、指定したセレクタにホニョホニョとコードを書けば、OK牧場です。

 まだちょっとこの辺、理解が足らないんですが、他のパラメーターとかも色々取れれば、今までNSTimerとかに頼っていたダサイ感じの所がスマートに書き換えられる予感です。 自分的にも結構スッキリしました。
さて、仕事しよ。

外注でiPhoneアプリを委託する際の注意

iPhoneアプリを作っていて最近思う事です。 受注する立場からの話。

  ・事前のUI設計は大体上手く行かない 

これは設計のポイントを理解しているベンダーさんならば精度が高く見積もれるのでしょうが、一般的にはそれなりにUI-Kitを使い込んでいても、リリースする段階まで無修正で行く事は中々難しいです。 特に、デザインの段階でデザイナーがUIの挙動を理解していないと、変な物が出来たり、無駄な工数が掛かったりします。 紙やwebでのデザインと、アプリのUIデザインは別物ですので、この分野でそれなりに実績のあるデザイナーさんをアサインする事で、総合的な工数がだいぶ変わります。 また、ある程度デザインも出来るプログラマーが考えたUIの方が、最終的な出来は理に適っている場合が多いので、ワークフローとしてUIデザインはプログラマ主導で設計するのも良いかも知れません。

  ・コアが出来るまでは早い。作業の7割位はUIの調整 

UIをキチンと作り込まないと中身がどんなに高機能でも、低い評価しか得られないというのは最早常識ですが、実際、プログラムの主機能の実装が全体に締める割合はどんどん少なくなっています。原因はライブラリの充実とか色々あるのですが、実際メイン機能が実装完了しても全作業の３分の1位の進捗度という見積もりで良いかと思われます。それくらいUI調整に手戻りが多く、調整がカット＆トライです。また、iOSの場合はメイン機能は全機種ほぼ共通ですが、UIに関しては機種毎に作り込みが必要な為、ここの調整に時間が取られます。機能を盛り込めば盛り込む程、UIに関する作業量も級数的に増えて行くので、企画段階で機能を絞り込むというフェイズを持たないと、リリースまでの工数も掛かるし、あまり良い事は無いです。
”UIの調整ってそんなに時間かかる？”という意見もあるかもですが、その場合は恐らくUIの作り込みが足りません。iPad対応を切れば、だいぶ楽にはなれます。

・iOSは最新の物だけ対応でいいんじゃね？

iOSはアップデート率が非常に高く、iOS6で93%という数字が出ています。
受託仕事で、過去のバージョンまで対応という話は結構あるのですが、7%に目をつぶる事で最新機能を使ったアプリが安い開発費で手に入るというのであれば、十分検討に値するかと思います。というか、iOS4対応必須などは今更だとソコソコしんどいです。
そこは別料金でいんじゃね？と思います。

猫も杓子もアプリと言っていた時代は終わったっぽいので、ここからが本当の勝負でしょう。ベースの機能が一緒でもUIの作り込みが勝って居れば後発でも勝算はあります。
また、今後ビジネスモデルの変遷も見られるかと思います。またここ半年位で状況が大きく変わるんじゃないかな。

iOSでMediaQueryを使った楽曲の取得

今、iPhone向けのアプリを作成中なのです。
ちょっとしたポイントを自分用メモ。

・iPhone内の楽曲の取得について。
iPhone内に入っている楽曲の取得は、簡易に行う場合MPMediaPickerを使用します。
感覚としてはImagePickerの使い方に近く、あまり考える事無く、別Viewが出て来て、選択した楽曲を送り返してくれます。

楽曲は曲単位でユニークなIDが付けられています。
固有なIDはMPMediaItemPropertyPersistentIDを取得すれば得られます。

    MPMediaItem *mediaItem = [[collection items] objectAtIndex:0];

    NSString *songid = [mediaItem valueForProperty:MPMediaItemPropertyPersistentID];//本命。

そんでもって、IDから曲を呼ぶ方法なんですが、次の様な流れになります。

• MPMediaPropertyPredicateに検索したいパラメーターを渡す。（この場合、MPMediaItemPropertyPersistentID）
• ・MPMediaPropertyPredicateをaddFilterPredicate:の形で、MPMediaQuery に渡す。
• ・そうすると条件に合ったQueryがMPMediaQueryに渡ってくるので、これを再生する。

という訳で以下の様になります。

NSString* preId = @"XXXXXXXXXXXX"; //MPMediaItemPropertyPersistentIDを何らかの形で入れる。
MPMediaPropertyPredicate *songFromId =[MPMediaPropertyPredicate predicateWithValue:preId forProperty:MPMediaItemPropertyPersistentID];
MPMediaQuery *songQuery=[[MPMediaQuery alloc]init];
[songQuery addFilterPredicate:songFromId];
[musicPlayer setQueueWithQuery:songQuery];
[musicPlayer play];

これで、指定した任意の楽曲を再生出来ると思います。
もっと効率がイイカンジのやり方（IDだからQueryで渡さんでも良くね?)とか思ってたんですが、このやり方だとAlbum単位での取得とかArtist単位での取得が容易です。
NSUserDefaultとかで保存しておくと、ID無いよって言われる可能性もあるんですが、その辺は未検証です。多分落ちる事はないかなあと。（一旦Queryに入れてるからね。）

ざっとこんな感じでした。さて仕事しよ。

iPhoneのペリフェラル

アイデアに煮詰まったため、一旦初心に却って、iPhoneのペリフェラルを書き出してみる。

・カメラ
・マイク
・スピーカー
・GPS
・ジャイロ
・方位センサー
・LAN
・Bluetooth
・3G回線
・ディスプレイ
・時計
・タッチパネル

こんなもんか。
まだまだ、発見されてないニッチな組み合わせ、ありそうだな。

iTerm2とEmacs

手元のPCのmacbook Airは最低スペックなので、SSDが64Gしかないんだけど、外付けHDDとの併用で何とかダマしダマしでここ２年やってきました。
そろそろ、容量がヤバいので、過去のプロジェクトとか色々と避難させてるんだけれども、どうにも容量が減らない。
仕方が無いので、結構容量を食うiPhoneのバックアップなどを別の容量のデカいPCに移動させたり、使用頻度の低いアプリケーションは削除したりしました。
んで、気になったのが、サーバ系の統合開発環境。NetBeansとEcrips両方入ってます。これ、前々から無駄だなーと思ってたんだけど、そろそろ見直しの時期にさしかかったっぽい感じです。

そんでもって、少し前からサーバ系の開発はEmacsを使う様に心がけようと思ってボチボチ弄ってたんですが、慣れてないのでこれがまぁ、使い難い。でもこういうのは人間を最適化すればいいのポリシーなので、良しとして修行に励む様にしました。

だけんども、標準のターミナルからだと、２画面同じ挙動で使い難いし、なんかやっぱLinuxと違うなぁと思っていたら、iTerm2とかいうターミナルの代替ソフトが良さそうなので、導入してみました。

ついでなので、借りてるVPNにgitサーバ立ててみたり、ステージングサーバとしての役割を強化したりしています。基本をサーバベースの開発に移行、みたいな。

今後の課題としては、折角導入したSassがEmacsだとイマイチ使い方がわかんないので、これを何とかする。（Sass-mode導入)
ソースの色分けとかが全然なので、この辺をカスタムする。
コード補完が無いといちいちググるヘタレなので、コード補完系を何とかしたい。
といった感じ。

今まで、開発環境は用途に応じて使い分けてた派なのですが、代替可能ならば軽量で環境を選ばない方がいいですよね。DreamWeaverが未だに手放せないのは、画像を見ながらのコードへの埋め込みと、テンプレートの適用とか補助機能を使いたい時だったりするので、この辺はちょっと代替は難しいのかなと思ったりします。

まぁ、その辺は適材適所で。原理主義って訳では無いので。

さて仕事しよ。

iOS7のUI部品の変更点

先程、Xcode5を落として来て、既存のプロジェクトをビルドしてみました。

結果、UI部品に関するコードの互換性はまぁ、大体維持されている感じ。
目につく所では、ボタンのUIButtonTypeRoundedRectとか枠が無くなっちゃってたり、TableViewのGroupedの表示が結構変わってたり、Xibファイルを開くとiOS7仕様にアップグレードしろって言って来るし、結構めんどうな感じです。

見た目に拘るクライアントさんのアプリのアップデートとかは結構揉めそうな感じですね。

今までのUI部品を標準で使ってた（カスタムしないでそのまま出してた）場合、フォントとか文字サイズは結構いい感じに置換されてます。が、色々カスタムしていた場合、指定通りの表示で来るので、再構築が結構めんどくさそうな印象。あと、新デザインの全体傾向として、日本語フォントとの相性も悪そうな印象。

互換性対応が難儀しそうな感じなのですが、正式リリースがアナウンスされている秋頃までには何とかなるっしょ。

#2013/6/14追記

その後、少しUI部品を触ってみた所、見た目が変わる物の、機能や操作感はほぼ同じ感じなので、やはり今からリリース予定のアプリはデザイン的にiOS7に移行した後も違和感ないデザインで作成するのが最適解っぽいです。

iPhoneアプリのUIカスタムについて考えてみる。

御無沙汰です。

昨夜ですか．WWDCでIOS7が発表になりましたね。

UIもガラッと変わって、かなり今っぽい感じです。

やはりiOSが出てからもう四年ですか？そうなると流行りのデザインも変遷して行こうというもの。時の立つのは早いです。

ここの所、iOSの案件多めでこなしているのですが、ちょっとUIについて分かって来た気になったので、思う所を書き散らかしてみたいと思います。

iOS7になって気になるのが、UIキットの変更です。

ボタンとか、諸々のデザインは旧IOSに合わせて作られていたために、恐らく新デザインでは違和感出ると思います。部品の内容は同じでガワだけ差し替える感じになるとは思うのですが、そうなると、コードの互換性は保たれたとしても、見た目が変わってしまうのがどう処理されるのか非常に気になる所であります。

丁度最近、標準のUIキット部品を使って作業するのも何かかっこ悪いという風潮がチラホラと意見ベースでは聞いたりします。まぁ、工数考えるとやはり標準UIキットを使って作った方が格段に早いので、結局実現はしないんですがね。

で、仮に工数が無視出来るとして、考えられるアプローチとしては、CALAYERを使った画面遷移なのかなと思ってたりします。

どういう事かと言うと、ひとつのViewControllerに複数のViewを配置しておき、常態遷移のポイントで、座標を弄ってコントロールする方法です。

この方法は今っぽいデザインを割と簡単に実現可能ですし、標準UIキットで用意されている部品も、普通に混在出来たりします。

ちょっとUI凝ってるなと思ったアプリは大体この方法で作られてたりするので、気が向いたらサンプル込みで解説したりしようかなとおもいます。

さて、仕事しよ。

#2013/6/12追記

 AppleのUIに関するドキュメントが出てたみたいだからチラ見してみたんだけど、やはりiOS6系とiOS7では両対応する為には、OSのバージョン検出して、出し分けをする必要があるみたい。レイアウトの自動化が進む為に、storyborad推奨とかとも読み取れる。
結構面倒ではあるが、この辺をもう少し読み込む必要がありそう。