AndroidはGoogle社が提供するOSです。
スマートフォンやタブレットはもちろん、 様々な展開が予測されるウェアラブル端末への搭載を目標に開発されましたが,
その主眼はそれらの出現によって多様化する画面や入力手段に柔軟に対応するプラットフォームを構築する事にあります。
アプリケーション開発においてはその理念を実現するために、
画面と内部構成、 そしてそれらを仲立ちする制御構造を分割するMVCモデルでの開発を最新の理論に基づき補助します。
スマートフォンの分野で世界シェア1位を持つこのOSは, オープンソース化した事でさらなる広がりを見せています。
ユーザーがAndroidデバイス(携帯端末)やタブレットをどのように使用するか、またアプリを どのように利用し、停止し、再開するかといった、アクティビティのライフサイクルと呼ばれる構成 のもと、Android開発の骨組みを作成します。
下図のように親画面のフレームとしてアクティビティ(Activity)、その中で構成される各画面をフラグメント(Fragment)として構成します。
フラグメント(Fragment)にも同様のライフサイクルがある(※1)ので、それに従ってプログラムを構成します。
※1 ActivityとFragmentのライフサイクルの基本的な流れは同じです（構成されるメソッドは異なるものがあります） また、APIレベルによりこの構成が異なります(追加されています)。
下記の表のように歴代のプラットフォームに付けられたコードネームは、カップケーキ、ドーナツ、エクレア、次期バージョン(6.0)はマシュマロと可愛らしい。
プラットフォームには対応したAPIレベルがあり、可能な振る舞いを指定するためAPIレベルを開発時に指定します。
（APIレベルとは、Androidプラットフォームのバージョンで提供されるフレームワークのAPIリビジョンを一意に識別する数値）
これらのAPIレベルや要求されるAndroidの最小バージョン、コンポーネント宣言、必要なハードウェア設定などの要件は、マニフェストファイルで宣言します。
| プラットフォーム | APIレベル | コードネーム | 公開日 |
|---|---|---|---|
| Android 1.0 | 1 | Base | 2008/09/23 |
| Android 1.5 | 3 | Cupcake | 2009/04/30 |
| Android 1.6 | 4 | Donut | 2009/09/15 |
| Android 2.0 | 5 | Eclair | 2009/10/26 |
| Android 2.2.x | 8 | Froyo | 2010/05/20 |
| Android 2.3 | 9 | Gingerbread | 2010/12/06 |
| Android 3.0.x | 11 | Honeycomb | 2011/02/22 |
| Android 4.0 | 14 | Ice Cream Sandwich | 2011/10/19 |
| Android 4.1 | 16 | Jelly Bean | 2012/07/09 |
| Android 4.4 | 19 | KitKat | 2013/10/31 |
| Android 5.0 | 21 | Lollipop | 2014/11/12 |
| Android 6.0 | 23 | Marshmallow | 次期 |
参考サイト：https://en.wikipedia.org/wiki/android_version_history
上位互換あり、下位互換なし
→Androidプラットフォームのバージョンとそれより高いAPIレベルで上位互換
→コンパイル済みバージョンより古いバージョンのAndroidプラットフォームで下位互換なし
どのAPIレベルを選択しどのプラットフォームに対応したAndroidアプリを作るかは、 下記の図のように、サービスの種類や顧客ニーズ、機能強化やパフォーマンス向上といった目的 によってサポートする最適なAPIレベルを決める必要があります。
今後新規にアプリを作成する場合（既存顧客がいない場合)は、より最新のプラットフォーム向けに開発可能ですが、
現行アプリのサービスが開始されていて顧客サポートが必要な場合は、古いプラットフォームをサポートする必要があります。
APIレベルの最低サポートバージョンを上げるためには、使用されているプラットフォームの調査が必要です。
アプリを作成し運用が始まった後でユーザーの様々な意見や要望を聞き、また、どういう使われ方をしているかを 総合的に分析すると、ユーザー目線に立ったよりよいアプリの作り方が見えてきたりします。 「ユーザー中心」となるUXの観点で、UI見直しや今後開発するアプリの設計を行っていくことが重要で、 これらを常に意識して今後もアプリ開発を行っていきます。
| 役に立つ | アプリで提供するサービスが本当に役に立つか |
|---|---|
| 好ましい | アプリのイメージやアイデンティティの力と価値のバランスが取れていて、ユーザーの関心を引くか |
| アクセスしやすい | すべてのユーザーが容易にアクセスできるか |
| 価値がある | アプリにより利益を上げることが可能で、すべてのユーザーの満足を満たしているか |
| 信頼できる | 多くのユーザーに信頼感を与えるデザインであり、また信頼できる内容のコンテンツが含まれているか |
| 見つけやすい | ユーザーが迷うことのない直感的なUIとなっているか |
| 使いやすい | MMI(主にタッチパネル、ソフトキーボード)の観点からユーザビリティを考慮した使いやすい構成であるか |
参考 "The User Experience Honeycomb" [Peter Morville]
http://semanticstudiOS.com/user_experience_design/