I've been working on an Android app in Eclipse, and it's gradually grown in complexity to the point where I find it difficult to locate individual classes in the Package explorer.
Java isn't my strong point, I come from a Visual Studio/C Sharp background, so my first thought was to move logical groups of classes into new packages, a bit like creating a new code folder in Visual Studio.
I created a new package, com.mycompany.myapp.activities and dragged all the Activity.java files into here.
The whole thing went pretty badly, I got tons of import errors, resources failed to build, and so on. The auto refactor tool messed up my Manifest file pretty badly too. It just doesn't seem like it was designed to work that way - I ended up moving them all back, and wasted two hours fixing it.
So my question is, does Eclipse have some way to organise .java files into logical subfolders without having to create new packages for them? I'd like to make a folder for 'Data Model', one for 'Activities', one for 'Interfaces' and so on.
How would I go about doing this? Or am I thinking about this the wrong way?
So my question is, does Eclipse have some way to organise .java files into logical subfolders without having to create new packages for them?
AFAIK, no. You just need to fix up stuff related to moving your code into packages.
I got tons of import errors
Your app's R.java is generated into your application package (com.mycompany.myapp), and any classes in that same package get R via auto-import. Code residing in other packages needs to import that class (e.g., import com.mycompany.myapp.R). Hence, if you refactor a class from your app's package to a sub-package, you need to add the import.
resources failed to build
That seems unlikely, as resources know nothing about Java packages. However, without any details, it is difficult to provide you with concrete assistance.
The auto refactor tool messed up my Manifest file pretty badly too
You would need to adjust your <activity> elements to ensure they point to the newly-repackaged classes. Ditto for any other components that you repackage (e.g., services). Beyond that, without any details, it is difficult to provide you with concrete assistance.
It just doesn't seem like it was designed to work that way
Certainly, moving activities into other packages is supported. Whether the ADT plugin handles all aspects of it with aplomb is another issue. If you come up with concrete repeatable scenarios where the ADT plugin is not doing the right thing, file an issue at http://b.android.com.
Related
I'm a beginning programmer and I apologize if my questions is trivial but I haven't found a sufficient answer to my problem.
I have a git repository called "toolbox" with some utility classes that I frequently use in other projects. Until now, I have manually copied those class files from this project in other projects whenever I needed them.
This if of course not a good way of doing it. I frequently add new features and fixes in whatever project I'm currently working on to these files. It makes version management a nightmare.
What I'd like to to is to import the toolbox-classes directly into the IntelliJ-Project(s) (which is also on the same git as the toolbox repo) and whenever I make a change to those files in the toolbox-repo I want the other projects to be able to automatically pull those changes as well.
If possible I'd also like to be able to share my toolbox-repo easily with others who might need those classes. But that is not a requirement. I'd just be nice to be able to do so.
I tried to use git submodule. It included the entire toolbox-repo in the target-repo but unfortunately I wasn't able to use the utility classes. I asked someone more experienced and they told me that I need to define "SourceSet" in the gradle.build but I wasn't able to configure that due to my lack of knowledge.
How can I include/import/use my utility classes from my toolbox-repo within other projects?
Thanks for any advice.
I am writing here because of desperation caused by refactoring a GWT project.
My first try:
After I read all the praises of the refactoring tool from Eclipse ( I am using it as IDE) I simply right clicked on a module ( what a fool i was ) and use the refactoring option. My project became unusable.
First Conclusion:
Found out that I need to start with the classes and then go up and refactor a module at a time.
Second try:
Refactored some classes, worked fine until I messed something related to a ui.xml file. Project unusable!
Second Conclusion:
Be careful at the ui.xml files!
Third try:
Went pretty well, but I got ahead of myself and tried to remove some comments or replace class names in comments. Predictable result : project unusable!
Third Conclusion:
Try again!
Forth try:
Fail!
Fifth try:
Fail!
You get the picture.
Can someone experienced with GWT please offer some guidelines about the mystical realm of refactoring?
GWT has some rules based on naming conventions (e.g. the two interfaces for GWT-RPC, the *.ui.xml files and the class that uses them through UiBinder, the files related to ClientBundle or ImageBundle methods, the *.properties files for I18N), so failing to respect them when renaming/moving one class/file will break it.
GWT also sometimes references classes by name in non-Java files (#eval in the *.css of a CssResource, or in *.ui.xml files), non-Java portions of classes (JSNI) or string literals (e.g. in #ProxyForName and #ServiceName). Failing to update them all will break the build.
Because a tool makes it easy to refactor does not mean you should let it do it blindly: it's just a tool, you have to understand what it does and double-check it (hint: check the box in Eclipse that forces a preview before applying the refactoring) so it doesn't do too much or too few.
When my project grows too big, it also get harder to recognize the growing number of classes. I'm looking for a plugin for eclipse, that makes it easier to differentiate the classes by assigning icons or colors to them.
Alternatively I'm looking for any tools, plugins or advice to see through the jumble of classes.
(Currently I'm only using packages for grouping classes)
You should be using packages to the full extent. That means, whenever you find that at least 2 classes in an already existing package share a common aspect, think about moving them into yet another sub package.
Over time, this can lead to quite long package names like org.eclipse.product.addon.technology.ui.someview.listeners. As those are not easy to browse, use the compressed package name display of Eclipse, which allows you to replace any package path by an arbitrary string (only for display in the package explorer). So your very long package names get shortened like here:
I was wondering if there is a way to reuse my classes in Android projects where the only thing that changes is the R import?
So for example I have one file saved where the import is :
import com.myname.project.R
And in my second project the class is exactly the same as the one in the first project except it's import for the R file is different:
import com.myname.projecttwo.R
This means I have to maintain two files with just the import being different, son when I change something in one I have to remember to change it in the other.
Is there a standard way to avoid this and have only one file where I can change whatever I want and I will be able to use it in both projects?
If you want to use a lot of shared code, you probably should be using a library project to keep your codebase and then two different projects with your resources.
Android Developer explains it nicely, see: http://developer.android.com/guide/developing/projects/index.html#LibraryProjects.
I do not think you need that line at all. I do not have it in any of my modules, and if one ever does it is usually an error. As far as I know, that include should be generated automatically. I am no expert on this and I can feel a downvote coming here, but that is my experience as a jobbing programmer. I do have a package statement though, and I would need to change that if I wanted to reuse the code.
I wrote a package in eclipse (Java/Android package, that is). Now I want to make another package which is a slight variation on the original. My plan is to copy and paste each .java file into the new package and change the import package.somename to the name of the new package, and develop from there. Is there a better way to do this?
Select the package in the project explorer, press Ctrl+C and then Ctrl+V, Eclipse will prompt with a package name conflict warning and ask you to enter a new package name. Just enter it and Eclipse will repackage all copied classes accordingly.
Unrelated to the problem, there's a design smell in your approach :)
In a comment on an answer you've given the reason you want to do this: "Now I want to put up a free demo version, with some functionality removed."
Instead of copying all the code to another package I'd take the approach of having only one code base and using a build parameter to specify if you're building the free or commercial version. The classes and config (e.g. spring) that are included in the build could then depend on this parameter.
Duplicating the codebase may seem like the easier option now but will duplicate your work in the long run when maintaining it, and increase the risk of bugs.
How about just extend the classes you want to change? that way you can the two variations in the same package
Depending on how much "slight variation" really is you might want to keep it as one package and handle the differences. Reasons you might not want to do this is that by duplicating a whole package for only small changes is not really clean. Duplicated code is a code smell and can cause headaches in the future if a bug is found in one package and needs to be fixed as well in other sections of code.
To answer the question though, Eclipse should have the functionality to copy the whole package and to paste it back into the project. You will have to rename either one of the packages so that you have a unique package name though.