続、サルりすってこんなアプリ

まだ原稿書いてるんですわ。

アプリを作るときに必要になるものはなんだろう。それはズバリ「愛」である。なんと言われようと愛が大事なのだ。愛のないアプリなんぞ、七味の入っていない蕎麦のようなものである。合ってますか。この例え。愛と言ったが、「ゲームちゅあーん」と言うような類のものではない。人目につかないところでそうすることは別に止めないが。もう少し誤解のないように言うと、愛着、と言ったほうが良いだろう。技術の前に、愛着を持って取り組むことが大事なのだ。

もう少しだけ掘り下げておこう。ワタシの過去の経験則から言って、「何を作っているかよくわからないけど、作れと言われたから作った」というモノほど、バグが出やすいものは無いのである。それはそうだろう、そのテキストフィールドにどんなデータを入力するのかを知らないし、知ろうとも思わないような人が、細かいチェックなどできるハズがない。結果、とりあえずそれっぽい見た目のモノが出来上がってしまうのである。この負の連鎖に陥らないためには、作るものを徹底的に知っておくことが必要なのだ。それには、愛着が要るのである。

すっかり精神論になってしまったので話を戻そう。今回のサンプルアプリ、サルりすを作るにあたって、我々は、まずこのアプリに必要以上の愛を注ぎこむことにした。技術力の無さをカバーするためじゃね?そういう話もある。ただ、本当にそれは必要なのだ。イイモノを作るためには。

まず、ストーリーを考えよう
ゲームを作ったこともないような素人がいきなり新作ゲームを考えると、こうなる。

どーだスゴイだろう。ニッポンの大人はこんなに病んでいるんだよ。黒い感情を埋めて埋めて埋めまくってやるぜ。ゴールなんて無え。後に残るのは無数の墓標と虚無感だけだ。

…えーと。さすがにコレはまずかろう、ということで、我々は考え方を変えることにした。何か面白いものを作ろうと思うと、人はどうしても仕組みの面白さに集中してしまう。否。ゲームは仕組みだけで出来上がるにあらず。ストーリーで楽しませることもできるものなのだ。楽しい世界を味わうための方法がたまたまゲームだった。そんな考え方、なんだか素敵でしょう?

森の動物達が楽しく遊んでくれるのはどうだろう。サルとか、ゾウとか、ウマとか。みんなにはいろんな力があって、それが遊びをより面白くしてくれるのだ。やさしい子もいれば、イジワルな子もいる。でもみんなで遊べばもっと面白い。さあ。キミもおいでよ!

…はいはーい。みなさま。帰ってきていただいてよろしいでしょうか。大の大人が、恥ずかしげもなく、真顔でこういうことを熱く語り合う。それがイイのだ。ユーザーさん達にそのストーリーを楽しんでもらおうと思っているのに、自分たちがストーリーを小っ恥ずかしがっていては始らない。目一杯時間を取って欲しい。紅茶でも入れて、ポンデリングでも買ってきて。非日常感にワクワクしつつ、今日だけは子供に戻って、リラックスして考えよう。

ストーリーができたら、次は絵を描こう
大半の人間様は、実際に目で見ないことにはイメージが湧かない。どんな素晴らしいストーリーができあがったとしても、3人で話し合っていたら、3人の頭の中に浮かんでいる絵はまず間違いなくバラバラなのだ。なので、下手でも何でも、目に見えるように絵を描くことがとても大事になる。場面設定、キャラクター、どんどん描いていこう。複数のページに及ぶような場合も、全ページ分描くこと。頭の中に残っているものを無くすことが、今の段階の目的である。

我々のサルりすは、最初こんな感じ。

いかがだろう。ワクワクしてくれるだろうか。伝わっているかどうかが物凄く心配だが、話し合っているときは大盛り上がりだったのだ。「ネコでしょネコ!やっぱライオンは入れておかないとさー!」「落ちゲーでこんな世界観無いよね。癒し系落ちゲー、ブームになったりして」夢はどこまでも膨らんでいくのである。

そしてそれを、絵を描ける人が描くとこう。

「キャー!ナニコレ。超カワイイ。グッズ行けるよグッズ!」我々の妄想は、既に世界を獲ったくらいの勢いである。プログラミングを始める前にこれくらいテンションが上がれば、大抵のキツイプログラミング作業も乗り切れる。プロはスゲェ、あっと驚くような見た目になる。ただ、順番からすると、自分で描いて、任せる。が正しい。全てを任せてしまっては自分のものにはならない。なんなら自分の絵でいいじゃないか。それはそれで、世界でひとつしかないアプリになるのだから。

ここからプログラムに触れる
充分にモチベーションが上がったら、いよいよプログラミングである。このサルりす。プログラム開始から終了まで、ダラダラダラダラやって結局4ヶ月くらいかかってしまった。当初は、2ヶ月くらいでできるかなーと、たかをくくっていたのだが、やればやるほど、「もうちょっとココをこうしたい」というアイデアが出てきてしまって、収集が付かなかったのである。

プログラミングは結構時間がかかる。問題は、そのかかっている時間に、我々は「いろいろ考える」のだ。考えた結果、当初想定よりも良いアプリになることも多々ある。が、反対に、当初の目的がすっかり抜けてしまうことも多々ある。だからこそ、最初にどれだけストーリーと絵をしっかり作っておけるか、ということが大事になってくる。サルりすはある程度時間に余裕がある中でできたから良かったものの、短期勝負で作るアプリの場合は、できるだけしっかり事前準備に時間をかけよう。

