I'd create a common CVS project and check it out into two different environments. It does take a little discipline to prevent the two copies from diverging, but if you check in/out on a regular schedule it should work.
On Dec 23, 12:56 pm, Eric <[email protected]> wrote: > We have a large, complex, Java client/server application that is > deployed in Java Swing. We hope to leverage this codebase and reuse a > lot of the client-side model, controller, and communication code in a > new Android port of this application. Does anyone have thoughts on > how best to do this (FYI, I use Jetbrains IDEA as my IDE, not > Eclipse)? > > For example, several questions come to mind: > > - is it better to create a new IDE project for the Android project, or > just add an Android module to the existing IDE project (I prefer the > latter to take advantage of global refactorings). > > - if adding an Android module to the current IDE project, how does one > best share lower-level Modules across Java Swing and Android? Things > become very problematic because Android does not ship with the full > standard JDK, and therefore code must be moved, refactored, or even > deleted if it depends on JDK packages that are not available on > Android. This means that for a pre-existing Util module to be shared > across the platforms, we may have to create a new lower-level version > of that Module that only depends on the packages that Android has > available to it. > > - I've also found through experimentation that when I try to depend on > a pre-existing module that has Jar dependencies of it's own, the > Dalvik conversion process doesn't always successfully convert that Jar > into Android format (possibly because it contains unsupported code). > What's confusing is that the Dalvik conversion works on certain jars > that contain unsupported code, but not on others. So the conversion > process must be ignoring code that isn't referenced somehow. In > summary, I've encountered a lot of problems trying to depend on third- > party jars on Android, and I'm wondering if anyone else has the same > problems, or suggestions? > > - another way to approach this is to copy the shared code into the > Android project and give up the ideal of trying to share the code, and > just maintain two distinct code bases (this is not at all ideal, but > it may be the most painless route). > > - I have another specific question about the Dalvik VM conversion > process. Exactly how does that process work? Does it strip out code > that is unsupported on Android? For example, I had a JAXB generated > file which referenced the import javax.xml.bind.annotation.* classes > that are not available on Android. With my Android module SDK set to > the main JDK, that code DID compile and DID get converted to Dalvik, > despite the fact it references classes that are not available on > Android. I did this by adding a dependency to another pure-java > module that has the jaxb.jar as its dependency. Did the Dalvik > converter actually convert the entire JAXB jar and put it onto > Android, or did it just strip out the JAXB classes and references from > the bytecode that are not available on Android? > > I'm very curious about how this all works, because the answer will > have a significant impact on how we move forward on our project. We > have a lot of code that is written to the standard JDK that we'd like > to reuse on Android. The code certainly does references packages that > are not available on Android, but we may not necessarily hit those > code paths from inside Android. But if the system will automatically > strip out the unavailable code paths for us, to allow us to reuse the > same source code, that would be very beneficial. Just wondering if > anyone has insights on this. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
