[flutas]

> I wonder why this great piece of code was deprecated if it's so great? And yes, that's another great thing about the Andorid SDK. Everything is deprecated while its replacements are only supported on new devices.

Again, same vibes.

The reason you are seeing anything like this, is because you are looking at foundation code and expecting app code. This code is going to be used by apps to run on ALL devices. Best way I can try to describe it is just library code sits between the kernel and software, it has to support everything. Company X's latest XR/AI app doesn't.

Software is constantly evolving for whatever the latest trend is be it VR, AI, or whatever, and eventually you move on from devices that don't get updated. But, so do users. Users by and far want the latest and greatest, shiniest thing. That means every company wants to support `thing`, even if it means dropping `oldThing`.

Funnily enough I had to have a discussion at my job today about dropping support for FireOS 6 devices because of OS specific bugs that happen with Compose that cause a buggy UI. We can't make it work exactly as we want while providing a good experience, so we won't be providing an experience at all. The reason that's okay? Those devices have usage percentage that's practically nil, as they are older devices and not the "latest and greatest".

[fngjdflmdflg]

>Again, same vibes.

Are you serious? The Android devs have been working to fix the deprecation and update issue for the last decade and a half. I think you are actually the junior dev here if you are defending it. They have been slowly moving from their custom fork of Linux back to mainline, separating device-level components (eg. Bluetooth) as separate modules, trying to force device vendors to support a baseline of features via GKI, trying to separate kernel updates from higher level system updates, and trying to increase SoC support duration from vendors like Qualcomm. The minuscule device support length on Android is a real issue that Google has spent tens of millions of dollars trying to fix (and only now are they even close to being able to start fixing it). A lot of it is due to political decisions that began at the beginning of Android's lifetime, when device vendors had much more control over the operating system. The fact that pointing that out as a flaw gives you "junior programmer vibes" is seriously concerning.

Also, you failed to address even a single point I made in my post about TextView.

[flutas]

> The fact that pointing that out as a flaw gives you "junior programmer vibes" is seriously concerning.

It's the fact that you hand wave away Text rendering as "just showing text" while claiming you've made your own.

Then claim that platform code is terrible because it...uses flags to determine what platform it's on and use the appropriate commands...

THAT is what gives me JR eng vibes.

> Also, you failed to address even a single point I made in my post about TextView.

And there's the lack of reading comprehension with a Jr.

"You didn't say anything about X component."

Yeah, when talking about components A-Z and the structure around them you don't typically need to point out that X will be included, but here we are.

[fngjdflmdflg]

>It's the fact that you hand wave away Text rendering as "just showing text" while claiming you've made your own.

I didn't wave away "text rendering" at all. TextView as nothing to do with text rendering. Have you tried reading the code? Also, even if it did, that would not make it any better. Your claim that TextView is good code because it implements everything from text layout and rendering to text editing is actually much much worse that it simply doing what it really does, which you would know if you would just read and understand the code. Why you have not done so by now is puzzling. Think of it this way: if you were looking at the source code of a text editor, would you expect the whole program to consist of just two classes? That is always going to be bad code.

>Then claim that platform code is terrible because it...uses flags to determine what platform it's on and use the appropriate commands...

Windows has backward compatibility going multiple decades. It even used to ship with a DOS emulator to ensure you can run programs from 30 years ago on it. Linux too has never broken ABI compatibility (although the same cannot be said for user space). Yet you seem to think it is fine for Android to break its API every update. Have you developed for any other systems? I get the feeling that all you know is Android and its awful SDK so you feel you have to defend it.

>Yeah, when talking about components A-Z and the structure around them you don't typically need to point out that X will be included, but here we are.

No. There were two points I made in the post you responded to. One was a very specific point about TextView where I gave my arguments as why it is bad code and in which I pointed out that you never even read the code we were talking about. The other was a side point about deprecating APIs in Android. You decided to ignore the entire main points of my post and only respond to the side point.