音を追加してみよう
プログラムをある程度組んで、ボタンやら画面遷移やらが出来てきたら、効果音を鳴らしてみよう。ワタシはあまり音に対して気にするタイプでも無かったので、正直効果音をあまり重要視していなかった。サルりすについても、最初の頃は、「ま、ゲームだしね。音が鳴らないのもカッコ悪いでしょ」くらいの認識だったのである。ところがどっこい。半完成品に音を足してみて驚いた。どうやら音というものは人間の感覚にダイレクトに訴えるものらしい。それまで自分が作っていたプラモデルが、突然言葉を喋ったくらいの劇的な進化を遂げたのである。

ただ、音作りは難しい。カエルの歌、もしくは猫踏んじゃったクラスのワタシの音楽スキルでは、まず何からしていいかわからない。こういうときにアップルは、「ほら!ガレージバンドがあるよ!」とオススメしてくる。うーむ。それもムズカシいんだよねー。そうなったら最後は素材集に頼ろう。インターネット上は数多くの音源が配布されている。アプリでも利用可能な無料音源を探すもよし、ハイグレードな有料音源を買うもよし。

音作りができる方が周りにいれば、ぜひお願いしてみよう。オリジナルの曲なら、アプリができあがったときの感動が違う。

ラストスパート、翻訳に挑戦しよう
愛着バリバリ、まるで我が子のように作ってきたサルりす。ここまできたら、ということで最後は海外対応までしてみることに。ええ、もちろんワタシの貧素な英語では対応になりませんのでして、それ相応のスペシャリストさんにお願いしたわけなのですが。これがもう大正解。

リリースしてからびっくりしましたけど、ガツンガツン海の向こうからダウンロードされました。アメリカ?いえいえ、そんな遠い海の向こうではなく、すぐお隣りの中国です。ビバ10億パワー。カスっただけでものすごいインパクト。你好中国のみなさま。サルりす楽しんでいただけましたか?

長きに渡って作ってきたサルりす。その割にリリース時にゲームセンターの登録をミスったりしていましたが、作ってる方は道中を楽しんで作ってきました。やっぱり愛だよね、愛。我々制作側の無駄に熱い想いが詰まったサルりすは、ダウンロードサイトからソースコードまるごとダウンロードすることが可能です。本に書ききれない部分は「コメント」として書いていますので、そちらもお楽しみくださいませ。

※この記事は今度出す本の下書きの下書きです。
※全ボツになることもありますので、番外編としてお楽しみください。

メモリー管理ちょっとだけ

ここで一旦終了。デリゲートをどうしようか検討中。

知らなくても特別困らないけど、知ってみるとより面白くなった。そんなこと、ないだろうか。ワタシの場合は、ネコの飼育である(iPhoneアプリ開発じゃないんかい)。コンゴウフグよりデカイ生き物を飼ったことがないワタシだったのだが、とあるきっかけで子猫を飼うことになってしまった。当初ワタシは、「ネコはイヌと違って散歩しなくていいし、構わなくても寂しがったりしないし、比較的大人の付き合いができるのではないか」と、ググッた結果の都合がいい部分のみを頭の中に格納して、勝利を確信していたのである。が、事実は小説より奇なり、とはよく言ったもので。我が家にやってきた子猫は、朝晩問わず部屋の中を走りまわり、「構われていない」と感じると大声で鳴き喚き、どう認識しているのかワタシの手首をありったけの力で噛み続けるという、甘ったれニャンコに成長してしまった。名前を「まろ」と言う。まったく。こいつめ。ワタシの作業机の上(お気に入りの場所らしい)で呑気に居眠りしおって。メチャクチャカワイイじゃないか。

こう言うと多くの開発者さんからお叱りを受けそうだが、iPhoneアプリにおける、メモリー管理というヤツは、ワタシにとっては、「知らなくても特別困らないけど、知ってみるとより面白くなるもの」程度の認識なのである。きっと知ってみると面白さが出てくるとは思うのだが、iPhone自身が健気に頑張って、プログラムに潜むメモリー関連のトラブルを回避してくれたりするので、目くじらを立てて意識しておかなくても、結構なんとかなってしまったりして、どうしてもやる気になれない(崖っぷちを全力疾走するような危うい考え方なので、良い子のみんなは表立って真似しないでネ)。偉いぞ、iPhone、褒めてつかわす。だったのだが。iOS5からARC(Automatic Reference Counting)なる仕組みが導入されて、今後はいろいろと便利になりそうな気配がプンプンしている。「オイシそうな波には乗っておけ」ということで、今回はメモリー管理について、そーっと触れてみよう。

メモリー管理、読んで字のごとく、「メモリーを管理すること」という意味である。メモリー、コンピューター君が何か処理をするときに、バサーっとノートやら鉛筆やらを広げるための作業台のことである(ついでに、この説明を延長すると、CPUはコンピューター君自身の頭脳、ハードディスクドライブはノートや鉛筆、参考書類をしまっておく棚、となる)。iPhoneもコンピューターなのでメモリーは当然組み込まれていて、新しい機種の場合、512MBという広々とした作業台が用意されている。とは言え、この作業台。プログラムの中で、沢山の値を取り扱ったり、各種ビューを作ったりしていると、徐々に空いている部分が少なくなっていき、やがては、出版社の編集者さんの机のような、「コーヒーの置き場もない状態(注:イメージです)」になってしまう。画面フリーズ&強制終了まっしぐら、これはマズイ。そういうことが起こらないように、「片付ける技術」を存分に活かそう、というのが、管理と呼ばれる部分なのだ。

