Android/組み込み系

Android Studio で Junit を使いたいので、戦い続けて挫折して立ち返って立ち直った話

片桐　継（Tugu Katagiri） — Thu, 21 Aug 2014 16:49:00 GMT

最初、EclipseでJunit 4.11+Robolectricを使ってたんだけど、AndroidStudioに移植した時に、全部グリーン状態のソースを移植したのでテストコードは省いてたｗ

なので、機能追加のついでに、テストコードも移植しようと思ったんだけど、意外な展開が。

!!! JUnit version 3.8 or later expected:

java.lang.RuntimeException: Stub!
＜中略＞
Process finished with exit code -3

素直にRobolectricを依存ライブラリに追加して実行して、なにこれ？？？というわけで色々と調査。で、判ったことは

Android StudioでRobolectric使うならプラグインいれましょう
クラスパスはJunit＞SDKの順番でライブラリ参照しましょう

あふー、gradleをいじる羽目になりましたですよorz　書き直すのメンドイなー。

RobolectricスタッフのブログやGoogleGroupを見る限りだと、この辺りの問題はできたら解決したいなー的レベルらしくて、しばらくは手動でごにょごにょの世界のようです。まぁAndroid Studio自身がbetaの立場だもんなー、正式版になってからなんだろうなぁ（遠い目）

で、やってみたこと。

app/build.gradleにrobolectricの依存ライブラリ追加
ルートのbuild.gradleにrobolectricのプラグインのための依存ライブラリ追加
app/buid.gradleにrobolectircのプラグイン追加
ここで、いったんgladleをSync
ターミナルから、プロジェクトルートでgladle robolectric を実行し、必要なクラスがコンパイルされていることを確認
テストコードを書いて、ライブラリが追加出来ていることを確認
テストコードから生成されたクラスの出力先をクラスパスに追加
プロジェクトルートにある、.imlファイルの中にあるクラスファイルの読み込み順番を変更
gladlew androidTest を実行

さらっと書いたけど、２から５の間はgradleソースの読み込みだったので、簡単じゃなかったよorz 　gradleソースはpom.xmlよりも何をやっているのかソースで追える分、楽と言えば楽だし、親切と言えば親切なんだけどね。やっててよかったgroovy。

そして、何とかたどり着く9のフェーズ。ここで恐怖のハマりポイント、自クラスをクラスパスにうまく追加できない、をやらかしてしまった。いや、世界には、この方法で解決している人もいるので（成功例がMacOSXだったりするのがとてもとても気になるけれどもｗ）きっと、何かが悪いんだろう。

収穫はgradleソースが読めるようになった、ってことで、挫折orz

これに丸々二日ハマって、なんか疲れたんで、基本に立ち返ってみたんだ。

Android SDK　にテストフレームワークがあるのかな？

結論から言えば、ある、Junitがある。ただし、バージョンは3.8。便利なassertもアノテーションも全滅のオールドタイプさん。まぁ悪いバージョンじゃないんだ、基本機能はガッチリ揃ってるし、実績も高いしさ。まさかとは思うけど、Mavenリポジトリサイトで、Junit3.8のダウンロード数が廃れないのは、こいつのせいだったりしてねｗ　

Testing Fundamentals | Android Developers:
http://developer.android.com/tools/testing/testing_android.html

基本に立ち返って、もう一度、この記事を目皿にして読み直し、抜粋したポイントは

ディレクトリを作成する
テストしたいAndroidオブジェクトに対応したTestCaseを継承してテストコードを書く
Android Test を実行する

これだけ。じゃ、やってみようか、もちろん、最初はレッドのテストでね。

まず、ディレクトリ作成

デフォルト配色で、androidTest/javaフォルダが緑色になればOK。これは、テストクラスのあるパッケージディレクトリですよ、を指している色で、これが指定されていないと、後の作業がメンドクサイ、フォルダ見難いｗ

このフォルダの指定は、モジュールの.imlファイルに記述されているので、検索してフォルダ表記が無かったら、それを記述追加してリビルドすれば環境ができているはず。できるだけ、いじらないでいたいなら、テストクラスとして指定されている別のフォルダがすでにあれば、それを新規作成すると後も綺麗に続けられるので楽。テストクラスのパッケージフォルダ記述が無いなら、仕方ないから追加ね。

そして、テストクラスを新規作成。これはいつもの新規作成の手順でOK。

public class ApplicationTest extends ApplicationTestCase<Application> {
    public ApplicationTest() {
        super(Application.class);
    }

