You wouldn't know it was deprecated though as the most current training documentation still recommends using this now-deprecated method ( https://developer.android.com/training/implementing-navigati... ). All you are left with is a pointer to a vague, ambiguous page in the context of the deprecation method. Welcome to the cathedral of Android developing.
BTW the release dates for these APIs:
API 11 - February 2011
API 13 - July 2011
API 21 - November 2014
The annoyance isn't that they changed it, it's that they didn't like the old way, so they changed it, then three years later they changed it again. They do this all the time. Plus they deprecated it, but still recommend the deprecated method in the tutorial, and leave it as a mystery how it should be implemented in current best practices.
The current most up-to-date tutorial on their web site is chock full of recommending things which they deprecated already.
And what about customizing a Spinner's font and background color and popupBackground color and putting a non-standard element at the top?
And the amount of time it took before Android got percentage based spacing in layouts?
And the fun of remembering what UI attribute-values like android:gravity="center_horizontal", android:layout_centerHorizontal="true" and android:layout_gravity="center" mean?
And the awkwardness of using non-standard typefaces and using things like the RecyclerView and it's weird Adapter?
And the fact that for some reason they used an XML element named "layout" when they implemented their data binding feature?
And the fact that some attribute names are camelCased while others are underscore_cased?
And the ease with which memory leaks are introduced by inadvertently closing around context instances because you need context instances all over the place because the Activity is a god object?
It's all so very ... not ... like ... a cathedral.
interesting. i often wonder how the Android SDK got the way it is too.
my hazy guess was that Google simply hired a bunch of extremely smart programmers and let them code whatever they wanted. but there is no equally smart architecture/design team to guide, organize and filter the work. there's just a build system.
I wish they would at least put dates on the documentation. I find myself reading halfway through a outdated tutorial before some names or versions makes me realize it.
And that is just one example, each Android release is full of such examples.
Then we also have the whole story with the NDK, after 3 years having officially deprecated Eclipse, only now they are finally getting something comparable to the CDT.
The experimental Gradle plugin for the NDK still doesn't work that well, just got replaced by something else in the stable Gradle plugin, which is also kind of legacy support, because the way forward seems to actually be cmake. All because that is what Clion knows anyway.
And as usual for these things, it is documentated across Android samples, Git commit messages and blogs.
And now we see just how confused this discussion is. It's conflating a bunch of concepts via a historically weighted analogy, which itself has a lot of baggage at this point.
I'd consider what's on top the more cathedraly part. It has the consistency in design and implementations. Merging FreeBSD with Mach might have been centralized developers looking for good results but actual results seem a bit more bazaar. QNX was the older cathedral of mixing UNIX and microkernels with good design + performance. There were others but it stands out.
> macos (nee osx) is the result of combining freebsd and the mach kernel, both very cathedraly technologies.
Not to mention the remains of NextStep. Also very Cacthedraly.
Edit: thinking about it, I wonder why Apple didn't keep using that name/brand. It's obviously there all over the API. Was the NextStep name/brand tainted as a doomed technology at the time?