Android: Qual è la ragione per deprecare startManagingCursor?

Qual è la causa del deprecamento di startManagingCursor?

La mia semplice applicazione presenta una vista tabella con l'elenco dei dati da DB. Quindi, quello che ho adesso in onCreate:

  • Perché non posso bloccare DrawerLayout con gravità di layout
  • Come installare le applicazioni Android sulla scheda SD per impostazione predefinita
  • Eclipse Debug Android non funziona
  • Cattura della camera Android utilizzando FFmpeg
  • Tracciare un marker sulla posizione corrente dopo l'async-task onPostExecution
  • ActionBarSherlock: cambiare homeAsUpIndicator non funziona
  • final Cursor cursor = getDataFromDB(); startManagingCursor(cursor); setListAdapter(new CursorAdapter(cursor)); 

    E questo e non ho bisogno di fare altro.

    Ma startManagingCursor è ormai obsoleto e dovrei implementare LoaderCallbacks, sovrascrivere onCreateLoader, onLoadFinished, onLoaderReset, creare ContentProvider per il mio DB e così via. Ma non ho bisogno di tutto questo personale, ho solo bisogno di get poche righe di informazioni da DB. Come essere ? Perché android ha fatto questo? Perché dovrei implementare tutto questo personale?

    2 Solutions collect form web for “Android: Qual è la ragione per deprecare startManagingCursor?”

    Detto questo, "deprecato" in Android di solito significa "continueremo a sostenerlo, ma pensiamo che ci siano soluzioni migliori".

    Se sei disposto a ereditare da FragmentActivity, puoi utilizzare l'implementazione del framework Loader nel pacchetto di supporto Android, tornando indietro a Android 1.6.

    È ansible utilizzare certamente startManagingCursor () sul livello API 11+. Tuttavia, i problemi con i cursori gestiti (in particolare quelli che richiedono () su un riavvio di attività nel thread di applicazione principale) sono ancora presenti nelle vecchie e nuove versioni Android.

    Origine: Android eclipse startManagingCursor Deprecato, ma desidera supportre le versioni API più vecchie?

    Penso che il motivo "perché" sia deprecato è che stanno veramente vogliono che le persone adottino ContentProviders. Ciò è ancora più evidente in quanto spingono i ContentProvider e forniscono un CursorLoader che funziona solo con ContentProvider s (personalmente che viene chiamato male e dovrebbe essere chiamato ContentLoader )

    perché startManagingCursor era nell'attività, rendeva troppo facile per le persone (come stai facendo nell'esempio) e fai semplicemente eseguire le query db sul thread UI, causando pause e, a volte, ANRs.

    Potresti scrivere il tuo CursorLoader che funziona con Cursori e non ContentProviders e renderla una class riutilizzabile in modo da poter utilizzare il framework Loader senza utilizzare ContentProviders.

    La mia soluzione a questo è stata quella di build semplicemente un piccolo framework che rende la creazione di un provider di contenuti un'operazione abbastanza banale, in modo da poter utilizzare il CursorLoader esistente.

    L'Android è un fan Android di Google, tutto su telefoni Android, Android Wear, Android Dev e applicazioni Android Games e così via.