On 12 Jan., 09:12, Dianne Hackborn <[email protected]> wrote: > Many classes that are public make use of private classes for implementation. > That isn't a reason to make those other classes public.
Of course. I just meant in this case the public and private classes do share the problems. If one day you'll replace NumberPicker, wouldn't that also cause troubles to keep Date- and TimePicker compatible? > Sure and then we end up with crud in the API we can't get rid of. This is a > pretty trivial widget, and everyone has the source code to it; we aren't > going to junk up the API for this thing. Sure. If the "old crap" is only in apps which cloned it, you can savely remove it from the system core. I wouldn't like to drag along two similar, incompatible variants of widgets for the same purpose as well. Maybe I just underestimated the possible compatibility issues. My thoughts were along the lines "Range in, number out - there's no complicated interface. And a wheel like the one posted above could easily fit the current widget size." But I don't know what you've got in mind for future implementations... Anyway. You've done so many good extensions in the past, I'm positive you'll find a good solution with an upcoming update. -- 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
