16日の表のエントリは@RKisatoさんです。前の日の記事は@LuckOfWiseさんによる「きっとお金が欲しくてAndroidを始めた僕たちへ | LuckOfWise.com」です。

こんにちは、@9reです。Androidアプリ開発に携わってそろそろやっと1年です。恐縮ですが、ごく普通のAndroidアプリ開発に関する記事を書きます。

Support Package

というと、ご存知の通り、Android 4.0用のコード等をそれらよりもっと前のAndroid 1.6とかでも使えるようにという素敵プロジェクトです。個人の感想を言うと、当初の設計ミスや使い辛さを半ば認めているようなプロジェクトだとも思います。という意味では新規プロジェクトなんかにはかなりオススメしたいライブラリではあると思っています。・・・が

サンプル・コードがそもそも動かない

まず、1.6で動かないのはわりと仕方ないし、これから導入する方にとってはあまり関係ないかも知れませんが、2.2でもサンプルコードが動かないので導入を躊躇ってしまわれた方もいるかもしれません。quick & dirty fixではありますが、1.6でも動くサンプル作っておきましたので是非。

MapViewをSupport PackageのFragment内で使うには？

ということでやっと本題に入りました。これはアチラこちらで質問がされていてFAQだと思います。android.support.v4.app.FragmentManagerという android.app.FragmentManager相当のクラスがあるのですが、これを使うには、FragmentActivityを継承する必要があります。

一方MapViewを利用するにはMapActivityを継承する必要があります。そうです。よくある多重継承の問題です。

多重継承

個人的には必要は感じませんが、やはり困ったとき(フレームワークに設計を強制される時)の最終手段があるというのはいいですね。

このケースでは、FragmentActivityとMapActivityのうちFragmentActivityはオープンソースですので、そちらに手を入れます。

一つの方法は、単純にFragmentActivityのsuper classをMapActivityにすることです。これは、android-support-v4-googlemapsというプロジェクトでの方針です。diffが少ない分メンテしやすいし、安全だと思います。しかし一方で、FragmentActivityまでもがMapActivityの制約を受けることになってしまいます。

MapActivityの制約

documented にあるように

これを無視すると、予期せぬことが起きるらしいです。少なくとも次のようなエラーメッセージが出ている人は、うっかりこの制約を冒してしまっているように思います。

この部分はオープンソースではないため詳細は分かりませんが、「ドキュメントにやってはいけない」と明記されていることをするのは、あまり得策ではないでしょう。

この場合でも、Activityが一つしか存在しない作りであれば、全く問題はないと思います。

しかし、既存のプロジェクトからの移行等そのようなことができない場合はmixin風のクラスを書くというような解決策になってくると思います。

mixinで書きなおしてみた

取り敢えず、forkしてブランチ作っておきました。experimental-fragment-activity-feature-impl

実装にあたっての指針

まず、本家のFragmentActivityで定義されているメソッドを2つに分けます。Activityのメソッドを上書きしているものと、独自のメソッドです。特に独自のメソッド群は新しくFragmentActivityFeatureとしてインターフェイスを定義します。また、ライブラリ内で直接アクセスされているフィールドのgetterやsetterもこれに加えます。

/***
 * FragmentActivity独自のメソッド
 ***/
Object onRetainCustomNonConfigurationInstance();
Object getLastCustomNonConfigurationInstance();
void supportInvalidateOptionsMenu();
void onAttachFragment(Fragment fragment);
FragmentManager getSupportFragmentManager();
void startActivityFromFragment(Fragment fragment, Intent intent, int requestCode);
void invalidateSupportFragmentIndex(int index);
LoaderManager getSupportLoaderManager();
LoaderManagerImpl getLoaderManager(int index, boolean started, boolean create);

/*** 
 * ライブラリ内でアクセスされているフィールド用のgetter
 ***/
FragmentManagerImpl<?> getFragmentManagerImpl();
boolean isRetaining();
Handler getHandler();

