プラグインなしのNetBeans IDEでのAndroid開発。 パート2

Android用のプログラミング用にNetBeans IDEをセットアップする実験を続けています。 前回、NetBeansでプロジェクトを作成し、ビルドシステムを構成し、アプリケーションを自動的に起動することもできました。 さらに、ビルドシステムが内部からどのように構築されるかを少し見ました。 記事の第2部では、NetBeansでデバッグ、ライブラリプロジェクトの作成、プロジェクトへのライブラリの追加、単体テストの操作を行う方法をさらに詳しく見ていきます。

デバッグ

興味深いことに、NetBeansをデバッグするには2つの方法があります。 最初の方法は、アリの魔術さえ必要としません。 2番目のものは、セットアップが少し複雑になりますが、場合によっては便利になり、Eclipseのようになります。

メソッド番号1

何かを始める前に、モニターと呼ばれるツールについて考える必要があります。 <Android-SDK>/toolsフォルダーにあります。 記事の最後の部分で書いたように、これは既にPATHにあるはずなので、Windowsのコマンドラインまたは検索バーから直接実行できますが、もちろん誰もショートカットを作成する必要はありません。 Eclipseで働いていた人は、このツールのすべてのパネルをすぐに認識します。 最も重要なのは、logcatとDevicesです。

モニターが開いた後、アプリケーションがまだ実行されていない場合は、アプリケーションを起動し、デバッガーに接続する必要があるポートを確認する必要があります。 ポートはアプリケーションの反対側に書き込まれます。 デフォルトでは、860x回線があります。 また、アプリケーションの1つをクリックしてポート8700を割り当てることもできます。その後、NetBeansでは、Attach Debuggerコマンドを使用してこのポートに接続する必要があります。 Socket Attach、localhost、必要なポートのパラメーターを選択します...それだけです。冷静にデバッグを処理できます。



パネルのボタンには、最近入力した設定が記憶されるため、次回は何も入力する必要もありません。



それとは別に、ポートを調べるためだけにモニターが呼び出されるわけではないことに注意してください。 また、仮想マシンへの接続の仲介者としても機能するため、仮想マシンが実行されていない場合、ポート8600にランダムに接続しても、動作しません。

このデバッグ方法には、いつでも接続および切断できるという利点があります。 これは重要です。接続されたデバッガーでは、Dalvik VMの速度が著しく低下するためです。 これは重要ではない場合もありますが、常にではないため、デバッガーなしでプログラムの特定の実行ポイントに到達する機能は不要な場合があります。

特定のポイントでデバッガーを接続するのに役立つ別のツールがあります。 もちろん、条件ごとにブレークポイントを作成できますが、先ほど言ったように、接続されたデバッガーでは、すべてがうまく機能しません。 したがって、 Debug.waitForDebugger()の呼び出しをコードに挿入できます。 プログラムがこのメソッドに到達するとすぐに停止し、デバッガーを接続した後にのみ実行が継続されます。

ただし、プログラムの開始時にデバッグを開始する必要がある場合があります。 前述のメソッドに対して同じ呼び出しを使用することも、デバッグを開始するための2番目の方法としてNetBeansを構成することもできます。

メソッド番号2

2番目の方法は、Eclipseの場合と同じように動作します。デバッグを開始すると、アプリケーション自体が起動します。 その後、デバッガの接続を待機し、その後のみ実行を継続します。 ここではNetBeansが役立ちます。 デバッグ（ CTRL+F5 ）しようとすると、NetBeansはAntファイルの生成を提案します。これにより、プロジェクトでの実行方法が通知されます。 それが必要です。 その後、 ide-file-targets.xmlでide-file-targets.xml 、その内容を次のものに置き換える必要があります。

 <?xml version="1.0" encoding="UTF-8"?> <project basedir=".." name="KillerApp-IDE"> <import file="../build.xml"/> <target name="-load-props"> <property file="nbproject/debug.properties"/> </target> <target name="-check-props"> <fail unless="jpda.host"/> <fail unless="jpda.address"/> <fail unless="jpda.transport"/> </target> <target name="-init" depends="-load-props, -check-props"/> <target name="-launch-monitor"> <if> <condition> <not> <socket server="localhost" port="8700"/> </not> </condition> <then> <exec executable="${android.tools.dir}/monitor${bat}"/> <waitfor maxwait="20" maxwaitunit="second"> <socket server="localhost" port="8700"/> </waitfor> <sleep seconds="2"/> </then> </if> </target> <target name="-launch-debug" depends="-find-main-activity"> <exec executable="adb"> <arg line="shell am start -D"/> <arg line="${project.app.launcharg}"/> </exec> </target> <target name="debug-nb" depends="-init, -launch-monitor, -launch-debug"> <nbjpdaconnect address="${jpda.address}" host="${jpda.host}" name="${ant.project.name}" transport="${jpda.transport}" /> </target> </project> 

