2015-07-27

UIViewControllerのview解放の罠

objective-c

こんにちは。
現在キュージーは、次期バージョン v2.3.1 のリリースに向けて最終の調整を行っています。

日々度重なるテストの中で、あれれ、とか、おやおやと思うことも沢山あるわけですが。そんな中でもiOSのバージョン毎にたびたび仕様が変更され、いつまでたっても制御が(自分の中で)安定しない UIViewController 。先日見事にハマってしまった、これの罠についてすこし書こうと思います。
というわけで、今回ははじめて？となる、プログラミングの突っ込んだお話です。

iOSアプリとは必ず何かしらの画面が表示されるもので、プログラムから見ると、その描画作業は UIWindow に格納された UIViewController が担当し、この UIViewController の中の view プロパティ(UIView)が、各パーツを収めた画面要素の集合、つまりカンバスとでも呼ぶべきものとなっています。

通常、このビューコントローラは生成・初期化を経て、以下のような順番でメソッドが呼び出されることにより、描画処理を行います。

alloc -> init (初期化)

loadView (self.view の生成)
viewDidLoad (実際の描画処理など)

そしてデバイスのメモリーが逼迫してくると、

didReceiveMemoryWarning

が呼び出され、可能であればここで描画領域(self.view)を破棄し、メモリの解放を行います。
可能である場合、というのは現在の画面が別のビューコントローラで描画されており、呼び出されたビューコントローラのビュー(self.view)が、実際には表示されていない場合です。

「iOS View Controller プログラミングガイド」は、呼び出されたビューコントローラが実際に表示されているか否かの判定を、以下のようなコードで実装すると解説しています。

if ([self.view window] == nil){

}

UIView の window プロパティは、そのビューが表示されている UIWindow を返します。つまりこの window プロパティが nil の場合、そのビューは実際に画面には表示されていないということになります。
通常、メモリの警告を受け取り、この window プロパティが nil の場合、呼び出されたビューコントローラは自らの描画領域(self.view)を(以下のコードを使って)解放し、同時にメモリの解放を行います。

- (void) didReceiveMemoryWarning ;
{
	[super didReceiveMemoryWarning] ;

	if ([self.view window] == nil){

		self.view = nil ;

	}
}

通常は UIViewController の継承クラスでも同じことを実行すればいいのですが、今回使っていたビューコントローラは UIViewController の孫クラスにあたり、self.view.window プロパティが nil の場合、それぞれの didReceiveMemoryWarning メソッド内で、viewプロパティ以外の解放処理も実行していました。

そしてこの「派生クラスをさかのぼる didReceiveMemoryWarning メソッド呼び出し」の中に、今回のバグの原因が潜んでいたのです。

システムによって派生クラスの didReceiveMemoryWarning メソッドが呼ばれると、先ずは、

[super didReceiveMemoryWarning] ;

として、親クラスの同名メソッドを呼び出します。一番底のクラスにおいて self.view を解放し、それ以降、世代を追ってそれぞれのクラスの解放処理を書くわけですが、当然のことながらどのクラスにおいても、このビューコントローラが実際に描画されているかどうかの判定をすることになるわけです。
つまり、各階層ごとに

[self.view window]

すなわち、

self.view.window

を呼び出すわけですね。

一見まともな処理を書いているように見えますし、自分自身もこれでビューが解放されているものと思い込んでおりました。
しかし、実際にログを吐いて検証してみると、どうやら self.view が nil を代入しているにもかかわらず空白になっていない。そればかりか didReceiveMemoryWarning メソッドのサイクル内で、viewLoad や viewDidLoad メソッドまで呼び出されている始末。

まるでゾンビのようによみがえる self.view に、一時ア然とさせられもしましたが、解決の糸口は前出のプログラミングガイドの中のたった一行、

「以後、viewプロパティがアクセスされれば、初回と同じ手順でビューを再ロードします。」

という所にありました。

"view プロパティがアクセスされれば"

つまり派生クラスの中で、判定のために使用していた self.view.window の self.view の部分が、プログラマの安易な予想に反して view プロパティを再生成し、結果として loadView や viewDidLoad が呼び出されていたということです。

この問題の対応策として、現在は self.view と連動する専用の判別フラグを用意するとともに、派生クラスではこのフラグを元に描画オブジェクトの解放を行っています。

ドキュメントはよく読め、というのが今回の教訓ですが。まあOSの海というのは中々に広漠で、すべてを見渡すというのは難しいものがありますね。というわけで、今回の失敗とリカバリの経験が、何かの参考になりましたら幸いです。

バージョン 2.3.1 のリリースも、ぜしぜしご期待下さいませー。