あとは、FragmentActivityとして定義されている変数を新しいインターフェイスの型FragmentActivityFeatureとして定義し直します。一部Activityとしての性質を要求されている箇所では取り敢えず、<FragmentActivityImpl extends Activity & FragmentActivityFeature>というパラメータ付きの型として定義します。

しかしながら、これではFragmentクラスようなパブリックなクラスまでもがパラメータ付きのクラスになってしまいます。これではもはや、android.app.Fragmentと同じようには使うことが出来ません。

Fragment<?> fragment = new Fragment<?>();

勿論ここでraw typeを使うことも可能ですが、コンパイラにも怒られてしまいますし、あまり気持ちの良い物ではありません。

そこで<FragmentActivityImpl extends Activity & FragmentActivityFeature>として定義していたフィールドmActivityをただのActivityとして定義しなおしました。そしてこのフィールドをprivateにし、setterのシグネチャを以下のように定義することで、このフィールドに対する代入の型チェックを行うことにしました。

<FragmentActivityImpl extends Activity & FragmentActivityFeature>
void setActivity(FragmentActivityImpl activity) {
    mActivity = activity;
}

なので、このフィールドに対して

((FragmentActivityFeature)mActivity).getSupportLoaderManager();

というキャストは安全です。

JDK 6のバグ

このフィールドのgetterを以下のように定義しました。

@SuppressWarnings("unchecked")
final public <FragmentActivityImpl extends Activity & FragmentActivityFeature>
FragmentActivityImpl getActivity() {
    return (FragmentActivityImpl) mActivity;
}

しかし、ここに書かれている通り、このコードはeclipseのコンパイラではコンパイルが通りますが、JDK 6の古いバージョンではコンパイルが通りません。

また、JDK 7ではこのコードは問題なくコンパイルすることが出来ます。ということでバグなのではないか？というように思っています。

ということでjdk6用のパッチも書きました。単純にActivityを返します。

Activity getActivity() {
    return mActivity;
}

FragmentActivityFeatureの機能を使いたい場合は、内部で行なっているのと同様の

((FragmentActivityFeature)getActivity()).getSupportLoaderManager();

というキャストを行います。

勿論、パッチを当てたバージョンをdefaultとして、パラメータ付きの型を返す方をパッチとするべき、という批判があるかもしれません。

困りがちな事例を幾つか

MapActivityにはMapViewは一つしか作れない

FragmentのonCreateViewでMapViewを生成するとこの制約にかかってしまいます。ActivityのonCreateで生成し、mMapViewのようなフィールドとしてインスタンスの参照を保持し、Fragment側で利用する際には、

MyMapActivity activity = (MyMapActivity) getActivity();
MapView mapView = activity.getMapView();

のようなgetterを通してインスタンスを利用すると良いでしょう。

ViewPagerの中でMapViewのスクロールが出来ない

ViewPagerは子要素のTouchEventsをViewGroup.onInterceptTouchEventをoverrideすることで、子要素から奪っています。この挙動を変えるにはこのメソッドを上書きしてください。

@Override
public boolean onInterceptTouchEvent(MotionEvent event) {
    if (shouldDispatchTouchEventsToTheMapView()) {
        // 子要素にイベントを送りたい！
        return false;
    }
    return super.onInterceptTouchEvent(event);
}

ListFragmentのちょっとしたハマり所

以下のようなコードは、エラー等は一切起きませんが、その後このFragmentの挙動がおかしくなる可能性があります。

@Override
public void onDestroyView() {
    super.onDestroyView();

    if (getView() != null) {
        // 何か終了処理のようなもの
        getListView().setOnScrollListener(null);
    }
}

以下のようにメソッドの呼び出し順序をかえてください。

@Override
public void onDestroyView() {
    if (getView() != null) {
        // 何か終了処理のようなもの
        getListView().setOnScrollListener(null);
    }

    super.onDestroyView();
}