このファイルは、 debug.propertiesファイルからプロパティをロードすることから開始します。このファイルは、次の内容の同じフォルダーにdebug.propertiesする必要があります。

 jpda.host=localhost jpda.address=8700 jpda.transport=dt_socket 

これで、このファイルの機能を理解できます。 ここでの主なタスクはdebug-nb 。これはdebug-nb開始時にNetBeansが開始し、 -init 、 -launch-monitorおよび-launch-debugに依存します。 -initには特に興味深いもの-initません。タスクはdebug.propertiesファイルから変数をロードしてチェックするだけです。 しかし、 -launch-monitor既により便利です。結局、monitorがまだ実行されていなければ、このタスクを実行する必要があり、このタスクはタスクを引き継ぐだけです。 Antには、プログラムが特定のポートまたは非socketリッスンしているかどうかを確認できる優れた機能がありsocket 。 この症状により、モニターが機能しているかどうかを判断できます。 そうでない場合は、実行して待機する必要があります（タスクのwait-for ）。 開始後も、モニターが接続の受け入れを開始するまで2秒間待つ価値があります（機器の特定の構成によっては、値をわずかに調整する必要がある場合があります）。

その後、アプリケーション自体を実行できます。 前の記事で、コマンドラインを使用してantからこれを既に実行しました。 これを行うには、コマンドadb shell am start -a android.intent.action.MAIN -n < >/<>ます。 今回は、コマンドをさらに詳しく分析します。 adb shellは、Android内のコマンドラインを直接操作できるコマンドです。 amは、かなり印象的な機能を備えたアクティビティマネージャーです。 それらについては公式ドキュメントで読むことができます 。 必要なアクティビティを開始するにはstartコマンドのみが必要です。これは、 -nスイッチの後に示され、 -aスイッチは、おそらく明らかになったように、意図を設定します。

custom_rules.xmlファイルには、実行に必要なパラメーター-find-main-activityを提供するタスクが既に含まれています。 今回は、前回と同じ方法でアプリケーションを起動する必要がありますが、 -Dスイッチを使用して、アプリケーションの起動後すぐに動作を継続せず、最初にデバッガーを待機します。

したがって、これらのすべての不正行為が完了した後、 debug-nbを開始する準備が整います。モニターが実行され、アプリケーションが実行され、デバッガーが待機しています。 nbjpdaconnectジョブを使用して接続するためにのみ残ります。 名前が示すように、このタスクはNetBeansに固有のものです。

私自身が2番目の方法を使用する頻度は1番目の方法よりもはるかに少なくなっています。これは、先ほど述べたように、Dalvikデバッガーを接続すると、VMの動作が遅くなり、アプリケーションのデバッグ領域に到達する時間が長くなるためです。 ただし、アプリケーションの起動時に問題が発生する場合は、このメソッドが必要です。

ライブラリの追加とライブラリプロジェクトの作成

ライブラリは、プリコンパイルされたjarファイルにすることも、プロジェクトに含める前にコンパイルする必要がある別のAndroidプロジェクトにすることもできます。 それぞれ異なる方法で接続されています。

プリコンパイルされたファイルの場合、手順はほとんどありません。

1. メインプロジェクトフォルダーのlibsフォルダーにファイルをドロップする必要があります。
2. [Javaソースクラスパス]タブのプロジェクトプロパティで、ファイルへのパスを追加する必要があります。 実際、これを行う必要はありませんが、IDEはこのライブラリのコードを教えてくれないため、IDEを使用する利点は無効になります。

ライブラリプロジェクトの場合、すべてが少し複雑です。 コマンドで追加できます（これが公式の方法です）か、設定ファイルの行で追加できます。 公式の方法が好きな人には、次のコマンドが必要です。

