Swift nauka bibliotek , taktyka, na pamiec czy jescze inaczej?

Powiedziecie mi prosze ,znam przykladowo juz jako tako skladnie jezyka, w miare rozumiem kod. Podam moze nie na przykladzie zerwnetrznej biblioteki tylko zwyklej metody o co mi chodzi, niech bedzie tableView i CellForRowAt.

Pytanie.- Czy przykladowo zdajac sobie sprawe z tego ze w table View istnieje cos takiego jak CellForRowAt , musze takze sie nauczyc jak mniej wiecej ta funkcja ma wygladac od srodka tzn ,ze musze wypelnic cell jakis tekstem czy musze tylko wiedziec ze istnieje cos takiego jak CellForRowAt a reszte juz ogarniam z dokumentacji.
Jak to jest u was ? CHodzi mi tylko o to zeby jakies dobre nawyki w sobie wyrobic bo w tym momencie jesli szukam informacji to wchodze na stackoverflow lub patrze po tutorialach. Jak wy robicie?

To samo tyczy sie JSON, Alomafire, jaka taktyke obrac podczas uczenia.
Nie mam zadnego backgroundu w programowaniu, wiec opieram sie tylko na tym jezyku, przez kilka miesiecy bladzilem i zastanawialem sie czy w ogole dam rade ale widze , ze zaczynam wychodzic na prosta co jest dla mnie mega sukcesem bo zastanawialem sie czy w ogole uda mi sie cos w tym jarzyc.

Wracajac do pytania , to samo moglbym zadac np z tworzeniem np Rootcontrollera Programatycznie wyrzucajac MainStorybard, czy mniej wiecej trzeba miec juz taka wiedze ze musimy wypelnic tam kilka linijek w Appdelegate czy w Dokumentacji sa takie instrukcje szczegolowo opisane?

Dziekuje za odpowiedz

CellForRow niekoniecznie potrzebuje labelki/tekstu. Ogółem jest to metoda i z hermetyzacji/enkapsulacji wynika, że na ogół powinieneś wiedzieć tylko: co metoda przyjmuje i co ma zwrócić. W tym wypadku musi zostać zwrócony widok, więc nadpisując tę metodę masz takowy stworzyć i zwrócić. Przyjmuje zaś index więc na podstawie indeksu masz dobrze rozpoznać jak stworzyć obiekt (co najczęściej przekłada się na odpowiednią tablicę z tekstami/obrazkami/czymś-tam utworzoną wcześniej).

Jak czegoś nie wiesz (lub ja nie wiem), to command + lewy przycisk myszy na metodzie i w wewnętrznej dokumentacji XCode (nad nagłówkami metod) masz wystarczająco dużo informacji (zazwyczaj).

Jak masz macOSa (a zakładam, że skoro Swift to masz), to zainstaluj sobie Dash (https://kapeli.com) i ustaw sobie na skrót klawiszowy (ja mam ⌥ + Spacja). Dzięki temu możesz szybko szukać w dokumentacji. Ogólnie IMHO nie opłaca się uczyć na pamięć na siłę. Z czasem sam zapamiętasz najważniejsze fakty, a od reszty masz dokumentację.

dzieki za odp. W sumie dosc jasno to wyjasniles. Co do metod to zawsze tak jest , ze byle wiedziec do czego metoda sluzy i jaka wartosc zwraca i tyle nam potrzebne? Reszta z dokumentacji?

Z tego co widze obaj jestesmy z Lublina:) chociaz jak uda mi sie w miare na juniora ogarnac Swifta to mam nadzieje ze juz nie:) Wracajac do tematu , a propoS JSON. Jak sie zabrac za to , jest tutoriali troche , mam przed soba jakis kod tylko pytanie jak i wczesniej, czy musze mniej wiecej znac jakies schematy na pamiec typu GET, POST czy tez bazowac na jakiejs dokumentacji? W dokumentacji Apple jest to dla mnie w miare juz jasne o co chodzi, natomiast JSON to chyba 3rd documentation o ile dobrze pamietam i tutaj nie wiem za bardzo na jakich materialach do tego bazowac.

Tulio napisał(a):

CellForRow niekoniecznie potrzebuje labelki/tekstu. Ogółem jest to metoda i z hermetyzacji/enkapsulacji wynika, że na ogół powinieneś wiedzieć tylko: co metoda przyjmuje i co ma zwrócić. W tym wypadku musi zostać zwrócony widok, więc nadpisując tę metodę masz takowy stworzyć i zwrócić. Przyjmuje zaś index więc na podstawie indeksu masz dobrze rozpoznać jak stworzyć obiekt (co najczęściej przekłada się na odpowiednią tablicę z tekstami/obrazkami/czymś-tam utworzoną wcześniej).

