以前のエントリの「 1apkでAndroidタブレット向けとスマートフォン向けアプリを実現する方法　その３」の「FragmentとActivityの役割分担」でFragmentとActivityの関係について記載し、上の図のように Fragment が導入されたからといっても、Fragment はActivityに依存しないように機能をモジュール化できる機能であり、以下の図のように他のActivityと依存関係を持たせることは良くないため避けるべきと記載をしました。

それについて、FragmentのAPIで依存しないような機能が提供されていることが判明しました。それについて記載したいと思います。以下で解説を行うAPIは、compatibility v4ベースで行います。Fragment クラスのAPIとして以下の2つのAPIが提供されています。Androidアプリ開発者にはなじみ深いAPIだと思います。

 void	startActivity(Intent intent)
          Call Activity#startActivity(Intent) on the fragment's containing Activity.
 void	startActivityForResult(Intent intent, int requestCode)
          Call Activity#startActivityForResult(Intent, int) on the fragment's containing Activity.

Fragment.java で提供される API

Fragment.java のソースコードは、（Windowsの場合）以下にあります。Linux, MAC の方はそれぞれの環境に読みかえてください。存在しない場合は、SDK Tool で Compatibility Package をダウンロードしてください。

...\android-sdk-windows\extras\android\compatibility\v4\src\java\android\support\v4\app\Fragment.java

Fragment.java の startActivity()メソッドとstartActivityForResult()メソッドをそれぞれ具体的に見ていきたいと思います。
それぞれのメソッドの抜粋が以下のようなものです。

    /**
     * Call {@link Activity#startActivity(Intent)} on the fragment's
     * containing Activity.
     */
    public void startActivity(Intent intent) {
        if (mActivity == null) {
            throw new IllegalStateException("Fragment " + this + " not attached to Activity");
        }
        mActivity.startActivityFromFragment(this, intent, -1);
    }

    /**
     * Call {@link Activity#startActivityForResult(Intent, int)} on the fragment's
     * containing Activity.
     */
    public void startActivityForResult(Intent intent, int requestCode) {
        if (mActivity == null) {
            throw new IllegalStateException("Fragment " + this + " not attached to Activity");
        }
        mActivity.startActivityFromFragment(this, intent, requestCode);
    }

上記の抜粋をみると、mActivityのメソッドを呼び出していることがわかります。
それ以外はただの初期化状態の確認（nullチェック）だけです。
ここで startActivityFromFragment()メソッドという見慣れないメソッドが呼び出されています。
これは何でしょうか？それを探るために、mAcitivyt が何者かを調査します。

FragmentActivity.java で提供される API

    // Activity this fragment is attached to.
    FragmentActivity mActivity;

すると、225行目で mActivity の宣言がありました。ここから FragmentActivity クラスということがわかりました。
続いて、Fragment.java と同じディレクトリにある FragmentActivity.java の中身を見ていきます。

FragmentActivity.java の643行目に startActivityFromFragment() メソッドがありました。

    /**
     * Called by Fragment.startActivityForResult() to implement its behavior.
     */
    public void startActivityFromFragment(Fragment fragment, Intent intent,
            int requestCode) {
        if (requestCode == -1) {
            super.startActivityForResult(intent, -1);
            return;
        }
        if ((requestCode&0xffff0000) != 0) {
            throw new IllegalArgumentException("Can only use lower 16 bits for requestCode");
        }
        super.startActivityForResult(intent, ((fragment.mIndex+1)<<16) + (requestCode&0xffff));
    }

ここでの super は何かというと、FragmentActivity.java の class 宣言で以下のように記載があり、Activity クラスということがわかりました。
つまり、startActivityFromFragment() メソッドで行っていることは、Android開発では一般的な Activity の startActivityForResult()メソッドか startActivityForResult()メソッドを リクエストコード（requestCode)の有無によって、切り替えて実行していることがわかりました。

public class FragmentActivity extends Activity {
    private static final String TAG = "FragmentActivity";