机の上を常にキレイにしつつ作業をする。そんなときに、アナタはどうしているだろう。作業はしないといけないので、紙や鉛筆、参考書類が机の上に出てきてしまうのは仕方がない。大事なのは、出したものを、出しっ放しにしておかない、ということである。一本鉛筆を出して、メモを取って、その鉛筆を机の上に置いた状態で、もう一本鉛筆を出す。こうすると、使っていない方の鉛筆は、机のスペースを狭くする、単なる邪魔者になってしまう。同じ鉛筆を使い回すか、一度しまって、あらためて別の鉛筆を出すか。細かいことなのだが、それを徹底することが、机をキレイに使う一番簡単なコツなのである。

iPhoneアプリのプログラムの中でも、変数やビューは、登場させるだけでしっかりメモリーを消費している。それを、机と同じように、適切にしまっていくこと、しまい方を覚えることが、メモリー管理においても大事なポイントなのだ。まずは、今アナタの目の前にある作業机の上を片付けることからはじめよう。机の上がスッキリすれば、頭もスッキリするはずだ。ワタシも、目の前の机の上で寝ているニャンコをどけるところからはじめようと思う。よーしよーし。ゴロゴロゴロ。カーワーウィウィー。仕方がないなあ、おやつの煮干をあげよう(片付けられないタイプ)。

※この記事は今度出す本の下書きの下書きです。
※全ボツになることもありますので、番外編としてお楽しみください。

【業務連絡】
メモリー管理の説明(イラストあり?)が続きます。

オブジェクト指向はじめの一歩

説明できる、自信なし。

オブジェクト指向。来ましたよ、ついにこのネタを取り扱うページが。プログラムをやっていると、誰しも一度は目にするアイツ、多くのチャレンジャーを闇に飲み込んできたアイツ。そう、その名もオブジェクト指向である。あらためて言うまでもなく、ほとんどの人が思っているであろう言葉を代弁しよう。「そもそも、『オブジェクト指向』という言葉の意味がわかりません」、ですな。直訳にも程があるというか、訳せてもいないというか。ワタシは最初オブジェクト指向と聞いて、心理学的な何かを想像していた。丸いものより四角いもののほうが好きなアナタは几帳面デース、みたいな。

こういう、いかにもムズカシそうなことをお話しするときには、コツがある。それは、「楽しく行こう」ということなのだ。どうせ100%スパッとわかるハズがないし、わかったところで今は使う場面もない。だったら、なんとなく「楽しそうなお話」という印象が残っていたほうが、後で本格的に勉強する際に助かるのである。楽しく行こう。オブジェクト指向。

はい、今から30秒ほど息を止めまーす。せーの。「オブジェクト指向とは、プログラムを組み立てる上での、ひとつの考え方のことである。プログラムというのは、機械が命令を順番に処理して、結果的に狙い通りのことができれば、正解、となるわけだ。逆に言えば、結果は決められた通りにできなければいけないものの、過程はあまり縛りがない。なので、昔のプログラムは、命令を機能の順番に書いて、ゴールまでたどり着かせる。という考え方が一般的だった。そんな中、「もっと効率よく、もっと便利に」、プログラムを書くための考え方を、頭のいい人達が研究したのだ。誰ですか?ちっ、余計なことを…と言ってる人は。その、ひとつの考え方が、オブジェクト(もの)中心に考える、オブジェクト指向、と呼ばれるものなのである」。はい、おつかれさまでしたー。

成り立ちから見ていくと、とてもわかりやすい出来上がり方をしているのがわかると思う。オブジェクト指向は、プログラムをより便利に書くための考え方であって、決して、ムズカシくしてやろうというイジワルな想いで出来上がっているわけではないのである。オブジェクト指向=良いヤツ。覚えておこう。

オブジェクト指向の具体的な考え方は、よく設計図と量産品に例えられる。今回は…何にしよう。うーむ。では、とある有名なモンスターでお話を進めていこう。ドラゴンクエストというゲームで出てくる、プヨンとした青色の半笑いモンスター、スライムというヤツをご存知だろうか。物語の序盤に出てきて、非常に弱い。世界の安全性を訴える役割を担っているモンスターである。コイツは、まず単体では出てこない。常に全く同じ見た目の仲間を引き連れて登場してくる。全員真っ青。全員半笑い。

こいつの亜種に、スライムベスというヤツと、ホイミスライムというヤツがいる。前者は赤いボディが特徴で、後者はクラゲ状の足が生えているのが特徴となっている。多少体力があったり、呪文が使えたり、それくらいの差異はあるのだが、コイツらは同じ郷土出身だ、と思えるほど、似通った部分が多い。世界にはそっくりな見た目をもった人が3人くらいいるらしいが、それにしてもコイツらは似すぎている。全員プヨプヨ。全員半笑い。

以上のイメージが頭の中に浮かんだら、オブジェクト指向はもうわかったも同然である。やったぜ。順にそれっぽくしていこう。アナタがこのゲームの開発者だったとして、ゲームの世界にスライム軍団を生み出す場合、すべての基本形になっているのが、スライムである。厳密に言ってしまえば、スライムの設計図、ということになる。設計図さえあれば、何匹でもスライムを生み出すことができるわけだ。この設計図のことを、クラスと言う。クラスは、「変数」と「メソッド」と呼ばれるもので出来ていて、スライムに例えると、変数は色や形、体力値や攻撃力などの、値。メソッドは、攻撃したり逃げ出したりする、振る舞い。その辺りがしっかり決まっていれば、同じスライムを何匹でも量産できるようになる。この量産されたスライムを、インスタンスと言う。

