Xcode. Pierwsze starcie.

9

Ostatnio opisałem swoje wrażenia po pierwszym dniu ze Swiftem: “Swift okiem programisty C#“. Już wiem, że będzie tego więcej! Nie dałem rady opisać drugiej – narzędziowej – części tego dnia… I dzisiaj nadrabiam zaległości.

Tak jak pisałem w poprzednim tekście, przez długi czas szykowałem się do powrotu do programowania. Rozmawiałem o tym z wieloma osobami, dzieląc się swoim planem: zrobię aplikację na ajfona! (Prawie) wszyscy życzyli powodzenia z zastrzeżeniem: “oj, w taki sposób to ty się do programowania ponownie nie przekonasz“.

Dlaczego?

Obawy i ostrzeżenia

Bo IDE słabe.

Bo uruchomienie CZEGOKOLWIEK własnego na telefonie po raz pierwszy to kilka dni roboty.

Bo “provisioning profiles” cię zjedzą.

Bo Apple kasuje sto dolców na dzień dobry i nawet nie wiesz za co płacisz.

Bo “Android spoko, ale z iOS to ty lepiej poczekaj aż się znowu wciągniesz“.

Pozytywnie to nie nastrajało. Więc… nastawiony byłem raczej negatywnie. Ale co tam, w końcu “Think for yourself. Question authority.“, c’nie? ;)

Jak było?

Xcode

Zaczęło się od instalacji Xcode. Samo instalowanie rzeczy na Maku jest bardzo niemiłe, nie znoszę iTunes i tego ich Store’a. Ale to akurat nie kwestia narzędzi developerskich, więc nie ma znaczenia.

Wszedłem na aplikację Xcode w Store. Wyjąłem portfel z szuflady, żeby w razie czego przed kamerką pomachać. Przeczytałem:

The Xcode IDE combined with the Swift programming language make developing apps easier and more fun than ever before.

No to chyba musi być dobrze, co nie? Nie kłamaliby w żywe oczy przecież.

Xcode instalował się z pół godziny. Najpierw szyderczo się rozHAHAłem że jak to tak, ale powoli, nie umiecie, japkowy niewypał… a potem przypomniałem sobie wielokrotną instalację Visual Studio i zamknąłem japę.

Dodatkowo zauważyłem, że Xcode wymaga jednak ściągnięcia 5,5GB zer i jedynek z neta. Może chwilę potrwać. Co zresztą jest przecież nieważne. Ważne, żeby się nie wywaliło w trakcie instalacji i nie wymagało restartu po jej zakończeniu. Oba warunki: spełnione. So far so good!

Pierwsze co odpaliłem w Xcode to “Playground” ze strony Swift Tour. I tutaj pierwsze zaskoczenie: sama koncepcja “Playground” jest rewelacyjna! Nigdy się z czymś takim nie spotkałem.

Instalacja na plus. Playgrounds na plus.
Trzy plusy i w mordę?

To konkretne playground polega na przeniesieniu całego tutoriala do IDE. Całość to normalny tekst – dokładnie ten sam co na podlinkowanej stronie – ale z możliwością modyfikowania i uruchamiania przykładów w kodzie. 100% Interactive! Bardzo fajne. Z tego co widziałem to playgrounds są różne i samo IDE może służyć nie tylko do czytania i pisania KODU, ale także nauki w ciekawy sposób. Drugi plus!

Trzy plusy i… w mordę?

No właśnie, na trzeci plus musiałem chwilę poczekać. Dlaczego? Bo dosłownie po kwadransie zabawy Xcode pada po raz pierwszy.

Tego się nie spodziewałem. To NIE JEST MORE FUN THAN EVER BEFORE, BITCH!!! To jest DLACZEGO RZUCIŁEM PROGRAMOWANIE!

Pogotowałem się chwilę, Xcode wstał. Za kilka minut wywalił się ponownie. W międzyczasie z Twittera dowiedziałem się, że tak po prostu jest. No cóż, widać taki nasz developerski kszysz.