android update project -p < > -l < >


たとえば、v7 appcompatサポートライブラリを追加してみましょう。これは、3.0より前のバージョンのAndroidでアクションバーを表示したい人向けにGoogleが作成したものです。 追加のリソースがあるため、プリコンパイルされたjarファイルとしてではなく、ライブラリプロジェクトとして配布されます。 メインプロジェクトと同じフォルダにあるとしましょう。

android update project -p KillerApp -l ../AndroidCompatibilityPackage-v7-appcompat


それだけです！ すでにプロジェクトをコンパイルできます。 project.propertiesファイルを見ると、 この構成ファイルに次の行があります。

android.library.reference.1=../AndroidCompatibilityPackage-v7-appcompat


実際、そのチームが行ったことはそれだけです。 まったく同じ方法で、コマンドなしで新しいライブラリを追加できます。主なことは、ライブラリ番号を1つ増やすことを忘れないことです： android.library.reference.2 、 android.library.reference.3など。

もちろん、プリコンパイル済みファイルと同様に、プロジェクトで言及されているライブラリプロジェクトのソースフォルダーと、使用するライブラリ（使用する場合）を忘れずに追加する必要があります。 つまり、ライブラリプロジェクトのlibsフォルダーにsrc 、 genおよびjarファイルフォルダーを追加する必要があります。

独自のプロジェクトを作成する場合はどうなりますか？ ライブラリプロジェクトの作成は、通常のプロジェクトの作成とまったく同じですが、例外が少し異なります。

android create lib-project -n < > -t android-< API> -p < > -k < >


主な違いは、 project代わりにlib-projectが導入されていることです。 さらに、ライブラリを直接起動する必要がないため、メインアクティビティの名前を指定する必要はありません。 さらに、プロジェクトの作成は通常のプロジェクトと同様に継続されます。

テスト用のプロジェクトの作成

ご存知のように、残念ながらAndroidでは、ユニットテストをプロジェクトに直接埋め込むことはできません。このアクションのために別のプロジェクトを作成する必要があります。 ライブラリプロジェクトの作成と同様に、すべての手順は通常のプロジェクトの作成と非常に似ていますが、もう少し微妙です。 次のコマンドが必要です。

android create test-project -p < > -n < > -m < >


通常、テスト用のプロジェクトはメインプロジェクトのサブフォルダーに作成されるため、メインプロジェクトのフォルダーからこのようなプロジェクトを作成します。

android create test-project -p tests -n KillerAppTest -m ..


さらに、通常のプロジェクトの場合と同じ方法で、NetBeansで新しいプロジェクトを作成し続けることができます。 ただし、今回は、3番目のステップで、Antジョブを異なるメニュー項目に割り当てるときにtest項目を残すことができます。 ただし、 Run Projectからは、ここで起動するものがないdebug install 、 launchを削除してdebug installのみを残す価値があります。



通常のプロジェクトでは、その後、アプリケーションの起動に関連するファイルを追加しましたが、今回は必要ありません。 しかし、できることは、テストのデバッグと選択的な実行に役立つファイルを追加することです。

最初に、NetBeansで追加のジョブ用のファイルを生成する必要があります。 個々のファイルの実行、個々のファイルのデバッグとデバッグに関心があります。 これらのアクションはすべて、 CTRL+F6 、 CTRL+F5およびCTRL+SHIFT+F5押すことで生成できます。 その後、2番目の方法でデバッグを通常のプロジェクトに追加する場合、 ide-file-targets.xmlのみがわずかに異なるため、 nbprojectフォルダーにファイルを再度アップロードする必要があります。 ファイルの先頭は通常のプロジェクトをデバッグする場合と同じなので、ファイル全体をコピーしません。 興味がある人はBitBucketでそれを見ることができます。 しかし、その後、他のタスクがあります：

 <target depends="-setup" name="run-selected-file-in-src"> <fail unless="run.class">Must set property 'run.class'</fail> <echo level="info">Running tests in ${run.class}...</echo> <run-tests-helper> <extra-instrument-args> <arg value="-e"/> <arg value="class"/> <arg value="${run.class}"/> </extra-instrument-args> </run-tests-helper> </target> <macrodef name="launch-debug-and-connect"> <element name="debugged-class" optional="yes"/> <sequential> <parallel> <run-tests-helper> <extra-instrument-args> <debugged-class/> <arg value="-e"/> <arg value="debug"/> <arg value="true"/> </extra-instrument-args> </run-tests-helper> <sequential> <sleep seconds="5"/> <nbjpdaconnect address="${jpda.address}" host="${jpda.host}" name="${ant.project.name}" transport="${jpda.transport}" /> </sequential> </parallel> </sequential> </macrodef> <target depends="-setup, -init, -launch-monitor" name="debug-selected-file-in-src"> <fail unless="debug.class">Must set property 'debug.class'</fail> <echo level="info">Debugging tests in ${debug.class}...</echo> <launch-debug-and-connect> <debugged-class> <arg value="-e"/> <arg value="class"/> <arg value="${debug.class}"/> </debugged-class> </launch-debug-and-connect> </target> <target depends="-setup, -init, -launch-monitor" name="debug-nb"> <launch-debug-and-connect/> </target> 