    public void testAssertion(){
        assertEquals(1,3);
    }
}

絶対レッドのテストｗ＜手抜きすぎｗ

今回はアクティビティやコンテンツのテストではないので、ApplicationTestCaseを継承したけど、テストしたいものによって継承するテストクラスが異なるので、細かい事は前記述のサイトのリンクから参照で。(そのうち、まとめるとは思うけどｗ)

クラスが書けたら、次は実行設定。私は、モジュール内のｘｘｘｘTestクラスのtestXXXXメソッドを総なめにした。細かくやりたい人はパッケージ事とかに分けると良いと思う。

Android SDKのJunitは実行環境を必要とするのでエミュレーターは起動しておき、立ち上がりを確認したら、テストを実行してエミュレーターに環境割り当てをすると、テストモジュールがエミュレーターにアップロードされて……

よっしあぁ！レッドすねぇぇくかもぉぉん♪

というわけで、立ち返ってからレッドになるまで、２時間だったというオチｗ

基本って大事だね！　痛感したわ。

JavaとF#で、AndroidアプリのListAdapter を書いてみる。

片桐　継（Tugu Katagiri） — Tue, 19 Aug 2014 08:58:00 GMT

Androidアプリで、リストを画面に表示したい時、用意するソースは４つ。

リスト表示するためのListViewを含むレイアウトファイル
リスト一行分の項目を定義したレイアウトファイル
リスト表示するためのアクティビティクラス
リスト一行分の項目を編集するためのリストアダプタクラス

この４つのファイルが必要。ちょっとメンドクサイｗ

でも、使い方を覚えれば簡単に色んなリストを作れるようになるので、ちょっと自慢できる、かも＜を

で、今回のお話の主人公は、リストアダプタクラス。

実はAndroidアプリの中ではお約束がとても多くて、このリストアダプタクラスなんかは典型的。リストを作りたい時には、一行分のことだけ作者は考えてればいいんだよ、という仕様になっていて、とてもシンプルにできている。だから、作る側はそのお約束さえ守っていれば、後はAndroidさんの方で良しなにリストしてくれるの。

で、そのお約束なんだけど、次の事がリストアダプタクラスで定義出来ていれば動くみたい。

BaseAdapterクラスを継承していること（継承の継承でもOK）
保持するリスト件数を返すgetCountメソッドがあること
保持するリストの項目を返すgetItemメソッドがあること
保持するリストのIDを返すgetItemIdメソッドがあること
一行分のリスト項目を返すgetViewメソッドがあること

こうしてできたアダプタクラスを目的のListViewのプロパティAdapterにセットしておくと、Androidアプリのフレームワークは、getCountして取れた件数だけ、getViewを回してリストを作成してくれるし、クリックされたリストのアイテム項目をgetItemやgetItemIdを使ってアクティビティに返すようにもしてくれる。うん、便利だね。

ポイントは、基リストの保持はアダプタでやっても良いし、別のクラスで持っても良いところ。リスト生成する間、リストアダプタクラスがインスタンスをもっている間、リストが維持できていればOKだから、意外と自由。一つの基リストを色んなアダプタでリスト項目に展開することだって可能。使いこなしたい機能の一つだなって思うよ。

そんなリストアダプタクラス、JavaとF#で作ってみた。

レイアウトはresult_item, 項目は数値だけの表示リストでidをresultとして名前を付けて作ってあるとしての例ね。

Javaだと

