> Are you sure that any of the old interfaces does not refer to one of the new
> one(s) (indirectly)?
> If you're sure that Foo2 (as an example) is entirely self-contained not
> referred to by any other 'old' interface/class in Interface.jar, then you
> should not have any problems.
I'm not sure what you mean by Foo2 being entirely self-contained.
Just to be clearer about what I mean by extending my interface, here
is a more concrete example:
In, say, version 1.0 of my plug-in, I release something like this. In
interface.jar:
public interface Foo
{
public void someMethod();
}
And, in implementation.jar:
public class FooImpl implements Foo
{
public void someMethod() { ... }
}
Later, in version 2.0, I want to expose new functionality that new
clients can use. So, I add this to interface.jar:
public interface Foo2 extends Foo
{
public void anotherMethod();
}
And change implementation.jar to this:
public class FooImpl implements Foo2
{
public void someMethod() { ... }
public void anotherMethod() { ... }
}
So, I would like older clients that only know about version 1.0 of my
plugin to be able to take version 2.0 of implementation.jar,
instantiate an instance of FooImpl using reflection, and cast it to a
Foo. Newer clients would cast that object to a Foo2 and use the new
functionality. Since FooImpl now implements both interfaces, both
should work. But I am stuck because if I compile the Foo and Foo2
interfaces into clients and implementation.jar, I get the Dalvik VM
error I mentioned earlier. But if I don't compile them in, then older
clients won't be able to instantiate an object of type FooImpl because
the definition of Foo2 will not exist.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
