Wpis z mikrobloga

To było pytanie do kolegów z teamu, stąd po angielsku, a co wy o tym myślicie?

What's your opinion about Marshmellow's Data Binding? Theoretically it should enable easier implementation of the Presentation Model. So a class, call it ViewModel wich provides (not sets) data, which a View reads automatically with help of binding. The View observs ViewModel class, so whenever something on the view has to be updated/changed it's enough to call in ViewModel notifyPropertyChanged. The view will automatically read new value and update itself. The main advantage I see is easier testing. ViewModel class doesn't modify the View directly, so it should be enough to test weather getters are giving proper data. (very simple sample test is here: https://labs.ribot.co.uk/approaching-android-with-mvvm-8ceec02d5442?source=latest--- ). Disatvantages which I see: Cannot reuse xml files. Yet another abstraction to use. Perhaps slower build time. I can imagine that in not trivial cases direct modification of views will be still needed.

http://martinfowler.com/eaaDev/PresentationModel.html
https://realm.io/news/data-binding-android-boyar-mount/
http://developer.android.com/tools/data-binding/guide.html
#androiddev
  • 18
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@darck: Databinding jak dla mnie to więcej kombinacji i problemów niż pożytku. Fakt faktem w kodzie fajnie wygląda, ale schodzi się z tym znacznie dłużej, kombinacja wyszukiwania co gdzie z xmla zostało użyte jest problematyczne i zaciemnia sprawę. Chyba zdecydowanie lepiej zacząć używać kotlina.
  • Odpowiedz
@pawelcar: ale potem chyba lepiej testować getery w ViewModel niż za pomocą Espresso czy view poprawnie się zmienia? Czy może w ogóle nie testujesz tej części kodu? Czy może uważasz, że takie testy nie zastępują testów integracyjnych z espresso, które są wystarczające. Bo uważam, że to może mieć sens tylko ze względu na testy.
A w jaki sposób rozwiązuje to Kotlin?
  • Odpowiedz
@darck: testuje na ile to możliwe i faktycznie im więcej kodu można przenieść do modułu javowego tym lepiej bo można je przejechać jUnitami, testy espresso też są ważne bo testujesz faktycznie to co się wyświetla na ekranie. Często jednak na testy nie ma czasu a klient nie chce za to płacić :) Co do kotlina to miałem na myśli sama notację, krótszy zwięzły kod i niekoniecznie zabawę, oczywiście databinding można
  • Odpowiedz
@darck: No właśnie Kotlin pozwala na testowanie getterów i setterów, bo każdy obiekt ma już właśnie te propertisy. NIe trzeba tego pisać, ale jest to dostępne. Co do DataBindingu, mam takie samo zdanie jak @pawelcar. Zaciemnia sprawę i trzeba grzebać po XMLach. A MVP jest idealne.
  • Odpowiedz
@darck: A teraz całkiem poważnie. Nie piszę co prawda w Javie, ale pracuję z Xamarinem i między innymi Androidem, gdzie podstawą dla mnie jest MVVM.

Uwagi:
a) cannot reuse XML files - skoro dzielisz widoki to prawdopodobnie część wspólna powinny mieć Twoje ViewModele. W takim razie dziedziczenie po bazowym ViewModelu powinno wyglądać OK - resuability layoutów.
b) MVVM samo w sobie nie pokrywa moim zdaniem wszystkich przypadków. MVVM Event-Aggreagor już tak. Po krótce wygląda to tak: tam gdzie bindingi są sensowne (edittexty, imageview, bindingi do commandow etc.) stosujesz bindingi.
Tam gdzie informujesz o zdarzeniu publikujesz wiadomość np. ( AsynchronousOperationFinishedMessage), którą obserwują odpowiednie widoki (czyli rejestrujesz obserwatory w Activity lub Fragmentach). Widoki, które zawierają obserwatory obsługują zdarzenie na różny znany sobie sposób. Przykładowo jeden z obserwatorów tej wiadomości odblokuje inputy, drugi rozpocznie jakąś animację i
  • Odpowiedz
@1080p: trochę offtop, czy w xamarinie aplikacje wyglądają tak samo na wszystkich platformach? Czyozesz dla każdej platformy zrobić inny wygląd aplikacji? Czy musisz znać SDK każdej z platform żeby moc pisać w xamarinie czy jednak jest to zgeneralizowane? No i najważniejsze czy xamarin udźwignie wszystkie nawet najdziwniejsze rzeczy? Niekiedy mając natywne SDK Androida jest coś trudno wykonać a co dopiero na wszystkie platformy na raz.

  • Odpowiedz
@pawelcar:
1. Masz Xamarin.Forms i Xamarin "Native"
To pierwsze - w teorii piszesz raz UI i "samo" zamienia Ci na widoki odpowiednie do platformy. W praktyce to nie działa i nie polecam - chyba, że dla małych appek ( ͡° ͜ʖ ͡°)

To drugie - masz natywne, pełne API dla każdej z platform (iOS/Droid). Różnica jest taka, że u Ciebie metody nazywają się np. onCreateView, u mnie OnCreateView - czyli Pascal notation ( ͡° ͜ʖ ͡°) No i API jest dostowane do C#, który nie oszukujmy się, ma dużo większe możliwości od
  • Odpowiedz
@1080p: dzięki za odp ( ͡° ͜ʖ ͡°) trochę jednak brzmi tak żeby n-------c dobrze w xamarinie to musisz znać dobrze wszystkie SDK poszczególnych platform
  • Odpowiedz
@pawelcar: Masz rację, ale widzisz co jest fajne na danej platformie, co fajnie byłoby z tego zaimplementować ( ͡° ͜ʖ ͡°) Gdyby nie Xamarin to w życiu bym nie przyznał, że WP to syf ( ͡° ʖ̯ ͡°)
  • Odpowiedz
2016, devloperzy WP nadal myślą że WP wygryzie andoida ( ͡° ͜ʖ ͡°)

@pawelcar: tak jest ze wszystkim

estuje na ile to możliwe...

@pawelcar: no ale nie odniosłeś się do meritum. Rozumiem, że nie korzystasz z żadnej wariacji Presentation Model, żeby
  • Odpowiedz
@darck: Nie. Możesz tak samo w XML lub w kodzie zrobić layout, ale chodzi o same obiekty które przy var image: ImageView mają z automatu getter i setter i nie musisz go samemu tworzyć.
  • Odpowiedz
@darck: Z databindingiem trzeba uważać, jeśli widok nie będzie najgłupszy jaki się da tzn. że wplatamy w niego logikę - robi się problem, a przy databindingu kusi żeby dodać tu if'a tam if'a :) Wg. mnie na pierwszy rzut oka fajne, ale do używania słabo - zaciemnia kod i ciężko się rozszerza te xml'e
  • Odpowiedz