前回、前々回に引き続き、今回もスマホアプリのプロジェクトの見方を紹介していきます。
最終回となる今回は、ソースコードの中でも主に画面周りを中心に見ていきます。
全体の流れ
まずは、前回同様おさらいとして全体の流れを見ておきましょう。
- 開発環境の確認
- 使っているライブラリ群の確認
- データの保持方法
- 通信周り
- 基底クラス
- 画面(Activity, Fragment, ViewController)一覧
- ビュー周り
前編では、開発環境の確認と使っているライブラリ群の確認の詳細を、中編ではデータの保持方法と通信周りのコードを見てきました。 今回はいよいよ画面周りの見方を紹介します。
基底クラス
さっそく画面をみていきたいところですが、その前にざっと基底クラスを見ておきましょう。 個人的には(プロトコルやインターフェースなどを積極的に利用して)あまり基底クラスを作らない設計を推していきたいところですが、 これまで引き継いできたコードではよくBase* のような名前のクラスがありました。
これまで見てきた中では、主にViewControllerやActivity、Fragmentに対して基底クラスが用意されていることが多かったです。 処理内容としては、通信中のプログレスの表示処理やナビゲーションバーボタンの制御などをよく見かけます。 また、プロジェクトによっては画面問わずいつでもポップアップ表示できるようなビューが用意されていたり、画面遷移の度に行う共通処理、アプリ全体のキーカラーを変更できるようなカスタム基底ビュークラスなどもありました。
基底クラスと書いてしまうと少し枠が大きくなってしまいますが、基本的にはこのタイミングではViewControllerやActivity、Fragmentの基底クラスが見えてればいいかなと思います。
画面(Activity, Fragment, ViewController)一覧
ここからはいよいよ実際にアプリを触りながら画面周りを見ていきます。
まずはアプリをビルドして、実機やシミュレータ等でアプリを触りましょう。
このときまず意識すべきは、アプリ起動後の画面です。
多くのアプリではスプラッシュ画面が用意されていると思います。
(もちろん起動直後からメイン画面が表示される場合もありますし、アプリの状態によって最初に表示される画面が複数あることもあります)
この起動直後の画面はアプリ内の画面構成を理解する際に、非常に重要な要素となりますので、ついでにクラス名も調べておきましょう。
さて、起動直後に表示されるクラスがわかったら、あとはその画面から芋づる式に遷移できる画面を見ていくだけです。
私の場合ですが、まずは、起動直後に表示された画面のクラス名でプロジェクト内を全文検索してみます。(MacならCtrl+Shift+f
から検索できると思います)
これはiOSの場合はstoryboardでのみ画面遷移処理が記述されている可能性があるからです。
次に、該当クラスのソースを開き、そのクラスでインポートしているクラスに、*ViewController
や*Activity
、*Fragment
などがないかを確認します。
ここでそれ(画面)っぽい名前のクラスがインポートされていた場合、いま調べている画面からその画面に遷移する流れがある可能性が高いため、今度はインポートされているクラス名で検索します。
(iOSの場合は、UIStoryboard
などのキーワードでも検索します)
すると、該当クラス名が画面遷移処理とともに記載されている箇所が引っかかります。
あとは、この流れをどんどん見つけた画面に対して繰り返していくことで、芋づる式に画面遷移の構成がわかっていくと思います。
1点、この作業を行う上で大事なことは、実際にアプリを手元で触りながら作業を行うことです。
これによって、ソースを見る前に次にどの画面に遷移できるかを予想できるので、効率的に作業を進めていくことができます。
もちろん、これで画面遷移の構成がすべて見つかるわけではありません。 なかには任意の画面に遷移できるようなメソッドを用意しているプロジェクトなどもあります。 が、引き継ぎ直後など全体の概要をすばやく把握したいときには、まずはこれくらいで十分でしょう。
ビュー周り
ここまでの流れを一通り行って、基本的な画面構成が把握できたら、アプリ全体の概要は把握したと考えていいでしょう。 ここから先は各画面の詳細な実装を見ていき、アプリの詳細にどんどん詳しくなっていくのみです。
したがって、ここではあまり書く内容はないのですが、1点、画面に表示している情報
に関しては目を通しておくことをお勧めします。
画面に表示されている情報のうち、動的に変わる要素は、
- ユーザーがそれまでに入力した情報
- サーバーから受け取った情報
であることが多いです。 特に1.の場合は、その情報を各画面間でどのように受け渡しを行っているか(インスタンス間で直接受け渡し、DBやファイルなどの共有領域に保持、APIサーバーを介して保存/取得)を早い段階で調べておくと、その後のアプリの実装詳細把握の助けになると思います。
最後に
私がプロジェクトの概要を理解するときにいつも行っている流れはこれですべてですが、いかがでしたでしょうか。
3回にわけたので、結構なボリュームとなってしまいましたが、当初の予定より詳しく書けたかなと思います。
ここまで書いてきたこと以外の重要な要素として、ここまでの作業は全て、予想しながら
作業を進めることが非常に重要だと感じています。
ここまで書いてきた流れの通りに作業を進めると、手順の後半では、それまでの手順が正しい予想
の助けになっていることに気づくと思います。
何が重要なのかをしっかりと考えながら作業を進める癖をつけることで、急なプロジェクト変更にも素早く柔軟に対応していきたいですね。
それでは、また次の記事をお楽しみに!