Jak czegoś nie wiesz (lub ja nie wiem), to command + lewy przycisk myszy na metodzie i w wewnętrznej dokumentacji XCode (nad nagłówkami metod) masz wystarczająco dużo informacji (zazwyczaj).

Jasne mam macbooka pro

Masz racje, nie ucze sie wszsytkiego na pamiec , wszystko samo wchodzi, natomiast chce sie skupic na powtarzaniu zadan tutoriali zeby to utrwalac i po prostu o sam schemat dzialania mi chodzi jak najwiecej wyciagnac z tego i czego sie musze nauczyc. Zaczalem nauke od 0 wlasciwie w styczniu, cos zaczalem juz kumac i widze ze musze to ustawic na wlassciwy tor, poniewaz postawilem sobie za cel marzec przyszlego roku , zeby wystartowac na juniora. Materialow zgromadzilem od groma. Podstawy z jezyka na biezaco wlasciwie uzupelniam na tutorialach, bo co cos przerobie to wyszukuje informacji na interesujacy mnie temat. O ile elementy z dokumentacji Apple sa dla mnie zrozumiale( w miare , przynajmniej widze ze juz jestem na wlasciwiej sciezce), o tyle Alomafire , Rest, Json z , ktorymi sie ostatnio zetknalem juz srednio, a przydaloby sie ten temat przyswoic dobrze i zastanawiam sie jak doswiadczeni devsi do tego podchodza.

Długa druga przed tobą drogi padawanie i wyboista. Uczenie się api Foundation w swifcie obecnie ma ten jeden mankament że nie wiadomo czy autorom nie strzeli do głowy jeszcze raz zmiana koncepcji nazewnictwa co już wersję temu miało miejsce :) Miałem niezły ubaw jak 90% copypastów z SO przestało nagle działać w swift 3. Powodzenia życzę :)

loza_szydercow napisał(a):

Długa druga przed tobą drogi padawanie i wyboista. Uczenie się api Foundation w swifcie obecnie ma ten jeden mankament że nie wiadomo czy autorom nie strzeli do głowy jeszcze raz zmiana koncepcji nazewnictwa co już wersję temu miało miejsce :) Miałem niezły ubaw jak 90% copypastów z SO przestało nagle działać w swift 3. Powodzenia życzę :)

Sugerujesz, ze zle podchodze do tematu?

Nie piszę w swifcie, ale generalnie ucząc się języka i biblioteki standardowej robię masę fiszek z nazwami, parametrami i kruczkami różnych funkcji, wyjaśnieniami pojęć itp. Pewnie, z czasem te najpopularniejsze i tak bym zapamiętał, ale ta metoda jest dużo szybsza i pozwala skupić się na myśleniu o problemie a nie na skakaniu co chwila do dokumentacji

Najważniejsze to czytać dokumentację. Najlepiej ze zrozumieniem.
Jak się dużo pisze używając danej biblioteki, to pamiętanie jak co działa samo przychodzi, ale wtedy będziesz robił coraz bardziej zaawansowane rzeczy i znowu trzeba czytać dokumentację, podopierać się google i stackoverflow (apple forum jest strasznie niewygodne, ale bardziej zakręcone rzeczy to tylko tam).

Ja kodze w C++ i Objective C (łącznie) (większość kodu idzie w C++ a potem za pomocą Objective C++ przerzucam most do Objective C i Swift).
Jak ana razie nie miałem okazji skorzystać z dobrodziejstw Swift-a, ale jako że biblioteki są wspólne to jak będę miał okazję to będzie to bezbolesne.

Niestety Apple lubi dymać third party developers.
Przykładowo korzystanie z Interface Builder zwykle oznacza, że co 2 - 3 lata trzeba będzie wszystko przekrzykiwać od początku. Na dodatek storyboard jest bardzo nieskalowalne.
Dlatego uwagi na temat Swift 3 jakoś mnie nie dziwią.

natomiast chce sie skupic na powtarzaniu zadan tutoriali zeby to utrwalac

To się nie opłaca, bo będziesz utrwalał to co już wiesz, a często same tutoriale (które są często słabo napisane). Poza tym będziesz utrwalał rzeczy, które są niepotrzebne.

Lepsze jest podejście ewolucyjne, czyli szukanie coraz to nowych wyzwań, problemów (tworzenie coraz to nowych projektów) i wtedy automatycznie potrzebne rzeczy będą ci się utrwalać, a pewne zapomnisz, a pewnych rzeczy się oduczysz. Czyli będziesz na plusie, bo przefiltrujesz sobie wiedzę, oddzielisz ziarna od plew, a nie będziesz utrwalać złych nawyków.

