I don't know what features are planned or contemplated beyond what Neil mentioned, but could the use of sub-interfaces help? For example, Neil's feature (+1 BTW) might use a PlaceAwareActivity which extends Activity? AbstractActivity can potentially implement them all new sub-interfaces.
The downside being that other framework classes, such as ActivityManager would be littered with instanceof checks. - Amir On Fri, Dec 3, 2010 at 12:18 PM, Ray Ryan <rj...@google.com> wrote: > Patrick, you're the case in point. Because you don't use the abstract > class, if we change the API later we will break your app. > > Were you unable to use the abstract class? If the Activity interface were > documented to encourage you to do so, would you have? When we break your > app, will you be okay with that? > > > On Fri, Dec 3, 2010 at 12:13 PM, Patrick Julien <pjul...@gmail.com> wrote: > >> This is more in line with what we're doing. With what we experienced >> with the ramp up to 2.1.0, we only use the Activity interface, we >> don't use the default implementation and instead make our own for >> common classes of use cases. >> >> >> On Fri, Dec 3, 2010 at 3:02 PM, John Tamplin <j...@google.com> wrote: >> > On Fri, Dec 3, 2010 at 2:58 PM, Patrick Julien <pjul...@gmail.com> >> wrote: >> >> >> >> I don't know since I don't know what your plans are, will just have to >> >> trust you. >> >> >> >> That being said, the Activity interface is currently really nice and >> >> it doesn't tie us down to a single class for inheritance. >> > >> > I have been very happy with the recent cases where I have used an >> interface >> > for the API but provided a default implementation, with the admonishment >> > that implementing the interface without extending the default >> implementation >> > is likely to be broken in the future. That way the people that care >> more >> > about being able to substitute alternate implementations or to use it >> > without having to extend the implementation can implement the interface, >> and >> > those that care more about not being broken by future updates can extend >> the >> > default implementation. >> > -- >> > John A. Tamplin >> > Software Engineer (GWT), Google >> > >> > -- >> > http://groups.google.com/group/Google-Web-Toolkit-Contributors >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