    private static final String FRAGMENTS_TAG = "android:support:fragments";

結論

以前のエントリで Fragment から startActivity() すべきでないと書きましたが、よく分析してみると Fragment で startActivity()しても以下の図のように上位のActivity の startActivyt()メソッドが呼び出される仕組みがあるため、Fragment からでも実施して問題ありません。

Honeycomb はソースコードが公開されておらずこのような調査・分析ができませんが、Compatibility package に関してはソースコードが公開されているのでこのように調査できることは大変有益だと思います。
Fragmentは、Honeycomb と Compatibility package のそれぞれで提供されているAPIが一部異なっているものがあります。
具体的には、ActivityとFragmentActivity や getFragmentMangaer() とgetSupportFragmentManager() などです。

それでも、本ソースコードと Honeycomb 内に実装が大きく異なっているとは考えづらいため、この Compativility package のソースコードから Honeycomb の実装が一部見えてくると思います。早くICSになってソースコードが公開されることを楽しみにしています！

設計方針の変更

そのため、今回はまず1apkでタブレット向けとスマートフォン向けアプリを実現するために、簡素化して実装を進めることにしました。

以下のものがそのクラス図です。

緑色のクラスが新規作成のクラスで、青色が変更を行う必要があるクラスです。

変更のステップは以下のような流れです。

1. 起動Activityのタブレット、スマートフォンの両対応向けの準備
2. スマートフォン向けレイアウト作成
3. スマートフォン向けノート編集画面の作成
4. Fragment クラスへの機能追加

起動Activityのタブレット、スマートフォンの両対応向けの準備

スマートフォン向けレイアウトを res/layout におくために、コードラボ完了時のタブレット向け画面レイアウトを res/layout-xlarge-v11 に名前変更を実施

起動Activityをタブレット向けとスマートフォン向けの両対応させるためには、Androidプラットフォームがどのようにレイアウトの切り替えを行っているかを知っておく必要があります。以下のアクティビティ図をもとに紹介します。Activity が起動されると onCreate() が呼び出されて、この中でレイアウトファイルを setContentView() するというのがAndroidのもっとも一般的な画面の作り方です。setContentView()を行うとAndroidの仕組みによって端末の固有情報をもとに読みだすレイアウト xmlファイルの読み出し先のディレクトリを変更してくれます。もっと詳しく知りたい場合は、Android SDK:Load the XML Resource（英語）を参照ください。

layout フォルダの使い方

今回の場合は setContentView(R.layout.notepad); と指定しているので、スマートフォンの場合、layout/notepad.xml が対象となり、タブレットの場合は、layout-xlarge-v11/notepad.xml が対象になり、対応したレイアウトファイルを読み込んでくれます。そのため、コードラボ完了時のレイアウトファイルのフォルダを以下のように変更してから、スマートフォン向けのnotepad.xml を新規作成します。

（※）layoutより後ろに続く識別子（xlargeやportやv11など）の順番は正しい順序で指定しないと正しく動作しません。詳細な項目や並べる順番を知りたい場合は、Providing the Best Device Compatibility with Resources（英語）やHow Android Finds the Best-matching Resource（英語）を参照してください。

続いて、新規作成するスマートフォン向けのレイアウトファイルを紹介します。中身はタブレット向けのものとあまり変化はなく、以下のようになります。

タブレット向けの /res/layout-xlarge-v11/notepad.xml と比較してみるために以下の掲載します。

もともとの notepad.xml では、２ペイン構成で左側にノートリストがあって、右側に編集画面がでてくるものでした。スマートフォン向けの画面の場合は画面サイズが小さいため、2ペイン構成にはできないため１ペインで画面遷移を発生させるユーザインタフェースにします。そのため、タブレットのレイアウトファイルの <fragment …. NoteListFragment のみを抜き出したものがスマートフォンの起動画面のノートリストのレイアウトになります。

タブレット向けのレイアウトファイルのnotepad.xml の中の <LinearLayout android:id=”@+id/note_detail_container” という部分はまだ Fragment 指定になっていないため、あとから Fragment の指定に変更します。コートラボの課題では問題になりませんでしたが、せっかく NoteEdit を Fragment 化したので、ここも Fragment 指定にするように課題に入っていたほうがよかったですね。

スマフォでの実行

この状態でスマートフォンで実行してみましょう。ノートが１つもないため、真っ黒な画面になると思います。ここでノートを追加するためにメニューボタンを押すと Exception が発生して落ちてしまいます。

onCreateOptionsMenu() の中のadd.setShowAsAction() で落ちます。理由は、このメソッドは Honeycomb 3.0(API Level 11)からのAPIのため、API Levelが 10 以下のスマートフォンでは提供されておらず、実行時に Exception が発生してしまいます。

これを避けるために、実行時にAPIレベルの判断ロジックを呼び出して実行するかどうかを制御します。具体的な判断ロジックについては、前回のエントリ「1apkでAndroidタブレット向けとスマートフォン向けアプリを実現する方法　その２」を参照ください。今回やりたいことはAPIレベルの判断のため、UIUtils.isHoneycomb() を利用して、add.setShowAsAction() メソッドをコールするかどうかを判定します。

NotepadActivity.java の具体例は以下のようになります。

スマフォ向け対応

続いて、「スマートフォンの場合に画面遷移が必要なため、それ向け対応」を行います。

メニューボタンを押して「Add Note」を実行したときに、タブレットの場合は画面遷移を行わずに右側に新規ノート画面を表示していましたが、スマートフォンの場合はノート編集画面を新しく起動するようにします。「Add Note」を実行したときには、onMenuItemSelected() がコールされるため、その中でタブレットかスマートフォンかの判断ロジックを利用して、処理の振り分けを行います。具体的には以下のようなコードになります。

いまの状態では、スマートフォン向けのノート編集画面(NoteEditActivity)がないため、コンパイルエラーのままなので、これを新規作成します。

NoteEditActivity はスマートフォン向けのみのActivityのため、明確にわかるように所属するパッケージを変更します。
パッケージ名：com.example.android.honeypad.phone の中に以下のように NoteEditActivity.java を新規作成します。

現時点で作成される NoteEditActivity は以下のようになります。

public class NoteEditActivity extends FragmentActivity implements
        NoteEditFragment.OnNoteSavedListener {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        setContentView(R.layout.note_edit_phone);

        FragmentManager fm = getSupportFragmentManager();
        NoteEditFragment edit = new NoteEditFragment();
        // add the NoteEditFragment to the container
        FragmentTransaction ft = fm.beginTransaction();
        ft.add(R.id.note_detail_container, edit, "Edit");
        ft.commit();

    }
}

続いて、NoteEditActivity で参照しているレイアウトファイル(R.layout.note_edit_phone)を以下のように作成します。

上記の res/layout/note_edit_phone.xml の中身は、res/layout-xlarge-port-v11/notepad.xml の <LinearLayout android:id=”@+id/note_detail_container” の部分を Fragment 指定に変更したものです。そのためこの機会に res/layout-xlarge-port-v11/notepad.xml の <LinearLayout android:id=”@+id/note_detail_container” の部分をFragment 指定に変更しておきましょう。変更後の res/layout-xlarge-port-v11/notepad.xml は以下のようになります。

これでスマートフォンの起動画面（ノートリスト画面）（NotepadActivity)からノート編集画面に遷移することができました。ここでTitleとBodyに文章をいれて、Confirm ボタンを押すと保存されますが、ノートリスト画面に戻りません。これはNoteEdit を Fragment 対応したときにタブレット向けしか想定しておらず、Confirm ボタンを押したときの動作として、保存を行うことしか実装されていないためです。タブレットの場合は、左側にノートリスト画面があるため、保存すればすぐに新しいノートのタイトルが追加されて反映されるので問題ないですが、スマートフォン向けの場合は保存を行ったあとにノートリスト画面に戻ってほしいため、この機能を NoteEditFragment に追加します。

