We Keep Coding

Basic Generic DAO based on Reflection

Well, there's something bugging me in my project. I have lots and lots of hibernate entity classes and each one of them have their own DAO (inherited from a GenericDAO). Most of them have no specific funtion, being just an empty class inheriting GenericDAO.
Since I believe that those were unnecessary classes, I decided to get rid of them using reflection.
After some coding, my call on all of those classes that have no specific methods apart from GenericDAO follow this design:
DAO.forClass(MyClass.class, MyClassPK.class).genericDAOMethod();
It works like a charm. I'm now rid of empty DAOs. But after searching through internet, I have found low to no solution like mine, so the question is:
is this approach wrong or bad in any considerable way? Why no one ever consider doing something like this?

Reflection is almost never considered the answer to a problem. Its just hard to read because a lot of people don't know what it is and people that come behind you to modify your code cannot understand it easily. Its not "self-documenting" to use a term from the book Code Complete.
Reflection is powerful, as you just found out doing it to implement a DAO. But you should just be weary of it. A term we use around my office is "code stink", which is code that might be there for specific purpose, but shouldn't be used everywhere unless absolutely needed. Make sure to documented properly so that people that do actually come behind you will know what the heck it is.
I like to use it to write jUnit tests in Spring to compare two objects from two different databases using reflection. But that's a test and isn't actually in production code.
Hope this helps and is kind of what you are looking for!

list of subclasses of one of my classes

Under Android environment, I need to list all subclasses of one of my classes.
I saw that there is samples with reading the directories.... But I would like to find them by asking to the Thread or application level or another running object.
Under iOS I use objc_getClassList and then I select the ones that I am interested in.
Dose someone know if there is a way to find a clean solution like objc_getClassList on generic java or specific android libraries?
Thanks in advance.
PS: All these classes I want to list are in a certain java package

I am not really sure did I understand your question, but you could make a class called AllClasses or something, and in it put an ArrayList subclasses; and then in every subclass you have do
AllClasses.subclasses.add(this).
Thanks should do it

You will need to use introspection and the class loader to find out the classes and test if they are subtypes of a given super type. Here is an interesting implementation of your problem on J2SE : http://nonstop-rp.blogspot.fr/2010/05/java-reflection-know-subclasses-of.html

What is the optimal way to share code between Activities with different base classes?

I have the following problem:
I have an abstract Activity class, lets call it MyAbstractActivity, that contains some code I'd like to reuse (for example: a standard service binder, common menu items, common initialization code, etc. etc.). Normally I would just use it to subclass my concrete activities and be done with it.
However, I occasionally need to use another supertype, such as a ListActivity or a MapActivity.
So the question is: how do I avoid duplicating that support code within an Activity, if I have to use another base class?
I have thought up of a solution based on the decorator pattern, like this one:
.
However, I see a problem with this approach:
What to do with protected methods (like onCreate())? Should I introduce an additional "bridge" class that makes them public for the purpose of the decorator, similarly to the way presented below (starting to look a bit byzantine...)?
Any other way?
I hope I made myself relatively clear. Thanks in advance for any feedback!
PS. Using static utility classes is not a good solution in my opinion, since it introduces a possibility of hard-to-identify programming bugs.

If I understand correctly, neither Fragments nor the Decorator Pattern are clean or appropriate solutions for what you want to accomplish. They were designed to solve other problems.
I find myself moving "support" code, or "framework" code, or "all that verbose, repetitive, boilerplate crap" to static utility methods. This isn't necessarily the approach I'd take on a non-Android project, but in my Android projects, it works pretty darn well.
Also, know that you don't need to subclass ListActivity to have a ListView.

class accessible from all other classes

I have some database functions and would like to make those database functions accessible too all of my other classes. I would like to keep the functions in one place so they are easy to modify. What is the best way to achieve this goal? My application is running on android and is using threading and events.
Thanks in advance, if you need more information let me know.

make a class with all static methods/variables, or alternatively a Singleton
synchronize stuff if you need to, sounds like you might

Absolutely no reason why you can't have a package level class called something like DatabaseUtils and put general static methods in there. Doesn't have much bearing on it that you're using threading and events, although you will want to ensure your utility methods can handle simultaneous access if that's a possibility.

Strategies for reverse engineering project that uses Guice?

I have tried to understand dependency injection and not quite gotten it, except I have managed to pick up the understanding that it makes it hard to understand somebody else's code. :'(
Anyway, I'm not sure how to briefly describe my problem but I will try. I am currently the sole coder working on a Java project that's been worked on by dozens of loners over about six years. It makes heavy use of Google's Guice library. I'm supposed to take some existing code and implement it differently; specifically, use the existing methods for password authentication and, instead of applying it to each JMenuItem in a JMenu, apply it to the whole JMenu, so that if the wrong password or no password is entered, all JMenuItems are disabled. This doesn't happen if the password is wrong, leading me to believe the problem is in the if statement, which is a long string of dependencies in itself:
if (!ViewScanApp.getApplication().getHistoryManager().isAuthenticated())
I trace my way back through this, to find that the HistoryManager class is an interface, and there my path seems to die; there's no code there, and it doesn't make a reference to any other class. I have found the end of the path through random exploration of the 100-odd classes in the project, but I can't quite seem to connect them. I cannot find where the first class I can find on the other end of this stack, AccessManagerImpl, gets called.
I could use an explanation of dependency injection that might be applicable to this situation. Thank you so much!

Assuming there's no #ImplementedBy annotation on the HistoryManager interface, you'll need to examine the Guice Module that is responsible for binding this type.
In Eclipse, there is a command to look for occurrences of a class. I'll bet that Netbeans has something similar. Use it to look for occurrences of HistoryManager. At least one of these should occur in a class that implements com.google.inject.Module (or extends AbstractModule). You'll likely see something like
protected void configure() {
…
bind(HistoryManager.class).to(HistoryManagerImpl.class);
…
}
Or, if you like quick-and-dirty empiricism, you can throw in a println():
HistoryManager mgr = ViewScanApp.getApplication().getHistoryManager();
System.out.println("HistoryManager implementation: " + mgr.getClass());
if (!mgr.isAuthenticated())
…
However you locate it, HistoryManagerImpl class is where you'll want to pick up the trail.
I haven't used it, but the Guice graphing tool might be helpful too.

Fire up a debugger. It will walk you through the exact class that is implementing that interface (assuming you have the source code to it)

Whenever you have an interface definition in Eclipse which is injected with Guice, instead of using F3 to go to the defintion which you would do if it was a class, then use Ctrl-T to choose among the implementations of that interface.
If you have more than one to choose from, then you need the module bindings printed out so you know which one to pick. Unfortunately Eclipse doesn't understand injection yet.