さらに、基本形があれば、基本形にちょっとだけ足したり引いたりすることで、スライムベスやホイミスライムを作ることができる。これを「クラスの継承」という。基本のスライムの設計図を一式作っておいて、まずはそれを量産(インスタンス化)。必要に応じて、チョイ足し、チョイ引きをしたクラスを複製編集(継承)して、それも量産。こうして、勇者から城から、全部の「もの」を作っていって、ゴールまでたどり着かせてしまう考え方、これをオブジェクト指向と呼ぶのである。

「どこが楽しいんじゃい!」という声が聞こえてくる気がする。え?楽しくなかった?楽しかったでしょう、あの頃の思い出がよみがえってきて。ワタシはこのムズカシいオブジェクト指向のことを考えるときは、こういう丸いもので頭をいっぱいにすることにしている。几帳面すぎないくらいが、きっと丁度いいのだ。

※この記事は今度出す本の下書きの下書きです。
※全ボツになることもありますので、番外編としてお楽しみください。

【業務連絡】
オブジェクト指向の説明(イラストあり?)が続きます。

タブバーを作ろう

午後の悪魔的な眠気はなんとかならないものか。

住宅事情のお話、続き。その昔、ワタシは旅行で香港に行ったことがある。香港はとてもエネルギッシュな街で、その刺激的な甘さと濃さは、若いワタシに多くの影響を与えてくれた。メシのウマイ街は、良い街だ。ただ、香港でワタシが一番印象に残っているのは、残念ながらメシのことではない。街中にニョキニョキ建っている、細長過ぎる建物のことなのである。細長過ぎる建物。伝わるだろうか。「ワンルームくらいの敷地面積で、フロアが数十階」、という建物なのだ。ちょっと押したら倒れそう。全盛期の小錦が、三人くらい部屋の片側に座ったら絶対アウト。香港の街には、そこら中にそんな建物が建っているのである。「根性が違う」、そんなことを思ったのを覚えている。

iPhoneアプリの画面は狭い。iPadですら、通常のデスクトップパソコンに比べたら、ずっとコンパクトにできている。狭いということは、つまり、ひとつの画面で、できることの絶対量が少ない、ということである。どんなに暇を持て余したスーパーエンジニアが、連日徹夜で作ったとしても、書ききれる文字数や表示できるフォントの大きさにそもそも差があるのだ、どうしたって小ぢんまりしてしまう(同じような文章をどこかで読んだ気がする?奇遇ですね、ワタシもです)。

その狭いスペースをどう有効に使うか、その工夫のひとつが、タブバーである。タブバーの発想は、香港式高層マンションの考えに似ている。何枚も何枚も重ねたビューを切り替えることで、空間を立体的に増やしてしまおう、ということなのだ。

ここで少々機能の違いについてお話ししておこう。タブバーと、とてもよく似た雰囲気の機能、ツールバーとの違いである。ワタシ、こんな感じに説明しましたね。「ツールバーの発想は、システムキッチンとかユニットバスの考えに似ている。空間自体を広く使うために、ボタン類をまとめて収納してしまおう、ということなのだ。」と。ツールバーは、UIViewから派生したクラスで、コイツの正体は、ビューである。つまり、ボタンやラベルと同様、あくまでひとつの「見た目」なのだ。

それに比べて、タブバーは、後ろにタブバーコントローラーなる、機能がくっついている。タブバー自身はツールバーと同じくUIViewから派生したクラスなのだが、タブバーコントローラーは、UIViewControllerから派生したクラス、なのである。うわぁ、なんだかヤバい雰囲気がする、そんな感じに思われている諸兄。スルドイ。確かにこいつは、深追いすると少々面倒くさいシロモノなのだ。ただ、今はそこまで追いかける必要はない。必要なことだけ、サラッと覚えてしまおう。UIViewControllerは、ビューの「遷移」を管理しているクラス、つまり、複数のビューを切り替える「機能」なのだ。

いたたた、頭痛が痛い。もう少し簡単な使い分け方を伝授しておこう。要は、その画面の中で使う機能を呼び出すボタンを設置したいならツールバーを、複数の画面を切り替えるためのボタンを設置したいならタブバーを、選べばいい。はい、解散。おつかれさまでした。

狭いiPhoneアプリ画面を、広く使うのはアナタの腕次第である。「たったこれだけ?」と思ったら、実は超高層マンションだった。そんなエネルギッシュでオトクなアプリ作りに、ぜひ挑戦して欲しい。

※この記事は今度出す本の下書きの下書きです。
※全ボツになることもありますので、番外編としてお楽しみください。

【業務連絡】
タブバーの画面が続きます。

ツールバーを作ろう

ぼちぼちコラムパートが終わります。ふ〜。

日本の住宅を指して、「ウサギ小屋」と言うことがある。日本の住宅は狭い。確かに狭い。ワタシも社会人になってからずーっと都心の賃貸マンションに住んでいるが、部屋が広くて困る、などといったことを悩んだことは一瞬たりともない。おかしなもので、既にちまっとした狭さに身体が慣れてしまっているので、大して不満もないのである。部屋に置く家具も、自然にコンパクト&まとまった機能のものを好むようになってしまった。広大なリビングなど与えられてしまったら、ワタシはおそらく、その一角に「ミニリビング」を作るのだろう。いいんだもんね、掃除楽だし。

iPhoneアプリの画面は狭い。iPadですら、通常のデスクトップパソコンに比べたら、ずっとコンパクトにできている。狭いということは、つまり、ひとつの画面で、できることの絶対量が少ない、ということである。どんなに高い技術を持った開発会社が、総力を挙げて作ったとしても、並べられる画像やボタンの量にそもそも差があるのだ、どうしたって小ぢんまりしてしまう。

