That there will be a new API is good news -- I think. The reason I say "I think" is because already, in the link you give, I am seeing the carelessness of phrasing in the documentation that usually ends up encouraging developers and OEMs to make a hash out of things -- just like they did in the API this new one replaces!
So please, please assert your considerable influence to quash such horrible wording as "Check the mounted path of an Opaque Binary Blob (OBB) file." Check the mounted path for WHAT? That phrasing is more opaque than the binary blob could be:( For that matter, once again, the name of the API itself implies it should have very different function. Rather than CHECK something, it should simply RETURN the path, but either returning null or throwing an exception if the path does not exist. And in fact, the detailed description says something closer to this, although it still does not say what exceptions can result in null, nor what is 'checked' for. Does it only check to make sure there is something at the path, or does it actually check the filesystem for consistency? If not, shouldn't there be an API to do this? For that matter, should it return the path, or the full form of the filename, including the path? Again, from the name, I would assume it really means only the path, so that the user will then append the filename as needed. But looking at the rest of the API, it seems to be more logical to return the complete filename, including path, a.k.a. "path to the file", which file IS the binary blob. And again: if we are going to say "OBBs contain filesystems", then that verb 'contain' should be reflected in the rest of the API: instead of mounting the OBB, the API should offer to mount the filesystem(s) contained in the blob. But no! Instead, 'mountObb' offers to mount a -file-. 'unmountObb' does the same thing. Linux 'mount', after all, mounts filesystems (found on devices) on mount points in directories, referred to as 'pathnames', (not as files) in the man page. For that matter, even what it means by 'internals of the OBB' is too vague: when I think of "internals of a filesystem", (recall that it is a filesystem we are promised OBBs contain), I think not of open/read/ write/close operations, but of inodes and the like. But I think the doc really means to say something else, such as that once "/.../ MyBlob" is mounted, I can do open/read/close on MyBlob and get the 'internals' of the blob, i.e., the raw binary data. Otherwise there is a glaring omission in the API: no way to actually USE the data in the blob! I know you said it was just "ongoing work", but... I know to many these will sound like trifling quibbles, but fixing the wording on such issues can save many man-months around the world when you consider how many people will be trying to read these things. BTW: the API says the client programmer can pass a key for encryption to mountObb, but where is it specified how the filesystem will recognize the format of the key, or how to use it in the encryption? Will this really be left up entirely to the OBB implementer? That sounds risky. As for the drama on changing getOrientation to getRotation, I see the former is since API level 1, the latter level 8. That gave people an awfully long time to get use to getOrientation, warts and all, so of course they felt uncomfortable with the change -- even though it was an improvement. So yes, I can see how there would have been drama there -- and not the good kind:( On Mar 1, 9:56 am, Dianne Hackborn <[email protected]> wrote: > There will be a new API, but it is part of larger ongoing work for managing > storage which is starting to appear > here:http://developer.android.com/reference/android/os/storage/StorageMana... > > We want this one to be right, though, so it will be a bit for it to be > available. > > I do agree that renaming APIs is the right thing to do in such situations. > See for example my renaming of Display.getOrientation() to > Display.getRotation()... and the drama that ensued. :) > > On Tue, Mar 1, 2011 at 9:47 AM, Indicator Veritatis <[email protected]>wrote: > > > > > > > > > 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 <[email protected]> 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 <[email protected] > > >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 <[email protected]> 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 < > > [email protected] > > > > >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 <[email protected]> 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 < > > > > [email protected] > > > > > > >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 <[email protected]> > > wrote: > > > > > > > > > On Fri, Feb 25, 2011 at 8:31 PM, Dimitry Golubovsky < > > > > > > > > [email protected]>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 > > > > > > > > > [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 > > > > > > > > -- > > > > > > > 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 > > > > > > -- > > > > > 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 > > > > -- > > > 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 > > ... > > read more » -- 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