CueZy開発チーム・三橋

参考：UIViewControllerまとめ
http://qiita.com/edo_m18/items/189acd18f1ecc368b5b0

CueZy Webサイト
日本語 http://www.cuezy.net/jp
English http://www.cuezy.net

CueZy - App Store のページ
日本語
http://itunes.apple.com/jp/app/cuezy-9-pad-sampler/id534202024?mt=8
English
http://itunes.apple.com/us/app/cuezy-9-pad-sampler/id534202024?mt=8

2015-06-02

CueZyの次なる新機能とは！？

開発中ですー。

こんにちは。
開発というのは日々淡々と進むもので、なかなかこれだっていう記事が書けませんね。かといってプログラミングの突っ込んだ所を書くには、それこそ沢山の下準備が必要になってしまいます。いつか『音響アプリの作り方』みたいなシリーズを書いたり、ワークショップをしたり、そんな事をしてみたいと思っています。

と言うわけで、いま開発チームはキュージーのパッドデータを手軽にバックアップできる新機能を実装しています。使用中のオーディオデータを一つにまとめて圧縮できたりと、なかなか便利な機能になりそうです。Dropboxからのダウンロード機能を実装した時にも『プランナーとオペレータを分けられる』というコンセプトがありました。そして今回の新機能は、そのコンセプトをさらに推し進めてくれるのではないかなと期待しています。

たとえば、オペレータが真っ白の iPad を持って現場に向かう。プランナーは事務所で CueZy にオーディオをアサインし、音ネタごとにセッティングを変え、圧縮する。あとはそれを現場に着いたオペレータがダウンロードし解凍すれば、すぐに本番の設定がロードされる。
うーん。これがあれば演出助手さんにも頼みやすいし、プランナーとして稽古場に顔をだす回数が激減してしまうかも知れませんね。うーん。

あ、そういえば。
先日は京丹波町にある旧質美小学校で、Little Seedsさんのアート・イベントがあり、おなじみユリイカ百貨店 + サギノモリラボのメンバーと15分ほどのパフォーマンスをしてきました。

音響屋さんとしても、CueZy開発チームとしてもなかなか得るものが多かったので、その辺りの事、また別の記事にしたいと思いますー。

『BALLOON』というショートストーリー。
風船の真下にあるLEDライトが、天井に摩訶不思議な月影を描いていました。

音楽も効果音も、みんなCueZyで再生！！
音量の上げ下げも、全部フェーダービューでされていました。
ちなみに見える鍵盤は、本物のグランドピアノ！

2015-04-03

録音もお仕事。そして『カムサリ』東京公演せまる！！

テスト中ですー。

こんにちは。

ここのところ開発の記事があまり書けていませんが、残念ながら今回も音響さんのお話です。
開発チーム・三橋が音響をつとめる、ニットキャップシアター『カムサリ』は伊丹公演を終えて、いまは東京公演の稽古が佳境をむかえています。

伊丹公演では、本番の音声収録も行い、そのうちの5チャンネルを使用して、プロモーション映像用に切り出しなどを行いました。

ニットお得意の民族楽器たちや、

コーラスや、ウクレレや、

カホン(という名前の打楽器)の演奏を、

MOTUのオーディオインターフェース(896 mk3)で受けて録音しました。

PA用のコンソールはこんな感じです。

バトンに吊ったガンマイク3本と、PA卓からのミックスが２チャンネル分。
それを波形ソフトで処理します。

(写真の上2トラックは、舞台上のPCCマイクですね。ミックスでは使っていません。)

という訳で、出来上がったPVはこちらです！！

『カムサリ』PV ワッゼェイ！編 https://youtu.be/EsUhlOscHoo

ワッゼェイは鹿児島弁で、とても、とか、すごくという意味。分厚い音楽とともに、役者さんたちのセリフの熱量がビシバシ伝わってきます。

『カムサリ』PV ラップ編 https://youtu.be/dDHZm-Gz3Qc

そしてカムサリは古事記をモチーフにしたお芝居。なんとイザナキとイザナミの物語を、ラップに仕立てて歌っています！！その名も『黄泉平坂 (よもつひらさか)』

ニットキャップシアター第35回公演『カムサリ (神避り)』

東京公演は、座・高円寺1でお待ちしていますー。

2015年 4月 9日［木］〜 12日［日］
　4/9［木］19:00★
　4/10［金］19:00★
　4/11［土］14:00★◎
　4/12［日］14:00

