[android-developers] Re: Announcing RoboGuice 1.0
On Apr 6, 9:06 pm, Michael Burton m...@niskala.org wrote: Hi ko5tik, Good idea, I agree that injection is not as simple as it should be for objects instantiated manually. I've added your suggestion here:http://code.google.com/p/roboguice/issues/detail?id=34 When you say you're not happy with inheritance, could you be more specific? Do you mean how Activities need to inherit from GuiceActivity instead of Activity? Composition is usually more flexible as inheritance (as there is no multiple inheritance in java) - but for rigigng up interface it should be less problematic. as there is not much of reuse of activities between projects. It would be interesting to put some business code under DI - injecting textviews to them , so they can update values (maybe not real text views, but proxy wrapped one, to overcome problems with interface thread. ) My actual playground: I have highscore service which sits behind the scenes and pulls highscore updates over http ( asynch) - it could receive HTTP-Connector as DI, could be configured via DI with some propeties out of manifest and and reference to some interface obect to push highscores there - with as few knowledge of android whereabouts as possible. regards, -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
Re: [android-developers] Re: Announcing RoboGuice 1.0
Hi Matthias, I'm with you on the sluggishness issues. I had to dial-back my use of libraries like gson because the overhead just ended up being too high. In my experience, run-time impact of RoboGuice isn't that high. As I was telling Manfred a few days ago, I notice zero impact on the Nexus One or Droid. For older devices, it's possible to notice an impact during activity startup if you're looking for it, but it's fairly innocuous. Reading reviews of apps that use RoboGuice indicates that it doesn't seem to be something users are generally aware of. I've got an action item (Issue #33) to publish some benchmarks at some point. Battery impact should be negligible as roboguice doesn't really do anything in the background. APK size is an issue though. Right now roboguice+guice adds about 450k (400 of that is just guice). I think proguard could probably take out much or most of that impact, but I haven't had a chance to get it working yet. In fact, if anyone is up for the challenge, I'd totally offer up a license to IntelliJ 9 to anyone who can supply detailed instructions on how to use Proguard with a roboguice android app. Any takers? :) Cheers, Mike On Apr 4, 2010, at 6:12 AM, Matthias wrote: I was thinking about using Guice myself before, but hesitated fearing to make the overall sluggishness of the platform even worse. How much of an overhead are talking about in terms of memory footprint and size of bundled libraries? Any noticeable impacts on speed or battery life? How often does Guice kick in in the background? I'm currently stepping back from overly abstract programming models on Android because of exactly these issues. On Mar 29, 8:53 pm, Michael Burton m...@niskala.org wrote: Hello Android developers, I'd like to announce the final release of RoboGuice 1.0! http://code.google.com/p/roboguice RoboGuice is a framework that brings the simplicity and ease of Dependency Injection to Android, using Google's own Guice library. If you've ever used Spring (the #1 enterprise framework on Java, now more popular than J2EE itself) or Guice, you already know how convenient this style of programming can be. To give you an idea, take a look at this simple example of a typical Android activity: class AndroidWay extends Activity { TextView name; ImageView thumbnail; LocationManager loc; Drawable icon; String myName; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); name = (TextView) findViewById(R.id.name); thumbnail = (ImageView) findViewById(R.id.thumbnail); loc = (LocationManager) getSystemService(Activity.LOCATION_SERVICE); icon = getResources().getDrawable(R.drawable.icon); myName= getString(R.string.app_name); name.setText( Hello, + myName ); } } This example is 18 lines of code. If you're trying to read through onCreate(), you have to skip over 5 lines of boilerplate initialization to find the only one that really matters: name.setText(). And complex activities can end up with a lot more of this sort of initialization code. Compare this to the same app, written using RoboGuice: class RoboWay extends GuiceActivity { @InjectView(R.id.name) TextView name; @InjectView(R.id.thumbnail)ImageView thumbnail; @InjectResource(R.drawable.icon) Drawable icon; @InjectResource(R.string.app_name) String myName; @InjectLocationManager loc; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); name.setText( Hello, + myName ); } } In this example, onCreate() is much easier to take in at a glance. All the platform boilerplate is stripped away and you're left with just your own app's business logic. Do you need a SystemService? Inject one. Do you need a View or Resource? Inject those, too, and RoboGuice will take care of the details. RoboGuice's goal is to make your code be about your app, rather than be about all the initialization and lifecycle code you typically have to maintain in Android. RoboGuice has been in development since August 2009, and 0.9 entered release candidacy in December and has been stabilizing ever since. After three months and a few finishing touches, we now believe it's ready to expose to a larger audience. We know that RoboGuice won't be for everybody. Although RoboGuice never prevents you from doing things the Android way, some people will still prefer seeing everything spelled out explicitly in their code. And other people who write extremely high performance applications such as games may not want to incur the small overhead imposed by yet another framework. But for people who want to build simple and straightforward code that's easily testable and easy to
[android-developers] Re: Announcing RoboGuice 1.0
Hi Michael, Being developer of pico I'm also watching what you are doing ;) Currently I'm not very happy with size (could/should be less) and inheritance. Though inheritance problem could be solved easily - Just create static method which will inject supplied object out of context: RoboGuice.inject(this) This (IMHO) would be less intrusive for users. But I think there is more room for DI on android - not only in interface creation ( I play with ideas to adapt pico, but its core is currently too big ) regards, On Apr 6, 4:38 pm, Michael Burton m...@niskala.org wrote: Hi Matthias, I'm with you on the sluggishness issues. I had to dial-back my use of libraries like gson because the overhead just ended up being too high. In my experience, run-time impact of RoboGuice isn't that high. As I was telling Manfred a few days ago, I notice zero impact on the Nexus One or Droid. For older devices, it's possible to notice an impact during activity startup if you're looking for it, but it's fairly innocuous. Reading reviews of apps that use RoboGuice indicates that it doesn't seem to be something users are generally aware of. I've got an action item (Issue #33) to publish some benchmarks at some point. Battery impact should be negligible as roboguice doesn't really do anything in the background. APK size is an issue though. Right now roboguice+guice adds about 450k (400 of that is just guice). I think proguard could probably take out much or most of that impact, but I haven't had a chance to get it working yet. In fact, if anyone is up for the challenge, I'd totally offer up a license to IntelliJ 9 to anyone who can supply detailed instructions on how to use Proguard with a roboguice android app. Any takers? :) Cheers, Mike On Apr 4, 2010, at 6:12 AM, Matthias wrote: I was thinking about using Guice myself before, but hesitated fearing to make the overall sluggishness of the platform even worse. How much of an overhead are talking about in terms of memory footprint and size of bundled libraries? Any noticeable impacts on speed or battery life? How often does Guice kick in in the background? I'm currently stepping back from overly abstract programming models on Android because of exactly these issues. On Mar 29, 8:53 pm, Michael Burton m...@niskala.org wrote: Hello Android developers, I'd like to announce the final release of RoboGuice 1.0! http://code.google.com/p/roboguice RoboGuice is a framework that brings the simplicity and ease of Dependency Injection to Android, using Google's own Guice library. If you've ever used Spring (the #1 enterprise framework on Java, now more popular than J2EE itself) or Guice, you already know how convenient this style of programming can be. To give you an idea, take a look at this simple example of a typical Android activity: class AndroidWay extends Activity { TextView name; ImageView thumbnail; LocationManager loc; Drawable icon; String myName; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); name = (TextView) findViewById(R.id.name); thumbnail = (ImageView) findViewById(R.id.thumbnail); loc = (LocationManager) getSystemService(Activity.LOCATION_SERVICE); icon = getResources().getDrawable(R.drawable.icon); myName = getString(R.string.app_name); name.setText( Hello, + myName ); } } This example is 18 lines of code. If you're trying to read through onCreate(), you have to skip over 5 lines of boilerplate initialization to find the only one that really matters: name.setText(). And complex activities can end up with a lot more of this sort of initialization code. Compare this to the same app, written using RoboGuice: class RoboWay extends GuiceActivity { @InjectView(R.id.name) TextView name; @InjectView(R.id.thumbnail) ImageView thumbnail; @InjectResource(R.drawable.icon) Drawable icon; @InjectResource(R.string.app_name) String myName; @Inject LocationManager loc; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); name.setText( Hello, + myName ); } } In this example, onCreate() is much easier to take in at a glance. All the platform boilerplate is stripped away and you're left with just your own app's business logic. Do you need a SystemService? Inject one. Do you need a View or Resource? Inject those, too, and RoboGuice will take care of the details. RoboGuice's goal is to make your code be about your app, rather than be about all the initialization and lifecycle code you typically have to maintain in Android. RoboGuice has been in development since August 2009, and 0.9 entered release candidacy in
Re: [android-developers] Re: Announcing RoboGuice 1.0
Hi ko5tik, Good idea, I agree that injection is not as simple as it should be for objects instantiated manually. I've added your suggestion here: http://code.google.com/p/roboguice/issues/detail?id=34 When you say you're not happy with inheritance, could you be more specific? Do you mean how Activities need to inherit from GuiceActivity instead of Activity? I'm glad to see you here! It's great to have developers who know DI inside and out. Cheers, Mike On Apr 6, 2010, at 2:37 PM, ko5tik wrote: Hi Michael, Being developer of pico I'm also watching what you are doing ;) Currently I'm not very happy with size (could/should be less) and inheritance. Though inheritance problem could be solved easily - Just create static method which will inject supplied object out of context: RoboGuice.inject(this) This (IMHO) would be less intrusive for users. But I think there is more room for DI on android - not only in interface creation ( I play with ideas to adapt pico, but its core is currently too big ) regards, On Apr 6, 4:38 pm, Michael Burton m...@niskala.org wrote: Hi Matthias, I'm with you on the sluggishness issues. I had to dial-back my use of libraries like gson because the overhead just ended up being too high. In my experience, run-time impact of RoboGuice isn't that high. As I was telling Manfred a few days ago, I notice zero impact on the Nexus One or Droid. For older devices, it's possible to notice an impact during activity startup if you're looking for it, but it's fairly innocuous. Reading reviews of apps that use RoboGuice indicates that it doesn't seem to be something users are generally aware of. I've got an action item (Issue #33) to publish some benchmarks at some point. Battery impact should be negligible as roboguice doesn't really do anything in the background. APK size is an issue though. Right now roboguice+guice adds about 450k (400 of that is just guice). I think proguard could probably take out much or most of that impact, but I haven't had a chance to get it working yet. In fact, if anyone is up for the challenge, I'd totally offer up a license to IntelliJ 9 to anyone who can supply detailed instructions on how to use Proguard with a roboguice android app. Any takers? :) Cheers, Mike On Apr 4, 2010, at 6:12 AM, Matthias wrote: I was thinking about using Guice myself before, but hesitated fearing to make the overall sluggishness of the platform even worse. How much of an overhead are talking about in terms of memory footprint and size of bundled libraries? Any noticeable impacts on speed or battery life? How often does Guice kick in in the background? I'm currently stepping back from overly abstract programming models on Android because of exactly these issues. On Mar 29, 8:53 pm, Michael Burton m...@niskala.org wrote: Hello Android developers, I'd like to announce the final release of RoboGuice 1.0! http://code.google.com/p/roboguice RoboGuice is a framework that brings the simplicity and ease of Dependency Injection to Android, using Google's own Guice library. If you've ever used Spring (the #1 enterprise framework on Java, now more popular than J2EE itself) or Guice, you already know how convenient this style of programming can be. To give you an idea, take a look at this simple example of a typical Android activity: class AndroidWay extends Activity { TextView name; ImageView thumbnail; LocationManager loc; Drawable icon; String myName; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); name = (TextView) findViewById(R.id.name); thumbnail = (ImageView) findViewById(R.id.thumbnail); loc = (LocationManager) getSystemService(Activity.LOCATION_SERVICE); icon = getResources().getDrawable(R.drawable.icon); myName= getString(R.string.app_name); name.setText( Hello, + myName ); } } This example is 18 lines of code. If you're trying to read through onCreate(), you have to skip over 5 lines of boilerplate initialization to find the only one that really matters: name.setText(). And complex activities can end up with a lot more of this sort of initialization code. Compare this to the same app, written using RoboGuice: class RoboWay extends GuiceActivity { @InjectView(R.id.name) TextView name; @InjectView(R.id.thumbnail)ImageView thumbnail; @InjectResource(R.drawable.icon) Drawable icon; @InjectResource(R.string.app_name) String myName; @InjectLocationManager loc; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); name.setText( Hello, + myName ); } } In this example, onCreate() is much easier to take in at a glance. All the
[android-developers] Re: Announcing RoboGuice 1.0
I was thinking about using Guice myself before, but hesitated fearing to make the overall sluggishness of the platform even worse. How much of an overhead are talking about in terms of memory footprint and size of bundled libraries? Any noticeable impacts on speed or battery life? How often does Guice kick in in the background? I'm currently stepping back from overly abstract programming models on Android because of exactly these issues. On Mar 29, 8:53 pm, Michael Burton m...@niskala.org wrote: Hello Android developers, I'd like to announce the final release of RoboGuice 1.0! http://code.google.com/p/roboguice RoboGuice is a framework that brings the simplicity and ease of Dependency Injection to Android, using Google's own Guice library. If you've ever used Spring (the #1 enterprise framework on Java, now more popular than J2EE itself) or Guice, you already know how convenient this style of programming can be. To give you an idea, take a look at this simple example of a typical Android activity: class AndroidWay extends Activity { TextView name; ImageView thumbnail; LocationManager loc; Drawable icon; String myName; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); name = (TextView) findViewById(R.id.name); thumbnail = (ImageView) findViewById(R.id.thumbnail); loc = (LocationManager) getSystemService(Activity.LOCATION_SERVICE); icon = getResources().getDrawable(R.drawable.icon); myName = getString(R.string.app_name); name.setText( Hello, + myName ); } } This example is 18 lines of code. If you're trying to read through onCreate(), you have to skip over 5 lines of boilerplate initialization to find the only one that really matters: name.setText(). And complex activities can end up with a lot more of this sort of initialization code. Compare this to the same app, written using RoboGuice: class RoboWay extends GuiceActivity { @InjectView(R.id.name) TextView name; @InjectView(R.id.thumbnail) ImageView thumbnail; @InjectResource(R.drawable.icon) Drawable icon; @InjectResource(R.string.app_name) String myName; @Inject LocationManager loc; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); name.setText( Hello, + myName ); } } In this example, onCreate() is much easier to take in at a glance. All the platform boilerplate is stripped away and you're left with just your own app's business logic. Do you need a SystemService? Inject one. Do you need a View or Resource? Inject those, too, and RoboGuice will take care of the details. RoboGuice's goal is to make your code be about your app, rather than be about all the initialization and lifecycle code you typically have to maintain in Android. RoboGuice has been in development since August 2009, and 0.9 entered release candidacy in December and has been stabilizing ever since. After three months and a few finishing touches, we now believe it's ready to expose to a larger audience. We know that RoboGuice won't be for everybody. Although RoboGuice never prevents you from doing things the Android way, some people will still prefer seeing everything spelled out explicitly in their code. And other people who write extremely high performance applications such as games may not want to incur the small overhead imposed by yet another framework. But for people who want to build simple and straightforward code that's easily testable and easy to read, I encourage you to give RoboGuice a try. We hope you like it. Stop by our discussion forums if you'd like to have any help getting started. Cheers, Mike PS. We're beginning work on RoboGuice 1.1 now, which will include more injectible objects, better unit testing support, and hopefully some general usability improvements as well. I'd love to hear your thoughts on other things you'd like to see in the next release. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.