RoboGuice and why Android Needs DI (at it's core)

So I've been playing around with RoboGuice, which is built from the semi-popular Guice Dependency Injection Framework.  This is my first experience with Guice, I've always thought Crazy Bob was a smart dude, and I  thought it'd be nice to give Guice a try, I never gave it a chance because Spring caught on like wildfire.

So my impressions so far are well good and bad...

I like:

• modules - instead of xml files from Spring, you write a Module class and this class binds things together) 
• Everything happens in the Application class, this makes sense.

I don't like:
extends -- I have to use the RoboGuice class heirarchy (i.e.)
public class BeaconActivity extends RoboActivity

verses
public class BeaconActivity extends Activity


annotations -  make the code less portable, and not have code with silly @Inject tags everywhere

more specifically in cases where you want to configure "library" code.  (You are using a library module and you need to configure it in your code (or module)... Also if you develop library code (i.e. ContourMap generator I created) I don't want to put @Inject annotations everywhere and force people to add this dependency to get it to work for Android.)
(Side note: I think this is why Crazy Bob has been trying to make @Inject a standard Java Notation, because (I fear) people don't want to ship any library code that uses Guice because it will require library users to also include guice.)

lifecycle - you need to understand how RoboGuice configures itself and when in the Android Application Lifecycle, I originally had a bunch of NPE's because I was trying to log out a value in onCreate() and it wasn't available until onStart().

Frankly I understand where the RoboGuice Team is going with the project, but it seems based on the idea that they can make things "more convenient" and get rid of boilerplate and make it "more testable".  But you also have to make sacrifices... new jar dependencies to guice-2.0-no-aop.jar and roboguice1.1.1.jar

Here's the creator giving an overview

http://bostinnovation.com/2011/02/08/what-boston-devs-are-working-on-androids-roboguice/

It got me thinking, though, really what Android needs is a good DI framework, and not some "Bolt on solution" (no offense, but that is what Robo-Guice is).  Android needs DI at it's very core.

Although currently people are arguing that DI systems are too "heavyweight" or resource intensive" keep in mind how android currently handles the R resource... (all this is done "pre" deployment time)...  the same could apply for Dependency Injection, if done correctly... ok well.. more later (on Why Android Needs DI)