Re: [roboguice] Making third-party Android libraries cooperate better with each other
Craig Andrews
https://ormlite.svn.sourceforge.net/svnroot/ormlite/ormlite-android/trunk/src/main/java/com/j256/ormlite/android/apptools/OrmLiteBaseActivity.java
I CC'ed the OrmLite Android list - perhaps that project would be
interested in collaborating on this solution as well.
~Craig
> Theoretically, perhaps. In practice, none of these seem particularly
> complex:
>
> https://github.com/JakeWharton/ActionBarSherlock/blob/master/library/src/com/actionbarsherlock/app/SherlockActivity.java
> http://code.google.com/p/roboguice/source/browse/roboguice/src/main/java/roboguice/activity/RoboFragmentActivity.java
> https://github.com/cyrilmottier/GreenDroid/blob/master/GreenDroid/src/greendroid/app/GDActivity.java
>
> The idea would be that yes, if they wanted to continue to support their
> own base activity, the burden would be on them, but migration to a
> delegate would, as much as possible, be a straight port. A little
> duplication is probably worth the pain if it reduces the integration
> nightmare in other respects (which is what this idea as a whole is
> intended to address).
>
> --Andy
>
>
> On Wednesday, April 18, 2012 at 1:40 PM, Cherry Development wrote:
>
>> I think regardless of how this is done, it would be difficult for
>> library authors to be compatible with both a self-contained and
>> delegate-based approach since some of their code is (likely) going to
>> rely on concrete subclasses while other code to support a delegate-based
>> would rely on another mechanism. If this could be done right, there's no
>> reason why library authors couldn't just require it. I just worry that a
>> library author trying to implement both approaches would end up with a
>> lot of duplicated and difficult-to-maintain code, basically shifting the
>> basic problem from the end-developer to the library.
>>
>> Otherwise, I agree with Andrew's criteria.
>>
>> The issue with resources is one for the libraries themselves to deal
>> with, but shouldn't involve the delegation layer. I agree that Android
>> libraries currently really suck in Maven + Eclipse.
>>
>> On 2012-04-18, at 1:31 PM, Michael Burton wrote:
>>
>> > I agree, I think this is a simple enough solution that it shouldn't
>> need to depend on contentproviders, manifests, or really anything
>> particularly android specific at all. I agree with all of Andrew's
>> criteria below, and the only one I'd add is the one I mentioned
>> previously about being able to use RoboGuice/ActionBarSherlock without
>> requiring an additional dependency.
>> >
>> > Actually, I lied, I'd add one more requirement, which is that it be
>> simple for library authors to implement. The easier it is to
>> implement, the easier the adoption path will be, which will benefit
>> everyone.
>> >
>> > --
>> > http://about.me/michaelburton
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Apr 18, 2012, at 1:24 PM, Andrew Toulouse wrote:
>> >
>> > > I disagree with both approaches. The EventManager functionality is
>> nifty, but the functionality seems just magical enough to
>> sufficiently confound straightforward reasoning about the code when
>> debugging. Adding an annotation to a method somewhere that observes
>> events is too implicit, in my opinion, and the not sufficiently
>> connected to implementation for someone to be clued in by searching
>> for the activity class (and finding a module) or locating the
>> interface and discovering its use that way. Admittedly, I don't have
>> as much testing experience as I would like, but I think that it's
>> likely that substituting an activity extension with a mocked one may
>> be confusing if the interface to an extension is not made explicit.
>> > >
>> > > Additionally, I think that the functionality would ideally:
>> > > 1) Require no declarations in the AndroidManifest.xml.
>> > > 2) Not require any Android resources in its own package. Depending
>> on an Android library is still much harder than depending on a jar
>> for many workflows. It really sucks in maven.
>> > > 3) Offer a clear migration path to those with their own substantial
>> base classes to migrate, i.e. allow custom Activity classes to add
>> support for pluggability.
>> > > 4) Allow plugins to be implemented in a type-safe manner.
>> > > 5) Be easy to follow when debugging.
>> > >
>> > >
>> > > --Andy
>> > >
>> > > On Wednesday, April 18, 2012 at 1:01 PM, Macarse wrote:
>> > >
>> > > > Michael talked about this over Twitter.
>> > > >
>> > > > I feel the best way to do this kind of things in Android is
>> providing
>> > > > an android library with a content provider.
>> > > >
>> > > > There I would place the logic to notify.
>> > > >
>> > > > On Wed, Apr 18, 2012 at 4:54 PM, Cherry Development
>> <cher...@gmail.com (mailto:cher...@gmail.com)> wrote:
>> > > > > Well, why don't we all continue to talk about it, then?
>> > > > >
>> > > > > What sort of design have you envisioned for this?
>> > > > >
>> > > > > On 2012-04-18, at 12:20 PM, Michael Burton wrote:
>> > > > >
>> > > > > > This is something that Jake Wharton (ActionBarSherlock) and I
>> have been talking about and bounced around, but haven't gained
>> traction on yet. I definitely support the general idea.
>> > > > > >
>> > > > > > My initial thinking was to do something similar to the
>> EventManager in RG, and allow subclasses to subscribe to pre-
>> and post- events for all the standard Activity and Service
>> methods. I also want RG (and ActionBarSherlock) to be
>> standalone and work without requiring an additional
>> dependency, but to allow users who need this kind of
>> interoperability to include an optional jar that would provide
>> this capability.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > http://about.me/michaelburton
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Apr 18, 2012, at 11:44 AM, Andrew Toulouse wrote:
>> > > > > >
>> > > > > > > Oops, added a "not" there. Meant "It sounds a bit repetitive
>> and tedious, though, since it requires both an annotation
>> and a custom interface definition that matches 1:1."
>> > > > > > >
>> > > > > > > --Andy
>> > > > > > >
>> > > > > > > On Wednesday, April 18, 2012 at 11:41 AM, Andrew Toulouse
>> wrote:
>> > > > > > >
>> > > > > > > > Possibly. It sounds a bit repetitive and tedious, though,
>> since it requires not both an annotation and a custom
>> interface definition that matches 1:1. And how does
>> testing fit with this? Perhaps a configuration module not
>> unlike Guice's makes sense:
>> > > > > > > >
>> > > > > > > > // Executed in this order
>> > > > > > > > hook(RoboGuiceDelegate.class).into(MyBaseActivity.class);
>> > > > > > > > hook(SherlockDelegate.class).into(MyBaseActivity.class);
>> > > > > > > >
>> > > > > > > > // Had to subclass someone else's activity, but added
>> extension support on our own subclass of it
>> > > > > > > > hook(SherlockDelegate.class.into(SomeOtherActivity.class);
>> > > > > > > >
>> > > > > > > > // Fragments
>> > > > > > > > hook(FragmentDelegate.class).into(MyBaseFragment.class);
>> > > > > > > >
>> > > > > > > > where the Activity classes implement an interface that
>> allows extensions to hook in. For activities which can't
>> be modified but can be subclassed, one could implement
>> their own API support as necessary.
>> > > > > > > >
>> > > > > > > > public interface PluggableActivity {
>> > > > > > > > runOnCreateHooks();
>> > > > > > > > runOnStartHooks();
>> > > > > > > > etc...
>> > > > > > > > }
>> > > > > > > >
>> > > > > > > > public interface PluggableFragment {
>> > > > > > > > runOnActivityCreatedHooks();
>> > > > > > > > etc...
>> > > > > > > > }
>> > > > > > > >
>> > > > > > > > This also means that the library wouldn't have to rely on
>> the android support library.
>> > > > > > > >
>> > > > > > > > --Andy
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > You received this message because you are subscribed to the
>> Google Groups "roboguice" group.
>> > > > > > > To post to this group, send email to
>> robo...@googlegroups.com
>> (mailto:robo...@googlegroups.com).
>> > > > > > > To unsubscribe from this group, send email to
>> roboguice+...@googlegroups.com
>> (mailto:roboguice+...@googlegroups.com).
>> > > > > > > For more options, visit this group at
>> http://groups.google.com/group/roboguice?hl=en.
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > You received this message because you are subscribed to the
>> Google Groups "roboguice" group.
>> > > > > > To post to this group, send email to
>> robo...@googlegroups.com
>> (mailto:robo...@googlegroups.com).
>> > > > > > To unsubscribe from this group, send email to
>> roboguice+...@googlegroups.com
>> (mailto:roboguice+...@googlegroups.com).
>> > > > > > For more options, visit this group at
>> http://groups.google.com/group/roboguice?hl=en.
>> > > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > You received this message because you are subscribed to the
>> Google Groups "roboguice" group.
>> > > > > To post to this group, send email to robo...@googlegroups.com
>> (mailto:robo...@googlegroups.com).
>> > > > > To unsubscribe from this group, send email to
>> roboguice+...@googlegroups.com
>> (mailto:roboguice+...@googlegroups.com).
>> > > > > For more options, visit this group at
>> http://groups.google.com/group/roboguice?hl=en.
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > You received this message because you are subscribed to the Google
>> Groups "roboguice" group.
>> > > > To post to this group, send email to robo...@googlegroups.com
>> (mailto:robo...@googlegroups.com).
>> > > > To unsubscribe from this group, send email to
>> roboguice+...@googlegroups.com
>> (mailto:roboguice+...@googlegroups.com).
>> > > > For more options, visit this group at
>> http://groups.google.com/group/roboguice?hl=en.
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > You received this message because you are subscribed to the Google
>> Groups "roboguice" group.
>> > > To post to this group, send email to robo...@googlegroups.com
>> (mailto:robo...@googlegroups.com).
>> > > To unsubscribe from this group, send email to
>> roboguice+...@googlegroups.com
>> (mailto:roboguice+...@googlegroups.com).
>> > > For more options, visit this group at
>> http://groups.google.com/group/roboguice?hl=en.
>> > >
>> >
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "roboguice" group.
>> > To post to this group, send email to robo...@googlegroups.com
>> (mailto:robo...@googlegroups.com).
>> > To unsubscribe from this group, send email to
>> roboguice+...@googlegroups.com
>> (mailto:roboguice+...@googlegroups.com).
>> > For more options, visit this group at
>> http://groups.google.com/group/roboguice?hl=en.
>> >
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "roboguice" group.
>> To post to this group, send email to robo...@googlegroups.com
>> (mailto:robo...@googlegroups.com).
>> To unsubscribe from this group, send email to
>> roboguice+...@googlegroups.com
>> (mailto:roboguice+...@googlegroups.com).
>> For more options, visit this group at
>> http://groups.google.com/group/roboguice?hl=en.
>>
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "roboguice" group.
> To post to this group, send email to robo...@googlegroups.com.
> To unsubscribe from this group, send email to
> roboguice+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/roboguice?hl=en.
>
>