Jestem oazą spokoju. Pierdolonym kurwa zajebiście wyciszonym kwiatem lotosu na zajebiście spokojnej tafli jebanego jeziora.
Wdech, wstrzymaj, wydech, do końca, trzymaj, trzymaj, wdeeech, trzymaj, trzymaj, trzymaj…. Loop for x in 0..10 … Uff, już dobrze.

A co poza tym? No cóż, Xcode to IDE jak IDE… choć nie do końca.

Latami kląłem na Visual Studio, nawet hejt-list po angielsku do jego autorów naskrobałem, zżymałem się i wyśmiewałem. Bo powolne, bo wielkie, bo się wywala… ale jak widać: Xcode też się wywala. I to na własnym prostym Applowym samplu. Będę jeszcze wnikał w różne ustawienia, ale póki co wygląda to nie tyle na IDE co edytorek tekstu z podpiętymi funkcjami deploy i drzewkiem plików.

Jest też oczywiście – i to całkiem fajnie działający – designer UI, co sprawia, że nie można Xcode ot tak po prostu porzucić, tfu, do worka i do rzeki. (tak, wiem, że jest AppCode od JetBrains, ale chcę zaznać doświadczeń programisty Swift jak Japko Nakazało).

Zaskoczyło mnie kilka domyślnych ustawień (jak na przykład otwieranie każdego pliku w nowym oknie zamiast w nowym tabie), ale 5 minut chodzenia po settingsach doprowadziło wszystko do porządku.
No… prawie wszystko, bo zmiana motywu/szablonu/theme faktycznie zmienia kolory, ale tylko w edytorze tekstu. Kolory samego IDE zostały takie same. Dogłębny 10-sekundowy research w internecie pokazał, że “tak ma być”, co w moim odczuciu nieco ubezsensawnia ideę themes w IDE. Temat do dalszej inwestygacji.

Ciekawym rozwiązaniem jednak – które zostawiłem włączone – jest wykorzystanie klawisza ESC do uruchomienia Intellisense. Sam bym sto lat myślał i nie wymyślił, fajnie się to sprawdza. Tym bardziej że inny binding, pokazywany w menu Xcode (ctrl+spacja) u mnie nie działa.

Xcode to dzieciak w krótkich portkach

Mamy dostępnych kilka refactoringów – ot, standard: rename, extract method, implement missing members itd. Brakuje takich ficzerów jak choćby wyniesienie klasy do osobnego pliku. Dodatkowo kontekstowość oferorowanych operacji jest dość uboga. Dla przykładu: jeśli nasza klasa nie posiada wszystkich funkcji z implementowanego protokołu (interfejsu), to refactoring “Add Missing Protocol Requirements” dostępny jest dopiero, gdy postawimy kursor na nazwie klasy; nie wystarczy, że kursor jest W klasie. Trochę to może utrudniać życie.
Ponadto okazuje się, że wsparcie dla refactoringu języka Swift dodano do Xcode dopiero niedawno! A przecież… no kurde, przecież i IDE i język nie powstały wczoraj! Nie ogarniam. No ale ważne że jest, choć szczątkowe.

Tak czy siak, Xcode w porównaniu do Visual Studio to ot, taki dzieciak w krótkich portkach, co do VS powinien mówić na “Pan”, spuszczać głowę gdy się na niego patrzy i nie odzywać się niepytany.

A to już przecież DZIEWIĄTA wersja, a nie pierwsza! Ooojjjjjjj, daleka droga jeszcze do “MORE FUN” i “EASIER”.

Lecimy dalej:

Deploy

Narzędzia narzędziami, już dawno nauczyłem się, że – szczególnie w tym kontekście – obniżenie oczekiwań zdecydowanie zwiększa satysfakcję z życia.

Jednak miałem cel: pierwszego dnia MUSZĘ mieć COKOLWIEK zainstalowane na TELEFONIE. Da się? Podobno nie. I wywalający się Xcode wcale nie nastrajał optymistycznie.

