Marc,
I apologize again for your issues but we always, at least I believe we did on the mailing lists, made clear that the public APIs would not be frozen until the Android SDK 1.0. We actually changed many thins from M3 to M5 then from M5 to 0.9. It should not be surprising that the same thing happened in 1.0. Like I mentionned earlier we'd rather remove features that we don't feel are ready rather than indefinitely support them. That does NOT mean these features won't come back. I also worked with the JDK since 1.0.2 (and I actually even worked on the JDK at Sun :) and I know that deprecating APIs is not always the best option *especially* before the project even reaches 1.0. I reiterate what I said: please send us your feedback, open bugs and feature requests. But the android sdk was, until 1.0, published as a developer preview. We know how difficult it was for all of you to follow our API changes but we did it to offer the best 1.0 APIs we could without hindering Android's future. Now that 1.0 is out, we are committed to backward binary compatibility (note that I said "binary," not "source"). On Nov 16, 2008 3:28 PM, "Marc" <[EMAIL PROTECTED]> wrote: 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... > Android Training on the Ranch! -- Mar 16-20, 2009 http://www.bignerdranch.com/schedule.shtml --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subs... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---