2015-10-14 11 views
13


ich zur Zeit den Aufbau einer app API 23, mit einem Minimum von 19 API
In API 23 einige der Methoden der android.widget.TimePicker Komponente Targeting ersetzt wurde.
Umgang mit veralteten Methoden in android

Zum Beispiel:

TimePicker.getCurrentHour(); 

ersetzt wurde:

TimePicker.getHour(); 

Nun, wenn Timepicker in meiner app soll ich überprüfen, ob das Gerät API 22 oder oben mit dem folgenden, wenn Anweisung:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) 
     TimePicker.getHour(); 
    else 
     TimePicker.getCurrentHour(); 

Was ich tat, war die TimePicker-Klasse zu erweitern und zu impl ementing die veralteten Methoden wie folgt aus:

public class TimePicker extends android.widget.TimePicker { 

    public TimePicker(Context context) { 
     super(context); 
    } 

    public void setCurrentHour(int hour) { 
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) 
      super.setHour(hour); 
     else 
      super.setCurrentHour(hour); 
    } 

    public void setCurrentMinute(int minute) { 
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) 
      super.setMinute(minute); 
     else 
      super.setCurrentMinute(minute); 
    } 

    public int getCurrentHour() { 
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) 
      return super.getHour(); 
     else 
      return super.getCurrentHour(); 
    } 

    public int getCurrentMinute() { 
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) 
      return super.getMinute(); 
     else 
      return super.getCurrentMinute(); 
    } 
} 

so dass der Benutzer, die diese Klasse verwendet, die Änderung der Methoden nicht beeinflussen (er nur den Import der Timepicker-Klasse in seiner Implementierung ersetzen sollte).

Ist es der richtige Weg? oder gibt es eine bessere Lösung?

Dank

+2

Es ist eine gute Art und Weise. Meiner Meinung nach hast du es geschafft! :) Vielleicht sollten Ihre Methoden nach der neuen Namenskonvention benannt werden, um den Übergang zu erleichtern, wenn Sie die Unterstützung für pre M fallen lassen. – Kenneth

+0

hey, Worum geht es bei .M? –

+0

Build.VERSION_CODES.M bezieht sich auf API 23 (Android Marshmallow) –

Antwort

3

Die Art und Weise ist eine gute Übung durchgeführt, soweit ich aus dem gezeigten Teil lesen kann.

Wie ich bisher gesehen habe, bestand die beste Vorgehensweise darin, aus jeder zu veröffentlichenden Klasse verschiedene Unterteilungen zu machen und das Programm während der Installation zu stapeln.

Dies bedeutet, dass if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) an der Spitze der Klasse geht.

Wenn Ihr Projekt soll unter mehr Versionen gehen, schlage ich folgendes:

public class Example extends moreExamples implements additionalExamples{ 
    switch(Build.VERSION.SDK_INT){ 
     case Build.VERSION_CODES.M: 
     codeVersionM(); 
     break; 
     case Build.VERSION_CODES.L: 
     codeVersionL(); 
     break; 
     case Build.VERSION_CODES.K: 
     codeVersionK(); 
     break; 
     default: 
     errorNoBuildImplemented(); 
    } 
} 
1

Es ist besser, die neuen Methodennamen zu verwenden. Auf diese Weise können Sie Ihre Kompatibilitätsklasse schließlich entfernen, wenn Sie Ihre min sdk-Version auf 23 erhöhen, ohne dass Sie einen anderen Code als Ihre Importe ändern müssen.

@SuppressWarnings("deprecation") 
public class TimePicker extends android.widget.TimePicker 
{ 
    public TimePicker(Context context) 
    { 
     super(context); 
    } 

    public TimePicker(Context context, AttributeSet attrs) 
    { 
     super(context, attrs); 
    } 

    public TimePicker(Context context, AttributeSet attrs, int defStyleAttr) 
    { 
     super(context, attrs, defStyleAttr); 
    } 

    @RequiresApi(api = Build.VERSION_CODES.LOLLIPOP) 
    public TimePicker(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) 
    { 
     super(context, attrs, defStyleAttr, defStyleRes); 
    } 

    public void setHour(int hour) 
    { 
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) 
      super.setHour(hour); 
     else 
      super.setCurrentHour(hour); 
    } 

    public void setMinute(int minute) 
    { 
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) 
      super.setMinute(minute); 
     else 
      super.setCurrentMinute(minute); 
    } 

    public int getHour() 
    { 
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) 
      return super.getHour(); 
     else 
      return super.getCurrentHour(); 
    } 

    public int getMinute() 
    { 
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) 
      return super.getMinute(); 
     else 
      return super.getCurrentMinute(); 
    } 
} 
3

Was haben Sie in Ordnung ist, aber wahrscheinlich nicht die beste Lösung, weil:

  • Sie verwenden die alten Methodennamen anstelle der neuen
  • eine benutzerdefinierte Klassenkräfte Erstellen Sie, dass die Verwendung benutzerdefinierte Klasse in Ihren Layouts und Code als Ersatz für die Framework-Klasse. Es wird empfohlen, keine benutzerdefinierten Ansichten zu erstellen, wenn dies möglich ist.

Es gibt im Allgemeinen zwei Arten empfohlen:

1) Halten Sie die veraltete Methode, bis Sie Ihre minSDK aktualisieren.Es wird die neue Methode intern in der neuen Implementierung nennen:

@Deprecated 
public void setCurrentHour(@NonNull Integer currentHour) { 
    setHour(currentHour); 
} 

2) eine statische Hilfsklasse erstellen, die die richtige Methode gemäß der SDK-Version nennen. Das ist, was die Support-Bibliothek hat für viele Klassen bereits (TextViewCompat, ViewCompat, ...):

public class TimePickerCompat { 

    public static void setHour(TimePicker timePicker, int hour) { 
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { 
      timePicker.setHour(hour); 
     } else { 
      timePicker.setCurrentHour(hour); 
     } 
    } 

}