public class ResultAdapter extends BaseAdapter {
    private List<Integer> list;
    private Context context;
    public ResultAdapter(Context context, List<Integer> list) {
        this.context = context;
        this.list = list;
    }
    @Override
    public int getCount() {
        return list.size();
    }
    @Override
    public Integer getItem(int position) {
        return list.get(position);
    }
    @Override
    public long getItemId(int position) {
        return position;
    }
    @Override
    public View getView(int position, View convertView, ViewGroup parent) {
        View view = null;
        if (convertView == null) {
            LayoutInflater inflater = (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
            view = inflater.inflate(R.layout.result_item, null);
        } else {
            view = convertView;
        }
        Integer result = getItem(position);
        TextView resultView = (TextView) view.findViewById(R.id.result);
        resultView.setText(result.toString());
        return view;
    }
}

F#だと

type ResultAdapter(activity : Activity, list:int[]) =
    inherit BaseAdapter()
    let _list : System.Collections.Generic.List<Java.Lang.Integer> =
        new System.Collections.Generic.List<Java.Lang.Integer>()
    do for i in list do _list.Add(new Java.Lang.Integer(i))
    override this.get_Count() = _list.Count
    override this.GetItem(position) = _list.Item(position) :> Java.Lang.Object
    override this.GetItemId(position) = int64(position)
    override this.GetView(position, view, parent) =
        let item = this.GetItem(position) 
        let view = 
            match view with
            | null -> activity.LayoutInflater.Inflate(Resource_Layout.ResultItem, null)
            | x -> x
        view.FindViewById<TextView>(Resource_Id.result).Text <- item.ToString()
        view

命名規約の問題で若干差があるけど、こんな感じ。F#の場合、JavaのObject型を使わなくてはならない分キャストがメンドイけれど、まぁクラスの一部だと考えれば、ただの変換作業なので苦も無く。Androidのクラスライブラリ群がJavaととても親和性がある、というかJavaで作られてるというのがよく判るよね。他言語で作るとなると、Javaの型を無視して作るなんて出来ないんだもの。まぁ、JNIを書いてラップして、なら出来るのかもしれないけど、ちょっとなんだか、それも違うんじゃないかなぁとか思ったり。

シリアライズの偉大さを知ったｗ

片桐　継（Tugu Katagiri） — Fri, 15 Aug 2014 21:02:00 GMT

SerializableAttributeAndoridアプリの画面を切り替える時、画面同士の情報の引き渡しができる仕組みがあるの。この時に、仲介役となるIntentクラスはとても大切。

やりたかったことは、とあるクラスに格納された情報を、画面の受け渡しに使いたいって事だったんだけど、Javaだと次の方法で出来る。

受渡のためのクラスにSerializableを持たせる
そのクラスを含むIntentを作成する
StartActivityする

NextActivityが次に行きたいActivity、Serializedが自分で作った型だという想定で、サンプルコートだと、

Serialized serialized = new Serialized();
String record_key = "Key"
Intent intent = new Intent(this, NextActivity.Class);
intent.putExtra(record_key, serialized);
intent.setAction(Intent.ACTION_VIEW);
startActivity(intent);

こんな感じ。ISerializableを持たせることで、情報を一つのクラスに取りまとめて渡せるので便利。

そして、この部分で使ってるJavaDocは、

http://developer.android.com/reference/android/content/Intent.html#putExtra(java.lang.String, java.io.Serializable)
http://developer.android.com/reference/android/content/Intent.html#putExtra%28java.lang.String,%20java.io.Serializable%29

これ。確かに、putExtra( String, Serializable ) のメソッドが使えるように、作られている。

で、これを今度は、F#で作る。調べたところ、C#でも同じようにクラスの宣言でISerializableを使うことができるので、出来るんだろうなと気楽に思ってた。さらに調べると、F#のtype宣言は[<SerializableAttribute>]を使うことで実現できるというところまで学習。

ところが、ちょっと問題ｗ　C#やF#でいうISerializableは.NetFrameworkのものであって、Java.IOのそれではない。

考えれば当たり前。

そこをラップしてくれるなんていう便利なものがXamarinAPIにあればなー、なんて思って頑張ったけど、行き着いた答えがこれ。

Working With JNI | Xamarin
http://developer.xamarin.com/guides/android/advanced_topics/java_integration_overview/working_with_jni/

ラップは自分でしろ、そのためのJNIは用意してやるから（ニッコリ）と、読めたｗ

つまり、

Java.IO.ISerializableをJNIした継承インターフェイスを作る
継承インターフェイスとSerializableAttributeをもつクラスを作る
putExtraでそのクラスを受渡す

うーん、はまりそう。深い闇というか沼の入り口に立ってる予感。とすると、逃げ道を考える。

Json化して、テキストにした後、Intent.Extras.GetSerializableメソッドでシリアライズしてputExtra
受渡クラスを保持するシングルトンクラスを作成し、項目を特定するIDでputExitra

どちらも、JNIを使わなくても、できる形。Json使うのも魅力だけど、２の方法で作ってみた。受渡したいクラスをリストで保持するシングルトンのrecordServiceを作って、メソッドGetPositionでそのリストの場所を取得できるようにしておく。

let position : int16 = int16 recordService.GetPosition
let activity = new Intent(this, typeof<NextActivity>)
let extra : int16[] = [|position|]
activity.PutExtra(record_key, extra) |> ignore
activity.SetAction(Intent.ActionView) |> ignore
this.StartActivity(activity)

これで、とりあえず、やりたいことは実現できた。個人で好きにやってるから、こんな風なやり方したけどJson化する方がC#やJavaとの移植性が高い感じがするので、良いかもしれない。

Toastを焼いてみる

片桐　継（Tugu Katagiri） — Thu, 14 Aug 2014 11:50:00 GMT

Androidアプリで、好きなところ、Toastがあるところ。

Toastっていうのは、画面のメッセージで、下の方に出てくる、ちょっと角の円いメッセージ表示のやつね。

これ。

表示するのはとても簡単。

たとえば、Toastにエラーメッセージを表示したい、とする。エラーの内容はエラーコードをIDに割り付けておいて、IDを渡すだけで表示できるように、メソッド化しておけば便利だよね。そんなメソッドを書いた時、

Javaだと

void displayError(int errorId) {
    Toast.makeText(this, errorId, Toast.LENGTH_LONG).show();
}

C#だと、

void displayError(int errorId) {
    Toast.makeText(this, errorId, ToastLength.Long).show();
}

F#だと、

member this.DisplayError(id:int) = 
    Toast.MakeText(this, id, ToastLength.Long).Show()

やってることは同じなのに、言語の違いで微妙な違いがあるのが面白いｗ

こういうのを楽しめるのがプログラミングの楽しい所の一つだと思ってるの。

JavaからC#への移植は簡単だけど、JavaからF#への移植は意外と手間かかるってのが、この１メソッドの比較からでも判る。

でも、間にC#を挟んで移植すると、もうちょっと楽になりそうな気がするね。

Xamarin Studio がバージョンアップしてるよ

片桐　継（Tugu Katagiri） — Thu, 14 Aug 2014 08:50:00 GMT

Xamarin studio が 5.2.1 にバージョンアップしてた。

２回目以降のデバッグ時に既存エミュレーターへアタッチできるように修正してくれたのが大きいｗ

地味に効いてたんだよなー、これ。

どうせやるなら、F#でやってみても良いよね？

片桐　継（Tugu Katagiri） — Wed, 06 Aug 2014 10:51:00 GMT

Xamarinで作ることのできるアプリケーションは、New Solutionすると一目瞭然。

VB.NetでAndroidプログラミングさせろぉぉぉっ！

C#でやれるんなら、もういっちょプリコンパイラ挟むだけなのにorz

やらせてくれても良いじゃないのよぅぅ。

C#も嫌いじゃないが、ここはやっぱ、F#でやってみようというのが私。

べ、別に、オライリーの表紙の鳥さんが可愛いからとか、そんな理由ぢゃないからね！冠鶴と金魚と蛇も捨てがたいんだけどさｗ＜を

オライリーさんとこでオンライン書籍DLで買うと、安いのな。サンプルコードの解説やなんや、オライリーさんところの英語は読みやすいのでしんどくないし、わざわざ日本語版探すより、原書をオンラインDLで買う方がずっと安い。会員コード持ってクーポンコード使うとさらに安い時あるし、対応言語やプラットホームも種類多いし、何より、表紙の動物が可愛い＜一番大事な所

というわけで、早速ソリューションを新規作成。

作るアプリは、Java＋AndroidStudioで作ったものと同じものを再作成、ということでｗ

ほー。ファイル配置お作法はテンプレだし、だいたいのやディレクトリ構成も一緒だね。これはステキ。すぐに取り掛かれそうだ。

ちょっと寄り道して、参照ライブラリとかみてみようかな。

Linq発見！Jsonもいるね。というか、そうか、NUnit　になるんだよな、テストエンジン。

Linqに久々に触れるとか、.Netよ、私は帰ってきた！みたいな気持ちになるね、しみじみするｗ

さて、サイトのサンプルはC#なんだけど、そこはF#に読み替えつつ、このページをじっくり読んでから手をつけようと思うの。

Getting Started | Xamarin
http://developer.xamarin.com/guides/android/getting_started/

Androidアプリのキモとお作法についても記載があるので、おさらいしつつ、進めよう。

Xamarinをインストールしてみる

片桐　継（Tugu Katagiri） — Tue, 05 Aug 2014 13:10:00 GMT

ついでだ。今度はXamarinを触ってみよう。

というわけでインストールしてみる。

Mobile App Development & App Creation Software - Xamarin
http://xamarin.com/

ここのDownloadNowから環境にあったインストールexeを取ってくるだけ。

あとはインストーラにおまかせ。

いつもの感じですねー。nextをクリックして進めてく。

ライセンス許諾は英語。なるほど、５人までの使用がスターター・インディーズというライセンスのくくりの扱いなのね。

共用はライセンス違反だよ、とも書いてます。あと、どんなライセンス形態があるのかも説明してまする。

まぁ、ボッチのいじりなのでスターターライセンスでいいのかな？

で、AndroidSDKインストの場所設定。デフォルトはちょっとそれでいいの？的場所なので、Choose new location　で新しい場所を指定。つか、すでにAS使ってるからあるんだけど、パス指定だけでも良かったような……といって、下手に指定して環境壊されるのもいやなので、ここは無駄だなぁとか思いつつも、新しい場所にした。

こんだけ入れますぜ、確認。AndroidSDKは最新だけを入れるんだね。ってことはLか。むむむむ。

プログレス表示開始ー。あとは終わるのをまって、

さて、はじめますかーｖ

Androidアプリケーションでジェスチャーを実装するためのお作法

片桐　継（Tugu Katagiri） — Thu, 31 Jul 2014 11:20:00 GMT

というのを知ったｗ

making-interactive
http://developer.android.com/training/custom-views/making-interactive.html

ここに書いてあるんだけれど、

Whether or not you use GestureDetector.SimpleOnGestureListener, you must always implement an onDown() method that returns true.

片桐的超意訳によると

GestureDetcector.SimpleOnGestureListenerを使う時には、必ずonDown()メソッドでtrue返してねん

ってことらしい。画面でジェスチャーを受け取る時、最初に発生するイベントがonDown()なのだそうで、ここからtrueが返ることで後続のイベントにeventオブジェクトを引き渡しつつ発火できるって仕組み。

イベント連鎖でジェスチャーを判断してるとか、面白いねー。

閑話休題

2014年の横浜恐竜博で恐竜ロボットの制作過程や実験なんかが展示されていたのだけれど、その中に、前に人が立つと、その動きに反応して動くドロマエオサウルスの展示があったの。

ノートPC＋キネクト→ロボットコントローラで構成されていたよ。フレームを認識して、反応させて、追いかけようとしたり、鳴いてみたり。将来、CGでもない、着ぐるみでもない恐竜コンテンツができそうな予感。個人的には、着ぐるみのモフモフ感と柔らかさは捨てがたいけれどもねｗ

Androidアプリケーションの設定画面設計と実装についてまとめてみた。

片桐　継（Tugu Katagiri） — Wed, 30 Jul 2014 12:39:00 GMT

そのまえに。

フラグメント(Fragment)という用語が意外と大事って知った。

これは、画面の縦横制御や別個に動作する画面オブジェクトの制御にかかわるライブラリ群らしく、AndroidのバージョンHoneycombから追加されている機能。つまり、UIをプログラミングするにあたって、避けて通れない存在……と考えて良いみたい。

モデルやコントロール部分を作ってる間は考えなくてよかったんだけど、いざ、画面の部分を作るとなると、この辺りきちんと考えて実装しないと、例外でストーンと落ちちゃうアプリができちゃう。うむ、メンドクサイな＜を

一画面一機能で、メニューやダイアログはできれば使わないでいくと、Fragmentを実装しなくちゃ！的に追いつめられる感じではなさそうだけど。その一方で、API使ってできるだけコードレスで楽ちんしたければ、Fragmentを意識して実装しつつ、APIコールもお作法に則っていきましょう、という事が基本だってことを勉強した。

さて、設定画面作り、いってみよー。

設定画面設計と実装の流れ。

作業手順は次の通り

設定項目を洗い出す。
項目のXMLファイルを実装
項目を入力するためのXMLファイルを実装
設定画面アクティビティの実装

まぁ、いつもの通り、っちゃぁそのままだ。

設定項目を洗い出す

設定項目洗い出しは設計のお話だけど、ここでのポイントは、２階層のアウトラインでまとめておくこと。

たとえば、

一般
- 画面の色
アカウント
- ユーザーID
- パスワード
ネットワーク
- プロキシの登録

とかいう感じで。小タイトル＆項目タイトル、中身の説明なんかあれば良い感じ。こうすることでそのままXMLにまとめて、APIからすんなり呼び出せるように実装できるよ。

項目のXMLファイルを実装

項目のタイトルや表示する説明書きが決まったら、それらを /res/values/pref_strings.xml にresources/stringとして実装。すでにあるstrings.xmlファイルでも良いんだけど、ファイルを分けておくと中身を管理しやすいと思う。といっても、好き好きだけど。

リストにしたいものがある場合には、ここで、選択肢の候補をresources/arrayで実装しておいてね。

項目を入力するためのXMLファイルを実装

実際に、どんな入力方式で項目を設定するのか、それを/res/xml/pref_xxxxx.xml　に実装。ここは肝。

入力形式には次の物があって、

テキスト
リスト
チェックボックス

が準備されてる。テキストは入力するときにダイアログが出るし、リストはあらかじめ作っておいた候補を選択、チェックボックスはON/OFFの形式ね。どの設定項目をどの方法で入力できるようにするかを決めて、実際にXMLに実装していくの。

settings
http://developer.android.com/guide/topics/ui/settings.html

サンプルはここに。

設定画面アクティビティの実装

ここまで準備できたら、次はアクティビティの実装。ここで、先述のフラグメントが登場。

If you're developing for Android 3.0 (API level 11) and higher, you should use a PreferenceFragment to display your list of Preference objects. You can add a PreferenceFragment to any activity?you don't need to use PreferenceActivity.
Fragments provide a more flexible architecture for your application, compared to using activities alone, no matter what kind of activity you're building. As such, we suggest you use PreferenceFragment to control the display of your settings instead of PreferenceActivity when possible.
Your implementation of PreferenceFragment can be as simple as defining the onCreate() method to load a preferences file with addPreferencesFromResource().

って書かれててね。片桐的超意訳すると、

APIのレベル11以降で作るなら、XMLで作った設定オブジェクト表示にはPreferenceFragment使わないとダメー、ダメダメ。PreferenceActivityは使わなくて良いからさ、使いたいActivityにPreferenceFragmentを追加してやってよ。
どんなアクティビティを作った時でも、フラグメントはアプリをよりフレキシブルにしてくれる便利もんだよ。だから、設定画面にはPreferenceActivity使うより、こっち使う事をオススメ。
PreferenceFragmentのonCreateでaddPreferencesFromResouceメソッド使うだけで簡単にできちゃうんだ。そのメソッドがXMLファイルから設定項目読みだしてくれるよ。

的に、ご本家からは推奨されてる。

実際に、そういう事なら、とかるーっく実装。

public class SettingsActivity extends PreferenceActivity {

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

