iOSアプリ開発におけるUI変更のつらさを取り除くためのアプローチ

Pocket

iOSアプリ開発でつらいのは、UIをちょこちょこ変える作業だと思っています。

UIを変えると言っても、レベル感はあって、

  1. Storyboard上でちょいちょいと修正できるレベルのもの
  2. ViewController上にコードをちょこっと書き加えるレベルのもの
  3. UIViewコンポーネントをいちいち作らなければならないレベルのもの
  4. ViewControllerごと挿げ替える必要のあるレベルのもの
  5. etc…

と、順につらくなり、大抵見た目はちょこっと変わるぐらいなのだけど、裏では結構たくさんコードを書かなければならないことが多いように感じます。そこから逃げようとしてViewControllerにダラダラ書いていると後々辛くなるので、おとなしくUIViewを作るパターンが多い気が。そういうわけで、そこそこの量のコードが生まれることになります。

UI変更のつらさを取り除くためのアプローチ

でも使ってたら「やっぱり使いづらいよねー」と思うことはあるし、Webアプリ作ってるみたいにコロコロUI変えたいよね感はあります。どうしよう。

標準コンポーネントでできるように工夫する

Storyboardでちょいちょいとできるところに落とすのが一番効率が良いので、できるだけ標準コンポーネントでやれるようにするのも一つの手段です。無理はしない。

とはいえ、これが難しいから困っているんですよねー。という訳で次。

すごいプログラマーになる

標準コンポーネントでできない。コード量多くなる。凝ったUIは実現が難しい。そうだ、そんなことを物ともしないすごいプログラマーになればいいんだ!

いつなれるんでしょうか・・・。なれるといいですね。という訳で次。

最初からそれなりにデザインしておく

「変更が困るなら、変更を少なくすれば良い(キリッ」

「使ってて使いづらいから直す」は甘え。最初からそれなりに気を配ってデザインしよう。そういうアプローチもない訳ではないと思います。

例えば以下のtogetterの実況中継をご覧ください。

勉強になりすぎる!!Webデザイナー板橋聡氏 @bash1boy のデザイン実況中継!【第4弾】

こういったデザインの調整をモックレベルでやるのは正しいアプローチです。これを動いているコードベースでやろうと思うと、想像するだけでかなりつらい。HTMLとCSSの世界ならそこそこいける気がしますが、アプリはギブアップです。

余談ですが、優れたデザイナーは「そのデザインにした経緯」をちゃんとメモとして残すと言います。このぐらいメモがあると、経緯が把握できている分、仮にUIを変更するとしてもつらさは抑えられると思います。つらさの成分には納得感も含まれます。

HTMLとCSSの世界に行く

「今HTMLとCSSの世界ならそこそこいける気がするって言ったよな?」

ネイティブで開発するのがそもそもの誤りでした。変更が多い開発ではパフォーマンスより生産性を取るのが定石です。JavaではなくRubyを使うように、ObjectiveCではなくHTMLとCSSを使えば良いではないですか。

以前ご紹介したionicというモバイルアプリ向けのフレームワークもあります。TopcoatをAngularJS向けにしたOnsenUIというフレームワークもあります。

そう、世の中はまさに大AngularJS時代。Cordovaもバージョンアップを続けて、ついに3.3.0になりました(2014/2/15現在)。これはHTML5アプリの時代が来るんじゃない?

そもそもAngularJSでなくても良いとは思いますが、わざわざAngularJS向けのUIフレームワークが登場している昨今の流れを見ると、その流れに乗ってしまう方がむしろ楽なのではと思います。

とは言っても、やりづらい部分はあります。Cordovaはプラグインが充実していていかにも何でも実現できそうな気配がありますが、プラグインを入れても動かないことなんて日常茶飯事です。変なところでハマりもします。UIの変更容易性をとって、中の機能実装で少し妥協が出る、という感じ。特にメモリ周りで問題が起こると、お手上げな面もあります。所詮はWebViewの世界。

また、このアプローチをとることでクロスプラットフォームという利点も得ることができると言われていますが、ここでは深く考えないこととします。

どこでもないどこかへ

アプリ開発の選択肢はこれだけではありません。TitaniumXamarinといった製品もあります。

とはいえこれはクロスプラットフォームに対するアプローチであって、UI変更のつらさを取り除くためのアプローチではありませんね。アーキテクチャを考えるという点においては、総合的に考慮に入れる部分ではありますが。

TitaniumはJavaScriptで書くプラットフォームですが、UIはHTMLではなくJavaScriptコードで表現されるので、そのあたりが難点。こんな記事があるのでずっと気にしてはいるんですけどね。

Titanium™ をはじめるとき

Titanium™ を捨てるとき

Titaniumの次期バージョンのTi.NextではJavaScriptからクッソ早いネイティブコードにコンパイルするHyperloopという仕組みを開発していて、既存のTitaniumアプリが800倍早くなるとかなんとか言っているのを聞いて気になってはいるんですよ。

で、結局どのアプローチが良いの

ネイティブ以外のアプローチを取ると、どうしても変にハマるときが来る気がします。これを避けるならネイティブ一択。この場合はこんなプロトタイピングツールを使って、プロトタイプの中である程度動きを確認したあとに実装するのがプロセスとして良い気がしています。

地雷を許容してプロトタイピングと同時に開発を進めるならCordovaも悪くない選択肢。AngularJS含めて考えると素敵なレールが整ってきたように思います。localStorageを自動的にiCloudとsyncしてくれる機能とか素敵すぎるんよ。

そんなわkで、ちゃぶ台返し的な変更を受容するなら後者しかないなーと思って、最近では後者のアプローチを中心に考えています。

(Androidの経験はほとんどないので、Androidに関しては語る言葉を持っていないのです。Androidはどうなんでしょうねー。)