On Wed, Jan 12, 2011 at 11:33 PM, mort <[email protected]> wrote: > 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? >
No the point is that if the NumberPicker API changes, it won't break apps, and the code built into the framework can be changed at that point to use the new APIs. > 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... > Nor do I, but I do know the current UI and design completely sucks, so it is best not to commit to what is there. -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
