Android versioning is a an absolute mess

[Gregary Boyles]

Another reason why it is a constant battle to get Android Studio to do what you want it to do!

Calendar class is only available above one API level.

Date class is available from a different API level but get and set functions are deprecated above a certain API level.

DatePicker is available only above API 11
.
.
.

Jeeessus! Why is this so god damned complicated????

Why, for example, can't Date class be just left alone under all API versions for backwards compatibility.

By all means add the Calendar class at higher API levels but leave the Date class alone!

I reckon this has got to be a case of too many 'opinions' ruling Android Studio development and no one being prepared to put their foot down and lay down the law.

None of this is a problem in MS Visual Studio - all versions of Visual Studio have the same basic set of controls that work under all versions of windows. There are additional more sophisticated controls that work only with certain versions of windows and .net etc but you are not compelled to use them.

 

[Deleted User]

It's because software evolves, gets better, and APIs deprecate methods.
This is so that frameworks or libraries don't build up a huge amount of baggage over time. It would be a total mess to maintain.
You mention the Date and Calendar classes. In Java the date/time has been notoriously badly implemented. In fact up until Java 8, the support was so bad, that developers preferred to use a third party library called 'Joda time'. With Java 8 they've done a better job.

Unfortunately this deprecation of APIs makes developing apps a bit messy in some respects, where the intention is to target multiple versions. Hopefully over time, things will settle down more.

 

[Gregary Boyles]

Better does not mean you destroy compatibility with previous versions.

Backward compatibility is 'better' in my view.

Even though MS Windows has its own problems, the one thing that MS got right is that an app compiled for windows 95 will still run happily on Windows 10.

And you can bet your boots that is the result of someone being in charge and laying down the law for all the developers.

That is far superior to state of Android with its mess of versioning and deprecation.

 

[mikedt]

Even though MS Windows has its own problems, the one thing that MS got right is that an app compiled for windows 95 will still run happily on Windows 10.

OT: Is that why Windows 10 is a huge bloated pig of an OS, because its got 20-30 years of legacy in it? Although I don't use Win myself these days.

Android doesn't keep legacy much between versions, because it's intended as a lightweight mobile OS? I know there was no legacy at all with Windows Phone which is also a mobile OS,, and apps built for previous versions wouldn't run the current Windows Phone 10.

 

[Deleted User]

Better does not mean you destroy compatibility with previous versions.

Backward compatibility is 'better' in my view.

It's a fact of life in software that things change. Every single software system I've worked on or used has 'degraded' over time. Meaning it becomes buggy, slows down, fails to meet modern requirements. Software must change, or die.
When APIs or methods are deprecated, there's always something else to replace it. It's your responsibility to take that into account and adapt your code. In the case that your app must target older versions of the SDK, then there's a penalty for that - you cannot use newer features, or you must include conditional code to detect the SDK level at run time, and do the correct thing.
Is it ideal? Probably not, but Google are very innovative, and are always looking for ways to do things better. You could also argue that the whole system of Android updates propagated to hardware vendors, and the way they trickle out isn't ideal. But again, Google are seeking to improve that too.

Even though MS Windows has its own problems, the one thing that MS got right is that an app compiled for windows 95 will still run happily on Windows 10.

And you can bet your boots that is the result of someone being in charge and laying down the law for all the developers.

Windows probably does a better job of retaining backwards compatibility, but that will come at an awful cost to the company. And if you're happy with Microsoft looking after you then that's fine, cough up your $$$ for whatever proprietary frameworks and tools they're touting. There are many advantages to using an open platform like Android. The sheer number of devices and apps available is testament to that.

 

[Deleted User]

OT: Is that why Windows 10 is a huge bloated pig of an OS, because its got 20-30 years of legacy in it? Although I don't use Win myself these days.

Good point. I try and avoid using Windows at all costs these days. I don't envy the engineers involved in supporting an O/S which carries that much baggage. Must be a nightmare!

 

[Gregary Boyles]

I just don't see how making a few basic things, like a bare bones date class and a bare bones date/time spinner etc, backwards compatible all the way from API 10 (or whatever) is going to bloat the android operating system!
Especially with Mores law applied to embedded devices!
I would have fixed the implementation of Date class (what ever was wrong with it) and extended it with the Calendar class.
Rather than just dump the Date class and break ll the older apps that use it.
That sort of approach just pisses clients off!

 

[Deleted User]

I just don't see how making a few basic things, like a bare bones date class and a bare bones date/time spinner etc, backwards compatible all the way from API 10 (or whatever) is going to bloat the android operating system!
Especially with Mores law applied to embedded devices!

The issue is one of maintenance. All backwards compatibility costs resources to maintain. Bug fixes to newer APIs may have to be back ported, and tested. Every legacy API you support hurts you in terms of time and money to maintain it. Software companies have to decide where to draw the line in terms of deciding what they are not going to support any more.
Plus there is a bloat issue, because all the legacy code you support, consumes resources such as memory, disc space etc. This impacts all applications which are running on the O/S.

I would have fixed the implementation of Date class (what ever was wrong with it) and extended it with the Calendar class.
Rather than just dump the Date class and break ll the older apps that use it.
That sort of approach just pisses clients off!

What exactly is your issue with the Date class?
Date and Calendar are not Android framework classes. They are Java library classes, and have been available since the dawn of time. And btw Date and Calendar are designed for different purposes. Calendar is a collection of utility methods to manipulate Dates.

Oh and to throw another spanner in the works that may really upset you - so sit down and grab a coffee for this one - Java 8 has introduced a whole new package called Date-Time, which completely revamps the entire Date/Time stuff. It's better btw, but you may not see it that way You can blame Oracle for this gratuitous replacement of the beloved Date/Time classes. Damn them!

https://docs.oracle.com/javase/tutorial/datetime/index.html

 

[Gregary Boyles]

If we are going to discuss 'bloating' then how about all the bloatware that manufactures fill their phones up with that rarely or never get used and that you can't uninstall easily.

More to the point to get rid of all the bloatware and allow some backward compatibility for older apps!

My problem is with the Date Class is that I looked it up on the Android site and though great, just what I need.
But then when I tried to use it in Android Studio most of the functions had a line through them!
Then it snowballed into problems with DatePickers and TimePickers that I could not use because was using API 10 for my app (which is what my mobile is running) and other incompatibility issues.

Fix any problems with Date class and extend it with Calendar - keep backward compatibility.
Isn't that partly what object oriented programming is supposed to be about!

 

[Deleted User]

If we are going to discuss 'bloating' then how about all the bloatware that manufactures fill their

My problem is with the Date Class is that I looked it up on the Android site and though great, just what I need.

Fix any problems with Date class and extend it with Calendar - keep backward compatibility.
Isn't that partly what object oriented programming is supposed to be about!

No. You misunderstand the purpose of class inheritance.

So let's go back to the beginning, before you spiralled off into all this other stuff. What's your problem with Date, and how are you trying to use it?