その狭いスペースをどう有効に使うか、その工夫のひとつが、ツールバーである。ツールバーの発想は、住宅に置き換えると、システムキッチンとかユニットバスの考えに似ている。空間自体を広く使うために、ボタン類をまとめて収納してしまおう、ということなのだ。

ツールバーをシステムキッチンに例えると、ひとつひとつの機器、シンクとか、オーブンとか、食洗機とかを、バーボタンアイテムと言う。iPhoneアプリに置き換えると、保存ボタンとか、カメラボタンとか、再生ボタンとか、どこかで見たようなお馴染みのボタンになる。沢山のボタンが予め用意されているので、自分でボタン一式を作るよりもずっと簡単に組み込むことができる。と、言いたいところなのだが、予め用意されているのは、画像だけで、機能は自分で作りこまないといけない。オーブンのガワはすぐできるので、配線を済ませて、肉を買ってこよう。

バーボタンアイテムをポンポンと並べたら、最後にシステムキッチン、もとい、ツールバー自体を、ビューに貼り付けて完了である。スッキリコンパクト、この部分にボタンをまとめてしまえば、余った空間は広々と使うことができる。まさに工夫の勝利だ。

狭いiPhoneアプリ画面を、広く使うのはアナタの腕次第である。「狭い画面の中に、機能がよくまとまってるな〜」と思わせることができたら、アナタのアプリ設計技術は、一級建築士にも劣らない。「なんということでしょう」、そんなナレーションが流れてくるような、iPhoneアプリ空間設計の魔術師を目指して、ぜひ挑戦して欲しい。

※この記事は今度出す本の下書きの下書きです。
※全ボツになることもありますので、番外編としてお楽しみください。

【業務連絡】
ツールバーの画面が続きます。

インジケーターで間をつなごう

一転して今日はどんより曇り空。寒さが刺さりますね。

冬のある日。ある教室にて。いつものと同じ風景。いつもと同じ顔ぶれ。始業前の、何気ない時間。「今日は寒いねー」「ホント、寒いねー」「あ、鼻赤いよ」「自転車通学ですから」「今日の一限ってなんだっけ?」「国語、現国」「宿題やってきた?」「アタシに聞く?」「あ、そうそう」「何?」「来るとき霜柱が立ってたよ」「うわー」「もう、『地面もこーるど』。って感じだよねー」「―――」。無限に続くかのような空白の時間。真っ白だ。何も見えない。相手の顔も、自分が今から言うべき言葉も、何も見えない。ただ、一面の、白―――。

学校で、職場で、ついうっかり、または確信犯的に、このような時間を作ってしまったこと、アナタもあるでしょう。無いなんて言わせない。ワタシも、もちろんある。そしてそれは、年々増加傾向である。このまま行けば、10秒くらいは時を止められるようになるのではないかとも思う。「能力は望んだ人にのみ与えられるわけではない」、という言葉を今グッと噛み締めている。ワタシが欲しかった能力はこれではないのです。そんな、なんとも言えない間。今回は、iPhoneアプリの中で、こういう「間」を見事につないでくれる、便利な機能をふたつほど紹介しよう。

iPhoneアプリの中で、何か処理をしているときに、間をつないでくれる便利機能その1。名前をアクティビティインジケーターと言う。日本語にすると、「活動状態表示計」とでも言うのだろうか。iPhoneアプリや、Webサイトで、何かの処理をしているときに、クルンクルンと回転している円形の物体、「今まさに処理中ですよ〜」ということをわかりやすく表現してくれる、アレ。あれがアクティビティインジケーターである。

心臓を叩いて聞いていただきたいのだが、アクティビティインジケーターは、「ただ回っているだけ」だったりする。処理のスムーズさをリアルタイムに計測している?ダウンロードのスピードを表している?ノンノン。あいつは、ただ回るだけの画像ビューなのだ。それだけの機能しかないので、設置にムズカシさはまったく無い。アナタが何かの処理を作ったときに、いかにも「間ができるな〜」というタイミングがあったら、ちょいっとビューを追加して、「回れ」と処理すれば終わりである。処理が完了したら、取り外せばいなくなる。サンタさんなんて、いないだぜ、ボウズ。

iPhoneアプリの中で、何か処理をしているときに、間をつないでくれる便利機能その2。名前をプログレスバーと言う。こちらも無理やり日本語にすると、「進行状況確認バー」とでも言うのだろうか。バー、英語だけど。アクティビティインジケーター同様に、iPhoneアプリや、Webサイトで、何かの処理をしているときに、「今何パーセントくらい処理しましたよ〜」ということをわかりやすく表現してくれる、アレ。あれがプログレスバーである。

こちらはある意味期待通りの機能が搭載されていて、分子と分母に該当する値を設定することで、「ちゃんとした」進行状況の表示ができるようになっている。25%処理完了、と言ったら、25%終わっているのだ。まあ、その分子と分母をどうやって算出するの?ということは、各プログラムとプログラマーに丸投げされているので、ちゃんと表示させようと思ったら、結構シンドかったりするのですが。美味しい話には、裏があるんだぜ、ボウズ。

一応注意をしておくが、上記の方法でつないでくれるのは、iPhoneアプリの中の間だけである。現実世界は対象外だ。自分自身でつながなければならなくなった場合は、胸を張って、大きく生きを吸い込んで、自信たっぷりに、こう言おう。「うっそぴょーん」

※この記事は今度出す本の下書きの下書きです。
※全ボツになることもありますので、番外編としてお楽しみください。

