Fragmenty wydają się być przesadą? Nie jest możliwa architektura MVC?

Question

Zacząłem od fragmentów kilka dni temu, ale wygląda na to, że jestem przewodowy. Nie widzę uzasadnionej przewagi za ciężki wzrost złożoności. Nie wiem, czy powinienem wdrożyć funkcjonalność w mojej Działalności lub w moim Fragmentie. Po pierwsze, próbowałem umieścić go we fragmentach, ale często wydaje się to niemożliwe.

Na przykład: Mam okno dialogowe jako dane wejściowe użytkownika po kliknięciu przycisku. Przesłałem więc kliknięcie przycisku przez detektor z fragmentu do działania, a w działaniu otworzyłem okno dialogowe. W oknie dialogowym uruchomiłem nowe funkcje (czyli implementacja w działaniu). Android dev daje wskazówkę, aby dodać okno alertu we fragmencie:

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

Ale ten fragment jest nadal realizowany i ciężki w połączeniu z (działanie przycisku w oknie dialogowym znajduje się w działaniach w działalności).

Model i widok są mocno pomieszane. Nie widzę dodatkowej wartości w tak trudnym do utrzymania, statycznym kodzie ?!

Twoja opinia i porady na temat fragmentów?

Answer 1

Podczas korzystania Fragments, można myśleć o nich jako o View i tym Activity jak będąc Controller . W mojej osobistej opinii Fragments to reakcja Google'a na kolana, która wspiera tablety, a teraz utknęliśmy w nich :(

Używam fragmentów każdego dnia, a ja z pewnością odczuwam twój ból. Kiedy po raz pierwszy o nich przeczytałem pomyślałem sobie „to jest naprawdę cool”, ale po ich użyciu, one spadną na tak wiele sposobów, ale głównie dlatego, że byłoby ich używać nieprawidłowo :(

Oto niektóre z pułapek, które ja napotykają ...

1. Nie używaj onclick w układzie fragmentów, ponieważ jest to Activity, a NIE Fragment, który obsłuży kliknięcie. Jeśli użyjesz tego atrybutu, a później użyjesz fragmentu w innym Activity, będziesz musiał pamiętać, aby dodać również metodę onclick do tego Activity. Tak więc, użyj findViewById, a następnie ręcznie załóż uchwyt do kliknięcia w onCreateView fragmentu.

2. Podczas komunikacji z innymi Fragmentami, użyj Activity jako kontrolera do kierowania wiadomości. (Wiele przykładów tego, jak to się dzieje przy użyciu interfejsów). Kluczem jest tutaj to, że jeśli uruchamiasz wiele fragmentów na urządzeniu, w którym jeden fragment będzie komunikował się bezpośrednio z innym fragmentem, wystąpi dziwne, ale przewidywalne zachowanie. Na przykład, jeśli Fragment A bezpośrednio zaktualizował Widok w Fragment B, ale Fragment B nie jest widoczny (ponieważ go zastąpiłeś - rozważ telefon), wtedy gdy Fragment B jest widoczny, wtedy View może nie zostać zaktualizowany, ponieważ View jest odtwarzany. Tak więc, jeśli aktualizujesz Fragment pamiętaj, aby zaktualizować dane w fragmencie, a następnie zaktualizować części View w onCreateView, które są wywoływane, gdy fragment staje się ponownie widoczny (np., Że został pobity bieżący fragment, wyświetlasz poprzedni fragment jeden)

3. Nie buduj kompletnej aplikacji, używając tylko fragmentów. Zamiast tego buduj aplikacje tak, jak zwykle, używając działań, a następnie traktując Fragment ma wyświdlony widok (który jest). tj. zaprojektuj aplikację tak, że masz wiele fragmentów i wiele działań, a niektóre działania mogą wykorzystywać więcej niż jeden fragment.

Moja pierwsza myśl z fragmentami był jednym gdzie myślałem, że to będzie wielki po prostu zbudować kompletną aplikację używając fragmenty i jedno działanie ... I ostatecznie zakończył App, ale wpadłem na tak wiele spraw, które z wykorzystaniem podejście. Moim kolejnym podejściem było użycie wielu fragmentów i wielu działań, a wszystko poszło znacznie lepiej.

Konkluzja jest taka, że ​​fragmenty są świetne, jeśli ich używać jako View, ale jeśli zaczniesz próbuje wykorzystać je podobną działalność, a potem idziesz do napotkasz problemy :(Pomyśl o Activiy ->Fragment jako bytu Controller ->View.

Polecam również lekturę i zrozumienie zasad cyklu Fragment oprócz działalności (Lifecycle Pro Android 4 ma świetny obraz do jej reprezentowania) i będziesz zaoszczędzić godzin bólu :)

Answer 2

Fragmenty zapewniają logikę widoku, dzięki czemu są przenośne do innych działań. W większości działania stają się bardziej rzeczywistymi kontrolerami. W poprzednich architekturach systemu Android logika widoku i logika kontrolera zostały pogrupowane, ponieważ nikt nie podklasował widoku, aby zaimplementować większość aplikacji. Zasadniczo zrobili układ w plikach układu XML, a następnie wyciągnęli obiekty View bezpośrednio w działaniu. Oznaczało to, że Activity rejestrował słuchacze kliknięć, słuchaczy kluczowych, logikę przeciągania itp., Co zwykle robisz w innej podklasie widoku w innych zestawach narzędzi. Ponieważ zrobili to, oznaczało to, że naprawdę fajne przeciąganie gestem wielodotykowym ListView, który właśnie zakodowałeś, utknął w tej jednej Aktywności. Teraz chcesz użyć tego ponownie w innym działaniu. Cóż, jesteś S.O.L. Dzięki Fragmentom możesz łatwiej przenieść tę logikę z Aktywności do Fragmentu. Teraz technicznie możesz przenieść go do widoku komponentu, ale Fragments zapewnia jeszcze jedną zaletę, która polega na tym, że Fragments umożliwiają pisanie aplikacji, które można uruchamiać na tabletach i mniejszych urządzeniach, jednocześnie zmieniając układ każdego z nich. Trudno jest zrozumieć, jak to działa, ale pojedyncze działanie może zawierać kilka fragmentów o różnym układzie dla każdego współczynnika kształtu. Coś, czego niestandardowy komponent nie może osiągnąć tak łatwo. Ponadto niestandardowe komponenty nie mogą używać plików układu. Musisz przejść pełny kod Java, coś, czego nie rezygnujesz z Fragments.

Myślę, że podany przykład to szybkie i brudne podejście do projektowania Fragmentów. Równie łatwo można wyodrębnić odwołanie zwrotne (zakres tego gniazda), wyodrębniając interfejs delegowany przez Fragment.

Answer 3

Ok, mam to działa z mv architektury ...

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(); 
} 

realizowane w Fragment ... zaczynając od tego alertdialog fragmentu:

 fragment_userlocation_btn_addLocation.setOnClickListener(new OnClickListener() { 

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

realizowane również we fragmentach.

Ale nadal wierzę w teorię przesadną ...

myślę < 5% mojego UI zostaną ponownie wykorzystane, więc zaleca się mieszać czynności ładunkowych fragmenty i działań w tym logiki ui bez fragmentów?

Uważam, że prawdziwą zaletą Fragments jest optymalizacja tabletu, ale wykorzystanie tabletów w porównaniu z wykorzystaniem urządzeń mobilnych jest obecnie bardzo małe. Poza że tabletki nie są tak „mobile”, a następnie urządzenia mobilne i nie są w centrum uwagi na kontekst świadomego rozwoju ...