Wpis z mikrobloga

Opisuję na blogu moją przygodę z Flutterem, w którym tworzę hobbistycznie side-project od ponad roku (można znaleźć na moim githubie) i fascynacja nie mija. Aplikacja wydana na Android i iOS, jest ogrom tematów do rozpisania, a dzisiaj #chwalesie pierwszym wpisem stricte technicznym o tym jak pozycjonować elementy na ekranie - https://rykowski.dev/blog/flutter-layout-grid/ Na taśmie produkcyjnej leży temat zarządzania stanem aplikacji - podstawy, bez dodatkowych paczek - a dalej czas pokaże ( ͡º ͜ʖ͡º)

#flutter #programowanie #tworczoscwlasna
  • 9
@harakiri888: Ahhh, kojarzę. Też swego czasu patrzyłem, ale jeszcze przed implementacją apki wiedziałem że będę budował projekt średnio-mały i wydał się overkillem. Padło ostatecznie na Scoped Model (teraz już przestarzały ale mi nie przeszkadza - działa tyle ile od niego potrzebuję) i się doturlałem do finiszu (deploymentu). Z ciekawości - znajomi obalili technologię czy pomysł samej aplikacji?
@kamil-rykowski: pomysł, sam w sobie nie był zły ale marginalne szanse na przebicie; później się okazało że już jest coś podobnego.

No jest srogi overkill, nie ukrywam; u mnie się nie sprawdził, ale idea mi się podoba i jakbym miał jakiś większy projekt robić, to pewnie w tej architekturze, z tym że strasznie mało jest materiałów czy też projektów na których można byłoby się wzorować (nie wiem jak to obecnie wygląda).
@kamil-rykowski: Nie pokazuj takiego antypatterna jak funkcje zwracające widgety, jeżeli chcesz coś wyciągnąć żeby nie było redundancji to należy stworzyć nowy stateless/statefull widget, żeby silnik sam rozkmnił kiedy rerenderować
@MrRuby: Dlaczego antypattern i dlaczego muszę tworzyć nową klasę widgetu, gdzie będę miał więcej kodu do utrzymania i pokazania w przykładzie? Nie niesie to w tej konkrentej aplikacji żadnej korzyści. A z drugiej strony chętnie bym poczytał porównanie tych dwóch technik i benchmarkiem który pokaże ile mogę zyskać i o jakim rzędzie wielkości mówimy.
@MrRuby: Dzięki, dobrze wyjaśnione co i dlaczego. W aktualnej apce sporo używałem rozbijania builda na kilka mniejszych metod z trzech powodów: oszczędność czasu, widgety i tak były specyficzne dla ekranu i wiedziałem że nie będę ich re-używał, myślenie że to jednak będzie wydajniejsze bo drzewo nie zawiera dodatkowego zagłębienia. Cóż człowiek się uczy całe życie :) Chociaż w przykładach z bloga nie ma to znaczenia bo są całkowicie stateless i nie