そのため、条件付きブレークポイントをスクラップブックにリンクすることはできないようです。ソースをハックして、スクラップブックコードまたはスクラップブックソースのカスタムバリエーションを呼び出すためのブレークポイントを取得する可能性があります。ただし、実装は存在しません。
幸いなことに、条件付きブレークポイントの使用法を十分に掘り下げていないことがわかり、それらはかなり強力であり、スクラップブックなしで問題を解決できることがわかりました。(それを研究している間、私は多くのチュートリアルを読みました、そしてそれらはすべてそれらを完全に使用する方法と実際にそのコードステートメントで変数の変更を実行する方法について詳しく説明しました。
if(position==0){
testObject=null;
com.example.test.customLogger(getClass().getSimpleName(),"Conditional BreakPoint Code");
}
return false;
注意すべきいくつかのこと、うまくいけば、彼らは他の誰かを助けるでしょう
上記のコードは正しく実行されますが、私の意見では、「return false」ステートメントは、条件が満たされた場合にのみ実行されるコードブロックの外側にあるため、奇妙な構造になっています。
「false」を返すと、デバッガーはスレッドを停止しません。「true」を返すと、コードが実行されて停止します。
以下のようなものを使用できます。ifステートメントに含まれていない場合でも、ブレークポイントがトリガーされます。(基本的に、Javaと単純なステートメントの両方を受け入れます)
"position == 0"
- 単純なステートメントとJavaを混在させることはできないようで、そうすると非常に不可解な誤解を招くメッセージがスローされます(これにより、条件付きブレークポイントと組み合わせてスクラップブックが必要であると私は信じるようになります
- デバッガーがスレッドを一時停止するか続行するかを決定するために使用するコードブロックの最後にブール値を返す必要があります。そうしないと、ブール値を返さないというエラーがスローされます。これは、ifブロック内でリターンを移動した場合に発生します。
このアプローチは、Androidで共有される多くのメソッドとオブジェクトで構成されるクラスにコードが高度に結合されている場合に非常にうまく機能し、事後に単体テストを実装するのが困難になります。ただし、役立つテストのその他の方法は次のとおりです。
- Android開発者の猿
- Android開発者のMonkeyRunner
- RoboGuice
- Robotium
- RobotElectric
- JUnit(RobotElectricと組み合わせて使用しない限り、Androidフレームワークと相互作用するものをテストできないため、実際には実行可能ではありません)