プロジェクト設定内容

制約

タスクについて

タスクは管理用の「data class」を作成し、次の properties を用いること。必要に応じて properties を増やしても構わない。また、関数を追加しても構わない。ただし、『冗長的なデータ』を保持するために properties を追加してはならない。

タスクの「priority: 優先度」は、コード（Int 型のデータ）で管理すること。

タスクの「date: 日付」「time: 時間」は Date 型でまとめてもよい。（その際は入力チェックを行うこと）

• val title: String
• val date: String
• val time: String
• val priority: Int
• val detail: String

画面遷移時のタスクデータについて

次にあげる画面遷移時のタスクデータの受け渡し方法は、Task インスタンスを Intent に putExtra() してやりとりをすること。

• 「AddTaskActivity（タスクを追加する Activity）」から「TaskManagerActivity（タスクを一覧表示している Activity）」へ追加されたタスクデータを渡す
• 「TaskManagerActivity（タスクを一覧表示している Activity）」から「TaskDetailActivity（タスクの変更・削除をするActivity）へ選択されたタスクデータを渡す

タスクの重複について

一般的なタスク管理ツールは、同様のタスクが重複登録できる仕様になっているものが多い（重複を許している）。よってタスクは重複して登録できるものとする。

タスクの保存について

SharedPreferences への保存は「TaskManagerActivity（タスクを一覧表示している Activity）」で行うこと。

Adapter について

タスク一覧を表示させる TaskListAdapter(Adapter) は BaseAdapter を継承して作成すること。また、ViewHolder パターンで実装すること。

評価ポイント

最低限

• レイアウトの乱れがない（画面を回転させても、表示が乱れないこと）
• 英語と日本語をサポートすること
• 入力チェックを行うこと（最低限: 未入力エラー。ただし、『date: 日付』『time: 時間』『detail: 詳細』は「未入力」でも構わない）
• 正しくタスクが保存されること（変更・削除含む）
• ClickListener は properties で宣言すること（setter 内にラムダで実装しないこと。可読性が下がるため）
• Extras の識別子は「companion object と const val」または「トップレベルに const val」を利用した定数で指定すること
• TaskListAdapter(Adapter) は ViewHolder パターンで実装されていること
• TaskListAdapter(Adapter) の getView() にて、View インスタンスを不必要に再作成していないこと
• 正しく画面遷移すること
• 動作可能であること（例外をスローし、App が強制終了しないこと）

加点項目

• 必要に応じて、拡張関数やスコープ関数を使う
• タスクの「Json 化」および「Json からのインスタンス復元」は変換用の関数を定義する
• 「date: 日付」「time: 時間」が正しいフォーマットで入力されているかチェックする
• 「Priority: 優先度」は enum クラスで宣言する
• 「Priority: 優先度」の「コード」と「記号」の変換は enum クラスに変換用の関数を定義する
• TaskListAdapter(Adapter) の getItemId() にて、「一意な識別子」を返却するように実装する
• タスクのソート機能を実装する（第1キー: time and date, 第2キー: priority ）。実装にあたっては Task クラスの properties の型を変更しても構わない

Hint

• 「Priority: 優先度」の英語表記とコードは意味がとおれば問題ない

表記例:

「!!!」緊急: Immediately; 0

「!!」（可及的）速やかに: ASAP (as soon as possible); 1

「!」すぐに: Soon; 2

「 」普通（いつでもよい）: Anytime; 3

• タスクの重複について

Json 形式で保存することで、特に意識せず「タスクの重複登録」を行うことができる。

しかしながら、重複しているタスクに「一意な識別子」をつけておかないと、タスクを削除するときに問題となる（「重複するタスクをすべて消してしまう」または「最初に検索されたタスクのみ消す」という偏った実装になりやすい）。

これを回避するためには、参考資料にあるように「ID」を付与する考え方がわかりやすい。

• 「変更」「削除」「キャンセル」の result 判定（処理分岐）について

Activity の Constants には3つの RESULT(RESULT_CANCELED, RESULT_FIRST_USER, RESULT_OK) が定義されている

それぞれの RESULT をそれぞれ「キャンセル」「変更」「削除」に割り当てて実装してもよい。

また、「変更」「削除」を RESULT_OK とし、「キャンセル」を RESULT_CANCELD と定義した上で、「変更処理なのか、削除処理なのか」を判断するための情報を返却して処理分岐する方法でもよい。

• 「変更」処理について

SharedPreferences 内のテキストデータを部分的に更新するのは容易なことではない。簡単に実装するには、SharedPreferences に保存する前の List を操作するのが手っ取り早い。とはいえ、List 内の要素を更新する関数は用意されていないので、更新対象のデータを Delete insert する。