【業務連絡】
インジケーター&プログレスバーの画面が続きます。

SQLiteにデータを保存しよう

部屋の湿度がようやく安定。加湿器二台稼働中。

「いや〜、昨日ウチの顧客データベースが飛んじゃってさ〜」「マジで?アレってこの間移行したばっかりじゃない?」「そうなのよ、とりあえずバックアップがあったから助かったんだけどね」「おお〜、良かったねぇ〜」。さて、今回はデータベースのお話である。データベース。とりあえずこの単語が出てくると、「システムに詳しそう」という雰囲気がプンプンしてくる。メガネスーツの彼、パソコンのキーボードを叩きながら、「え?オレ?データベース一級」。なんのことだかよくわからないけれども、合コンでモテそうである。デキるオトコの、データベース。

データベースって何だろう。ワタシは、この質問に対してこう答えることにしている。データベースとは「姿が見えないExcelのお化け」である、と。まず、そもそもデータベースとは、データを管理するための仕組み、なのである。うーむ。このままでは少々ムズカシイですな。「データ」つまり、数値や文字列を、「管理」つまり、保存しておいて、必要に応じて取り出す。ための仕組み、と言ったらどうだろう。なんとなくわかるだろうか。この手の用途で使われる最も一般的なツールが、毎度おなじみ、Excelというツールである。

Excelは、画面からユーザーがデータをイジることを前提としたツールなので、縦横のマス目がビッシリ並んだ、あんな感じの見た目になっている。あれでも一応わかりやすい見た目、という設定なのである。コンピューターの世界って怖ぇ。そのユーザーフレンドリー(?)なExcelに対して、プログラムからイジるから見た目はどうでもいいや、ということで、バッサリ見た目部分を削って、その代わりに、Excelよりもずっと多くのデータを管理できるようにしたものが、データベースである。「姿が見えないExcelのお化け」、いかがだろう。

iPhoneの中には、SQLite(エスキューライト)というデータベースが予め組み込まれている。これをプログラム上から呼び出すことで、データの保存と取り出しが可能になる。SQLiteは、アプリ自体からは独立しているので、アプリを終了しても、データは残り続ける。おや?どこかで似たような話を聞いたような。そう、ユーザーデフォルトだ。あれも同じように、保存する場所がアプリから独立しているので、アプリを終了しても、データを残しておくことができた。一見似たような機能なのだが、SQLiteはデータベースの名前のとおり、大量のデータを保存しておくのに向いている。用途に合わせて使いわけよう。

ここから一気にSQLiteの説明を…と行きたいところなのだが。残念なことに、SQLiteを使うのは結構ムズカシイ。使えるように設定するためにもやらなければならないことはあるし、使えるようになったとしても、データの出し入れは「SQL(エスキューエル)」という特別な書き方を覚えなければならない。SQL自体は、Webの世界でも広く使われているものなので、一旦使えるようになってしまえば非常に応用が利くのだが、ゼロからやろうとすると、それなりに腹をくくる必要が出てくるのだ。なので、ここでは、概要の説明と、FMDBというライブラリ(お助けプログラム)を使った接続方法にとどめることにする。今は、そんなものもあるんだ、程度で気楽に読んで欲しい。

ワタシは、システム屋になった一番最初に、オラクル社のデータベースをしこたま使うプロジェクトに配属されたため、なにがなんだかわからないうちにSQLを叩き込まれた。ひとつのデータを取り出すのに、なんでこんなに面倒なやり方をするのだろうと、ブツクサ言いながら勉強したものである。今になって思うと、その機会は実に有意義だった。SQL、ホントに結構使えるんです、あっちこっちで。この機会に、気合入れてデータベースを覚えよう、と思ったら、専門書を一冊お買い上げいただくことをオススメする。iPhoneアプリ開発から、さらに深い世界に出発だ。じっくり覚えて、目指せモテモテ!

※この記事は今度出す本の下書きの下書きです。
※全ボツになることもありますので、番外編としてお楽しみください。

【業務連絡】
SQLite概要とFMDBの説明が続きます。

UserDefaultにデータを保存しよう

体調が良くなってきました。いい薬が見つかった模様。

「おきのどくですが ぼうけんのしょは きえてしまいました」。この言葉を聞くと、ブワッとイヤな記憶が蘇える方、大勢いるのではないだろうか。一世を風靡したRPG(ロールプレイングゲーム)、ドラゴンクエストにおける、セーブデータが消えたときのメッセージである。RPGという種類のゲームは、一連のストーリーが長大に作られており、その長い旅路を一度にプレイすることができないため、道中、現在の状況をデータとして保存しつつ進めていく、というのがお約束なのだが、諸般の事情(カセットを落としたり、雑に扱ったり)でデータが消えてしまうことがまれにある。そんなとき、とっても不吉なサウンドと共に、このメッセージが表示されるのだ。ああ、古傷が痛む。

そういえば、iPhoneアプリって、データをセーブすることができるのだろうか。という素朴な疑問について、今回は考えてみよう。今まで見てきた各種変数。あれは確かにデータを保持してくれているのだが、あくまでもひとつのアプリ内でのみ有効な機能なので、アプリを終了してしまったら、保持していた値も全部一緒に消えてしまいそうに思える。当然だ。アプリはあくまでアプリなので、終わるときには、むしろ綺麗サッパリ終わってしまわないと逆に問題なのだ。つまり、セーブするということは、iOSとか、iPhoneとか、そういう「もう一段上」の部分で、データの保存ができないといけないことになる。そんなこと、できるのだろうか。

