1

What's the reason that pushes android development team to deprecate some system methods, I know there are some methods that replaced with another methods which are more handful and helpful but some others not even replaced with another methods or are just replaced with one generalized big method which won't be helpful when trying to deal more specifically with some element, for example some methods from Date class: 

Date mDate = new Date();
mDate.getDate();            //Deprecated
mDate.getDay();             //Deprecated
mDate.getHours();           //Deprecated
mDate.getMinutes();         //Deprecated
mDate.getMonth();           //Deprecated
mDate.getSeconds();         //Deprecated
mDate.getYear();            //Deprecated
mDate.getTimezoneOffset();  //Deprecated

and the only one is exist now is :

mDate.getTime(); // gives the whole Time & Date as a `long` Value in milliseconds

now, when I get a Date Object and try to get the Year , I have to:

  1. Declare a new Calendar Object.
  2. makes it equal an instance of Calendar Class.
  3. sets this calendar object time to the date I got.
  4. extract the required attributes from this calendar object.

and what if that Data Object contains only the Date with the time equals to zero. now I have to make a workaround to save the time of the calendar before applying date to it, then reset the saved time to it again after applying date to it.

another example found here which illustrates that the entire PictureListener interface is deprecated and There's no sign of what, if anything, is supposed to replace it.

third example when want to get screen width & height, that was direct:

int windowWidth, windowHeight;
windowWidth = getWindowManager().getDefaultDisplay().getWidth(); // Deprecated
windowHeight = getWindowManager().getDefaultDisplay().getHeight(); // Deprecated

but now:

int windowWidth, windowHeight;
DisplayMetrics metrices = new DisplayMetrics();
mContext.getWindowManager().getDefaultDisplay().getMetrics(metrices);
windowWidth = metrices.widthPixels;
windowHeight = metrices.heightPixels;
Community
  • 1
  • 1
Muhammed Refaat
  • 8,914
  • 14
  • 83
  • 118
  • 1
    @Funkystein looool, that does make sense – Muhammed Refaat Oct 28 '14 at 10:22
  • 2
    I believe **[this](http://stackoverflow.com/a/26235866/681929)** , Yesterday we used to do something,today we came to know that the same can be achieved by some different and efficient approach,hence I prefer replacing it today – nobalG Oct 28 '14 at 10:23
  • 1
    I do find it **really annoying** when they deprecate something and force me to use something else. I liked `fill_parent`, because it's shorter an easier than `match_parent`. But now I have to use `match_parent` (I **really hate** deprecation warnings - and, yes I could trick Lint, but don't feel like). And this example is only the top of the iceberg... – Phantômaxx Oct 28 '14 at 10:30
  • 1
    @nobalG considerable thinking, but if the different approach isn't that efficient, why heading to it – Muhammed Refaat Oct 28 '14 at 10:30
  • 1
    The java language designers were in a hurry to also provider the basic classes and didn't design the Date class that well. For example it should have been immutable; now you'll have to do a defensive copy (http://www.javapractices.com/topic/TopicAction.do?Id=15) when returning it from a getter function. They deprecate the things for which they have new insights. It is advice not to use it as it may/will be removed from the language in the future. There are always alternatives, but unfortunately marking it deprecated doesn't tell you which. You'll have to google it. – Rob Meeuwisse Oct 28 '14 at 10:31
  • 2
    Found it funny but yet in complete agreement for that **hurry** thing that @RobMeeuwisse is pointing too .. :) – nobalG Oct 28 '14 at 10:32
  • 1
    @Funkystein that's true, something link `fill` and `match`, why changing that? what's is the be development benefit of changing just a word spelling? – Muhammed Refaat Oct 28 '14 at 10:32
  • 1
    @MuhammedRefaat Exactly. **What's better** in `match_parent`? **Nothing**. As opposed, it's **longer** and **counter-intuitive**. It really behaves the same as `fill_parent`. So, why do **they bother us**? – Phantômaxx Oct 28 '14 at 10:32
  • 2
    @Funkystein +1,for pointing it out... [**(0_o)**](http://stackoverflow.com/questions/5761960/what-is-the-difference-between-match-parent-and-fill-parent) – nobalG Oct 28 '14 at 10:35
  • 1
    @RobMeeuwisse you mean, all Deprecations have nothing to do with Android Development Team? and they came from Java Restrictions? – Muhammed Refaat Oct 28 '14 at 10:39
  • 1
    @MuhammedRefaat Not **all ones**. As I pointed out the deprecations about Android Views are **Android-specific**. – Phantômaxx Oct 28 '14 at 10:40
  • 2
    http://stackoverflow.com/questions/2901262/why-were-most-java-util-date-methods-deprecated more on the Date deprecation. And since every API designer makes mistakes / requirements change you'll have that happen over and over again. – zapl Oct 28 '14 at 10:41
  • 1
    @zapl thank you for pointing us to that great post. – Muhammed Refaat Oct 28 '14 at 10:51

2 Answers2

4

The methods of java.util.Date you've mentioned were not deprecated by Android team, but were deprecated by Sun in Java 1.1. This is just an example of Java legacy. If you think Calendar API is unbearable I would consider using Joda Time instead.

mbukowicz
  • 41
  • 1
1

Depecration is way to inform developers that there is a better way to do things, and that they should not use the old way anymore.

Framework devs could delete obsolete APIs, but as they don't want to disturb developpers that still uses these APIs, they deprecate them instead. Instead of blaming them, you should thank them for managing changes this way.

clemp6r
  • 3,665
  • 2
  • 26
  • 31