個々のテストを実行するにはrun-selected-file-in-srcタスクが必要です。 run-tests-helperマクロを使用します。このマクロは、追加のパラメーターを使用してAndroidビルドシステムで定義されています。 実際、このマクロが行うことは、プログラムをテストするためのパラメーターを使用してadb shell am instrumentコマンドを実行することadb shell am instrument （はい、これもアクティビティマネージャーです）。 引数-e class < >をコマンド起動に追加して、デバイスがすべてのテストを無差別に実行するのではなく、特定のファイルに焦点を合わせるようにします。

その後、デバッグを実行する必要があるタスクがありました。 そのためには、まずテストを開始し、デバッガーを待機するように指示してから接続する必要があります。 しかし、ちょっとした問題があります。テストはロックから始まり、別のタスクを実行する必要があります。 異なるタスクを一緒に実行するparallelタスクは、私たちを救います。 結果はマクロとしてフレーム化されるため、テストが呼び出されるパラメーターを制御できます。 したがって、デバッグタスクは、必要に応じて、追加のパラメーターを使用して単純に呼び出します。

まとめ

これで、実行したことを要約できます。 全体として、非常に多くの可能性が得られました。

• プロジェクトの完全な組み立てと立ち上げ。
• R.java手動生成。
• デバッグプロジェクトの起動。
• ライブラリとライブラリプロジェクトの追加。
• テスト用のプロジェクトの作成。
• デバッグ機能を備えた個別のテストを実行する
• ヒントとオートコンプリート。

プロジェクトは、コマンドラインからの1つのコマンドと、各プロジェクトに共通するいくつかの追加ファイルによって作成されるため、人件費の点ではすべてが非常に単純です。 EclipseまたはAndroid Studioにすでにあるものと比較して不足しているもの：

• インターフェイス編集;
• ヒント付きのXMLファイルの編集。
• リソース宣言に移動します。

XMLファイルの編集はそれほど重要ではありませんが、もちろん、WYSIWYGエディターがなければ、インターフェースを編集するのは非常に悲しいことです。 したがって、私は個人的にプロジェクトをEclipseにインポートし、必要に応じてそこでインターフェイスを編集します。

また、このようなツールの適用可能性についても少し言いたいと思います。 前の記事へのコメントで、同様の質問が生じたので、もう一度思い出します。これは実験です。 IDEに依存しないantを介した公式のビルドシステムがある場合、Androidで動作するように設計されていないツールをセットアップするために抵抗することはできず、それを使用しようとすることは困難でした。

さらに、実際には、このシステムを使用するためにNetBeansを使用する必要はありません。 プロジェクトを設定した後、コマンドライン（たとえば、 ant debug install launch ）を入力するだけで、プロジェクトをビルドおよび実行できます。 また、 自作のスクリプトアセンブリとは異なり、完全なアセンブリになります。ADTを備えたEclipseとまったく同じです。AIDL、BuildConfig、RenderScript、zipalign、ProGuardなどのすべてのインターフェイスを生成します。 NetBeansでのプログラミングにそれを使用することに関しては、もちろんこれはすでにアマチュアです。 しかし、いずれにせよ、私は個人的にこの実験の実施に非常に興味があり、他の人がそれについて読むことに興味を持っていることを願っています。

いくつかのリンク

1. BitBucket上のすべてのファイル
2. プラグインなしのNetBeans IDEでのAndroid開発。 パート1