その答えは、「できる」が正解である。しかも、「超簡単に」できる。そんなリクエストもあろうかと、アップルの方で事前にしっかり考えられていたらしい。気が利くじゃないの、アップルのくせに(純粋にホメています)。どんな感じにセーブできるかというのをイメージでお伝えすると、iPhoneの中に予め「貸し金庫」みたいなものが用意されていて、各アプリの中から、無くなったら困るデータを、その貸し金庫に預けておき、必要に応じて、取り出しに行く。そんな感じである。

その貸し金庫。iPhoneアプリの中ではNSUserDefaultと呼ばれている。ユーザーデフォルト、少し詳しく分解して書くと、ユーザー固有のデフォルト(標準)設定を保存しておくための場所、という意味である。あれ?逆に難しくなってしまった気がする。うーむ。まあ、ザックリ分類すると、アプリの設定等を保存しておくための場所らしい。よくありますな、アプリのオプション設定機能。ああいう画面で設定しておくようなデータを保存しておけ、と。ほうほう。…まっ!それはそれとして!折角保存できるわけですし。ありがたく、いろいろな用途で使わせていただきましょう!

ということで、このユーザーデフォルト。値であれば大抵のものを保存しておくことが出来るようになっている。文字列や数値はもちろん、配列もOK。もっと言ってしまうと、値、という範囲から少しハズレてしまうのだが、画像等も、上手くデータ変換すれば、保存できてしまったりする。おまけに、使う場所を選ばない。ビューが立ち上がる前後でも、自分で作った処理の間でも、一行で呼び出せるし、一行で保存できる。便利すぎるぞ、ユーザーデフォルト。

「町に着いたら、一旦セーブ」、RPGの基本である。今こそ思い出そう、そして、もう二度とあの苦い思い出は味合わないように、胸に刻み込もう。「処理の間で、一旦セーブ」、iPhoneアプリ開発の、次の基本として、ワタシからの提案である。

※この記事は今度出す本の下書きの下書きです。
※全ボツになることもありますので、番外編としてお楽しみください。

【業務連絡】
NSUserDefaultの説明が続きます。

配列ってなんだろう

日が暮れるのが早くて損した気分。

冬はこたつでみかんだよねー。とりあえず寒くなると誰か一人は言っている、冬の定番である。だが、この狭いニッポンの住宅事情で、どのくらいのご家庭にこたつがあるのか、と言われると「うっ」となる人も多かろう。ワタシもここ数年こたつでみかんなど味わったことがない。別にいいけどね、ハロゲンヒーター暖かいし。こたつなんて、ついウトウトして風邪を引くだけだし。けっ、羨ましいじゃねぇか。いやいや。今回はこたつではなく、みかんの方が主役である。

みかんの袋、パッと想像ができるだろうか。あの赤いメッシュの袋のことである。先日雑貨屋さんに行ったら、あの袋が10袋くらいまとまって「みかん袋」として売られていた。名称、みかん袋でいいようです。そのみかん袋、だいたい一袋にみかんが五個くらい入っている。袋の中で一列に並んでいるみかん。この絵が想像できたら、今回のお話、配列についての事前準備はバッチリだ。

配列という言語、聞いたことがあるだろうか。プログラムの本には必ず出てくる、でも正直なんだかよくわからない、アイツである。意を決して読んでみると、「数値や文字列を、配列なる枠の中に格納して、様々な場面で使うことができる」とかなんとか…。日本語として読むことは読めるのだが、どうにもピンと来ないシロモノなのだ。知らないとヤバイ気がする、それはわかるけど、ピンとくる方法がわからない。よーし。ということで。今回はカワサキおにいさんが、「みかんとみかん袋で」配列のことをお話ししてあげよう。みかんで配列、みんなー、わーかるーかなー。

そもそも、なぜ「みかんをみかん袋に入れるのか」、というお話からはじめよう。「なにそれ?」、いやいや。とっても大事なことなんだ。みんながテレビの部屋に行くときに、みかんを両手に持っていたら、ドアが開けられないだろう?袋に入れることの良い事のひとつは、「まとめられる」ということなんだ。とりあえず袋に入れておけば、置いておいてもバラバラにならないし、一個二個持って行き忘れることもない。これはとっても大きいね。

次に、「みかん袋はどういう特徴があるだろう」、というお話だ。みかんを入れる、これは当たり前だね。入っているみかんを取り出す、これも問題ないね。入っているみかんを並べ替える、これはどうだろう。みかん袋はメッシュでできている、引っ張ると少し伸びるのだ。伸ばして、グリっと。これで並び替えることもできた。入れたり出したり、並び替えたり、そうして詰め込んだみかんを、まとめてテレビの部屋に持って行ける。これがみかん袋の特徴だね。

さて、ここまでわかったら、最後は「みかん袋はどのくらい無理ができるのだろう」、ということを押さえておこう。例えば、みかんの代わりに、りんごを入れる。うん、これは入りそうだね。レモンでも、桃でも、似たようなものなら入りそうだ。他には、みかんの入ったみかん袋を、みかん袋に何個も入れる。これはどうだろう。みかん袋がものすごくよく伸びるものであれば、きっと入っちゃうね。山ほど果物が入ったみかん袋を、ヒョイっとテレビの部屋に持っていくことができたら、それはとんでもなく便利だと思わないかい?そう!それが配列なのさ!ハッハー!

