I have an app written with GWT and GAE where every supported city has its own app. Clearly this is not the best way to manage the map so I want to merge them all into one app. Currently my app is at the urls sub1.myapp.com, sub2.myapp.com, sub3.myapp.com, etc, and I want them to be at myapp.com/sub1 ,myapp.com/sub2, etc. All the supported cities share common code, so I'm going to put all the that code in one module, and have a different module for each piece of unique code block. Is this going about it the right way? How will the different modules interact?
Also, I currently have JSPs at sub1.myapp.com/listofsomesort and I would like to move these to myapp.com/sub1/listofsomesort. Is there a simple way to accomplish this?
By making a module with EntryPoint for each old application, in one and the same application. Each module has one 'welcome page' which you can put in different directories. All the shared code can go into another module. The shared code can be used by the inherit setting in other modules.
The only thing I bumped into was that when you deploy to GAE, ALL modules should have an entry point, also the library modules. I solved it by adding a dummy EntryPoint to them, that does nothing, but still searching for a better solution. See my question at How to deploy GWT Project containing GWT modules without entry points with Eclipse GAE plugin?.
This seems like the job for Code Splitting :) It might require some changes in the structure of your code, though - depends how tightly coupled your classes are. A compile report should tell you if your code splits up nicely, or if not, where the connections are.
Related
Hopefully this is a question that only needs a fairly quick answer, but I haven't had much luck finding something online that is in terms I understand!
Quite simply, I'm working on my first real project in Java, a text adventure, (using IntelliJ IDEA) and I was just wondering if I need to be splitting my code into modules? So, for my monsters, should I keep all of my monster classes within a module called Monsters, or can I just keep it in the same module?
I only ask because; a) I wasn't sure whether it was a done thing in order to keep the project tidy and b) When I tried to create a Monster module, I received a warning telling me that the files in this module wouldn't be accessible from the rest of the program, which seems to defeat the object to me...
Many thanks in advance for any advice!
I believe you are referring to IntelliJ's concept of a module. As stated on their page:
A module is a discrete unit of functionality which you can compile, run, test and debug
independently.
Modules contain everything that is required for their specific tasks:
source code, build scripts, unit tests, deployment descriptors, and
documentation. However, modules exist and are functional only in the
context of a project.
So, modules should not be referencing the source code from other modules. They should essentially be completely different units.
As in thecbuilder's answer, you should look into using Java's packaging system instead.
By modules if you mean packages, then its a good habit to keep related classes in one package and distributing unrelated classes in different packages.
And to the thing, that the classes wouldn't be accessible, you'll have to make them public to access them from different packages.
More on package structuring :
http://www.javapractices.com/topic/TopicAction.do?Id=205
http://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html
https://stackoverflow.com/a/3226371/3603806
For access specifiers :
Taken from : http://www.go4expert.com/articles/java-access-specifiers-t28019/
I am about to embark on a personal JAVA project in eclipse where myself and a friend create a game server, game engine, and a game based on an existing card game. The game server will come last, but for now I'd like to concentrate on building the card game engine followed by the game itself.
In school, we would just create packages like gameEngine.whatever and then the different games would be in packages like game.gameName.whatever. I was thinking of making the game engine its own separate project and then have the game be an individual project as well, instead of having them all in one project and separating them based on packages, like I've done in school. In my internships, we have multiple projects working together, but have not touched on that in classes at all.
Is there any difference in doing it one way versus the other? Or are they basically equivalent? Thanks!
If I understand your situation correctly, you should not worry too much about code organisation at this point. Of course there are some projects where it is clear upfront as to where what goes in. Not so in many cases.
In your case, as you start implementing things, you'll gain more clarity on the direction to take and the organisation. One advantage of using IDEs like eclipse is that you can refactor code (both packages or even move packages/classes across projects) at a later stage. For eclipse, the code is not just files/directories. It is looking at the parse tree and so can let you move around a lot of fine stuff safely - moving code across packages or projects is among the most trivial things it can do.
Just focus on what you have to do and try to make progress with the real stuff. If you have to worry about multiple projects, you'll know when to. I'd suggest starting off with something like:
Create one project for now. First find a standard and unique package prefix. Say you decided to go with something like "org.abc" (just an example not a good one)
Now start working on your project. As you keep adding classes, focus on organising well just package wise. Keep adding packages as you go. For instance..
org.abc.game.engine
org.abc.game.util
org.abc.game.games.mario
org.abc.game.engine.phy
org.abc.game.server
org.abc.game.common
...
After a while when you want-to, you can create the new projects. For instance you can decide to
call the current project as GameMario
move the entire org.abc.game.common and org.abc.game.util with some files to a project called GameCommon. The same package can exist (and in many cases do) in two projects
move the org.abc.game.engine, org.abc.game.server and all their sub-packages to a new project GameServer and continue adding game server code in that project
Both GameMario and GameServer will have a project dependency on GameCommon
I'd say you should make a separate project for "X" if "X" can be used on its own or there are (or could be) at least 2 different projects that use "X". Otherwise, a package is fine.
Using multiple projects instead of packages has some advantages
You can compile, test and run the server, client and engine separately.
I know this is possible with packages as well, but it would be cleaner. If there is a code collaboration like in a git, it will be way easier to manage.
If you are dubious about using the engine as a module in the client, you can always use one project as a library of the other. That way, you can keep the work separate, but use the functions without a hassle while developing the game.
On the other hand, there are some disadvantages. Your code will be three separate entities. So, if you're used to moving one jar file everywhere and issuing arguments to a single class telling it which module to run, this project approach may not work.
It all comes to your application and your style. If I were you, I'd do three projects.
Good luck.
My understanding of a GWT module is that it is a "unit of reusability".
My understanding of an EntryPoint is that it is a module that is mean to interact with a client browser. Thus, I think of an EntryPoint as sort of an "executable JAR", and a module as a library JAR or DLL.
My understanding of a fragment is that it is a sub-component of a module used for the purposes of deferred binding and codesplitting.
So first, if I am incorrect on any of these assertions, please begin by correcting me or clarifying things for me!
If I am correct, then it is obvious that you decompose a module into fragment based on need. You write your module, you test it every which way, you review your soyc compiler reports, and if you see bottlenecks, you begin to fragment and codesplit as necessary, yes?
But how do you decompose an app into modules and entry points?!? Again, I'm sure it all comes down to need and is application-specific. I just read this article on structuring a GWT app, and although it was quite helpful, it still didn't provide any litmus or set of guidelines for decomposing an app into modules/entry points.
I am already planning on splitting my app into two modules: a WebModule and an AppModule. The WebModule would be the "public" portion of the app (the website, if you will), and the AppModule will be downloaded after the user successfully logs in (I do this for security purposes).
But beyond that, I'm not really sure as to how to break my AppModule out into other modules, and how to determine whether or not those modules need entry points. So I ask: if you fragment a module to circumvent network latency issues with the code download, when/why do you modularize an app, and when does a module need an entry point?
EntryPoint is not a seperate module. It is part of a module and has a function which will be invoked when the application is started.
The point of modules is to group logical functionality so you can share code between different projects. Nothing else. GWT already comes with a bunch of modules (HTTP, Activity, Places, Debug). You may have a COMMENT or a USER module in your application if you decide to group it like that.
Codesplitting should only be used where needed. It can be a major annoyance that you can only reference code beyond fragment boundaries through the GWT.runAsync(). I suggest you only take this step if you experience your application being slow to load.
I have several applications that differ mostly based on resources. As of now, I'm copying the code around to each application. This can be problematic. An example, fixing a bug in one, and forgetting to update to the others.
I don't think creating a JAR is appropriate for this situation, as these are application specific UI classes, (actually android activity classes in specific) including the actual app start-up code.
It may be possible to include these source files into several packages, but then I have the problem that each file specifies a specific package name on the first line.
Most of the code is related to the UI and Activity processing. (The actual common code is already in a library). A similar question is posted here.
Are there any elegant solutions to this situation?
A jar is absolutely appropriate for this situation. You should split your application into layers, separating the application-specific classes from the shared code.
I solved this by going with Android Library projects. (Not sure of the details, perhaps they are ultimately jars) Check out details here, specifically the section 'Setting up a Library Project'.
I basically put in all my activity classes (except for the start-up one) into the library.
For true non-UI bound code, JARs, do seem to be the way to go.
I agree with artbristol.
I also recommend to use Maven and:
release the common jars to a corporate Maven repository
declare a dependency with specific versions on these jar artifacts
Like this you don't break applications if you do some incompatible changes.
I am very new to java and android development and to learn I am trying to start with an application to gather statistics and information like munin does. I am trying to be able to load "plugins" in my application. These plugins are already in the application but I don't want to have to invoke them all separately, but be able to iterate over them. I was trying to use serviceloader but could never get the META-INF/services into my apk. So I am wondering if it is possible to use serviceloader on android
Thanks
EDIT: I am asking about java.util.ServiceLoader, I think it should, but I can't figure out how to get my services folder into META-INF on the apk
There is an open bug report against this issue. See https://code.google.com/p/android/issues/detail?id=59658
The META-INF folder is deliberately excluded from the APK by ApkBuilder; the only comment in ApkBuilder.java is "we need to exclude some other folder (like /META-INF)" but there is no other explanation.
Even after adding META-INF with ant, you will still get in trouble if you want to use Proguard, which refuses to replace the content of META-INF/services/* files or rename them (that's another story, the author wants to keep Proguard agnostic).
However, people using maven may want to check https://github.com/pa314159/maven-android-plugin (the branch named "modified"), that tries to solve both issues. It is a fork from the original "android-maven-plugin" I modified one month ago for my own Android projects.
It also provides a patch for Proguard-4.7
Hope this helps, any feedback is welcome.
I've figured out a solution that may work for some situations. Instead of ServiceLoader, I'm using the org.openide.util.Lookup class / library that comes with NetBeans - it is a superset of ServiceLoader. It does not require NetBeans itself and seems to work ok with Eclipse. It is necessary to replace whatever ServiceLoader functionality you are using in your application with Lookup equivalents, and add the org-openide-util-lookup library. Then, you can just do something like this:
Lookup lookup = new ProxyLookup(Lookup.getDefault(),
Lookups.metaInfServices(myClass.getClassLoader(), "services/"));
And move your ServiceLoader files from META-INF/services/ to services/.
Note that, because of the ProxyLookup, this will continue to work on standard Java environments unchanged (i.e., in those cases it will continue to look in META-INF/services).
Here is a link to the documentation for the library: http://bits.netbeans.org/dev/javadoc/org-openide-util-lookup/org/openide/util/lookup/Lookups.html
UPDATE
After working with this for a couple of days, it seems to function well - I move between environments (standard Java and Android) and it works properly in each location. The primary downside is having to manually copy the files to the /services directory.
It is possible. You may want to check http://developer.android.com/reference/java/util/ServiceLoader.html
ServiceLoader is stuff from the Java language that is not really relevant on Android. I recommend not using it. If you just want to find a list of classes within your .apk to load, there are all kinds of ways to do this -- put in XMl file in res/xml that lists them, use reflection, annotations, etc.