Hi there, I am developing for Android from Eclipse running on the Windows OS. As I have multiple projects that share certain parts of code, I have made said code into an Android library, and then reference said libraries to the projects. I am doing this by using the 'Library' panel under the 'Android' section (when you right click -> Properties on a project). The library projects have 'Is Library' ticked, and the main projects add the library projects.
In terms of being able to build and run, this appears to work. However I have run into two problems, one more serious than the other: 1. When I make a change to the source for a library, when I ask Eclipse to run/debug it doesn't pick up the change. I have to instead refresh (F5) the main project - this appears to correctly pull in dependencies (incidentally, I also have to do this if I make a change to native code using the NDK and rebuild the resulting .so file). Is there a way to force these sorts of dependency checks to automatically be taken into consideration when I debug run? I have got reasonably used to refreshing when running, but it is somewhat easy to loose track of what source file you are editing, and forgetting it is one in a library that means a refresh is required. It can result in wasted debug sessions when you are running unexpected code! 2. My more serious problem is: when an unhandled exception is thrown in library code, it doesn't tell me about the exception in an easy way. For example, today I had an exception raised, and it reported to me that it was coming from the GLThread.run method, from GLSurfaceView.java - so I went through the various hoops for getting the source code for Android onto my PC, so I could view GLSurfaceView.java, and saw the exception was coming from 'guardedRun', which in turn was calling 'onDrawFrame', which in turn called out to my native render + update function (using the NDK), which in turn called back into my Java code to load some music, and *that* code then went onto attempt to access an array with an invalid index. None of this was shown in the callstack (only GLThread.run appeared there), instead I had to make my own version of GLSurfaceView that had some try/catch statements that caught the exception, and gave me a callstack of where the problem lies by using e.printStackTrace(). Once I had the callstack, I was able to fix up the offending code. I don't remember having this problem before I made my code into a library - I thought previously exceptions were getting caught much earlier on. I am simply not remembering correctly? Or is there some limitation when using libraries? If I am not remembering correctly, clearly I just need to wrap my Java code that is being called from my native code with try/catch/print exception blocks so I can avoid this problem again. I look forward to your responses, Steve -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
