iOSアプリ開発体験記(4) - コーディングは怖くない
早速コーディングを始めていきます。
いきなり全画面を作るのではなく、部品を一つずつコーディングしながら、都度シュミレーターで確認する方がわかりやすいです。
例えば「ikitell Alarm」の場合は以下の画面や機能が必要になります。
-
アラーム設定画面
- 背景
- ロゴ画像
- アラーム時刻選択
- アラーム設定ボタン
- フッターメニューアイコン
-
アラーム停止画面
- 背景
- ロゴ画像
- アラーム時刻選択
- アラーム設定ボタン
- フッターメニュー
-
アプリ設定画面
- 背景
- ロゴ画像
- アラーム時刻選択
- アラーム設定ボタン
- フッターメニュー
-
見守り設定管理画面
- 背景
- ロゴ画像
- アラーム時刻選択
- アラーム設定ボタン
- フッターメニュー
これだけでも「背景」と「ロゴ画像」は各画面で共通なのでコードを使い回せます。
「フッターメニュー」の場合は、現在表示中の画面とそれ以外を区別するため、アイコンの色を変えるなどの処理が必要になりますが、デザインの記述などは使い回せます。
というわけで、実際の作業は上記以外の独自機能を、各画面につきだいたい２〜３個ほどコーディングしていくことになります。
こうやって考えれば、それほど先の長い話ではないように感じませんか？
実際、コーディング自体はそれほどかかりません。サンプルソースがネットにあふれていますので、それを貼り付けてデザインを少し変えるだけです。
問題は、自分が納得できるラインをどう引くか、これにつきます。
デザインや機能はこだわり始めるとキリがありません。
この「キリ」というのはけして言語やiOSアプリ仕様の限界がないということではなく、自分の欲求が再現なく続くということです。それもいろんな方向へ。
例えばある機能を実装したいと思い孤軍奮闘して完成した後、「やっぱり前のがよかったかも」ということになります。私は実際にありました。
また、これも私の経験なのですが、実装する機能、特にエフェクト系ですが、あまりこだわらない方がよいです。
STEP１で参考にしたアプリと同じエフェクト（スクロールの動きやページ送りの動きなど）は、ある程度簡単に実装できるものに抑えて、まずはアプリの完成を目指しましょう。
さらに、アプリをリリースするためにはアップルやグーグルの審査を通過する必要がありますが、あまりに複雑多機能な仕様にしてしまうと、審査で引っかかる可能性が増え、その対応で余計な時間がかかる恐れもあります。可能な限りシンプルを目指しましょう。
そういうわけで、自分が目指している完成形に対して、ある程度の線引きをする必要があります。
最低限実装しなければ、STEP１で決めた要件を満たせない、それがデッドラインになります。
またユーザービリティについても、「ここまで作り込まないと使い勝手が悪い」という線引きではなく、「こういう機能がないとサービスにならない」という最低ラインでかまいません。
もちろん、シンプルにし過ぎて使いづらくなるのは避けるべきですが、そこはリリース前に他人に使ってもらって、そのフィードバックを受けることで有益です。
次回記事「iOSアプリ開発の心得(5) - 私のコーディング・ルーティン」
Discussion