        // Display the fragment as the main content.
        getFragmentManager().beginTransaction().replace(android.R.id.content,
                new GeneralPreferenceFragment()).commit();
    }

    public static class GeneralPreferenceFragment extends PreferenceFragment {
        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            addPreferencesFromResource(R.xml.pref_general);

        }
    }
}

Activityのクラスに、サブクラスとしてFragmentを実装し、それをonCreateで読みだすだけ。うん、これだけだったわ。 テンプレに登録しておいても良いくらいだｗ

Eclipseで作成するAndroidアプリケーションの問題？

片桐　継（Tugu Katagiri） — Fri, 25 Jul 2014 17:14:00 GMT

色々と書いていたけれど、最後の最後で、どうしても、うまく行かなくなったの。

プロジェクトからapkを作成すると、自作クラスが含まれない。

怪しいとおもって、Eclipseから新規のandoroidアプリケーションプロジェクト作成からやり直したのだけれど、どうしても、うまくいかない。

Unable to Instantiate Activity: ClassNotFound Exception を発生して、アプリケーションが起動できない。

で、クラスやソースのコーディングならともかく、プロジェクト構成の問題のようで、一日かけても解決できなかったの。

そこで、発想を変えてみた。

開発IDEをeclipseからAndroid Studio に変えて、プロジェクトを新規に作成して、コーディングソースをコピペで移植。

動いたーーーー！

デバッガも動くし、エミュレーターにも接続できるし、さくさくapkもビルドしてくれる。

問題は、Gitの実行エンジン「git.exe」を外部から登録する形なので、Eclipseプラグインでgitしていたようなことはできない、ってことくらい。

でもそれも、SouceTreeで解決。これ、内部実行Gitエンジンもってるので、インストする必要ないんだわ。

Git、Mercurial 対応無料 DVCS Mac、Windowsクライアント | Atlassian
https://www.atlassian.com/ja/software/sourcetree/overview

SouceTree　から、AndroidStudioで作成したプロジェクトをgitプロジェクト化したうえで、BitBucketにリモートするよう設定しておけば、Gitで管理できる状態にできる。うむ、便利だ。

さて、さくさく続きを作っていくぞー。