> Which is not relevant to the discussion. The discussion is about apps that aren't updated. Android doesn't break those. Developers targeting previous releases is a wholly unrelated issue.
No, it is the discussion. If you rely on the OS and lean into new features, many updates will break your app, and in fact many devices on the same OS version will break it!
But there's a massive reluctance to rely on anything but the lowest common denominator of functionality in your apps, so there is outwardly an impression of backwards compatibility.
Seriously, you're talking about backwards compatibility when Android can barely do sideways compatibility, the mind boggles.
> And yet everyone does rely on android.R, because those color redefine issues are vanishingly rare.
Well I guess I'm referring to a certain level of experience... so just call it a code smell.
You get Lint warnings for not fully qualifying any use of it since it's usually not what you want.
Those of us who've needed to support enough apps realize it's really not that rare for random android.R overrides to exist in things like animations, and especially if you have a global footprint. So we just take 5 seconds to define ourpackage.R.color.black or ourpackage.R.anim.fade_in
> There's also entire CTS suites that verify oems don't modify theme.holo and theme.material. which is why everyone inherits from those, and don't have problems with it
No... they inherit from AppCompat wrappers on those because there are many subtle breaking changes between versions.
-
You're clearly not making the logical connection conveyed here, and I don't think there's anything wrong with accepting that.
No one will completely understand or agree with everything they read, but clearly others are able to make the link, and I think I've gone out of my way enough explaining the link, but you're completely stuck at the first step convinced that someone who's dealt with backwards compatibility for a very long time doesn't know what it is, instead of opening your mind to comprehending the bigger picture.
No, it is the discussion. If you rely on the OS and lean into new features, many updates will break your app, and in fact many devices on the same OS version will break it!
But there's a massive reluctance to rely on anything but the lowest common denominator of functionality in your apps, so there is outwardly an impression of backwards compatibility.
Seriously, you're talking about backwards compatibility when Android can barely do sideways compatibility, the mind boggles.
> And yet everyone does rely on android.R, because those color redefine issues are vanishingly rare.
Well I guess I'm referring to a certain level of experience... so just call it a code smell.
You get Lint warnings for not fully qualifying any use of it since it's usually not what you want.
Those of us who've needed to support enough apps realize it's really not that rare for random android.R overrides to exist in things like animations, and especially if you have a global footprint. So we just take 5 seconds to define ourpackage.R.color.black or ourpackage.R.anim.fade_in
> There's also entire CTS suites that verify oems don't modify theme.holo and theme.material. which is why everyone inherits from those, and don't have problems with it
No... they inherit from AppCompat wrappers on those because there are many subtle breaking changes between versions.
-
You're clearly not making the logical connection conveyed here, and I don't think there's anything wrong with accepting that.
No one will completely understand or agree with everything they read, but clearly others are able to make the link, and I think I've gone out of my way enough explaining the link, but you're completely stuck at the first step convinced that someone who's dealt with backwards compatibility for a very long time doesn't know what it is, instead of opening your mind to comprehending the bigger picture.
So I'll leave it at that :)