これはsuper.onDestroyView()を呼んだ後に、getListView()を呼んでしまうと、内部のフィールドmListがonDestroyViewの後は本来はnullとなっている筈であるのに対し、getListView()を呼ぶことで、mListが古いListViewの参照を持つこととなってしまいます。結果再びonCreateView()が呼ばれても内部変数は、ensureList()の

private void ensureList() {
     if (mList != null) {
         return;
     }
}

という実装により、古いListViewと古いListViewに対するOnItemClickListenerという組み合わせが残ってしまい、コールバックvoid onListItemClick (ListView l, View v, int position, long id)は呼ばれなくなってしまいます。

最近出たrev.5になっても未だに修正されない明らかなバグ

受け売りですみません。

結び

少々バグもありますが、Fragment apiやLocalBroadcastReceiverやModernAsyncTask等、便利なapiも結構ありますので、 何か困ったことがあったら、ソースにパッチを当てたり等しながら導入するといいのではないでしょうか。

長々とありがとうございました。少し翻訳調なのは、焦りつつ原稿を日本語に直していたからです。

以上、日本語も英語も不自由な@9reでした!

10月21日に恵比寿支社の地下にて行われた「スマートフォンアプリワークショップ　"twitterアプリ改造大会！"」に参加してきました！
iPhoneアプリとAndroidアプリのワークショップを同時に行うイベントはちょっと珍しいのではないでしょうか。

Androidチームに与えられた課題はこちら。

1. 毎回ログインしなくていいようにする　　ヒント：SharedPreference
   


2. リストビューを高速化する　　ヒント：使いまわす
   


3. 画像（Followerのアイコン）表示を高速化する　　ヒント：非同期処理
   


4. ブレストを行い、新しい機能をつくる

アイデア出しから始まるワークショップ系の勉強会には、
何か今まで自分が作ったものやネタをいくつか持っていってベースにすると完成度が上がるかもしれません。

懇親会は和やかにすすみましたが、もっと開発中にiPhoneとAndroidの開発者で意見交換したかったかも。
こんどは全く同じものをiPhoneとAndroidでそれぞれつくる、とかもおもしろいかもしれないですね！

みなさん、よくアプリ開発しててリリース直前になって、あーあれ忘れてた、これどうなってんのーみたいな話になったことはないでしょうか。
ありがちなところでは、マーケット用の画像ないよ、とかアプリ説明決まってないとか。

今日はディレクター向けに、アプリ開発時にチェックしておくことのまとめです。

まずはアプリ開発スタート時にチェックしておきたいもの。
すぐ決まることはさっさと決めるのが、ブラッシュアップ時間を確保するポイントです。

次に、マーケット情報関連。
アカウントの用意や証明書、あとはレビュー依頼予定やプレス準備などです。

まだまだ続きます。
次は制作チーム内での情報共有として整理しておきたいもの。

多いように思いますが、ここまではワイヤー作る以前にほとんど書けてしまいます。
仕様からもれがちなものを抑えていきましょう。

ここからは制作進行中などに注意していくもの。

以上はアサイン後にチェックが始まります。
デザインデータの書き出しをどちらがやるか、などはメンバーによって変わってくると思います。

そして忘れちゃいけないテスト仕様書づくり。
ここでもれそうなものたち。

だいたいこんな感じじゃないでしょうか。
あとはおまけ。iPhone版が先にあって、移植する際に見直すポイント。

ざっくりまとめてみてこんなところじゃないでしょうか。
このあたり整理されているだけでもチーム内の意思疎通はだいぶうまくいくんじゃないかと。
仕様書以前の確認もれ対策でした。

※対象機種などについては意図的に外してあります。
　基本的にOSバージョンがOKならすべてで動く、というのが大前提なので。

KAYACでは、わいわいアプリ作りたいエンジニアほかいろいろ、募集しています