Dopiero się ucze fluttera i mam pytanie co do pracy z restowym api, chcę np. po kliknieciu na button, wykonac akcje POST która przekaze dane z inputów do backendu, no i jesli nastapi sukces to powinno mnie przekierować do środka aplikacji. Jakiej biblioteki powinienem do tego użyć?
Na przykład http https://pub.dev/packages/http
Najlepiej wyszukać sobie, co tam ci pasuje na https://pub.dev/ - to taki zbiór wszystkich bibliotek dla dart i flutter.
Kilka linków, które mogą się okazać przydatne.
Ale zanim je przejrzysz to zachęcam do przyjrzenia się hasłu ``GraphQL```, które jest uważane za alternatywę (albo nieraz lepszą wersją/lepszym zamiennikiem) REST'a:
https://graphql.org/
https://bulldogjob.pl/news/1789-rest-vs-graphql-porownanie
https://www.howtographql.com/basics/1-graphql-is-the-better-rest/
https://www.mobilelive.ca/blog/graphql-vs-rest-what-you-didnt-know/
https://en.wikipedia.org/wiki/GraphQL
https://graphql.org/
Jeśli temat Cię zainteresuje to mogę dodać, że Flutter już posiada odpowiednie możliwości do korzystania z tego dobrodziejstwa:
https://pub.dev/packages/graphql_flutter
https://pub.dev/packages/graphql
https://hasura.io/learn/graphql/flutter-graphql/introduction/
A wracając do REST'a we Flutterze - obczaj poniższe:
https://flutter-tutorial.com/flutter-rest-api-tutorial
https://www.geeksforgeeks.org/implementing-rest-api-in-flutter/
https://www.tutorialspoint.com/flutter/flutter_accessing_rest_api.htm
Ło jezu ! Aż sam z przyjemnością pooglądam i poczytam ! :)
@cerrato a musze uzywac jakiegos state managera? Bo chodzi mi o cos takiego, np ze po zalogowaniu ma fetchowac od razu jakis endpoint i jak przejde na jakis widok, wróce to te dane powinny tam nadal byc.
Tu masz najprostszy sposób na to: https://docs.flutter.dev/development/data-and-backend/state-mgmt/simple
jak przejde na jakis widok, wróce to te dane powinny tam nadal byc
Nie do końca rozumiem pytanie, ale wydaje mi się, że mieszasz 2 rzeczy - komunikację (czy to przez REST czy cokolwiek innego) z nawigacją po aplikacji. Jedno z drugim raczej za wiele wspólnego nie ma.
Pobieranie/wysyłanie danych to jeden mechanizm i jak już je pobierzesz to tylko od Ciebie zależy, co z nimi zrobisz. A pokazywanie kolejnych ekranów nijak się ma do komunikacji przez sieć.
@cerrato: ale jeżeli pokazanie ekranu nie ma za każdym razem pobierać danych z webserwisu to wypada gdzieś je trzymać w pamięci poza drzewem widżetów
@Ghost_: no tak, ale to jest chyba oczywiste. W sensie - napisałem, że chyba nie zrozumiałem pytania. Ale to tak samo jak w webówce - jak robisz webaplikację to nie jest pożądanym działaniem, żeby np. po dodaniu klienta i wciśnięciu F5 ten klient się dodał ponownie ;)
W tym najprostszym przypadku pierwszy widok może trzymać dane i podawać drugiemu np w konstruktorze. Chyba że pierwszy to widok logowania, ten musi być zniszczony po zalogowaniu, tzn zdjęty ze stosu i drugi trzyma dane. Bo nie może być tak, że jak wciśniesz wstecz to znów wracasz do okna logowania bez wylogowania.
W ogóle zresztą, tokeny sesji wypada zapisać np w shared preferences i jeśli user się nie wylogował, to wcale nie pokazywać ekranu logowania, tylko od razu ekran główny po uruchomieniu aplikacji. A wylogowanie polega na usunięciu tokenów i pokazaniu ekranu logowania od nowa
Tylko ja bym w ogóle oddzielił trzymanie danych (a przynajmniej takich niezwiązanych z konkretnym widokiem) od widoków. A wtedy już nie ma znaczenia co jest na ekranie, bo dane są stałe i od widoków niezależne.
Ja bym proponował na początku zapoznać się z klasyką, czyli MVC.
Przykładowe linki:
https://medium.com/flutter-community/mvc-design-pattern-in-flutter-4ad6641b7863
https://medium.com/flutter-community/mvc-in-flutter-part-1-51d5eba081a3
Flutter jest po prostu stworzony do takiego modelu: mamy miejsce/miejsca gdzie trzymamy dane, mamy logikę i mamy widoki.
Zmiana np. danych automatycznie odświeża widoki i to wszystko w cenie "biletu".
Macie jakiś prosty przykład jak utrzymujecie strukture api u siebie w projektach?
Ja używam retrofit z dio.
Robert Karpiński napisał(a):
Ja bym proponował na początku zapoznać się z klasyką, czyli MVC.
Przykładowe linki:
https://medium.com/flutter-community/mvc-design-pattern-in-flutter-4ad6641b7863
https://medium.com/flutter-community/mvc-in-flutter-part-1-51d5eba081a3Flutter jest po prostu stworzony do takiego modelu: mamy miejsce/miejsca gdzie trzymamy dane, mamy logikę i mamy widoki.
Zmiana np. danych automatycznie odświeża widoki i to wszystko w cenie "biletu".
Do tego wystarczy ci provider i wszystkie widżety mogą być stateless. Każda zmiana modelu danych sama odświeży widżety, które podepną się pod model. To, co wkleiłeś to dla mnie jest przeinżyrowanie. Najprostszy przykład:
https://www.freecodecamp.org/news/provider-pattern-in-flutter/
Możesz też podpiąć się Consumerem, żeby nie odświeżać całego drzewa widżetów, a tylko jeden wybrany. Możesz nawet wsadzić notifyListeners
w setter i wtedy będzie to wyglądało jak zmiana wartości, która odświeży automatycznie gui - prawie magia.
Gdy widzę gdzieś setState
w kodzie i widżety stateful to już wiem, że to horror.