Hi Mark, Sorry if I do sound a bit harsh, but I'm really very disappointed.
Of course a lot if possible, if you are ready to spend the efforts, the money, the collaboration required. But the whole point why I took the Android path about 6 months ago was that it was advertised and marketed to be different here. (I can forward you a hadfull of links that are still out there (from Feb this year) that still, today advertise exactly this.) I am not saying that Android is not open. I'm saying that it NOT as open as was advertised, and key stuff (at least in the area that was key for me) that was still made available to the public with the previous (prior to sdk 1.0) version of the API is simply gone today. You don't do that, not if you attract developers from all over the world like google did. You make stuff deprecated, you give people time to adjust, you propose alternatives (workable alternatives) or you give people enough notice. But you do NOT from 1 day to the other remove key elements from your api like google (or android) just did with their SDK 1.0. And most importantly, you do communicate about your intentions, about the strategy. You communicate about the fact that the APIs will change and that areas like Telephony, messaging etc are likely to become restricted. You don't leave your customers in the dark and then put them in fron of the "fait accompli" with the release of the first hardware device. You understand that you do have your reasons, and I am sure you guys do, but you're not alone out here. If you advertise and publish information to the public, then you cannot 3 months later change your mind, and simply remove public interfaces or change the qualifers of your classes that destroy your customer's work. I am sorry, but there is no excuse for this. I have never ever seen this in the Java JDK, why there is this thing called depreciation. I have been developing enterprise applications and complex technical frameworks in C++ and Java since Jdk 1.0!, and I have never had any similar experience. Sorry, but this is a fact. - why my frustration. And I know that the toughest challenge is to guarantee backward compatibility. And if you have to break it, then you supply tools, code generators, you name it, in order for your customers to be able to follow. Simple question: android.provider.Telephony is gone. How do I replace it in my source code in order to be able to ship my application so that it works on off-the-shelf phones. in a month from now? I'm serious, if I'm wrong, and if there are ways, why not openly explain me here? I don't know the answer. How do I tell my customer to "disable" the core contact application once they have installed mine, since removing it is not possible? (My business case expects it to be removed or at least "disabled" without a quick re-activation option) Of course, I can create my own distribution, and change the source- code of the core androis libraries to make it do exactly what I want, and get into the partnership with a device producer like you suggest in order for them to ship my distribution :-) (I have by the way modified the SDK 1.0 source-code and managed to get my stuff to work, but it just works on my impelementation, and there is no way I'll be able to sell this to the public now. And I don't have the critical mass to contact a major corporation in order to ship something different from the core android platform, simply because I do have a much better set of small "core" applications. Please remain realistic. Android is more open then the Microsoft and Apple alternatives, and most if not all other proprietary mobile phone operating systems. And? your point? And that's ok, because everybody knows this, and they don't advertise it otherwise. I would never have started my project on any of their platforms, simply because it wouldn't have made sense from day one. - So no deception, no disappointment, simply not possible. And that is all I'm asking for (or would have wanted to know from the beginning from Android) don't promise the world, and then deliver part of it (which looked promising) and later turn around and start closing doors, simply because it might not be maintainable in the future.... but don't tell your customers until it's too late. Please revert, cheers, Marc. P.S. This is not personal, and I would really love anyone out here to prove me that I'm wrong, because that would allow me to save my project and the many weeks of development that went into it. On 16 nov, 23:02, Mark Murphy <[EMAIL PROTECTED]> wrote: > Marc wrote: > > Android is NOT the open platform as was once advertised > > Sure it is. Open does not mean easy, however. > > > Not only can you not replace core applications > > 1. You can take the SDK-level approach that Mr. Guy described > > 2. You can contribute your modifications to core applications as patches > to the OS > > 3. You can put your alternate versions of the core applications into > your own firmware and distribute that firmware through hardware > manufacturers > > 4. You can contribute patches to the OS that enable the hooks you need > to add your desired functionality to the existing core applications > > 5. You can contribute patches to the OS that allow you to replace the > core applications outright > > Does this combination of options cover every possible desired means of > deployment? No. > > Do some of these require cooperation with the core Android team? Yes. > > Do some of these require more time and more work? Yes. > > However, while this battery of solutions may not fit your particular > commercial aims, that does not mean that Android is not open. In fact, > most of these options are impossible for other major mobile device > platforms, because Android *is* open while others are less open. > > Open is not a binary state; rather, there is a spectrum of openness. > Android is more open than the alternatives. There are ways in which > Android could be yet more open, and it is only with time and hard work > that we will be able to push Android further in that direction. > > > that's what happens if you put trust in the open-source community. > > And your proof of this assertion is...what, exactly? > > > At least with Microsoft or Apple, you know what you can and cannot do, > > you take it or leave it, but you don't get screwed. > > I suspect there are many, myself included, who do not give Microsoft and > Apple the benefit of the doubt that you appear to. In my case, it's from > a quarter-century of development experience, including with technologies > from both of the firms you cite. > > > All you people who read this, go somewhere else, and don't waste your > > time and money on Android. It's dead before it ever came to life... > > You are certainly welcome to your opinions. > > -- > Mark Murphy (a Commons Guy)http://commonsware.com > > Android Training on the Ranch! -- Mar 16-20, > 2009http://www.bignerdranch.com/schedule.shtml --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