さて、この機能はどのように実現すればよいでしょうか？何も考えずに実現しようとすると、NoteEditFragment にタブレットかスマートフォンかの判断ロジックをいれて、スマートフォンの場合に Activity を finish() するという以下のような実装を行いそうです。ここで判断ロジックにisHoneycombTablet() を使っている理由は、、前回のエントリ「1apkでAndroidタブレット向けとスマートフォン向けアプリを実現する方法　その２」を参照ください。

    private void saveNote() {
        // save/update the note
        ContentValues values = new ContentValues(2);
        values.put(NotesProvider.KEY_TITLE, mTitleText.getText().toString());
        values.put(NotesProvider.KEY_BODY, mBodyText.getText().toString());
        if (mCurrentNote != null) {
            getActivity().getContentResolver().update(mCurrentNote, values,
                    null, null);
        } else {
            getActivity().getContentResolver().insert(
                    NotesProvider.CONTENT_URI, values);
        }
        Toast.makeText(getActivity(), "Note Saved", Toast.LENGTH_SHORT).show();
        if( UIUtils.isHoneycombTablet(getActivity()) ){
                getActivity().finish();
        }
    }

FragmentとActivityの役割分担

この方法でも実現は可能ですが、Fragment の導入された目的に照らし合わせるとよろしくありません。

ここで今一度、ActivityとFragmentの関係について考えてみたいと思います。Fragmentが導入された経緯は、スマートフォンとタブレットという画面サイズが大幅に異なる２つの製品群に対して、いままでのActivityで画面を開発していくというスタイルのままではスマートフォン向けアプリとタブレット向けアプリに対してそれぞれの画面レイアウトをもったActivityを２つ開発していく必要があり、開発者にとっては大変な負担になっていくところでした。

そこで、honeycomb （Gingerbread 以下向けにも互換パッケージを提供）から Fragment という概念を導入し、画面を構成するActivityよりも概念的に小さく、ユーザに提供する機能単位で実装を行えるFragment の提供を開始しました。

Fragment はユーザに提供する機能を実装し、ActivityはFragmentの要素をいつ、どこに利用するかの管理や、Androidのお家芸であるIntentの処理を担当することによって、ソフトウェアのコンポーネント化を進めて、再利用性を向上し、ユーザに有用なアプリを提供していけるようになる仕組みです。

ということから考えると、上記のFragmentのなかでUtils.isHoneycombTablet()の判断ロジックをもって、Activityの画面遷移を操作していることは、Fragment が Activity の役割である画面遷移やIntentの処理を行っていることになり、本来の趣旨から外れてしまいます。

そのため、これらの処理は、Activity 側で実装を行い、Fragment 側はActivity の機能を呼び出す仕組みにします。

具体的なやり方としては、Fragment内でコールバックメソッドを定義し、Activityがそのコールバックメソッドを必ず実装するように定義することによって実現します。

この仕組みについては、Creating event callbacks to the activity（英語）かソフトウェア技術ドキュメントを勝手に翻訳：アクティビティとのやり取り：アクティビティへのイベントコールバックの作成に紹介があります。

NoteEditFragment.java に追加するコールバックメソッドは以下のようになります。

public class NoteEditFragment extends Fragment {

    public interface OnNoteSavedListener {
        public void onNoteSaved();
    }

これを Activity で implements して実装します。注意点としては、Activityに対して実装を強制するため NoteEditFragment 内でこのコールバックメソッドが実装されていなければ、ClassCastException を発行して実行時例外が発生し、実行できないようにしています。

上記の実行時例外の発行は、以下のようなコードで実現しています。

public class NoteEditFragment extends Fragment {
...
    @Override
    public void onAttach(Activity activity) {
        super.onAttach(activity);
        try {
            mListener = (OnNoteSavedListener) activity;
        } catch (ClassCastException e) {
            throw new ClassCastException(activity.toString()
                    + " must implement OnNoteSavedListener");
        }

    }

NoteEditFragment にコールバックインタフェースに追加ができれば、以下のようにそのコールバックを呼び出すように変更します。

