I frammenti sembrano essere eccessivi? Non è possibile l'architettura MVC?

Question

Ho iniziato con alcuni frammenti qualche giorno fa, ma sembra cablato per me. Non vedo il vantaggio giustificato per il forte aumento della complessità. Non so, se dovessi implementare la funzionalità nella mia attività o nel mio frammento. In primo luogo, ho provato a metterlo nei frammenti ma quello sembra spesso non essere possibile.

Ad esempio: Ho una finestra di dialogo come input dell'utente, dopo il clic del pulsante. Così ho trasferito il clic del pulsante tramite listener dal frammento all'attività e nell'attività ho aperto la finestra di dialogo. Nella finestra di dialogo ho iniziato nuove funzioni (quindi implementazione in Attività). Android dev dà il suggerimento di aggiungere una finestra di avviso in un frammento:

http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/app/FragmentAlertDialog.html

Ma questo frammento ancora è implementata e pesante accoppiato con il (azione del pulsante della finestra di dialogo è in attività) activty.

Quindi il modello e la vista sono molto confusi. Non vedo un valore aggiuntivo in un codice statico così difficile da mantenere ?!

Qual è la tua opinione e consulenza sui frammenti?

Answer 1

Quando si utilizza Fragments, si può pensare a loro come il View e la Activity come il Controller . A mio parere personale, Fragments è stata la reazione istintiva di Google a supportare i tablet, e ora li abbiamo bloccati :(

Io uso frammenti ogni giorno, e sicuramente sento il tuo dolore. Quando ho letto su di loro ho pensato a me stesso , "questo è davvero cool", ma dopo il loro utilizzo, sono a corto di così tanti modi, ma soprattutto perché io li userei :(in modo non corretto

Ecco alcune delle insidie ​​che ho incontrato ...

1. Non utilizzare onclick nel layout del frammento, poiché è il Activity e NON lo Fragment che gestirà il clic. Se si utilizza l'attributo e in seguito si utilizza il frammento in un altro Activity, sarà quindi necessario ricordare di aggiungere il metodo onclick a quello Activity. Quindi, utilizzare un findViewById e quindi collegare manualmente il gestore di clic nel frammento onCreateView.

2. Quando si comunica con altri frammenti, utilizzare Activity come controller per dirigere il messaggio. (Un sacco di esempi su come farlo usando le interfacce). La chiave qui è che se si stanno eseguendo più frammenti su un dispositivo in cui un frammento comunicherà direttamente con un altro frammento, si verificherà un comportamento strano, ma prevedibile. Ad esempio se il frammento A ha aggiornato direttamente una vista nel frammento B, ma il frammento B non è visibile (perché lo hai sostituito - considera un telefono), quindi quando Frammento B è visibile, allora lo View potrebbe non essere aggiornato, dal momento che il frammento View viene ricreato. Quindi, se aggiorni un Fragment assicurati di aggiornare i dati in un frammento, aggiorna le porzioni View nello onCreateView che viene chiamato quando il frammento diventa di nuovo visibile (cioè, hai scoccato il frammento corrente, ora stai mostrando il precedente uno)

3. Non creare un'applicazione completa utilizzando solo frammenti. Costruisci invece app come faresti normalmente, usando Attività e poi tratti la Fragment con una vista glorificata (che è). Ad esempio, progettare l'app in modo tale da avere più frammenti e più attività e alcune attività potrebbero utilizzare più di un frammento.

Il mio primo pensiero con frammenti è stato un anno in cui ho pensato che sarebbe grande per costruire solo un'applicazione completa utilizzando frammenti e un'attività ... alla fine ho finito l'App, ma mi sono imbattuto in così tanti problemi che utilizzano tale approccio. Il mio prossimo approccio è stato quello di utilizzare più frammenti e più attività ed è andata molto meglio.

Linea di fondo è che i frammenti sono grandi se li si utilizza come un View, ma se si inizia cercando di utilizzare loro come Attività, allora si sta per incorrere in problemi :(Pensate al Activiy ->Fragment come l'essere il Controller ->View.

vi consiglio anche di leggere e capire il Frammento del ciclo di vita, oltre alla attività del ciclo di vita (Pro Android 4 ha un grande quadro per rappresentare) e potrai risparmiare ore di dolore :)

Answer 2

I frammenti forniscono la logica di visualizzazione in modo che siano trasferibili ad altre attività. Per la maggior parte, le attività si stanno spostando maggiormente nel ruolo di un vero controller. Nelle precedenti architetture Android la logica di visualizzazione e la logica del controller erano unite perché nessuna sottoclasse View per implementare la maggior parte della loro app. Essenzialmente hanno fatto il layout nei file di layout XML, quindi hanno estratto gli oggetti View direttamente nell'attività. Ciò significava che l'attività registrava gli ascoltatori di clic, gli ascoltatori di chiavi, la logica di trascinamento, ecc. Che normalmente è ciò che si farebbe in un'altra sottoclasse di Visualizza in altri toolkit. Perché hanno fatto questo significava che il ListView multi-touch con gesti multi-touch davvero geniale era bloccato in quella attività. Ora vuoi usarlo di nuovo in un'altra attività. Bene, sei S.O.L. Con Fragments puoi spostare più facilmente quella logica dall'attività in un frammento. Ora tecnicamente è possibile spostarlo in un componente personalizzato Visualizza, ma Frammenti offre ancora un altro vantaggio che consente a Fragments di scrivere applicazioni che possono essere eseguite su tablet e dispositivi più piccoli mentre si varia il layout per ciascuno. È difficile capire come funziona, ma una singola attività può contenere diversi frammenti con layout diverso per ogni fattore di forma. Qualcosa che un componente personalizzato non può realizzare quasi altrettanto facilmente. Inoltre i componenti personalizzati non possono utilizzare i file di layout. Devi andare in codice Java completo qualcosa che non hai rinunciato a Frammenti.

Penso che l'esempio che hai fornito sia un approccio rapido e sporco alla progettazione di Frammenti. Si potrebbe facilmente estrarre il riferimento posteriore (ambito nidificante di questo) estraendo un'interfaccia a cui il Fragment delega.

Answer 3

Ok, ho capito in esecuzione con l'architettura mv ...

public AlertDialog openLocInput() { 

    AlertDialog.Builder alert = new AlertDialog.Builder(getActivity()); 
    alert.setTitle("Login"); 
    alert.setMessage("Enter Pin :"); 

    // Set an EditText view to get user input 
    final EditText input = new EditText(getActivity()); 
    alert.setView(input); 

    alert.setPositiveButton("Ok", new DialogInterface.OnClickListener() { 
     public void onClick(DialogInterface dialog, int whichButton) { 
      jsonHandler.obtainMessage(1, input.getText().toString()) 
        .sendToTarget(); 
      dialog.dismiss(); 
      return; 
     } 
    }); 

    alert.setNegativeButton("Cancel", 
      new DialogInterface.OnClickListener() { 

       public void onClick(DialogInterface dialog, int which) { 
        dialog.dismiss(); 
        return; 
       } 
      }); 
    return alert.create(); 
} 

implementato nel frammento ... a partire da questo alertdialog dal frammento:

 fragment_userlocation_btn_addLocation.setOnClickListener(new OnClickListener() { 

     public void onClick(View v) { 
      openLocInput().setOwnerActivity(getActivity()); 
      openLocInput().show(); 
     } 
    }); 

implementato anche in frammenti.

Ma io continuo a credere nella teoria eccessivo ...

Penso < 5% del mio UI sarà riutilizzata, così è consigliabile mescolare attività di carico frammenti e attività, tra cui la logica ui senza frammenti?

Penso che il vero vantaggio di Fragments sia l'ottimizzazione del tablet, ma l'utilizzo di tablet rispetto all'utilizzo di dispositivi mobili è molto ridotto in questo momento. In aggiunta a che le compresse non sono così "mobile" e poi i dispositivi mobili e non sono a fuoco per il contesto di sviluppo consapevole ...