Przy tworzeniu projektu Xcode prosi o podanie jakiegoś “team” – można pracować bez tego, ale nie można wtedy wgrać aplikacji na telefon. Team, certyfikaty, provisioning profile… tutaj nastawiałem się na godziny walki. A walka trwała… z 30 sekund? Nawet nie pamiętam co zrobiłem, klik klik klik i gotowe. Uff. Ale czy to wystarczy?

Od pokodowania ważniejsze dla mnie było odpalenie czegokolwiek. Przejście przez cały ten żmudny proces od razu, na początku, żeby mieć to za sobą.

Miałem wcześniej styczność z emulatorami Pocket PC czy czegoś takiego w Visual Studio, baaaardzo dawno temu. Trochę to działało, trochę nie działało. Tutaj spodziewałęm się walki. A… jeden klik i odpala się piękny emulatorek z wybranym modelem IPhone. I… już, działa. Bez bólu, bez łez, bez płaczu.

Podbudowany lecę po kabel USB, żeby wpiąć swojego SE i uruchomić cokolwiek na fizycznym urządzeniu. Co prawda gdzieś w reklamach Xcode przewinęło mi się przed oczami, że można robić wdrożenia bez kabla, po WiFi. Ta, akurat, bajki dla małych dzieci. Nie ma to jak kabel (jak to Tomek napisał – jak używam kabla USB to od razu jestem developerem IoT!).

Wpinam kabel, podłączam telefon, klikam RUN i…

Podaję hasło -> ENTER. Znowu hasło -> ENTER. I znowu i znowu. Przy dziesiątym razie pomyślałem, że coś jest chyba nie tak. Okazało się że wszystko jest TAK, tylko okienko wyskakuje miliard razy! Po wybraniu “Always Allow” cały proces idzie dalej.

No… nie tyle “idzie” co “czołga się” dalej. Przy moim urządzeniu kręci się kółeczko i widnieje napis: “Preparing debugger support for Procent SE“. Czekam. Czekam. Czekam. W końcu się doczekuję i aplikacja się instaluje. JES!!

Deploy na telefon? Klik klik klik i gotowe!

Mam na telefonie aplikację BEZ ANI JEDNEGO PROBLEMU!

Ale teraz trzeba ją uruchomić. I:

Na szczęście tutaj komunikat o błędzie dokładnie mówi co trzeba zrobić: oznaczyć samego siebie (mój wyklikany wcześniej “Team”) jako zaufanego dostawcę aplikacji.

I… działa!

No ale dobra, nie dawało mi spokoju to wdrażanie bez kabla. “No to teraz na pewno się wywalisz i będę się z ciebie śmiał do rozpuku!” – wymamrotałem. Wchodzę w Window -> Devices and Simulators. A tam:

Zaznaczyłem. Odpiąłem kabel. Kliknąłem “RUN”. I szczęką uderzyłem o stół, bo – ponownie – ZADZIAŁAŁO!

Szok. I Niedowierzanie.

Żeby nie było tak różowo – nie za każdym razem działało po WiFi. Ale okazało się, że stary dobry sposób, tak doskonale znany z innych środowisk – czyli restart IDE – pomaga.

A no i – do tej pory za nic nie zapłaciłem! Akurat nie jest to jakaś wielka korzyść, bo z płaceniem za rzeczy nie mam problemu, ale jednak fakt godny odnotowania. Czyli te magiczne 99$ rocznie potrzebne jest dopiero przy wrzucaniu aplikacji do sklepu czy jak?

Podsumowując…

… było o wiele lepiej niż się spodziewałem.

Samym Xcode jestem nieco zawiedziony, ale jeszcze nie wniknąłem w niego zbyt głęboko. Co prawda wygląda na to, że za bardzo nie ma w co wnikać, alecusz.

Natomiast fakt, że w kilka chwil uruchomiłem – poprzez “powietrzny deploy” – aplikację na fizycznym urządzeniu, bez żadnych kłopotów, nastraja mnie bardzo optymistycznie.

Nie mogę się doczekać co dalej wyniknie z tej mojej przygody. Trzymajcie kćuki!

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

