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
-~----------~----~----~----~------~----~------~--~---

Reply via email to