※ 受付開始は開演の60分前。開場は開演の20分前。
★ 終演後、シアタートークを予定。
4/9［木］→『古事記』リーディングイベント
4/10［金］→トークゲスト：三浦佑之（国文学者（古代文学・伝承文学）、千葉大学名誉教授、立正大学教授）
4/11［土］→トークゲスト：北川大輔（王子小劇場芸術監督・カムヰヤッセン）
◎ 託児サービスあり。（劇場までお問い合わせください。）

詳細とご予約は、ニットキャップシアターWEBから！
http://knitcap.jp/35th/

また劇場入りしたら、作業の様子などツイッターでつぶやこうと思います。
それではー。

2015-03-05

ニットキャップシアター『カムサリ』迫る！！

テスト中ですー。

こんにちは。
京都は春を連れてきそうな雨がふったり、また寒さが帰ってきたり。季節のせめぎ合いの狭間にいるようです。今夜はずいぶん寒かったです。

さて、開発チーム・三橋が音響として参加する、ニットキャップシアター『カムサリ (神去り)』いよいよ本番が近づいてきました。

古事記から着想をえて、黄泉平坂(よもつひらさか)という、生と死の境目のような場所を題材にした現代劇。一見して会話劇なのですが、ダンスあり、生演奏ありと盛りだくさんで、90分、けっして飽きさせない舞台に仕上がりつつあります。

そんな詰め込みすぎな舞台演出。音響も大変です。7系統を使って効果音を流しながら、14チャンネル?のバンドPAをします。
稽古場でマイクの本数を数えながら、あれ本当にできるのかな？と思いはじめたので、PA用に新規アプリを作る事にしました。そう、開発です。MIDIコントロールチェンジを記憶して、各シーンのバンドミックスを、エンターキーひとつで順に呼び出します。

まだまだ無骨で必要最低限なインターフェース

商品化はまだ先になりそうですが、同じ技術を使って外部のMIDIパッドからCueZyを操作したり、CueZyのパッドを使って別の外部機器を操作できるようにしたりと。CueZyへのフィードバックもたくさん考えています。
そうです、CueZyは現場生まれの、現場育ち。これからも音響の現場でますますパワーアップしていきます。

幻想的な、どこか懐かしい音色を奏でるアジアの楽器たち。

これはキャストの中谷萌ちゃん作『もえピリンバ』

というわけで、ニットキャップシアターの本公演、どうぞよろしくお願いいたします。
開発チーム・三橋はきっと客席後方の音響ブースにおりますので、もしご来場の際は『CueZyを使っています』と、ぜひぜひお声かけください。

あ、CueZy (キュージー)をまだお使いでない方は、こちらからダウンロードしていただけます。
https://itunes.apple.com/jp/app/cuezy-9-pad-sampler/id534202024?mt=8

ニトッキャップシアター『カムサリ』

伊丹公演 (アイホール)

2015年 3月 13日［金］〜 15日［日］
3/13［金］19:30
3/14［土］14:00 / 19:00
3/15［日］13:00 / 17:00

東京公演 (座・高円寺1)

4/9［木］19:00
4/10［金］19:00
4/11［土］14:00
4/12［日］14:00

カムサリ・特設サイト (WEBからもご予約いただけます)
http://knitcap.jp/35th/

ぜひぜひ、ご来場くださいませー。

2015-01-29

山元ゆり子・作品展『Into your Whirlpool』

テスト中ですー。

こんにちは。
京都はまだまだ、湿り気の多い底冷えのする日々が続いておりますが、みなさまいかがお過ごしでしょうか？
もちろん、開発チームは元気です。

Dropboxからの音源ダウンロードに対応した v2.2.1 や、その修正版のリリースなど、年明けから慌ただしく開発を続けておりますが。それらに平行しながら、CueZy開発の原点でもある舞台芸術への取り組みもしっかりと続いています。

京都を拠点に活動を続けるインスタレーション作家、山元ゆり子さん。
現在開催中の作品展『Into your Whirlpool - 渦の中へ』では、開発チーム・三橋が、音響と照明を統合制御するシステム開発で参加しています。あ、もちろん音響屋さんなので音源づくりもしています。

ギャラリー G-77 にて、山元さん

制御環境には Max/MSP を使い、そこから音響は 5チャンネル (4ch サラウンド + Low)で出力、照明は Doctor MX 経由の 16チャンネルで出力しています。
また、美術の作品展という事で、柔軟なコントロール環境を実現するべく、専用のコントロール用 iPhoneアプリを制作し、MIDI信号のより遠隔操作で Max の制御を行えるようにしています。

こちら Max 動作用の Mac Book と音響システム、とDoctor MX 本体。あとワイヤレス環境の構築に専用の無線LANルータを使っています。ミキサーは簡易の 1U ラインミキサーです。