Maybe my approach is wrong, but here is what I want:
A logging library, written in pure JAVA
It should work on Android as well
I want to use it in Android and desktop apps
The approach I tried is taken from VS and C#, there it is called "multi targeting" - it basically means a module shares source code with another module.
So my idea was to create 4 modules:
AndroidApp
AndroidLog
DesktopApp
DesktopLog
The "real work" on the logging stuff (most of the classes which are pure Android compatible JAVA) would go into AndroidLog (to prevent me from accidently using classes not in the Android SDK).
The Android App can use the log library without any problem, thats the way I do it at the moment. Now the DesktopLog should have some of the folders the AndroidLog has, basically reusing the same JAVA code.
I tried to add a source folder from AndroidLog to the DesktopLog, but I get an error telling me "the root already belongs to...". I am working with an SVN, but I think thats not the issue here (actually, I tried the above without SVN, but it might provide some workaround if there is no simpler solution).
So how do I get IntelliJ to:
Share JAVA files across different modules with different target platforms.
Thanks for tips,
Chris
PS: Search tearms are also welcome "sharing source JAVA" is not very google friendly.
mm. I think you're going about this the wrong way. I would organise it like this:
Common-Log - A common Java package containing classes which are used by DesktopLog and AndroidLog
DesktopLog, with a dependency on Common-Log
AndroidLog, with a dependency on Common-Log
DesktopApp
AndroidApp
Trying to simultaneously reference partial source trees from a single project in different sub-projects sounds like a recipe for headaches; I think you'll have more luck if you follow the approach of extracting the common support classes from both Logging projects to a separate common project.
Related
So my project structure looks like this:
Applications/Project1/Build/Android/AndroidManifest.xml
Applications/Project2/Build/Android/AndroidManifest.xml
Common/Library1/Build/Android/AndroidManifest.xml
Note that beside AndroidManifest.xml are the other usual directories and files, such as .project, jni directory, src directory, and so on.
I want to import these as Android Studio projects, however when I do that it reorganizes the structure, in addition it doesn't seem to do the upgrade in-place, when I want it to. What I get instead is this structure:
Project1/build.gradle
Project2/build.gradle
Library1/build.gradle
To make things worse, it also copied my physical source files and recognized those as well. Is there an easier way to transition to Android Studio, while at the same time keeping the existing structure as close as possible? I also don't want the upgrade to happen in a remote location. I want this to physically replace the current Eclipse and Ant project files. Should I do this by hand? Or is there some trick I can use in Android Studio's import wizard?
Also: Not sure if it matters, but the code base is primarily C++ + CMake. Current projects use Android.mk, but I'd want to make them use the CMake scripts instead. However, if that doesn't bear any affect on this process we can ignore it and I'm happy to address the C++/CMake integration later as a separate step. Right now I just want the general projects to get setup, have proper Gradle scripts, and other things (Java side, basically).
I suggest doing it by hand. It could be faster than getting to make the tool do the right thing.
Remember that migration/import tools are much more rarely used tools than, say "call hierarchy" or "find usages" and thus they might get less love and polish.
Writing gradle files by hand is actually quite fast. The syntax is quite light (unlike, say, Maven, or worse, Ant).
Try it and you might find Gradle to become a friend, rather than "foe" ;).
Also, don't forget settings.gradle to tie the modules together.
Another suggestion would be to trick the import tool via making a project with simpler structure and then copy&paste the relevant bits into your own structure (so that you more-or-less know what to put in your gradle files).
Say I implement an algorithm for a project. Say I want the same code to be used on another project. What would be the approach to do so? Just copy and paste code? Create a "library" project? What? Is there a tutorial or site that explains how to do this?
Sure, add it to a library project, but the benefit of reuse should always be compared to the cost of making the code general. Sure if you improve the code by fixing a bug or increasing performance, it is nice to get that into all projects where you use the code, but it also makes you slower because you have to keep the library compatible with all clients (at least the ones that will build after a breaking change).
It is often better to copy and adapt solutions to new projects, than to maintain far more complex solutions. One very important thing to take into account is how many client you think you will have for the library. How much work would it be to maintain those clients separately?
On the other hand some code is generic by nature and can most definitely be shared in a library to make your life easier.
If your algorithm is in Java, build it as a jar.
Then create a folder called "libs" in the root directory of your android project. Copy your jar into that folder. In eclipse go to
-> Properties -> Java Build Path
Under tab "Libraries", add your jar.
Now you can use your code.
You can as well link it with multiple projects.
If your algorithm is in natice C/C++, follow
http://marakana.com/s/introduction_to_ndk,1153/index.html
If you have a class/set of classes generic enough to be reutilizable, the solution would be separating them to a different project.
In your IDE, make your projects use the generic project as part of their build path (it is more flexible than including a jar).
When deploying, package all the generic classes in a jar and it to your solution. Don't forget to include that jar in the classpath.
In Java, there is no difference between "main project" and "library", other than the "library" usually does not include any main method (but it is not forbidden). They are classes in the classpath.
I am using Eclipse + Subversion for Android development. I used to create a free version of my apps with ads, and another one payed without them, so I kept them in two separate branches on subversion.
The problem I have found is that as these are two different app for Google Play and other markets, they must have different package names. So I have, for example:
com.package.game
com.package.gamefree
When I do some changes on the free version of the game and want to merge them with subversion into the payed branch, I found myself in a trouble because source files for the free game are below com/package/gamefree and for payed under com/package/game
I ended up doing a "manual" merge, making a diff of source file by source file, but I also have to check those files that have been added into another directories and those that has been deleted. A waste of time.
So, is there any manner to make subversion know that com/package/game in one branch is the "same" directory than com/package/gamefree in the other?
Thanks a lot in advance,
I'm guessing here, but maybe you could have the free app on the trunk in the com.package.gamefree package.
On the branch you could have the other importing the one developed on the trunk as a dependency lib, and wrap it around with launcher class which is packaged under com.package.game, adding the license stuff...
This way you'll only have to modify the code once, and build 2 apps.
After googling a bit in deep, I found that my better chances was just two:
Using ANT in anny manner that automatizes the switch between free and payment versions at building time.
Using an Android Library project shared between two versions.
I have seen that most of the people using ANT were doing it some time ago by the lack of another option, but since there is Android Library projects on Eclipse/ADT this is the preferred way for this kind of things. Even in the development docs of Android, says:
http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject
If you are creating an application that exists in both free and paid versions. You move the part of the application that is common to both versions into a library project. The two dependent projects, with their different package names, will reference the library project and provide only the difference between the two application versions.
This seems to be the best way for me also because I have never used ANT and given the library option there is no reason for learning it.
So I have done that way: my project is splited now into MyGameCore that is the library project with all common files to both MyGameFree and MyGamePay projects, that now just have the minimal classes needed to have a different main package name so Google Play knows they are different applications, plus the raw assets folder that according to Google Docs cannot be moved to the library. Anyway these are binary files that I simply copy from one version to another when they are changed, that is not very often.
So from now on, most of the time I just need to work on the MyGameCore project and the changes done have inmediate effect on both MyGameFree and MyGamePay projects without needing to merge branches.
This will save me A LOT of time and I will use it on my further projects from the very first code line.
I've had several classes - university level - on Java.
However, what these classes lack is some practical approach to Java - or, to programming as a whole. Things you can only learn in a business.
However, since I am not allowed to use Java on the workfloor, I don't get to learn this now - even though I would like to.
So I guess what I'm asking for is any number of plain have-to-know Java resources. Things concering, for example, what Ant is and why and how to use it; using revision control systems from your IDE; standard Java libraries you would use often ... Anything that would help with actual software development, really.
As some side information, I've been using Eclipse for about four years now, and I feel at home there.
I have a system that works fairly well for class assignments and for projects as well. Firstly, I create one Eclipse project per class. This way I can re-use classes from previous assignments. You can also customize your classpath by adding another project as a library.
I use the Maven plugin for Eclipse M2Eclipse. Not only does this give you the ability to search for libraries and add them easily but the exec:java plugin is an easy way to execute your code from the command line. It's helpful because when it executes your code, it uses a classpath that includes all linked Maven dependencies. If you aren't using external libraries, you might not need Maven but I've found it to be helpful to learn in preparation for the job market. It's fairly simple to start with plus there are a ton useful plugins for open source projects.
Next, for revision control I recommend Subclipse. You can get a free SVN account with a single login from Unfuddle.com. Link that up to your Eclipse environment and Import your project.
When I want to get a particular class specification, I go to Sun's Java documentation.
Another excellent resource that will certainly give you the reference material (searchable!) to answer any java question would be this torrent containing ~100 ebooks on Java, sorted by directory on various topics (like Ant, Eclipse, or Swing).
I intend to develop a system that is entirely based on modules. The system base should have support for finding out about plugins, starting them up and being able to provide ways for those modules to communicate. Ideally, one should be able to put in new modules and yank out unused modules at will, and modules should be able to use each other's funcionality if it is available.
This system should be used as a basis for simulation systems where a lot of stuff happens in different modules, and other modules might want to do something based on that.
The system I intend to develop is going to be in Java. The way I see it, I intend to have a folder with a subfolder for each module that includes a XML that describes the module with information such as name, maybe which events it might raise, stuff like that. I suppose I might need to write a custom ClassLoader to work this stuff out.
The thing is, I don't know if my idea actually holds any water and, of course, I intend on building a working prototype. However, I never worked on a truly modular system before, and I'm not really sure what is the best way to take on this problem.
Where should I start? Are there common problems and pitfalls that are found while developing this kind of system? How do I make the modules talk with each other while maintaining isolation (i.e, you remove a module and another module that was using it stays sane)? Are there any guides, specifications or articles I can read that could give me some ideas on where to start? It would be better if they were based on Java, but this is not a requirement, as what I'm looking for right now are ideas, not code.
Any feedback is appreciated.
You should definitely look at OSGi. It aims at being the component/plugin mechanism for Java. It allows you to modularize your code (in so-called bundles) and update bundles at runtime. You can also completely hide implementation packages from unwanted access by other bundles, eg. only provide the API.
Eclipse was the first major open-source project to implement and use OSGi, but they didn't fully leverage it (no plugin installations/updates without restarts). If you start from scratch though, it will give you a very good framework for a plugin system.
Apache Felix is a complete open-source implementation (and there are others, such as Eclipse Equinox).
Without getting into great detail, you should be looking at Spring and a familiarization with OSGI or the Eclipse RCP frameworks will also give you some fundamental concepts you will need to keep in mind.
Another option is the ServiceLoader added in Java 1.6.
They are many way to do it but something simple can be by using Reflection. You write in your XML file name of file (that would be a class in reallity). You can than check what type is it and create it back with reflection. The class could have a common Interface that will let you find if the external file/class is really one of your module. Here is some information about Reflexion.
You can also use a precoded framework like this SourceForge onelink text that will give you a first good step to create module/plugin.