# 自分だけのニュースアプリを作ってみよう! ニュースアプリの画面を考える
# この記事
- ニュースアプリが「こうだったらいいな」を考える
- ニュースアプリの画面を考える ←⭐この記事
- ニュースアプリに機能を考える
- ニュースアプリの画面をつくってみる
- ニュースアプリの機能をつくってみる
- ニュースアプリを使ってみる
# 目次
# 画面のイメージを書いてみる
まずは画面のイメージを描いてみます。
やり方は人それぞれあると思いますが、個人的には最初のラフなイメージ作成は、手書きのほうが良いような気がしています。
この時、以下の3つを洗い出せるように書くことがポイントです。
- 必要な画面
- 画面の項目
- 画面のイベント
# 画面の設計
いわゆる「外部設計」と呼ばれる部分の設計を行っていきます。 簡単に言うとユーザの操作に直結する部分の設計です。
以下の3つを整理していきます。
- 画面一覧:必要となる画面をリストアップします
- 画面項目:各画面に表示するデータ項目を整理します。あとあと、テーブル設計につながります
- 画面イベント:各画面のボタンなどで発生するイベントを整理します。あとあと、機能の設計につながります
(※DBテーブル設計まで、外部設計の中で終わらせることも多いですが、今回は便宜上、画面だけにしました。)
# 画面一覧
ラフスケッチにも書いてある通り、今回のニュースアプリでは以下の3つの画面を作成します。
※今回のニュースアプリでは、フッターは画面には含めませんでした。
画面 | 概要 |
---|---|
ニュース一覧 | 日付の降順でニュースの一覧を表示 |
ニュース詳細 | ニュースの詳細情報を表示 |
キーワード管理 | ニュースを収集する際のキーワードを登録/削除できる |
フッター | ニュース一覧とキーワード管理を切り替えるために常に表示 |
# 画面項目
画面イメージから項目を洗い出します。
ここで洗い出した項目が、テーブル設計へつながっていきます。 今回はデータを保存するためにGoogle Spread Sheetを使います。 (GlideがGoogel Spread Sheetから画面を自動生成できるため)
そのため、ここでリストアップした項目は、表形式でデータを保存することになります。
もう少し難しい画面(明細が表示される画面、など)だと、データ構造のリレーション(関連)も設計します。 が、今回は比較的簡単なデータ構造になっており、1つの表で管理できそうです。
具体的な設計は03.ニュースアプリの機能を考える/DBテーブル設計 でしていきます。
画面 | 項目 | 項目説明 |
---|---|---|
ニュース一覧 | タイトル | ニュース記事のタイトルを表示する。 |
キーワード | ニュースを取得したい際の検索キーワード。 ツイートする際のハッシュタグに使いたい。 | |
日付 | ニュース記事の作成日 | |
ニュース詳細 | 画像 | ニュース記事のアイキャッチ画像を表示 |
タイトル | ニュース記事のタイトルを表示する。 | |
作成日 | ニュース記事の作成日 | |
URL | ニュース記事のURL。クリックすると元の記事が表示される。 | |
概要 | ニュースの概要を表示 | |
ツイート | ツイートボタン | |
キーワード管理 | キーワード | ニュースを収集する際の検索キーワード。登録や削除できる。 |
フッター | - | - |
# 画面イベント
画面で発生するイベントを整理します。
画面 | イベントトリガー | イベント概要 |
---|---|---|
ニュース一覧 | 記事をクリック | ニュースを詳細画面で表示 |
ニュース詳細 | 戻る | ニュース一覧へ戻る |
ニュースURLリンクをクリック | 元のニュース記事をブラウザで表示 | |
ツイートボタンをクリック | 定型文、コメントを付けた上で、ニュースのツイートを行う | |
キーワード管理 | キーワード登録ボタンをクリック | キーワードを入力し、OKを押すことで登録 |
キーワード削除アイコンをクリック | キーワードを削除する | |
フッター | ニュース一覧タブをクリック | ニュース一覧画面を表示する |
キーワード管理タブをクリック | キーワード管理画面を表示する |
# 画面の設計について
規模が大きなアプリケーションを作ろうとすると、1人では開発ができないため 他の人が見てもわかるように設計書を作成する必要があります。
そのため、画面や項目の名称にブレが無いようにしたり、項目の桁・型をきちんと統一したりします。
ただ、今回は1人で開発をするので(出来る程度の規模にしているので)、画面の設計はこのくらいで良いかなと思います。