Dianne, talking about limitations, as a developer I'm not happy at all with the fact that Android does not support an official interface for reading SMS messages (simple, the ones that you've received and sent) and e-mails. I don't understand why the Android designers didn't include this in the official interface, because it is something extremely simple to do. A developer who is interested to write an app which works with SMS mesages and e-mails has to dig into the code of Android to find out how to do it. However, there is no backward compatibility guarantee in this approach. I don't know if iOS supports this, but my impression from discussion platforms is that many developers are interested in this functionality.
-Ali On May 26, 9:16 pm, Dianne Hackborn <[email protected]> wrote: > On Wed, May 25, 2011 at 9:39 PM, Chris Stratton <[email protected]> wrote: > > On Wednesday, May 25, 2011 6:14:55 PM UTC-4, Dianne Hackborn wrote: > > >> I'm still wondering what these "limiting decisions" are. > > > I find that surprising, considering the amount of time you spend explaining > > to people that the things they want to do are not possible, some because > > they are not yet supported and others because your team intentionally chose > > to preclude any means for a user to authorize an application to do that. > > Frankly I would agree some of the things people want to do are really bad > > ideas; but others a quite good ideas - the point is that this is a > > subjective decision. Your team made its choices, but a lot of people > > disagree with you about what should or shouldn't be allowed or supported, > > and Android has not in the past been readily suitable for doing things > > outside of it's architects' vision. Fortunately, the theoretical > > possibility of producing one's own build is increasingly becoming a > > well-organized reality of alternative distributions - changing "one little > > thing" no longer means going it alone. Projects that weren't worth doing > > when there was no base of devices capable of using them become worth doing > > when the installed base of alternative builds grows. > > I think you are using "limiting decisions" in a way different than DanH. > What you are talking about here a simply policy decisions about what > applications will be allowed to do. They are nothing the platform is tied > to -- they can always be changed in the next release if there is a > compelling reason to do so. (As I said, from a platform maintenance > perspective it is *much* easier to remove restrictions on what applications > can do than it is to enforce new ones.) > > The vast majority of limitations on applications (beyond what people coming > from desktop operating systems expect) are there either because there is a > compelling benefit for the overall platform or ecosystem for them to be > there, and/or there has not yet been time to design and implement a facility > for apps to use that is robust and maintainable for many years to come. > > But again, these have little do to with whether android has "legs" which was > the original point of discussion. > > Let's take one of the limitations that comes up -- being able to intercept > input events before they go to other applications. If we find ourselves in > a situation where another platform has such a facility, and has allowed some > developers to write extremely compelling applications that aren't possible > on android, and this is threatening android's viability in the market, it > would be fairly trivial to add such a facility to android. It was actually > much harder to design and implement android to have the restriction than to > not have it. > > That said, this is something we would 99% positively never just open up, > because it would have many negative impacts across the platform. > > And consider it from the other direction -- if your platform already allows > applications to freely intercept input events from other apps, and you find > this is actually harming your platform, how do you fix it? That's a > *really* hard problem, especially if you don't want to break a bunch of > third party apps. (And when it comes to third party apps, you will often > find them relying on this kind of stuff in places you never think they would > have.) > > In fact this has been an issue for Windows. For example to implement the > UAC dialog in a way that it can be sure the user is interacting with it and > not some app, one of the things it does is switch to a completely different > user environment in which the dialog is run, with a screenshot of the > previous screen shown behind it to make it feel more integrated. > > So Android can actually implement a much cleaner and integrated experience > with the user because of this limitation it places on apps. More than that, > *apps* themselves can implement such interactions with users. Thus, as not > infrequently happens, imposing a limitation on what applications can do > actually opens the door for other things. > > > I think we are coming out of the most limiting period as official builds > > are enhanced and alternative builds gain a following on a wide variety of > > devices, but a lot of things that we expected would be possible with a > > "pocket linux box" have historically not been possible with android devices, > > for reasons ranging from the java-apis-first decision to the inability of a > > user to alter the security model. > > Yes if you want Android to be a "pocket linux box," that is not what it is. > That really is a different product, and as the example I give above shows, > making such a product is most likely going to be done at the detriment to > many good things android provides. > > > It probably is worth looking at that subject of security for a minute. By > > not giving the user any real ability to customize or exert fine grained > > control, a given user cannot make their device less secure than the default, > > but neither can they make it any more secure than a default they may find > > quite inadequate. In an official build, I cannot for example decide that > > it's okay for an application to know if I am on the phone, but not okay for > > it to be able to discover my phone number. > > I certainly agree that this particular permission was poorly done. This is > a good example of where giving apps too much access bites us. I think there > has been some ongoing work to split those pieces of information apart, > because clearly access to personal information is a big and growing concern. > > These kinds of things have only served to reinforce my feeling that limiting > what applications as much as possible should be the first design priority. > :) > > -- > Dianne Hackborn > Android framework engineer > [email protected] > -- 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
