A private API does not necessarily mean the class or method has the "private" Java keyword on it. Actually there are many Java-public classes and methods that are part of the private APIs. Normally these are stripped from the SDK. I don't know why the internal package is still in the SDK but indeed, the internal name of the package is a good indication that this is not a public API.
Again there is no need for an API checking tool in the SDK because the SDK itself *is* the API checking tool. Apparently we just let a few things slip and we need to fix them. We also perfectly agree that you should get a detailed changelog with the new SDK. Such a changelog should NOT, however, include changes about anything private and/or internal. On Sun, Feb 8, 2009 at 4:52 AM, Stefan <[email protected]> wrote: > > Dianne, > > In this particular case, the SlidingDrawer class is not "private", it > is "public" but it is in the > "package com.android.internal.widget" package. This ".internal." (and > the lack of official documentation on it) is the only clue you get > that this class is probably not intended to be used directly. > > (I come from the world of Windows Mobile development where it is to a > large degree "a custom" to rely on some undocumented APIs to do what > you want to do, so that made me take that gamble, which in my case did > not pay of) > > I actually did something similar to what you suggest - as my app was > already built around it - I end up creating my own implementation for > the SlidingDrawer - this way I know it will work with RC30, RC33 and > probably Cupcake. > > I have to admit, the fact that the Android is an open source OS and we > have at all access the the source code to learn and diagnose issues, > is like a breath of fresh air after having to deal for many years in > the proprietary Windows world. > > My only suggestion is that at least for the official releases RC30, > RC33 etc. that are being "pushed" to the end users - give us a way to > find what has changed in the APIs and what bugs have been fixed. I > simple change list will do, or an API checking tool or whatever other > means that you can think of. > > > > > On Feb 7, 10:48 pm, Dianne Hackborn <[email protected]> wrote: >> When a new SDK is posted, there is a complete API diff and overview of the >> changes. However, there is very little change to the platform APIs in 1.1, >> so there isn't much to say about this one. I'm not sure when an SDK for it >> will be available. >> >> Also, out of curiosity, how did you go about using the private class? If >> you are actually using the SDK, you shouldn't be able to use any of the >> private classes, just to protect people from accidentally using things that >> will break on them. >> >> Finally, if there is a class like this in the internal implementation that >> you really want to use, just copy it out and build the copy in to your own >> code. That way your code won't break when the system changes. >> >> >> >> On Sat, Feb 7, 2009 at 4:10 PM, Stefan <[email protected]> wrote: >> >> > Yes, I do agree that relying on private APIs is dangerous and should >> > be avoided for all the reasons you mention. >> >> > (The only reason I posted my findings is to save somebody the >> > debugging time as it was not obvious what was the reason at first) >> >> > This brings another related question. Is there a single place where we >> > as developers can see what has changed between the public releases of >> > the API's for example from RC30 => RC33? - (preferably both internal >> > and external changes)? >> >> > The only thing I could find is that RC33 has fixed several bugs and >> > added several features, but nothing specific about what has changed >> > and what bugs have been fixed. >> >> > Stefan >> >> > On Feb 7, 6:21 pm, Jean-Baptiste Queru <[email protected]> wrote: >> > > Even worse, it hurts the entire ecosystem, by making users believe >> > > that plaftorm upgrades have bugs when in fact the applications are >> > > broken to start with. >> >> > > JBQ >> >> > > On Sat, Feb 7, 2009 at 3:18 PM, Romain Guy <[email protected]> wrote: >> > > > That means your app will break in cupcake though. >> >> > > > Please, please don't use private APIs, it only hurts the users :( >> >> > > > On Feb 7, 2009 1:43 PM, "Stefan" <[email protected]> wrote: >> >> > > > After digging a bit around in the source code, it looks like the >> > > > namespace used for the attributes of the "internal" widgets has >> > > > changed in RC33 from xmlns:android=" >> >http://schemas.android.com/apk/res/ >> > > > android" to some other namespace >> > > > (probably something likehttp:// >> > schemas.android.com/apk/res/android.intenral >> > > > ??) and that caused the SlidingDrawer to not >> > > > find its attributes. >> >> > > > Well... one should never rely on internal classes, but... the >> > > > SlidingDrawer is actually so useful... >> > > > I am glad it will make it as an officially supported class. >> >> > > > On Feb 7, 4:34 pm, Romain Guy <[email protected]> wrote: > Even >> > worse, >> > > > SlidingDrawer will move ... >> >> > > >> On Sat, Feb 7, 2009 at 12:14 PM, Jean-Baptiste Queru < >> > [email protected]> >> > > >> wrote: > > > Oh, ah, I had... >> >> > > >> > On Sat, Feb 7, 2009 at 11:28 AM, Romain Guy <[email protected]> >> > > >> > wrote: > > >> No, SlidingDraw... >> >> > > >> >> On Sat, Feb 7, 2009 at 7:18 AM, Jean-Baptiste Queru < >> > [email protected]> >> > > >> >> wrote: >> >> > > >> >>> Can you please report this issue >> > > >> >>> inhttp://b.android.com/?(a<http://b.android.com/?%28a>plain >> >> > > >> >>> copy-paste will do). > > >>> Thanks, > >>> JBQ > >> >> > > >> >>> On Sat, Feb 7, 2009 at 6:54 AM, Stefan <[email protected]> >> > wrote: > >> > > >> >>> > >>>> It appears that ... >> >> > > >> >> [email protected] >> >> > > >> > >> Note: please don't send private questions to me, as I don't have >> > time >> > > >> > >> > >> to provide private... >> >> > > >> Romain Guy > Android framework engineer >> >> > > >> [email protected] >> >> > > >> > Note: please don't send private questions to me, as I don't have >> > time > >> > > >> > to provide private suppo... >> >> > > -- >> > > Jean-Baptiste M. "JBQ" Queru >> > > Android Engineer, Google. >> >> -- >> 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. All such questions should be posted on public >> forums, where I and others can see and answer them. > > > -- Romain Guy Android framework engineer [email protected] 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 [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 -~----------~----~----~----~------~----~------~--~---