Bo nauka z tego samego ciągle to zamknięcie się na naukę i powielanie tego samego w kółko.

A same tutoriale są dobre na początek, ale w pewnym momencie trzeba je wyrzucić w kąt i napisać coś własnego.

Czyli praktyka > wiedza.

jaka taktyke obrac podczas uczenia.

Żadną. Po prostu przestań się uczyć. A raczej przestań przywiązywać uwagę do tego, bo każdy programista się uczy, ale dobrze jeśli robi to przy okazji zabawy/pracy a nie jest to jego główna aktywność, bo to do niczego dobrego nie prowadzi raczej...

LukeJL napisał(a):

natomiast chce sie skupic na powtarzaniu zadan tutoriali zeby to utrwalac

To się nie opłaca, bo będziesz utrwalał to co już wiesz, a często same tutoriale (które są często słabo napisane). Poza tym będziesz utrwalał rzeczy, które są niepotrzebne.

Lepsze jest podejście ewolucyjne, czyli szukanie coraz to nowych wyzwań, problemów (tworzenie coraz to nowych projektów) i wtedy automatycznie potrzebne rzeczy będą ci się utrwalać, a pewne zapomnisz, a pewnych rzeczy się oduczysz. Czyli będziesz na plusie, bo przefiltrujesz sobie wiedzę, oddzielisz ziarna od plew, a nie będziesz utrwalać złych nawyków.

Bo nauka z tego samego ciągle to zamknięcie się na naukę i powielanie tego samego w kółko.

A same tutoriale są dobre na początek, ale w pewnym momencie trzeba je wyrzucić w kąt i napisać coś własnego.

Czyli praktyka > wiedza.

jaka taktyke obrac podczas uczenia.

Żadną. Po prostu przestań się uczyć. A raczej przestań przywiązywać uwagę do tego, bo każdy programista się uczy, ale dobrze jeśli robi to przy okazji zabawy/pracy a nie jest to jego główna aktywność, bo to do niczego dobrego nie prowadzi raczej...

Czyli krotko mowiac mam sie opierac tylko na dokumentacji?

A dam przyklad jeszcze. Gdybyscie mieli taki problem. Chcecie stworzyc np aplikacje to-do-list, jak sie do tego zabieracie.

Nie chodzi mi tutaj kompletnie o to jak to zrobic tylko o to ,ze ja przerabiajac jakies tutoriale znam metody itd ale jesli nie widzialbym tego na tutorialach i chcialbym np dodac opcje "dodaj kolejny element do tabeli" i "odswiez zawartosc" skad mam wiedziec gdzie tego w ogole szukac i , ze cos takiego istnieje. To jest moj glowny problem chyba, z ktorym nie umiem sobie poradzic ;/

Na zdrowy rozum , wchodze w dokumentacje table view i szukam tego tam? Czyli jesli interesuje sie np praca z Table View to musze sie dobrze zapoznac z dokumentacja metodami, przeczytac wszystko po kolei itd. Dobrze rozumuje?

https://github.com/Alamofire/Alamofire , gdybym mial sie uczyc Alomafire to to bd odpowiednie?

jest takie powiedzenie "first make it work, then make it right, then make it fast"
najpierw robisz byle jak, żeby działało, a potem robisz retrospekcję i patrzysz na to co narobiłeś i myślisz, jak można zrobić lepiej. I przeprowadzasz refaktoring (przerabiasz kod, ale tak, żeby zachować funkcjonalność), ew. przepisujesz od nowa. Na tym etapie jest miejsce na robienie dodatkowego researchu, przemyślenia. Czyli "make it right" (przy czym "right" jest subiektywne. To ty decydujesz co jest "right").

A potem szlifujesz i robisz dalsze "końcowe" poprawki(czyli "make it fast", albo "make it beautiful").

Potem z kolei wracasz do punktu wyjścia, bo programowanie nie ma początku ani końca, tylko jest procesem interacyjnym, w kółko powracasz do tego samego tylko robisz to lepiej. Albo łapiesz się za kolejny problem i przechodzisz ten cykl od nowa, tylko rozwiązujesz już inny problem. To się nazywa Agile.

Na zdrowy rozum , wchodze w dokumentacje table view i szukam tego tam?

dobrym pomysłem jest też zobaczenie po źródłach różnych projektów na Githubie jak coś można rozwiązać. Niekoniecznie w swoim języku. Jeśli się uczysz Swifta (nowy język) to pewnie i tak będziesz musiał się uczyć programowania z materiałów do innych języków, np. do Objective C.

Jeśli dalej chcesz się bawić w zabawki Apple to poczytaj tego gościa https://www.mikeash.com/pyblog/ - zwłaszcza starsze wpisy. Tylko się nie przestrasz :D