Your frank admission that the API is poorly named is valuable. And your wording of it here is much, much better than the wording in the doc (at the link you gave). For the wording in the doc suffers from trying to cover up the embarrassment they should feel at such a divergence between name and meaning:(
When the divergence gets this bad, sometimes people will simply create a new API whose name reflects its function better, and deprecate the old one. I wish that course had been taken here, though I admit that even after reading your post, I am not 100% certain that that really is the best course of action. I am sure it was at least mentioned when the problem was discussed internally. But since that option was not taken, the same question is going to be asked over and over again, so I hope you will get tired of adding "Don't get stuck on the name", especially when it is exactly the opposite of "what it is supposed to mean";) Names have meanings, after all, or we would not use them. On Feb 28, 5:05 pm, Dianne Hackborn <hack...@android.com> wrote: > The API at this point is very poorly named -- it makes perfect sense for the > original device configurations where all media storage was on the external > SD card. When manufacturers started putting that storage into the internal > device, the name became unfortunate. Don't get stuck on the name, just what > it is supposed to mean. > > This is explained in the doc: > > http://developer.android.com/reference/android/os/Environment.html#ge...() > > And this was the first step of complexity on that name: > > http://developer.android.com/reference/android/os/Environment.html#is...() > > And Android 3.0 introduces even more fun: > > http://developer.android.com/reference/android/os/Environment.html#is...() > > On Mon, Feb 28, 2011 at 2:13 PM, Indicator Veritatis <mej1...@yahoo.com>wrote: > > > Is it a typo is the CDD requirement really this backwards? You say: > > > The current CDD requires that the API return the directory of the > > primary > > "external" storage, that is the one you can count on always being > > there, > > that is the internal storage partition of such devices. > > > So the API named EXTERNAL storage is required to return the "INTERNAL > > storage partition"! > > > Sounds pretty contradictory to me. > > > On Feb 28, 7:23 pm, Dianne Hackborn <hack...@android.com> wrote: > > > The current CDD requires that the API return the directory of the primary > > > "external" storage, that is the one you can count on always being there, > > > that is the internal storage partition of such devices. The very first > > > devices that introduced multiple storage areas caught us a bit by > > surprise, > > > implemented this in a broken way (leaving the code to return the SD card > > > storage which was actually shipped without a card on those devices), and > > the > > > CDD has since been clarified about how the device needs to behave. > > > > On Mon, Feb 28, 2011 at 9:25 AM, Indicator Veritatis <mej1...@yahoo.com > > >wrote: > > > > > Dianne rightly observes: "The platform really needs to define a good > > > > UX story around this before just > > > > throwing APIs at developers. " > > > > > Which would be a lot easier to do if OEMs would insist on a good UX > > > > story also before implementing bizarro features like two SD cards! > > > > Unfortunately, their history of failing to do this extends to long > > > > before the beginning of Android. > > > > > But I still see no answer to the question: do such devices, for having > > > > such a non-standard configuration, fail CDD and therefore are not on > > > > the Market? I am sure such info would still be useful for the OP. > > > > > On Feb 26, 4:32 pm, Dianne Hackborn <hack...@android.com> wrote: > > > > > It returns the main partition, that you can count on being populated; > > for > > > > a > > > > > device with a built-in USB mass storage and an external SD card it > > will > > > > > return the built-in one. > > > > > > Android does not yet define the behavior for dealing with multiple SD > > > > cards. > > > > > Devices that use that configuration are outside of the core > > platform, > > > > and > > > > > should provide their own mechanism for them if they want -- such as a > > > > shared > > > > > library to find out about the secondary storage. > > > > > > The platform really needs to define a good UX story around this > > before > > > > just > > > > > throwing APIs at developers. > > > > > > On Sat, Feb 26, 2011 at 4:11 PM, Indicator Veritatis < > > mej1...@yahoo.com > > > > >wrote: > > > > > > > What does this API do on a phone that has two SD cards? Does it > > just > > > > > > pick only one of them? Or do all such devices fail CDD and so are > > not > > > > > > on the Google Android Market? > > > > > > > On Feb 26, 3:41 pm, Dianne Hackborn <hack...@android.com> wrote: > > > > > > > On Fri, Feb 25, 2011 at 8:31 PM, Dimitry Golubovsky < > > > > > > golubov...@gmail.com>wrote: > > > > > > > > > I am not worried about Market at all. I am worried about the > > > > portable > > > > > > > > way to tell my program where is the sdcard root directory is > > > > mounted > > > > > > > > because part of the usage scenario is user being able to upload > > > > > > > > certain files to sdcard where my program must be able to find > > them. > > > > > > > > > To clarify, this is a port of Squeak (Smalltalk) [1], [2] to > > > > Android > > > > > > > > which I am trying to alter to fit my needs; in particular the > > > > original > > > > > > > > port loaded the image from assets, but I would like to be able > > to > > > > load > > > > > > > > it from sdcard where user may place it after customization > > using an > > > > > > > > instance of Squeak on user's PC. > > > > > > > > The correct way to do this is > > > > Environment.getExternalStorageDirectory(). > > > > > > > > If you want to make your application work on an incompatible > > device > > > > that > > > > > > has > > > > > > > this API broken, you will need to write code specifically for > > that > > > > > > device. > > > > > > > There is no magical solution that makes your app work regardless > > of > > > > what > > > > > > > someone has done to Android. > > > > > > > > -- > > > > > > > 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, 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 > > > > 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 > > > > > > -- > > > > > 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, 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 > > 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 > > > > -- > > > 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, 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 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 > > -- > 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, 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 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
