[M.....3]

Jeśli pole EditText ustawiam na przyjmujące tylko liczby, android:inputType="number", to powinienem w kodzie sprawdzić czy aby na pewno wartość znajdująca się w tym elemencie jest liczbą, czy mogę założyć że na sto procent jest to liczba i żadne sprawdzanie nie jest konieczne?
No gdyby się okazało że to jednak nie jest liczba to aplikacja się wysypie.

#androiddev

[Mike-Wazowski]

@Matt23: jeżeli zostawisz pusty Edit Text albo tylko separator dziesiętny to później Float.parse(s) wyrzuci wyjątek więc i tak zabezpiecz się w kodzie.

[ra_s]

@Matt23: Jeżeli użyjesz android:inputType="number" to user powinien tylko mieć możliwość wprowadzenie liczb i tylko liczb bo wyskoczy mu klawiatura odpowiednia do wprowadzania tylko liczb. Co innego z walidacja takiej liczby jak chcesz przesłać dalej wtedy back-end powinien mieć odpowiednia walidacje i ty na kliencie tez powinieneś mieć jakaś walidacje czy to liczba.

[M.....3]

@Mike-Wazowski: @ra_s: Ok, tylko która warstwa aplikacji powinna przeprowadzić walidację? Presenter czy View? W chwili obecnej robię to w warstwie View, czyli pobieram wartości z EditText, konwertuje na int i łapię ewentualny wyjątek i wyświetlam informację. Prawidłowo?

[Malthan]

@Matt23: Walidację powinien przeprowadzić prezenter i ewentualnie wywołać na widoku pokazanie stosownej informacji o błędzie.

[ra_s]

@Matt23: No nie View jak view? view głupie ma być do wyświetlania. Walidator w prezenterze niech się tym zajmie wtedy będzie łatwiej testować tego walidatora.

[M.....3]

@Malthan: @ra_s: Czyli widok ma jedynie przekazać wartości z pól tekstowych do prezentera? Czy może przekazać całe EditTexty? Już się trochę pogubiłem.

W prezenterze mam metodę doSomething(int a, int b); W tej sytuacji nie mogę jej wywołać od razu, bo ona wymaga liczb jako parametrów. A więc muszę sobie dodać jakąś metodę pośredniczącą (w prezenterze), która przyjmie String a, String b, spróbuje zrzucić na int i jeśli to się powiedzie

[ra_s]

Czy może przekazać całe EditTexty

@Matt23: Zartujesz tak ?

Masz wziąć co jest editText(ach) i zrobić jak opisałeś czyli nadpisz metodę ze stringami tam zrób walidacje.

[Malthan]

@Matt23: Prezentera nie powinno obchodzić to, że w ogóle istnieją jakieś EditTexty. Widok nie powinien mówić prezenterowi co ma robić. Widok powinien przekazać prezenterowi zdarzenie, np. wprowadzenie tekstu przez usera. Powiedzmy dla uproszczenia, że przekazuje String. Prezenter wie co z tym dalej zrobić - albo wywołać sobie swoją prywatną metodę doSomething(int a, int b), albo kazać widokowi pokazać komunikat błędu walidacji na polu X.

Oczywiście to dosyć urposzczony schemat zakładający wzorzec

[M.....3]

@ra_s: @Malthan: Tutaj jest więcej filozofowania niż kodowania i później się trzeba zastanawiać jak zrobić by było zgodnie z konwencją. No ale dla 15k warto się pomęczyć ( ͡° ͜ʖ ͡°). Dzięki za pomoc.

[ra_s]

@Matt23: Tu nie chodzi o konwencje. Takie coś ci będzie łatwiej testować, tylko kto by pomyślał o testach.... tak ? :)

[Malthan]

@Matt23: Po to jest konwencja, żeby nie trzeba się było ciągle zastanawiać ;) Wystarczy ją zrozumieć i stosować, a z wiedzą i doświadczeniem człowieka nabiera wprawy pozwalającej na łamanie konwencji z pozytywnym skutkiem.

[M.....3]

@ra_s: @Malthan: A jeszcze jedno pytanko mam. W zależności od pozycji elementu Switch chcę wywołać inną funkcję dla danych z editTexta. Czy powinienem przekazać prezenterowi wartości editTextów i elementu Switch i na poziomie prezentera zdecydować którą metodę należy wywołać, czy bezpośrednio w widoku wywołać inną metodę prezentera w zależności od pozycji switcha?

1)

onClick() {

presenter.decideWhatToDo(string1, string2, isChecked);

}

2)

onClick() {

if (isChecked)

 presenter.action1(string1, string2);

else

 presenter.action2(string1, string2);

}

[ra_s]

@Matt23: No pomyśl sam, w ktorym przypadku widok decyduje co robi prezenter zamiast prezenter decyduje co robi widok ? :)

[M.....3]

@ra_s: W myśli zasady, że widok ma być tak głupi jak się tylko da, rozwiązanie nr 1 wydaje się właściwe. Ale z drugiej strony, przerzucanie nawet najbardziej oczywistych decyzji na prezenter wydaje mi się bezsensowne.
Gdybym zamiast switcha miał dwa buttony to pod jeden button podpiąłbym presenter.action1(), a pod drugi presenter.action2(), czyż nie? Ma to więcej sensu niż wywołanie jednej i tej samej metody prezentera z dodatkowym argumentem, który

[M.....3]

W moim przypadku switch ma jedynie powodować że odpowiedź z prezentera będzie bardziej szczegółowa, więc wydaje mi się, że lepiej jest przekazać isChecked do prezentera i po prostu rozszerzyć w nim odpowiedź, niż robić dwie oddzielne metody.
Ale jakby w zależności od switcha miała się wykonać zupełnie inna akcja, np. zapisz / usuń, to w myśli tego co powiedziałem w poście wyżej, opcja nr 2 zdaje się być lepsza.
No chyba że

[ra_s]

@Matt23: Próbujesz się dostosować zamiast zrozumieć, przykład z dwoma buttonami jest inny niż przykład ze switchem wiec te przykłady maja tu dwa rożne rozwiązania i to nie ma nic wspólnego z konwencja (chyba). W jednym przypadku występuje boolean isChecked a w drugim nie.... jeżeli byś pisał test to tak żeby ten boolen był testowany a w drugim przypadku nie musisz sobie zawracać tym głowy bo masz dwa osobne buttony dwa osobne