9 Comments

  1. Michał Kwiecień on

    “Bo IDE słabe” – po kilku miesiącach przyzwyczajasz się jak i jakoś się z nim współpracuje – intuicyjnie wiesz czego nie robić żeby go nie crashować :D

    “Bo uruchomienie CZEGOKOLWIEK własnego na telefonie po raz pierwszy to kilka dni roboty” – Nope, jak już sam zobaczyłeś, kilk i śmiga. Odpalanie apek przez wi-fi ma więcej problemów więc jeśli nie chcesz się zrazić i tracić czasu to polecam kabel.

    “Bo “provisioning profiles” cię zjedzą” – Całkowicie niepotrzebny temat podczas nauki (xcode generuje to sam), potrzebny dopiero do wrzucenia apki na sklep lub udostępnieniu apki gdzieś poza twój telefon. Jest sporo tutoriali step by step, po którymś razie już się to rozumie ;)

    “Bo “Android spoko, ale z iOS to ty lepiej poczekaj aż się znowu wciągniesz“.” – Po programowaniu na obie platformy stwierdzam, że iOS dużo przyjemniejszy na start – nie ma takiej fragmentacji i problemów że coś działa u ciebie a u klienta już nie.

    “Czyli te magiczne 99$ rocznie potrzebne jest dopiero przy wrzucaniu aplikacji do sklepu czy jak?” – Zmieniło się to kilka lat temu. Teraz potrzebne jest gdy chcesz dodać troche bardziej zaawansowane funkcje typu Push Notifications lub udostępnić innym ludziom apkę bez potrzeby wtykania kabla w ich telefon. Oczywiście do wrzucenia na sklep też potrzebne.

    Powodzenia dalej! Będę bacznie śledził twoje poczynania iOSowe! Przyuczam teraz jedną osobę na juniora z zerowym doświadczeniem. Jestem bardzo ciekawy porównania jak będzie wyglądało to u osoby która spędziła wiele lat w innej technologii.

  2. Xcode jest najwolniejszym IDE na jakim pracowałem ale jest tez AppCode na macOSy, No i wiadomo to nie VisualStudio. Xcode jest działa dobrze z objC z Swift jednak ciagle zchodzi do bazy czesciej niz powinno. Na pewno ogromnym plusem xCode jest to ze nie musisz stawiac CMAKE jak w Android Studio (czy tam *.mk) albo pre-build steps z palca pisac jak w VS tylko przeciagasz all do drzewa i on juz wie ktore statyczne bibliteki podlinkowac, gdzie przeniesc assety jak je traktowac ktore pliki kompilowac a ktore nie (np Shadery OpenGL) ma swoje plusy i minusy. Ogólnie patrzac na rozne dostepne IDE (Uzywalem VS, xCode, Android Studio, CodeBlocks, etc.) To Android Studio naprawdę jest najszybszym i najstabilniejszym. Trzeba pamiętać ze xCode to jest banka Apple i nie nadaje sie do niczego innego (No moze pisanie w C++ też jest znośne)

  3. Duża zmiana na plus z tym odpalaniem aplikacji na telefonie bez płatnego konta. :) Z tego co kojarzę jest taka możliwość jakoś od przełomu 2015/2016 ( iOS 9 i Xcode 7). Wcześnie niestety trzeba było mieć konto za 99$ rocznie, by odpalić na telefonie.

  4. Pingback: "Swift okiem programisty C#" okiem programisty Swift | devstyle.pl

  5. Grzegorz Kwasniewski on

    Jeszcze trochę posiedzisz i więcej kwiatków będzie. Ja zaczynałem na wersji 7 i wydaje mi się, że był bardziej stabilny niż 9. Czasami jest tak, że pierwsze pół godziny pracy nad projektem poświęcam na “połatanie” wszystkiego. Taki urok. AppCoda ponoć lepsza, ale nie sprawdzałem jeszcze. A na początku Android Studio mnie drażnił. Ogólnie szkoda bo iOS to bardzo fajna platforma.

Leave A Reply