On Sun, Feb 8, 2009 at 6:02 AM, Stefan <skyntc...@gmail.com> wrote: > Building apps with the SDK is apparently NOT enough to insure API > compliance > as the example with the SlidingDrawer showed - the app was build with > the latest SDK > 1.0 r2 and without using reflection or any other "funky" access.
I have to say I am extremely surprised by this. When I look through the SDK documentation, I don't see a com.android.internal... package anywhere. It is the same tool that builds this documentation that also does the SDK library stripping, so it is very unlikely that it got included in the SDK library but wasn't exposed in the documentation. The only thing I can imagine is if it was -only- referenced through the layout XML file as <com.android.internal.widget.SlidingDrawer ...>, but the application never actually tried to use any of the Java APIs? That is certainly possible, because the layout file is parsed at runtime, on the real system library and not the stripped SDK version of it. If that is all that happened here, I don't think there is much more help we can give. It would mean that you indeed can not make use of any internal APIs from the SDK, but you can deliberately cause an internal class to be instantiated from XML. The latter to me is suffucient for the purpose of letting the developer know what they are getting in to -- writing <SlidingDrawer ...> vs. <com.android.internal.widget.SlidingDrawer ...> is a big, obvious difference, and if the developer is going to ignore what they are doing on the second one I think it is no longer the SDK environment's responsibility to protect them. :} > I firmly believe that we as developers, have the most vested interest > for our apps > to work on the widest possible range of API versions and device types > (Just wait until Android gets a "candy bar" style models > where users rely mostly keyboard for navigation. How many of the > apps > available today will still work flawlessly?). For the most part, if you design your app to work well with either the touch screen or the trackball in the G1, you should be in good shape here. This is one of the nice things about the G1's hardware design, it provides multiple ways of interacting with the UI. > If you put lots of time and effort to write your app, you want to > ensure that > you did not do (unknowingly) anything "stupid" to limit its use. > Even more you want to find as soon as possible all "stupid" things you > did and fix > them before they hit the end user. I am sure we all test our apps on > the emulator > and the G1 device we have, but can you be absolutely sure it will work > flawlessly on the next release (RC33.. Cupcake...)? If there are actual places where you can use internal Java APIs, we definitely want to hear about them (with sample code) to fix them. So far, I am not clear if that is what is going on here, or if it is just a matter of taking advantage of the layout file to access an internal class, which as I say is outside the bounds of what I think we can protect against. That said, I don't think we can make any assurances of an application working "flawlessly" on a platform update even if it completely sticks to the SDK. We are certainly going to do what we can to keep things working, and definitely don't want to just break things, but: (a) The platform code -is- changing and there can be situations where some select application is relying on some behavior that has changed, which may result in some issue for it. (b) In some very rare circumstances it may be necessary to change something for larger good of the platform, for example in Cupcake applications can't modify the "data roaming" setting so if someone is relying on that their call will no longer do anything (though we made sure to not through an exception and just crash the app). One other example I noticed - the text on the tab buttons - in RC30 > if it is longer - it wraps, in RC33 - the same text is displayed in a > "marquee"). > Is this an API change? While the tab text is probably not significant > issue, > it points that you really don't know about it until > you get the RC33 and realize that your UI may be a bit off here and > there. Yeah this was a change made for internationalization purposes, to make the tabs more flexible about the text in them so that localizing it wouldn't break the UI. While this is certainly a change in behavior, it is not clear whether this is really an API change or not. :) (Falls in my (a) category above.) This is also kind-of part of a larger issue we will all be dealing with, that as we move forward hardware vendors are going to want to customize the Android UI for their device. We need to be careful that this doesn't cause applications to break, but if you are using standard widgets you do need to do that with the expectation that you don't know -exactly- what you will get, but rather that your UI will match the UI of the rest of the device. > The truth is API changes happen - sometimes they are big and obvious, > sometimes > small and less obvious. In my opinion the smart thing to do is to give > developers > the information and tools to react to the changes and update our > applications as > soon as possible. If you've been following along since before 1.0, you've seen the SDK updates we've done as the platform has changed. There shouldn't be anything of that magnitude any more (we shouldn't be outright changing APIs and such), but there should continue to be that kind of information. I don't think there is an SDK yet for 1.1, but hopefully there will be one soon. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
