Similar to Kostya's suggestion, but requires less knowledge of eclipse/ ant/java; however, it doesn't meet your criteria of "I prefer to keep my app in one single project."
This is what I came-up with before libraries were available; it's not fully automated. But, if you're old-school like me and host in a unix (Mac OSX, Linux, Cygwin+Windows) like environment, you can setup multiple projects in eclipse for each target, making one project your working/master environment, and the others are just build projects (except for things specific to the target). Files that have no differences and don't have any target differences are symbolicly linked in each target project directory tree. Files that are only different because of target dependencies (most often due to java IMPORTs like R.* for your resources/assets), are the part that require a manual step before you perform a build. I create stream-editor (unix sed commmand) scripts via shell language that I run before a build, it reads the input file from the working/master project and re-writes it in the target directory, I create marker comments in the source file that are keys telling sed what to substitute/delete/etc. I'm sure there is probably a way in eclipse to actually tell eclipse to invoke the script as part of a build, but I've never bothered to go look. This is way more complicated than libraries, but if your background is command-line oriented, it's pretty common-sense and easy. I tried libraries the day they were first available and had too many small issues and re-turned to this method. I suspect most of those "issues" have been cleared-up, but my methods gives me some flexibility with my source (that I find lacking (!!) in java) because it allows me to modify the source as though the language had a decent pre-processor built into it's definition. Some of the things my scripts modify can probably (??) be worked around with java reflection and such, but my working knowledge of java is not as good as it should be. And I prefer compile/build/static solutions over run-time when ever available. I'm purposely not providing examples because this method should not be used unless you can comfortably implement it from the description provided !! I keep the shell script(s) in the target project tree, but they could just as well be in the master/working project. On Jan 10, 5:18 pm, Kostya Vasilyev <kmans...@gmail.com> wrote: > What I just did in a similar situation, is use additional source folders, > thus avoiding excessive use of libraries. > > I have two versions of the same app: one for Market and one for another > store. > > My source directory structure has: > > src > package org.kman.FooBar.licensing > SomeClass.java > > src-market > package org.kman.FooBar.licensing > SomeClassFactory.java > SomeClass_Market.java > > src-another-store > package org.kman.FooBar.licensing > SomeClassFactory.java > SomeClass_AnotherStore.java > > There are two versions of the same class, SomeClassFactory, in either > additional sKostyaource folder, under the same name, in the same package, and > so > I can just do "SomeClassFactory.create()" in the main body of application > code, without worrying about which one it is. The implementation of those > factories is different, each instantiating its own subclass of SomeClass - > the one for Market or for AnotherStore. > > Now, the bulid setup: > > 1) In Eclipse: src-market and src-another-store are added as additional > source foldeKostyars in the application project. Then src-another-store has an > exclude filter matching everything: "**/*.*". > > This way, both folders are accesible for browsing / editing / source > control, but only the sources inside "src-market" are compiled. > > 2) For command line builds: I have a modified build.xml, and use > "sourcepathref" with <javac> when compiling, to supply one or the other > additional source folder, depending on which version I'm building. > > This additional path reference is set by a task that executes early in the > ant build setup sequence, and makes the decision based on a property passed > into the build script with "-Dbuildtype=market" or > "-Dbuildtype=anotherstore" on the ant command line. > > Finally, there are two very simple shell scripts that call ant with the > appropriate -D... flags.The shell script(s) > > End result: > > - The sources for both versions are accessible in Eclipse > - The app can be built in Eclipse, defaulting to one of the two possiblebut > when faced with spending my time learning features of java that aren't really > necessary > configurations > - The main body of application code is not in a library, but rather a > regular application project so my change-compile-debug cycles are faster (I > think) > - Clean command line builds are just a simple shell command away, for > either configuration > - The Market version doesn't contain any code for the alternate store, and > vice versa. > - Command line builds name the build output with a suffix, something like > "FooBarApp-market-1.0.5.1.apk", where the version number is automatically > extracted from the manifest > > This message is overly long and too detailed, so.... sorry, but I hope it > can provide some ideas. > > -- Kostya > > 10 января 2012 г. 23:34 пользователь TreKing <treking...@gmail.com> написал: > > > > > > > > > On Tue, Jan 10, 2012 at 12:55 PM, Ricardo Amaral <mas...@ricardoamaral.net > > > wrote: > > >> You could include both libraries into your one project, abstract both > >>> into concrete classes that are instantiated based on some static flag, and > >>> only instantiate and use the one you need based on the flag. Build, flip > >>> bit, rebuild. > > >> That's the kind of behavior I wanted to automate, instead of manually > >> building the application twice... > > > Replying back to the whole group. Careful with which button you click. > > > I haven't used Ant but doing an in-file replace and rebuild is probably > > something you can easily do with it. > > > ------------------------------------------------------------------------------------------------- > > TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago > > transit tracking app for Android-powered devices > > > -- > > 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 -- 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
