Hi Dianne and anyone else who might care about this, I'm a little (ok, more than a little) disappointed regarding RC33 and the lack of communicating UI look/behavior changes to developers. The specific reason is that RC33 seems to also have one more UI change - Dialog titles can't be longer than 2 lines. The change itself is reasonable and I'm fine with it but the problem is that I'm finding out about this change by an email from a US user of my app who said he can't read the text of some Dialogs. For him (and all other US users who have received the update), my app suddenly broke after he received the OTA update. And that's not because I used JNI, undocumented code or internal classes that you all seem to be very worried about :) In my opinion it broke because: a) I used titles that are longer than 2 lines b) a subtle change in the UI behavior in RC33 c) the failure to warn developers before this update was pushed out
For this case - all I can say to the end-user is that the OTA update broke the app and he should blame Google and/or t-mobile for it. Of course I should never use dialog titles longer than one or two lines but that's not my point :) I'm not talking about this specific change. I'm complaining and whining about the lack of any warning and/or changelog and/or updated SDK BEFORE the end-users get the update and see that things are broken. Providing the changelog or SDK AFTER the update is kind of pointless since people start having problems right after they receive the update. I'm not asking for ponies here, really. Just some kind of communication with the developers about upcoming changes. Currently the app lifecycle for the user is: Download app -> get OTA -> broken app -> wait for app update -> download app update -> working app -> get OTA -> broken app -> wait for app update -> download app update -> working app -> .. How it should be (in a perfect world): Download app -> download app update -> get OTA update -> download app update -> get OTA update ->..and the app is always working for the user. Anyway - it would be nice to know beforehand if someone decides that the correct length for dialog titles is 1 line instead of 2 in a future update so I could update my apps BEFORE they break again ;) Tauno > If there are actual places where you can use internal Java APIs, we > definitely want to hear about them (with sample code) to fix them. So far, > I am not clear if that is what is going on here, or if it is just a matter > of taking advantage of the layout file to access an internal class, which as > I say is outside the bounds of what I think we can protect against. > > That said, I don't think we can make any assurances of an application > working "flawlessly" on a platform update even if it completely sticks to > the SDK. We are certainly going to do what we can to keep things working, > and definitely don't want to just break things, but: > > (a) The platform code -is- changing and there can be situations where some > select application is relying on some behavior that has changed, which may > result in some issue for it. > (b) In some very rare circumstances it may be necessary to change something > for larger good of the platform, for example in Cupcake applications can't > modify the "data roaming" setting so if someone is relying on that their > call will no longer do anything (though we made sure to not through an > exception and just crash the app). > >> One other example I noticed - the text on the tab buttons - in RC30 >> if it is longer - it wraps, in RC33 - the same text is displayed in a >> "marquee"). >> Is this an API change? While the tab text is probably not significant >> issue, >> it points that you really don't know about it until >> you get the RC33 and realize that your UI may be a bit off here and >> there. > > Yeah this was a change made for internationalization purposes, to make the > tabs more flexible about the text in them so that localizing it wouldn't > break the UI. While this is certainly a change in behavior, it is not clear > whether this is really an API change or not. :) (Falls in my (a) category > above.) This is also kind-of part of a larger issue we will all be dealing > with, that as we move forward hardware vendors are going to want to > customize the Android UI for their device. We need to be careful that this > doesn't cause applications to break, but if you are using standard widgets > you do need to do that with the expectation that you don't know -exactly- > what you will get, but rather that your UI will match the UI of the rest of > the device. > >> >> The truth is API changes happen - sometimes they are big and obvious, >> sometimes >> small and less obvious. In my opinion the smart thing to do is to give >> developers >> the information and tools to react to the changes and update our >> applications as >> soon as possible. > > If you've been following along since before 1.0, you've seen the SDK updates > we've done as the platform has changed. There shouldn't be anything of that > magnitude any more (we shouldn't be outright changing APIs and such), but > there should continue to be that kind of information. I don't think there > is an SDK yet for 1.1, but hopefully there will be one soon. > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support. 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
