2017-12-27 3 views
6

Die nächste Frage, die ich diesbezüglich finden kann, ist Android Studio 3.0 lint warnings for references to activity, aber es hilft nicht.DialogFragment getActivity() "möglicherweise Null" Hinweis Warnung in AndroidStudio 3.0.1

Mit Android Studio 3.0.1, ich habe ein DialogFragment, wo ich diese üblichen Sachen tun:

@Override 
    @NonNull 
    public Dialog onCreateDialog(Bundle savedInstanceState) { 
     AlertDialog.Builder builder = new AlertDialog.Builder(getActivity()); 
     ... 

Ich habe eine Fussel Warnung Stöhnen bei mir, dass Argument 'getActivity()' might be null.

Ich verstehe, warum getActivity() null sein kann, und ich verstehe, wie die Flusen Inspektion weiß das (von der @Nullable Anmerkung).

Meine Frage ist: Es ist alles sehr gut und gut, dass getActivity() Null sein kann, aber praktisch wie soll ich damit anmutig und sauber umgehen? onCreateDialogmuss zurückkehren ein Dialog (wegen der übergeordneten Klasse @Nullable Anmerkung), damit ich muss die Aktivität Kontext um es zu schaffen haben.

Ich könnte annehmen, dass onCreateDialog nie aufgerufen wird, wenn die DialogFragment nicht an eine Aktivität angehängt ist, aber immer noch - wie adressiere ich die unordentliche Flusenwarnung?

+2

"Wie adressiere ich die unordentliche Flusenwarnung?" - unterdrücken Sie es und gehen Sie weiter. – CommonsWare

+0

warum verwenden Sie nicht getContext() –

+0

Vielleicht können Sie auf onActivityCreated oder onAttach (depacated) verlassen, die Ihnen gültige Referenz geben würde. Dann benutze es anstelle von getActivity()? – marcinj

Antwort

1

Die Antwort von @Niklas erklärt, warum Sie diese Warnung jetzt erhalten. Ich möchte meine Gedanken darüber teilen, was Sie eigentlich tun sollten.

Zuallererst macht all diese hinzugefügte NULL-Zulässigkeit den alten Konstruktionsdefizit aus, der all diese Jahre vorhanden war - diese Methode könnte immer Null zurückgeben (z. B. Fragment losgelöst).

Ich würde es vorziehen, wenn sie den Rückgabewert als @NonNull kommentiert und intern eine Ausnahme auslöst, wenn diese Methode aufgerufen wird, wenn die Aktivität tatsächlich null ist, aber ich verstehe, dass es Rückwärtskompatibilität brechen würde und als solches sehr riskant ist (obwohl ich kann kaum zu sehen, warum sollte jemand diese Methode nennen, wenn die Aktivität tatsächlich null sein kann).

Also, was sollen wir dagegen tun?

Da die Funktionalität sich überhaupt nicht änderte, wenn der betreffende Code bereits funktionierte, tun Sie was @CommonsWare vorgeschlagen hat - entweder die Warnung unterdrücken oder ignorieren.

Sie könnten auch jeden Anruf in Null-Überprüfung mit z. Ausnahme.

Was werde ich aber tun, ist diese Methode in meinem BaseDialog zu setzen (die von allen anderen Dialogen erweitert):

protected FragmentActivity getActivityNonNull() { 
    if (super.getActivity() != null) { 
     return super.getActivity(); 
    } else { 
     throw new RuntimeException("null returned from getActivity()"); 
    } 
} 

Beachten Sie, dass alle diese Optionen effektiv feststellen, dass Sie don‘ Ich erwarte wirklich, dass null zurückgegeben wird, und es ist OK, wenn die App abstürzt, wenn das passiert. Deshalb habe ich gesagt, dass ich dies lieber im Support-Bibliothekscode hätte.

Verwandte Themen