    private void saveNote() {
        // save/update the note
        ContentValues values = new ContentValues(2);
        values.put(NotesProvider.KEY_TITLE, mTitleText.getText().toString());
        values.put(NotesProvider.KEY_BODY, mBodyText.getText().toString());
        if (mCurrentNote != null) {
            getActivity().getContentResolver().update(mCurrentNote, values,
                    null, null);
        } else {
            getActivity().getContentResolver().insert(
                    NotesProvider.CONTENT_URI, values);
        }
        Toast.makeText(getActivity(), "Note Saved", Toast.LENGTH_SHORT).show();
        // イベントをホストのアクティビティに送信する
        mListener.onNoteSaved();
    }

NoteEditFragment でコールバックの実装を強制することによって、それを利用する２つのActivityで implements する必要がでてきました。

NoteEditActivity では、本来やりたかった保存時にActivityを終了して、ノートリスト画面に戻るという機能を実現したいため、以下のように onNoteSaved() 内で Activity を終了する finish() を実行します。

NotepadActivity では、現状通り特になにもすることはないので、以下のように空のまま実装します。

public class NotepadActivity extends FragmentActivity implements
        NoteListEventsCallback, NoteEditFragment.OnNoteSavedListener {

    @Override
    public void onNoteSaved() {
        // do nothing
    }

これでスマートフォンとタブレットの両方でノート編集画面でノートを追加することができるようになりました。

次は、スマートフォンの起動画面のノートリスト画面ですでに作成済みのノートをクリックした場合に追加編集できる機能を実現します。

現状では、ノートリストを選択した場合、NoteListFragment の onListItemClick() メソッドが呼び出されます。

public class NoteListFragment extends ListFragment {
...
    @Override
    public void onListItemClick(ListView l, View v, int position, long id) {
        super.onListItemClick(l, v, position, id);
        Uri noteUri = ContentUris.withAppendedId(NotesProvider.CONTENT_URI, id);
        mContainerCallback.onNoteSelected(noteUri);
    }

onListItemClick() メソッドの中でさきほどもあったような mContainerCallback.onNoteSelected(noteUri); のようにコールバックインタフェースを実行しています。このコールバックは以下のように定義されています。

public class NoteListFragment extends ListFragment {

    public interface NoteListEventsCallback {
        public void onNoteSelected(Uri noteUri);

        public void onNoteDeleted();
    }

このコールバックインターフェースは誰が実装しているかを調べてみると、NoteListFragment を利用している Activity で実装していることが以下からわかります。

public class NoteListFragment extends ListFragment {
...
    @Override
    public void onAttach(Activity activity) {
        super.onAttach(activity);
        try {
            // check that the containing activity implements our callback
            mContainerCallback = (NoteListEventsCallback) activity;
        } catch (ClassCastException e) {
            activity.finish();
            throw new ClassCastException(activity.toString()
                    + " must implement NoteSelectedCallback");
        }
    }

NoteListFragment を利用しているActivityは、NotepadActivity１つのため、こちらを見てみます。

public class NotepadActivity extends FragmentActivity implements
        NoteListEventsCallback, NoteEditFragment.OnNoteSavedListener {
...
    @Override
    public void onNoteSelected(Uri noteUri) {
            showNote(noteUri);
    }

    private void showNote(final Uri noteUri) {
        // check if the NoteEditFragment has been added
        FragmentManager fm = getFragmentManager();
        NoteEditFragment edit = (NoteEditFragment) fm.findFragmentByTag("Edit");
        if (edit == null) {
            // add the NoteEditFragment to the container
            FragmentTransaction ft = fm.beginTransaction();
            edit = new NoteEditFragment();
            ft.add(R.id.note_detail_container, edit, "Edit");
            ft.commit();
        } else if (noteUri == null) {
            edit.clear();
        }

        if (noteUri != null) {
            edit.loadNote(noteUri);
        }
    }

NoteListFragment のリスト項目のクリックから onNoteSelected() コールバックインタフェースが実行されて、showNote(noteUri);が実行されます。

この中で FragmentManager を利用して fragment の管理を行っています。この処理は、2ペイン構成の場合の処理がモロに記載されているため、スマートフォン向けには不必要な処理です。

そのため、onNoteSelected() コールバックインタフェース内でスマートフォンかタブレット判断ロジックを利用して、処理を分岐させます。分岐させたスマートフォン側の処理では、ノート編集画面を起動するように実装します。

public class NotepadActivity extends FragmentActivity implements
        NoteListEventsCallback, NoteEditFragment.OnNoteSavedListener {
...
    @Override
    public void onNoteSelected(Uri noteUri) {
        if (UIUtils.isHoneycombTablet(this)) {
            showNote(noteUri);
        } else {
            showNotePhone(noteUri);
        }
    }

    // for phone api
    private void showNotePhone(final Uri noteUri) {
        Intent i = new Intent(this, NoteEditActivity.class);
        i.setData(noteUri);
        startActivity(i);
    }

これでスマートフォンのノートリスト画面からノート編集画面に uri を渡して起動することができました。動作確認を行ってみると、どのノートリストを選択しても、TitleとBodyは表示されずに新規作成扱いになってしまいます。

これはまだNoteEditActivity 側で受信した Intent の処理を行っていないためです。

Activity と Fragment の役割分担の上記で話をしましたが、今回のようなバグを追うときにも Intent の処理の場合は、基本的に Activity が担当するため、呼び出す前のActivityが正しく送っていることが確認できていれば、デバッグを呼び出した後のActivityに注力することができます。

NoteEditActivity の onCreate() 内で Intent の受信を行っていないことが原因と判明したため、以下のようなロジックを onCreate() 内に追加します。

追加後のNoteEditActivity は以下のようになります。

public class NoteEditActivity extends FragmentActivity implements
        NoteEditFragment.OnNoteSavedListener {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        setContentView(R.layout.note_edit_phone);
        Intent intent = getIntent();
        Uri uri = intent.getData();

        FragmentManager fm = getSupportFragmentManager();
        NoteEditFragment edit = new NoteEditFragment();
        edit.loadNote(uri);
        // add the NoteEditFragment to the container
        FragmentTransaction ft = fm.beginTransaction();
        ft.add(R.id.note_detail_container, edit, "Edit");
        ft.commit();

    }

    @Override
    public void onNoteSaved() {
        finish();
    }

}

おわりに

これで目的の1apkでタブレット向けとスマートフォン向けのアプリを作成することができました。今回のコードラボのアプリがActivityベースのスマートフォン向けアプリをスマートフォン向け構成を維持しないままにタブレット向けアプリにするというものでした。そして Fragment 実装に置き換えたうえで２ペイン対応のタブレット向けアプリにするというものでした。それをあとから、1apkでスマートフォンとタブレットの両対応アプリにするという一直線ではなく、横道にそれて一度喫茶店で休憩したあとに戻りながら目的地に歩いていくというやり方でした。

本来なら、Activity ベースのスマートフォン向けアプリがベースになるなら、スマートフォン向けアプリのままで Fragment 対応を実施して、スマートフォン向け動作を確保しながら、徐々にタブレット向けアプリを開発していくというスタイルがよいと思います。

今回作ったアプリは eclipse のプロジェクト形式で整理したうえ（まだぐちゃぐちゃなので）で公開したいと思います。もし急ぎでほしいという方は（そんな人いないと思いますが）ご連絡頂ければ先に展開させて頂きます。

「Android Layout Cookbook アプリの価値を高める開発テクニック」の作者の方もY.A.M の 雑記帳：Android Developer Lab Tokyo 2011 のノートパッドをカスタマイズしてみた。（こちらのほうが相当レベルは上ですが。。。大変勉強になります。）でカスタマイズされています。

Fragment についてはまだ日本でAndroidタブレットが普及していない事情もあり、利用されているアプリは少ないと思います。Fragmentは、画面を持たないものも開発可能ということでタブレットアプリとスマートフォンアプリの両方で利用できる汎用ライブラリ的なものを作るプラットフォームにもなれるのではないかと考えています。ADL2011で google の android developer Advocate の方が次期バージョンの IceCreamSandwich(ICS) でも Fragment は推進していくのでどんどん Fragment を利用すいてアプリを開発してくださいとおっしゃっていました。そういうことを踏まえると、今後Androidアプリを開発していくにあたって Fragment は避けて通れないものになっていく予感がしますし、使いこなせるようになれば大変強い武器になっていくのではないかと考えています。

今後の色々と調査結果を紹介していければと思っています。Fragment使ってAndroidアプリを作っていきましょう！！

public static boolean isHoneycomb() {
    return Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB;
}

public static boolean isHoneycombTablet(Context context) {
    return isHoneycomb() && (context.getResources().getConfiguration().screenLayout
            & Configuration.SCREENLAYOUT_SIZE_MASK)
            == Configuration.SCREENLAYOUT_SIZE_XLARGE;
}

上記の isHoneycomb()と isHoneycombTablet() の判断ロジックを解説するために、以下の表で端末の対応APIバージョンと端末のインチサイズの関係を整理しました。(1)から(6)についてそれぞれ紹介します。世の中に対応端末が多い順番に紹介します。

xlargeなどの詳細な説明は、公式ドキュメント（英語）のSupporting Multiple Screensの「Range of screens supported」を読んでみてください。ソフトウェア技術ドキュメントを勝手に翻訳(2. 多様な画面のサポート)に日本語訳がありますのでこちらもお役に立つと思います。

(2)は、現在発売されているAndroid端末のほとんどが該当するものでいまAndroidマーケットにあるアプリのこの端末サイズに対応しているものがほとんどです。

(3)は最近発売されたAndroidタブレット端末で、xoom や Galaxy tab 10.1 や Optimus pad が該当します。

(4)は、該当する端末が今も将来も発売されません。理由はグーグルが honeycomb 3.0 系はタブレット向けのみでスマートフォン向けのリリースは実施しない、スマートフォン向けの次期OSは、IceCreamSandwich(ICS)(バージョン番号未定）で対応するという発表を行っているためです。

(1)は、現在のGBの最新バージョンが2.3.4ですが、GBも今後アップデートされる可能性があり、端末メーカーから発売される可能性があるためアプリ開発者としては対応しておく必要があります。（発売後に対応してもよいですが、事前に準備できることはしておきましょう）

(5),(6)については、まだ発表もされていませんが、現段階でわかっていることは、APIバージョンは11以上の数字が割り当てられますし、タブレット向けとスマートフォン向けのインチサイズの両方に対応されるということです。

では、 isHoneycomb()と isHoneycombTablet() の判断ロジックがどれに対応しているかというと、以下のようになります。

isHoneycomb()は、(3),(5),(6)を判断するために利用します。

isHoneycombTablet() は、(3),(5)を判断するために利用します。

isHoneycombTablet() の中で isHoneycomb() と実行端末のスクリーンサイズの取得、比較を行っています。これによって、将来(6)の端末が出てきたときに isHoneycomb() だけの判断ロジックではタブレット向けの画面レイアウトになってしまい、3インチのスマートフォン向けで2画面構成のアプリになり大変使いづらくなってしまいます。それをさけるために、 isHoneycomb()だけでなく、実行端末のスクリーンサイズを参照して、適切は画面レイアウトをユーザに提供する必要があります。

もちろん、開発スピードを上げるために、いま出ている端末だけの対応に注力して、 isHoneycomb()のみを利用することもよいと思います。
必ず上記のロジックを使わないといけないということではなく、きちんと開発するアプリの目的や対象端末、対象期間、対象とするユーザに応じて、適切な判断ロジックを利用して、1apkでタブレット向けとスマートフォン向けのアプリを開発していく必要があるということです。

このイベントの codelab ではスマートフォン向けアプリをタブレット向けアプリに変更する実践を行いました。さらにそれを発展させて、1apkでタブレット向けとスマートフォン向けアプリに対応させる方法を検討してみました。
codelab でスマートフォン向けアプリをタブレット向けアプリに変更して、以下のようなクラス図になりました。

1apkで両対応させるために、以下の方針でクラス設計を行います。
タブレット向けアプリ： 1 Acrivity に 複数の Fragment を割り当てる（変更なし）
スマートフォン向けアプリ： 1 Activity に 1つの Fragment を割り当てる

更新したクラス図は以下のようになる予定です。タブレット向けとスマートフォン向けのActivity が明確になるように、パッケージをそれぞれ tablet と phone を追加して、そのパッケージ内に Activity をいれました。緑色のところが今回のために追加・変更した部分です。Fragment を実装した各画面パーツはそのまま上位のパッケージのままとしました。

ここで１つ重大な課題が発生しました。1apkのため、アプリ起動時に起動した端末がタブレットかスマートフォンかを判定するロジックが必要になりました。
これについては、

Google IO 2011 のスケジュールアプリ(http://code.google.com/p/iosched/)の中で Honeycomb 3.1かつ大画面タブレット と それ以外（大半がSDK Version 10(GingerBread 2.3.3)以内でしょうが）の判定ロジックがあり、参考になります。今回はこのあり方を採用させて頂くことになると思います。

年末に出るといわれている Ice Cream Sandwich (ICS)(バージョン番号不明）ではタブレットとスマートフォンの両方に標準対応するそうで、このあたりの判定ロジックも提供されると思うので、それまではこのやり方が利用できそうです。

public static boolean isHoneycomb() {
    return Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB;
}

public static boolean isHoneycombTablet(Context context) {
    return isHoneycomb() && (context.getResources().getConfiguration().screenLayout
            & Configuration.SCREENLAYOUT_SIZE_MASK)
            == Configuration.SCREENLAYOUT_SIZE_XLARGE;
}

クラス設計を行ったクラスの具体的な実装はまた後日紹介する予定です。

以上

クラス図で全体像を把握しよう

資料だけでは全体像がわかりづらいため、トレーニングの全体像を把握するために変更前のスマートフォンアプリのクラス図と変更後のタブレット向けのクラス図を書きました。これをみてわかるように、既存のActivityはFragmentを継承したクラスに変更され、新しくActivity(NotepadActivity)(android-support-v4.jarを利用する場合はFragmentActivityを継承すること)を作成しています。

スマートフォン向けに作っていた Activity はタブレット向けアプリでは Fragment に相当していて、ListActivity は ListFragment に相当しています。
ContentProvider 関連は変更がないため、スマートフォン向けアプリで利用していたものがそのまま再利用できるということがわかります。
いままでスマートフォン向けにアプリを開発していてDBを作成していた方には朗報ですね。

今回のトレーニングでは、スマートフォン向けアプリをタブレット向けアプリに変更するというものでしたが、１つのアプリでスマートフォン向けとタブレット向けに両対応することも可能なようです。

Google IO 2011 のスケジュールアプリ(http://code.google.com/p/iosched/)はそのような作りになっています。このアプリは嬉しいことにオープンソースになっているので中身を見ることができます。
スマートフォン向けとタブレット向けの両対応しているアプリとして大変参考になります。

いきなりソースコードから見始めると全体像がつかめずわかりづらいと思います。幸運なことに全体像をつかむのに有効な資料を公開してくれている方がおられます。Iosched読書会向け資料（途中で力つきられたようで途中までの分析のようですが）で全体像を掴んでからソースコードを見ていくとよいと思います。

変更前と変更後のクラス図

■（変更前）スマートフォン向けノートパッドサンプルアプリのクラス図

■（変更後）タブレット向けノートパッドサンプルアプリのクラス図

Fragmentについては以下のサイトが役に立ちます。

• Android SDK > Fragment(英語）
• ソフトウェア技術ドキュメントを勝手に翻訳: Android 開発ガイド>1.1 フラグメント
• Techbooster: Fragmentを使ってMenuを動的に作成する
• Techbooster: Fragmentを動的に変化させる
• Y.A.M の 雑記帳: The Android 3.0 Fragments API
• Y.A.M の 雑記帳: Android　Fragment を使う

ハッシュタグは
#adl2011jp
です。

Togetterは
#adl11jp Android Developer Lab 2011 7/2-3
です。

以下のソースコードをベースに既存のスマートフォン向けのアプリ（Activityベース）をタブレット向けに変更していきます。
コードラボ向けソースコード
をダウンロードしてください。

手順はHoneypad Codelab Steps — Tokyo 2011に書かれていますが自分の復習のために以下に記載しておきます。
以下の情報だけでは今回のトレーニングの全体像がつかみづらく、いま何をしているのかがわかりにくいため、Androidタブレット向けアプリ開発方法その２に全体像がわかるように変更前と変更後のクラス図を記載しておきました。参考にしてください。

Honeypad コードラボ 東京2011　目次

• Step 1. ターゲットをHoneycombにしよう
• Step 2. アクションバーを利用しよう
• Step 3. Fragments（Honeycomb 3.0からの新機能）を利用して新しいActivityを作成しよう
• Step 4. Fragment対応するために NoteEdit クラスを変更しよう
• Step 5. Fragment対応するために Notepad クラスを変更しよう
• Step 6. 新しいActivityのために Manifest を更新しよう
• Step 7. Activityと Fragments をつなげよう。パート１
• Step 8. Activityと Fragments をつなげよう。パート２
• Step 9. 縦画面レイアウトに対応しよう
• 最終のクラス図とレイアウト図

Step 1. ターゲットをHoneycombにしよう

Step1のゴール

• プロジェクトのビルドターゲットをAPI level 11に変更する
• minSdkVersionを API level 11 として明記する
• Set the android “Theme.Holo.Light” theme on the application
• アプリケーションのテーマを “Theme.Holo.Light”に設定する
• おまけ（余裕があれば）：ハードウェアアクセラレーションをオンにする

実施手順

• AndroidManifest.xml の タグのコメントを外す

  <uses-sdk android:minSdkVersion="11" />
  <activity android:name=".Notepad"
            android:label="@string/app_name"
            android:theme="@android:style/Theme.Holo.Light"
            android:hardwareAccelerated="true">
  

Step 2. アクションバーを利用しよう

Step2のゴール

• アクションとテキストを’Add Note’ オプションメニューを表示する
• 適切なアイコンを追加する

実施手順

• Notepad.java から古いonCreateOptionsMenuを削除して、新しいonCreateOptionsMenuのコメントを削除する

  @Override
  public boolean onCreateOptionsMenu(Menu menu) {
          super.onCreateOptionsMenu(menu);
          MenuItem add = menu.add(0, MENU_ADD_ID, 0, R.string.menu_add);
          add.setShowAsAction(MenuItem.SHOW_AS_ACTION_IF_ROOM
                          | MenuItem.SHOW_AS_ACTION_WITH_TEXT);
          add.setIcon(R.drawable.ic_menu_add);
          return true;
  }
  

• おまけ（余裕があれば）：メニューをXMLで定義する

Step 3. Fragments（Honeycomb 3.0からの新機能）を利用して新しいActivityを作成しよう

Step3のゴール

• NotepadActivityを作成する
• プロジェクトに入っているレイアウトファイルの notepad.xml を利用する
• NotepadActivityの onCreate メソッドをオーバーライドする
• notepad.xml を content view にセットする

実施手順

• NotepadActivity.java の中で、クラス定義と onCreate() メソッドのコメントを外す。
• （注）onCreate() メソッド以外のメソッドのコメントは外さないでください！！

  public class NotepadActivity extends Activity {
      @Override
      protected void onCreate(Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
          setContentView(R.layout.notepad);
      }
  }
  

Step 4. Fragment対応するために NoteEdit クラスを変更しよう

概要

• Fragmentクラスを継承する
• 空のコンストラクタを追加する
• onCreateView()を実装する
• 目的のレイアウトをインフレートして、それを返す

     View v = inflater.inflate(R.layout.note_edit, container, false);
  

• これでsetContentViewを呼ぶ必要はない
• onCreateView()に初期化ロジックを移動して、onCreate()メソッドを削除する
• １つのスクリーン向けに setTitle() を行う必要はないでしょう
• findViewById() メソッドコールを実施して、view を利用する
• Fragmentは、Context を拡張するものではありません。例えば、Content Resolver にアクセスするために必要な場合など。
• Context にアクセスする必要な場合は、上位（親の）Activityから取得する
• NoteEdit スクリーンを閉じるためにコードを削除する
• intent で起動されるのではなく、起動intent によって特定された Data Uri の蓄積も削除する
• NoteEditをNoteEditFragment に名前変更する

実施事項

• NoteEdit.javaの中で、loadNote()とclear()メソッド以外のすべてのコメントを外す
• NoteEdit を NoteEditFragment に名前変更する
• おまけ（余裕があれば）：タブレット向けの fragment を widgets に最適化する
• テキスト書体とパディングを適切に設定する
• widgetにバックグラウンドボーダーを設定する

Step 5. Fragment対応するために Notepad クラスを変更しよう

概要

• ListFragment を継承する
• 空のコンストラクタを追加する
• viewが作成された後の初期化場所を変更する
• onActivityCreated() メソッドをオーバーライドする
• onCreate()メソッドから初期化ロジックを移動する
• onCreate()メソッドを削除する

    @Override
    public void onActivityCreated(Bundle savedInstanceState) {
          super.onActivityCreated(savedInstanceState);
          fillData();
          registerForContextMenu(getListView());
    }
  

• Fragment は Context を継承していません。そのため、Content Resolver を得るためには、上位（親の）Activityから取得する必要あり。
• オプションメニューのメソッド(onCreateOptionsMenu() & onMenuItemSelected() ) を NotepadActivity クラスに移動する
• メニューのアイテムIDも移動すること
• createNote()メソッドコールを削除する
• createNote() メソッドを削除する
• Notepad　クラスを NoteListFragment クラスに名前変更する

実施事項

• Notepad.javaの中で、NoteListEventsCallback インタフェース, mContainerCallback フィールド, onAttach() メソッド以外のコードのほとんどのコメントを外す
• NoteListFragment クラスに名前変更する
• createNote()メソッドを削除する
• おまけ（余裕があれば）：タブレット向けの notes_row エントリに最適化する
• ‘activated’ として選択済み row を設定する

Step 6. 新しいActivityのために Manifest を更新しよう

step6のゴール

• NotepadActivityをメインアクティビティに変更する
• NoteEditFragment のActivity 継承を削除する

実施事項

• AndroidManifest.xml の中で、２つめのタグのコメントを外して、NoteEditFragment 向けのタグを削除する

Step 7. Activityと Fragments をつなげよう。パート１

設計上の留意点

• 追加した大半の部品を接続するための実装（コンポーネントを接続するためのコード）
• 次のようなUIイベントのルーティングを実施： Fragment (NoteList) –> Activity –> Fragment (NoteEdit).
• このルーティングを実装するために、NotepadActivity　にインタフェース定義を実装を追加
• もう１つ（概要より少ない）の方法は NoteList を得るためにNoteEditに直接アクセスする方法。しかし、それでは密結合である。
• コンポーネントを疎結合にするために、NotepadActivity がここでルーターの役割を担う。
• Step7のPart1では、NoteListからNotepadActivityへの接続を実装する
• Step8のPart2では、NotepadActivityからNoteEditへの接続を実装する

概要

• リスト上のNoteの選択と削除のイベント処理のための(NoteListEventsCallbackを呼ぶために）コールバックインタフェースを定義する

  public interface NoteListEventsCallback {
          public void onNoteSelected(Uri noteUri);
          public void onNoteDeleted();
  }
  

• NotepadActivityの中でインタフェースを実装する
• NoteListFragment は含まれているアクティビティに接続されるときに、インタフェース実装と参照補助を確認する
• この参照のコールバックを実行可能にする

  @Override
  public void onAttach(Activity activity) {
          super.onAttach(activity);
          try {
                  // check that the containing activity implements our callback
                  mContainerCallback = (NoteListEventsCallback) activity;
          } catch (ClassCastException e) {
                  activity.finish();
                  throw new ClassCastException(activity.toString()
                                  + " must implement NoteSelectedCallback");
          }
  }
  

• Call the relevant callback when a note is selected from the list
• リストからノートが選択されたときに、関連するコールバックを呼び出す

  @Override
  public void onListItemClick(ListView l, View v, int position, long id) {
          super.onListItemClick(l, v, position, id);
          Uri noteUri = ContentUris.withAppendedId(NotesProvider.CONTENT_URI, id);
          mContainerCallback.onNoteSelected(noteUri);
  }
  

• リストからノートが削除されたときに、関連するコールバックを呼び出す

  @Override
  public boolean onContextItemSelected(MenuItem item) {
          switch (item.getItemId()) {
          case DELETE_ID:
                  AdapterContextMenuInfo info = (AdapterContextMenuInfo) item
                                  .getMenuInfo();
                  getActivity().getContentResolver().delete(
                                  ContentUris.withAppendedId(NotesProvider.CONTENT_URI,
                                                  info.id), null, null);
                  fillData();
                  mContainerCallback.onNoteDeleted();
                  return true;
          }
          return super.onContextItemSelected(item);
  }
  

実施事項

• NoteListFragment.java の中で、インタフェース定義をコメントを外す
• NoteListFragment.java の中で、onAttach() メソッドとmContainerCallback フィールドのコメントを外す

Step 8. Activityと Fragments をつなげよう。パート２

概要

• 与えられたUriでノートが開くように NoteEditFragment にメソッドを追加する
• 関連するメンバの値を Uri に保持する
• フィールドの値を代入する
• もし fragmentが初期化されたときにこのメソッドを呼びたい場合のみ、onCreateView()メソッドの中で状態の初期化を行う前にコールされないようにガードしてください。

  protected void loadNote(Uri noteUri) {
          mCurrentNote = noteUri;
          if (isAdded()) {
                  populateFields();
          }
  }
  

• NoteEditFragment にテキストフィールドをクリアするためのメソッドを追加する

  protected void clear() {
          mTitleText.setText(null);
          mBodyText.setText(null);
          mCurrentNote = null;
  }
  

• NotepadActivityの中で、リストからノートが選択されたときにノートの詳細を表示するためにNoteEditFragmentを呼び出す。
• もし NoteEditFragment がアクティビティに追加されていれば、FragmentManager をチェックに利用する
• ヒント：与えられたタグでFragmentをチェックする
• もし、Fragment が見つけられなければ、コンテナーに追加を行う
• タグ上の note_detail_container に NoteEditFragmentの新しいインスタンスを追加するためにFragmentTransaction を利用する
• 選択したノートを表示するために NoteEditFragment の新しいメソッドを呼び出す
• もしユーザが’Add Note’をクリックした場合は、edit fragment をクリアする

  @Override
  public boolean onMenuItemSelected(int featureId, MenuItem item) {
          switch (item.getItemId()) {
          case MENU_ADD_ID:
                  showNote(null);
                  return true;
          }
          return super.onMenuItemSelected(featureId, item);
  }
  

  private void showNote(final Uri noteUri) {
          // check if the NoteEditFragment has been added
          FragmentManager fm = getFragmentManager();
          NoteEditFragment edit = (NoteEditFragment) fm
                                  .findFragmentByTag("Edit");
          if (edit == null) {
                  // add the NoteEditFragment to the container
                  FragmentTransaction ft = fm.beginTransaction();
                  edit = new NoteEditFragment();
                  ft.add(R.id.note_detail_container, edit, "Edit");
                  ft.commit();
          } else if (noteUri == null) {
                  edit.clear();
          }
  
          if (noteUri != null) {
                  edit.loadNote(noteUri);
          }
  }
  

• もし、ユーザがノートを削除する場合、NoteEditFragment を取り除く。

  public void onNoteDeleted() {
          // remove the NoteEditFragment after a deletion
          FragmentManager fm = getFragmentManager();
          NoteEditFragment edit = (NoteEditFragment) fm
                          .findFragmentByTag("Edit");
          if (edit != null) {
                  FragmentTransaction ft = fm.beginTransaction();
                  ft.remove(edit);
                  ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);
                  ft.commit();
          }
  }
  

• おまけ（余裕があれば）：いくつかの画面では UI スレッド上でディスクアクセスを実行している。
• StrictMode上でこれらの場所を発見してみてください。
• そして、これらを修正してください。

Step 9. 縦画面レイアウトに対応しよう

Step9のゴール

• 縦画面用のレイアウト向けのフォルダを作成する
• すでに存在する notepad.xml レイアウトをコピーして、縦画面になったときにリストが詳細画面の上に配置されるように修正する
• widthとheightを適切な値に設定する

実施事項

• コメントアウトされていないところの場合、layout-port/notepad.xml の中で記載されているセクションで vertial(portrait)版に変更する

最終のクラス図とレイアウト図

以上、これであなたも honeycomb マスター！！

一番のサプライズは、Docomo様から Optimas Pad のプレゼントがありました。
これを利用して、コードラボのアプリ開発体験に参加できました。

Optimus Pad L-06C

■Optimus PadのUSBドライバ
http://www.lg.com/jp/mobile-phones/download-page/L-06C/product-info-driver.jsp

OptimusPad Lg Driver

■Optimus PadのUSBドライバをインストールする
http://darkroid.net/archives/928

■Optimus PadのUSBドライバをインストールする その2
http://darkroid.net/archives/933

コードラボで開発したアプリは、昔懐かしい notepad アプリでした。
スマートフォン版のnotepadアプリを Fragmet Technology を利用して、２ペインのタブレット向けアプリ化するというものでした。

■当日の資料やアジェンダは以下にあります。
http://j.mp/adltokyo2011

（※）イベント中に「なぜgoogleの中の人がgoo.gl じゃなくて j.mp を使うんですか？」と質問があり、
「j.mp は後ろが自由に定義できるので利用している。それだけの理由です。」というやりとりがありました。

■当日のQ&Aは、以下の moderator にあります。
https://www.google.com/moderator/#16/e=954eb

Honeycomb タブレットアプリ開発に参考になるリンクは以下です。

■ドキュメント系
Android 3.0 Platformの紹介
Optimizing Apps for Android 3.0（タブレット）向けのアプリ最適化

■Google I/O 2011 セミナー動画、プレゼンテーション資料
Honeycomb ハイライト
Android Protips: さらに発展したトピック。。。
スマートフォンとタブレット向けのUIデザインについて
開発者向けのAndroidマーケット

■参考になるサンプルプログラム
Google I/O 2011 スケジュールアプリ
– セッション内容や参加会社情報などが見えるアプリ
Photo Album (xlarge-demos)
Honeycomb ギャラリー(Android SDKにソースコードがあります)