…コホン。はい、というわけで。みかんで配列、お楽しみいただけただろうか。では、上記の内容をiPhoneアプリ用語に置き換えてみよう。配列はNSArrayという型の変数。みかんは数値、りんごは文字列、レモンや桃は、ボタンビューやイメージビューなどの、ビューのことである。「NSArray型の変数に、数値や文字列やビューを、入れたり出したり、並び替えたりして詰め込んで、処理したい場所に持っていく」。うーむ。この一行だけで、一気にムズカシイ雰囲気になってしまった。絵を想像できるかできないかで、理解するムズカシさが大違い。そう、それが配列というシロモノなのである。

※この記事は今度出す本の下書きの下書きです。
※全ボツになることもありますので、番外編としてお楽しみください。

【業務連絡】
配列の説明が続きます。

オレ流ユニバーサルバイナリの作り方

いい天気。気分が晴れるわ〜。

今を遡ること20年くらい前、当時の少年少女たちの間を、ある不吉な噂が流れていった。「スーパーファミコンは、どうやらファミコンのカセットが使えないらしい」、というものである。「ええっ!じゃぁ今持っているカセットはどうなっちゃうの!?」「お金返してくれるの!?」。友達の手前、恥ずかしくて口には出せないものの、皆表情は暗い。ファミコンを買ってもらうのにも四苦八苦したのだ。使えなくなるなんて、そんな状況、誰が納得できようか。責任者出てこい。一般的な家庭用ゲーム機として爆発的に普及したファミコンであったが、「初代」というものにはいつだって「認識不足」という問題が付いて回る。我々は知らなかったのだ、「互換性」という言語と、その意味を。

時は流れて、現在。我々は新しいハードが登場すると、すぐさま互換性を確認するようになった。せっかく新しいものが出ても、やれることが少なくては楽しくないことを、イヤというほど経験したからである。ノーモア、「これでしかできない」。ということで、iPadが登場したときに、当然のように我々は思ったのである。「iPhoneのアプリは、iPadで使えるのだろうか」と。どう見てもサイズが違うし、新機能とか追加されるんだろうし。「同じような雰囲気をした別物」だったらどうしよう。だが、その心配は杞憂に終わった。アップルは抜かりなくその部分を考えていたのだ。そう、iPadでお馴染み、「2倍」拡大機能である。

すごいねー。さすがアップル。完。
これでこの話を終わらせてしまっても構わないと言えば構わないのだが、あの「2倍」拡大機能。少々残念な気がするのはワタシだけではありますまい。その場しのぎというか、突貫工事と言うか。画像の縦横比には対応のしようがないので、拡大後に黒い帯が入ってしまうし。うーん。なんとかしたいなー、と、そんな時に出てくるのが、ユニバーサルバイナリである。

iPhoneアプリ用語で、「iPhoneとiPad両方に対応するアプリ」のことを、ユニバーサルバイナリと言う。ユニバーサル、随分大きく出たものだ。もう何でも来んかい、くらいの勢いである。アンドロイド?そんなもんは知らん。Xcodeでは、このユニバーサルバイナリを作るための方法を様々にサポートしている。一見親切そうなのだが、様々、とワタシが言う場合は、大抵「めんどくさー」という気持ちでを含んで言っている。これもそう。まともにやろうとすると、いろいろしなければいけないことが出てくるのだ。

ここで、大胆に仮定してみよう。おそらくアナタは、iPhoneとiPadで、「ほとんど同じ見た目のアプリ」を作りたいのではないだろうか。「え?それはそうでしょう?」、と思ったアナタ。良かった良かった。そんなアナタは、ワタシ流の裏ルールを覚えておけばよろしい。Xcodeに用意されているユニバーサルバイナリ用の設定を全て行う必要がある人というのは、「iPhoneとiPadで、各々が最適になるようなアプリを作りたい」という人だけなのだ。あるでしょう?iPhoneアプリとは完全に見た目の違う、iPad専用の見た目をしたアプリ。標準アプリのメールとか。ああいうのを作ることになってしまった人、ゴメンナサイ。

そういう前提で、ワタシ流のルールをご紹介しよう。いつものように思いっきり簡単に考えて欲しい。iPhoneとiPadで、違いが問題になる部分は、縦横比だ。(960×640ピクセルのiPhoneに対して、1024×768ピクセルのiPad)その影響がモロに出てくるのが背景画像で、拡大縮小しようと、iPhone用のサイズでは、iPadでは横が足りなくなってしまうし、iPad用のサイズでは、iPhoneでは縦が足りなくなってしまう。まず、それを解消するために、背景画像だけは二種類(960×640ピクセルと1024×768ピクセル)用意しておこう。

で、ここからがポイント。プログラムの中で、現在の画面の横幅と縦幅は、いつでも算出できるのである。算出した結果、iPhoneのサイズなら、iPhone用の画像を配置をし、iPadのサイズなら、iPad用の画像を配置する。これだけで背景画像問題は解決する。次に、算出した横幅(縦幅)を一旦データとして保管しておいて、ボタンやラベルを設置するときに、横幅が、iPhoneサイズの場合はこう、iPadサイズの場合はこう、とサイズを指定しておく。これで、準備は終了だ。あとは、「このアプリ、ユニバーサルっす」、と、Xcode上でチェックしておけば、iPhoneでも、iPadでも同じような見た目のアプリができるのである。

面白そうなiPhoneアプリなのに、ボクのiPadではクールな見た目になってない。次世代の少年少女が、ションボリすることがないよう、我々オジサン、オネエサマ世代は気をつけていきたいものである。自分はまだピチピチの学生で、オジサンじゃない?10歳以下の少年少女からしてみれば、18歳以上の人間なんて等しくオジサン、オネエサマである。わっはっは。いらっしゃい。