3 ms·

> I'm saying that Android doesn't do backwards compatibility well, but it doesn't need to since everyone is actively going out of their way to support old versi

> I'm saying that Android doesn't do backwards compatibility well, but it doesn't need to since everyone is actively going out of their way to support old versions. 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. > AppCompat. You know why it's called that? Because it provides compatibility for new APIs on older platforms. You seem to be completely lost on what backwards compatibile means. It means old binaries/APIs work on new releases. Which it does on Android quite well. It does not mean that new APIs magically work on old releases. Which is the problem jetpack/appcompat is targeting, and is the entirety of your rant. > android.R.color.black to be something completely different than black! That's why you can't rely on android.R for anything And yet everyone does rely on android.R, because those color redefine issues are vanishingly rare. 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

BoorishBears 4y ago
> 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. So I'll leave it at that :)

BoorishBears 4y ago

> 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. So I'll leave it at that :)