Różowy Windows Phone i kobiety na wysokościach

28. stycznia we Wrocławiu odbyło się 8. spotkanie Women in Technology. Niecnie wykorzystałam swoją znajomość z szefową i wkręciłam się wtedy na prelekcję ze swoim cyrkiem obwoźnym, czyli wstępem do programowania w Windows Phone. Sam łysogórski zlot odbył się na 25 piętrze SkyTower. Przypomniało mi się dość szybko, że mam lęk wysokości, więc przez całe spotkanie unikałam wielkiego okna z tyłu sali. Mimo wszystko trochę go przełamałam i udało mi się uchwycić widoczny stamtąd uliczny zgiełk.

wit

Gosia rozpoczęła spotkanie od przedstawienia kilku nowości technologiczno-konferencyjno-sponsoringowych (jakkolwiek dziwacznie to brzmi Uśmiech). Następnie po krótkim przedstawieniu się wszystkich, rozpoczęłam prezentację.

Po ostatniej porażce konfiguracyjno-przygotowawczej, mój poziom pewności siebie oscylował w okolicach –10. Dlatego tego dnia pojawiłam się na miejscu dużo wcześniej i sprawdziłam, czy na pewno wszystko dobrze działa.

Działało Uśmiech … do momentu, gdy miałam rozpocząć. Na pierwszy ogień poszedł rzutnik – nie chciał wyświetlić niczego co miałam na ekranie, choć robił to zaledwie 15 min wcześniej. No ale powiedzmy, że się na mnie obraził za to, że udostępniłam go Gosi zamiast tkwić wiernie przyczepiona kabelkiem. Nie obyło się bez jego restartu, co wprowadziło nieco ożywienia, bo pilot również odmówił współpracy. Pozostała więc drabina i ręczne użycie guzika prezentera przyczepionego do sufitu.

Potem oczywiście padła mi sieć i wywalił się emulator, ale… wpadłam na iście genialny pomysł. Zamiast miotać się z szukaniem problemów w konfiguracji, postanowiłam zastosować najstarszą sztuczkę w świecie IT – turn it off and on again… wiedząc, że mój komp wstanie w czasie ok. 5 sekund. Decyzja ta zbawiła moje wystąpienie, a dalsza część przeszła już gładko i bez zbędnych przerywników.

W kilku momentach pojawiły się dyskusje, ponieważ na sali obecne były ekspertki od Windows Phone. Sama też dowiedziałam się kilku rzeczy, dzięki czemu moja prezentacja po raz kolejny została ulepszona. Przekonywałam jak zwykle, by w codziennej pracy używać urządzenia zamiast emulatora. A z racji takiego, a nie innego grona, wzbudzałam mniej kontrowersji, gdy machałam różowym telefonem.

WP_20140128_001-150x150

Po mnie nastąpiła kolej na ćwiczenie networkingowe, za przygotowanie którego należy się wielki szacun dla Kasi. Dowiedziałyśmy się (pewnie po raz kolejny) jak ważna jest komunikacja i jak różne może przybierać formy. Poznałyśmy się trochę lepiej i już w całkiem luźnym, choć nadal licznym gronie wybrałyśmy się na afterowego browara.

Żółtodziób w świecie Windows Phone – pierwsze kroki

Gdy zaczynałam swoją przygodę z programowaniem w Windows Phone (jakoś w maju zeszłego roku) okazało się, że to nie jest po prostu kolejny rodzaj projektu w Visual Studio. A szkoda, bo samo rozpoczęcie pracy, czy przeglądnięcie kodu, który zastałam w nowej pracy, wymagało wielu instalacji. Jasne, że wiele z nich dotyczyło konkretnych bibliotek użytych w projekcie, jednak kilka ruchów było niezbędnych, by w ogóle zacząć pracę z platformą. Postanowiłam opisać dla potomności te moje pierwsze kroki, a nuż ktoś skorzysta z opcji #lazyweb.

Konfiguracja środowiska developerskiego

By zacząć programować na WP8 (dla WP7 wymagania są mniejsze) potrzebne nam są przynajmniej :

  • Windows 8 64-bit (MSDN sugeruje, że musi to być Pro, ale to nieprawda),
  • Visual Studio 2012 (wystarczy Express),
  • Windows Phone SDK 8.0.

Tak jest na początek – samo SDK instaluje nam:

  • VS 2012 Express (jeśli nie mamy),
  • szablony projektów (które są już w VS jeśli mamy już choć wersję Professional),
  • Emulator WP

Tuta mała notka – emulator wymaga Hyper-V, więc jeśli chcemy go używać, wersja Windows powinna być przynajmniej przynajmniej Pro. Ale o samym Hyper-V za chwilę.

No i teoretycznie można zaczynać programowanie.

Tworzenie projektu

Tutoriali do WP jest całe mnóstwo. Nie ma sensu bym się powtarzała. Powiem tylko, że po instalacji SDK w VS pojawia się cała sekcja Windows Phone, można wybrać jeden z kilku rodzajów projektów i zacząć programować. Fazy budowy aplikacji przedstawię w kilku kolejnych wpisach.

Uruchamianie i debuggowanie

Gdy już stworzymy jakąś funkcjonalność lub jeśli chcemy sprawdzić jak działa szablonowy projekt, to trzeba go jakoś uruchomić. Tutaj mamy dwa wyjścia – emulator lub telefon.

Aby użyć emulatora potrzebujemy Hyper-V, które wymaga pewnych ustawień w BIOSie, DHCP, 4GB RAM i tego, by użytkownik należał do grupy Hyper-V Administrators. Tak naprawdę tych wymagań jest trochę więcej (odsyłam tutaj), ale widocznie miałam (tym razem) ogromne szczęście i mój lapek je wszystkie spełniał, nie musiałam więc nic dodatkowo konfigurować.

A jednak nie polecam zbytnio pracy na emulatorze. Jest wolny w działaniu (maaasaaaaakryyyycznieeee, chociaż, to się poprawiać pewnie będzie), bardzo wolno się uruchamia i nie zawsze zgodny z tym jak aplikacja zachowuje się na telefonie (chociaż tych różnic jest naprawdę niewiele). Dodatkowo, jeśli sobie go wyłączymy (np. przez przypadek, jak mi się często zdarzało), a nasza appka ma bazę danych, byliśmy do niej zalogowani, czy jej start trochę zajmuje, to przy kolejnym uruchomieniu emulatora musimy poczekać na to, aż on sam się rozkręci, aż nasza aplikacja wystartuje, trzeba się będzie zalogować oraz stracimy wszystkie zcachowane dane (również te z bazy danych).

Jakie w takim razie mamy wyjście? Słuchawkę 🙂 Podpinamy ją kabelkiem i uruchamiamy aplikacje na telefonie. Działa to trochę wolniej w trybie debuggowania (jednak to normalne), natomiast aplikacja zachowywać się będzie tak jak w rzeczywistości. Hola, hola, czy to takie proste? Tak, ale… Trzeba wykupić sobie konto developerskie i zarejestrować w nim telefon. Teraz to koszt ok 20$ rocznie i zapewniam, że jest warte nerwów, które można stracić przy walce z emulatorem.

Co z debuggowaniem? Tutaj nie ma nic szczególnego w stosunku do innych platform – możemy to robić zarówno na emulatorze jak i telefonie.

Miłego zaczynania! Uśmiech

Przystanek KGD.NET, czyli jak przegrać u siebie

W styczniu miałam dość gorący okres, więc moje Windows Phonowe tournee postanowiłam kontynuować w Krakowie, by już daleko nie jeździć. Drugi gig zaplanowałam więc 22 stycznia na 85. spotkaniu KGD.NET. Ogólnie rzecz biorąc… nie poszło mi za dobrze. Dlaczego? To za chwilę, bo najpierw zrelacjonuje wieczór.

Weszłam na styk, powiedziałam co wiedziałam (i parę dodatkowych rzeczy też) i z podkulonym ogonem zebrałam się z miejsca na widoku w bardziej ustronny kąt. Po przerwie publikę na szczęście przejął Paweł, który opowiadał o tym jak budować efektywne zespoły (tak Pawle, wiem, że polskie słowo nie oddaje tego co chciałeś przekazać Uśmiech). Wskazał na znaczenie różnorodności członków zespołu i przedstawił jak w to wpasowują się kobiety i ich naturalne predyspozycje. Nie z wszystkim się zgadzałam, ale w przeciwieństwie do prelegenta nie stały za mną wyniki badań naukowych Uśmiech

600_326350732

Jak to często na spotkaniach KGD.NET bywa, punkt 21. przyszedł personel sprzątający, czego efektem było pospieszne losowanie nagród i zakończenie spotkania. After party odbyło się przy ciekawych smakach piwa i… cydru gruszkowego(?), a pod koniec pojawiły się nawet jakieś shoty. W gronie ograniczonym do 5 osób (organizatorzy, czyli Marta i Jarek, Szymon, Andrzej i ja), posiedzieliśmy do ok. północy poruszając dość szerokie spektrum tematów, choć w większości technologiczno-pracowych.

No a teraz… kilka wskazówek jak położyć wystąpienie publiczne Uśmiech

Zapytać o feedback

… dzień przed wystąpieniem. Tak było – we wtorek poprosiłam o informację zwrotną osoby, które były obecne na mojej prelekcji w Warszawie. Choć ogólna ocena była dobra i niemal każdy powtarzał, że mu się podobało, to… no cóż, mamy skłonność do skupiania się na negatywach. Zresztą na tym właśnie najbardziej mi zależało.

No i mi się dostało Uśmiech Nie, no trochę żartuję, ale spisałam sobie te uwagi i zaczęłam intensywnie myśleć jak tych samych błędów już nie popełnić, zwłaszcza, że miałam okazję sprawdzić to następnego dnia. Dość powiedzieć, że zabrałam się za mission impossible. Może gdybym wzięła na warsztat jedną rzecz, to miałoby to szanse powodzenia w tak krótkim czasie jakim była doba. A w tej sytuacji, zamiast prezentować, co chwilę przypominałam sobie moją listę niedostatków i szarpałam się chcąc wprowadzić implementację rozwiązania ad hoc.

Zaprosić na występ wszystkich znajomych Królika

Pomyślałam, jestem u siebie, więc wiele osób przychodzących na KGD znam. Kilku znajomych uprzedziło mnie o swojej obecności tego dnia (innych zobaczyłam na liście zapisanych osób). Wiedziałam, że pojawi się jeden kolega z pracy i jeden z moich studentów. Nie spodziewałam się jednak, że ok połowa audytorium, to będą znane twarze – z dawnych prac, z obecnej, ze studiów, z twittera, a także moi studenci. Można byłoby się spodziewać, że znajomi to dobre wsparcie, w końcu nie życzą źle i wybaczą potknięcia. A jednak – mój stres wzrósł niebotycznie. Tak jakby zwiększyło się we mnie poczucie odpowiedzialności – trochę mniej wstyd wyłożyć się przy obcych Uśmiech

Spóźnić się

Nie żeby to była jakaś wyjątkowa sytuacja w moim wydaniu. Ja się wszędzie spóźniam, chyba, że planuję, że będę godzinę wcześniej – wtedy istnieje pewna szansa na punktualność. No ale nie stało się tak tego dnia, kiedy to byłam starą dobrą spóźnialską Basią. Dodałam przez to stresu również organizatorom, bo wg planu występowałam pierwsza, Paweł pojawić się miał później. Publika, chyba nie do końca to zauważyła, ale mi przybyła cegiełka stresu i kilka siwych włosów.

Próbować odpowiadać na pytania, na które nie zna się odpowiedzi

To już była zupełna porażka… Wstyd mi do tej pory. Zamiast zwyczajnie, gdy do takiej sytuacji doszło stwierdzić: “Nie wiem, nie znam się, zarobiona jestem”, zaczynałam po prostu mleć ozorem. Tylko, że na moje nieszczęście, na sali było kilku ekspertów od WP, no i moje “mądrości” były szybko weryfikowane.

Dlaczego tak robiłam? Do dzisiaj nie wiem do końca. Chyba przejęłam się wnioskiem, który padł na początku autoprezentacji. Pracuję z WP już ok pól roku, więc powinnam występować z pozycji osoby bardziej doświadczonej niż początkujący programista tej platformy. A ponieważ zazwyczaj nie mam w naturze przyznawania się do poziomu advanced w jakiekolwiek dziedzinie (chyba, że mówimy o spaniu, oglądaniu seriali czy innych technikach marnowania czasu), więc… naprawdę nie wiem.

Nie przetestować połączenia internetowego

Czy też, jeśli już o tym mówimy, nie przetestować uruchomienia VS, emulatora, programu. Ale od początku. Aplikacja, która pokazuję łączy się z Twitterem, więc potrzebuje internetu. W siedzibie ABB (bo tam się spotkania odbywają) nie udostępniają wifi dla gości, umówiłam się więc z kolegą, że mi jej trochę pożyczy. Ponieważ byłam spóźniona, przetestowaliśmy to łebkach, no i oczywiście efekt tego był taki, że gdy chciałam wyświetlić listę tweetów, internet przestał działać. Potem do buntu maszyn dołączył emulator, uruchamiając się we wszystkich rozdzielczościach. W pewnym momencie rozłożyłam ręce, bo już nic się nie dało zrobić. Byłam wdzięczna losowi, że pozostało mi VS i miałam jak pozywać kod.

Pech, wiem, ale też rzecz, która tak naprawdę najmocniej z przedstawionych tutaj zadziałała na negatywny odbiór. Jak coś nie działa, cała prezentacja spada w głęboką przepaść laaaaame i jest jej bardzo ciężko się z niej wykaraskać.

Tak naprawdę nie wiem, czy było tak źle jak opisuję, bo większość feedbacku z tego wystąpienia brzmi: “Miałaś wyjątkowego pecha”. Czy to oznacza, że miała pecha, była klapa, więc trudno, let’s move on, czy miałam pecha, ale mimo to pokazałam coś wartościowego? Nie wiem. Osobiście mam nadzieję, że szala przechyla się w tę drugą opcję. A ja mam materiał do pracy na kolejne razy, z których pierwszy odbył się tydzień później we Wrocławiu. Ale to już w kolejnym odcinku…

Windows Phone w stolicy

Pewnie nie wszyscy wiedzą, ale od kilku miesięcy zajmuję się programowaniem w Windows Phone. A ponieważ najlepsze tematy na sesje powstają w pracy, postanowiłam co nieco o tym opowiedzieć, gdy umawiałam się na swoją pierwszą poważną sesję na grupie .net. Temat jednak wtedy nie siadł, architektura była bardziej pociągająca, postanowiłam więc ruszyć z nim w tournee w inne rejony.

I tak 16. stycznia tego roku pojawiłam się w końcu jako prelegent na 71. spotkaniu WG.NET. W końcu, bo Michał, szef grupy, namawiał mnie na wystąpienie już… 6 lat temu. Ale, jak to mówią, co się odwlecze, to nie uciecze, zawitałam więc w końcu do stolicy.

Osobiście bardzo podobał mi się support, zrobiony przez Sebastian Solnicę, który opisywał różne czary, jakie można zrobić przy debuggowaniu z pomocą Visual Studio. O większości nie miałam bladego pojęcia, a ponieważ lubię się uczyć nowych rzeczy, jestem Sebastianowi bardzo wdzięczna. Dodatkowo niezmiernie przypadły mi do gustu jego dowcipy. Nie miałam więc nic przeciwko temu by snack rozciągnąć do… 40 minut, bo świetnie bawiłam się przy tej prezentacji. Oczywiście cały ten czas zjadał mnie stres, a dzięki temu chwilę mojego wystąpienia mogłam nieco odwlec. Wreszcie jednak nadeszła godzina zero… wyszłam i  zaczęłam mówić.

Prezentacja

Moja prelekcja nie miało być monologiem eksperta, lecz garścią informacji o tym jak zacząć budować aplikacje na WP i na co zwrócić uwagę. Nie chciałam nawet nikogo przekonywać do programowania mobilnego ani pracy na tej platformie. Miałam natomiast meta cel – by zachęcić innych do występowania, nawet jeśli w danym temacie nie są alfą i omegą.  Dużo może dać samo przygotowanie prezentacji. Dla mnie największym wyzwaniem było zrobienie aplikacji od zera, gdyż w pracy zastałam ją w pewnym sensie gotową. Siedziałam nad tym cały (piękny Uśmiech) weekend.

Plan początkowo miałam taki, by taką prostą appkę zbudować na oczach widowni. To by dopiero mi dodało parę punktów do zaje…fajności. Wiadomo jednak jak to jest z planami – aplikacja się rozrosła i tworzenie jej w real time byłoby niczym innym, jak strzałem w kolano. Zdecydowałam się więc na pokazywanie kodu i jego różnych aspektów.

Agenda wyglądała mniej więcej tak:

  • Konfiguracja środowiska deweloperskiego
  • Uruchamianie i debuggowanie
  • Jak budować GUI
  • Zastosowanie MVVM
  • Testowanie
  • Praca z bazą danych
  • Kilka niespodzianek programistycznych

Gdy już zaczęłam, czułam się bardzo dobrze i swobodnie. Pewnie dlatego, że audytorium było bardzo przyjazne, choć niestety dla mnie już nieco zaznajomione z WP. Poczułam lekki pomruk zdziwienia i rozczarowania, gdy przyznałam, że nie jestem ekspertem i pokażę podstawy. Mimo to dostałam wiele pytań w trakcie, a także po i nawet umiałam na niektóre opowiedzieć (o czym później). Przede wszystkim zdałam sobie sprawę jak jeszcze niewiele wiem i jak dużo pracy przede mną.

Po wszystkim, jak to jest w zwyczaju, postanowiliśmy się wybrać na piffko. Szkoda, że jedynie w znanym mi gronie Kuby, Marcina, Karola i Sebastiana (chłopaki załóżcie blogi, będziecie się świecić na niebiesko Uśmiech). Liczyłam po cichu, że poznam kogoś nowego, ale mimo to świetnie się bawiłam, a stres prezentacyjny powoli, za to skutecznie ze mnie zszedł.

Feedback

Po pewnym czasie poprosiłam osoby obecne wtedy na sali o feedback, a o tym co m.in. było tego konsekwencją jeszcze kiedyś napiszę. Teraz przedstawię czego się dowiedziałam, a być może to spowoduje, że wezmę sobie te informacje do serca. Ponieważ ja zawsze wszystko wiem, najbardziej druzgocący był dla mnie fakt, iż można było mnie czymś zaskoczyć, że ludzie mają uwagi, o których nie miałam pojęcia.

Plusy

Nie będę robić kanapki z g…, w końcu to mój blog i moja informacja zwrotna. Powiem więc najpierw o tym co było fajne, a potem przedstawię obszary do poprawy. Po pierwsze miło było się dowiedzieć, że byłam pierwszą dziewczyną-prelegentką występująca na wg.net. Inną sprawą na plus było to, że odbiór prezentacji był dość pozytywny. To było zresztą widać, gdy po prelekcji ludzie podchodzili do mnie i pytali o rady. Dostałam też kilka maili w związku z tematyką.

What’s the point?

Jak to często u mnie bywa, dużo mówiłam, ale brakowało jasnego celu, zdania czy tezy, wokół których obracałaby się prezentacja. Męłłam ozorem, ale nie wynikał z tego żaden wniosek. Choćby taki czy fajnie czy niefajnie programuje się w WP. W pewnym sensie miałam nadzieję, że moim clu będzie to, że na platformie programuje się… śmiesznie i dość niedeterministycznie. Nawet udało mi się to pokazać – publicznie wywaliło mi się debuggowanie, internet, a nawet Visual Studio, a chciałam pokazać jedynie jak wolno uruchamia się emulator. Ale i tu pojawiły się wątpliwości u odbiorców – wyszło trochę nieprofesjonalnie.

Q&A

Inne informacje dotyczyły tego, że pozwalałam na pytania w trakcie prezentacji, a nie czekam z tym na koniec. To podobno dość rozpraszało odbiór. Trochę mnie ta uwaga zasmuciła, bo kontakt z widownią jest dla mnie kwestią priorytetową, a bez pytań się tego nie osiągnie. Najgorsze, że momentami wydawało się, iż nie znam odpowiedzi, a próbuję jednak ją wyprodukować zamiast przyznać, że czegoś nie wiem. Z drugiej strony sama zadawałam chyba za mało pytań, co tylko smutek mój spotęgowało.

Inne dobra…

Z innych spraw – widać było, że się stresuję, siedziałam, co minimalizowało dynamikę (choć to trudno będzie przeskoczyć, gdy pokazuje się kod) i za dużo robiłam osobistych odniesień do znajomych z sali. Dodatkowo dostałam dwie skrajnie różne uwagi – pokazywałam za mało i za dużo kodu, więc w tej kwestii muszę zdać się na własny judgement call.

Podsumowując, wystąpienie na wg.net było dla mnie bardzo przyjemne i wygląda na to, iż również dla słuchających mnie osób. Mam więc nadzieję, że jeszcze dostanę zaproszenie do Warszawy Uśmiech

Focus i bindowanie w Windows Phone

Pewnie starzy wyjadacze Windows Phone’owi problem znają, a nawet zapomnieli, że istnieje, ale mi się od czasu do czasu odbija czkawką, gdy próbuję zbudować nową aplikację. Chodzi mianowicie o następującą sytuację.

Budujemy aplikację, mamy w niej stronę, a na stronie kontrolkę z bindingiem. Niech będzie to TextBox.

<TextBox Text="{Binding MyText, Mode=TwoWay}" />

Jak widać nasz TextBox jest związany z polem MyText. Oznacza to, że jeśli w kontrolce wpiszemy jakąś wartość tekstowa powinna ona wylądować w polu MyText.

Nasza aplikacja może wyglądać np. tak:

Binding

Dodam, że pod przycisk w AppBar podpięte jest jakieś zachowanie, które wykorzystuje wartość wpisywaną do pola tekstowego. A jednak gdy wpiszę coś do kontrolki i spróbuję użyć tej wartości w metodzie, to widzę, że MyText jest nullem. Czyli pole się nie zaktualizowało.

image

Po długich rozkminach i czytaniu internetów, w końcu doszłam do wniosku, że nie jest to moja wina. Chodzi mianowicie o to, że bindingi się nie aktualizują, jeśli wciąż na kontrolce jest focus. Co więcej, kod zadziała jeśli najpierw wpiszę tekst, potem tapnę gdzieś poza pole tekstowe (aby stracił focus), to nagle property jest wypełnione.

image

Rozwiązanie jest proste, trzeba podpiąć zdarzenie Click pod AppBarButton, by znalazł naszą kontrolkę (w tym wypadku TextBox), zaktualizował binding i ustawił focus na stronie głównej:

private void ApplicationBarIconButton_OnClick(object sender, EventArgs e)  
{
    var focusedElement = FocusManager.GetFocusedElement() as TextBox;

    if (focusedElement != null)
    {
         var binding = focusedElement.GetBindingExpression(TextBox.TextProperty);
         if (null != binding)
             binding.UpdateSource();
    }
    Focus();

    // do something with MyText value
}

Tylko ja się po raz kolejny na tej platformie pytam… why? Dlaczego muszę to robić sama…? I to dla każdej kontrolki, dla każdego AppBar… Dlaczego to nie jest coś out of the box?

ABC aplikacji mobilnych

Jak już ostatnio pisałam, będąc w Rzeszowie, opowiadałam o tworzeniu aplikacji mobilnych. Skupiłam się głównie na synchronizacji danych, ale wspomniałam również o kilku innych cechach, które odróżniają je od np. webowych, czy desktopowych. Tematyka może być niezbyt odkrywcza dla kogoś, kto pracuje z aplikacjami mobilnymi, ale gdy ja po raz pierwszy siadłam do komputera, by zostać developerem Windows Phone, zupełnie nie wiedziałam z czym to się je. Myślałam, że zwyczajnie siądę do Visual Studio, otworzę projekt stworzony w specyficznym szablonie i… zacznę programować.

Okazało się, że to nie takie proste, nie tylko dlatego, że zanim cokolwiek dało się zrobić musiałam zainstalować tysiące rzeczy, ale również ze względu na fakt, iż nie jest to zwykła aplikacja warstwowa. Więc jaka? Z grubsza aplikacje mobilne można podzielić na dwa rodzaje – natywne i webowe.

Aplikacja webowa, czy też responsive desing, to tak naprawdę strona internetowa zaprojektowana dla mniejszego ekranu. Aplikacja natywna z kolei, to taka, która jest ściągana i instalowana na urządzeniu. Którą wybrać i kiedy używać? Jak zwykle – to zależy… Wybrałam kilka aspektów, które przedstawiłam podczas spotkania, ale oczywiście jest ich o wiele więcej.

Wieloplatformowość

Jeśli planujemy działanie naszej aplikacji na wielu platformach (albo choćby na dwóch), to mniejszego nakładu pracy będzie wymagało stworzenie wersji webowej. Dzisiaj jedynie niewielka ilość działa tylko na jednym systemie. Głównie z uwagi na to, by nie skazywać użytkowników na  kupno odpowiedniego sprzętu, albo nie skazywać nas na klęskę rynkową, bo użytkownicy raczej nie kupią odpowiednich telefonów tylko dla naszej aplikacji. Poza tym dostęp do funkcjonalności z różnych źródeł może być cechą bardzo pożądaną ze względu na UX. W przypadku aplikacji natywnych, każda platforma to tak naprawdę odrębne środowisko i wymagać będzie adekwatnych umiejętności developerskim. To może oznaczać, że będziemy potrzebowali wiedzy na temat każdej z platform i zapewne również różnych ludzi, którzy tę wiedzę posiadają.

Wykorzystywanie funkcji smartfonów

Czy twoja aplikacja będzie używać funkcjonalności specyficznych dla urządzenia? Będzie dzwonić, wysyłać smsy, robić zdjęcia? Chociaż aplikacje webowe rozwijają się w kierunku wykorzystania coraz większej ilości funkcjonalności telefonów wciąż, jeśli bardzo chcesz na nich polegać – wybierz aplikacje natywną.

Personalizacja

Jedną z największych zalet aplikacji mobilnych jest możliwość użycia personalizacji urządzenia przy jak najmniejszych ograniczeniach. Ponieważ aplikacje natywne są ściśle związane z urządzeniem, pozwalają na lepsze wykorzystanie ich możliwości.

Praca offline

Jasne jest, że jeśli mamy mieć możliwość pracy offline, to nie ma wyboru – należy zdecydować się na aplikację natywną. Ale po co w ogóle pracować bez sieci? Czy dzisiaj w ogóle istnieje taka potrzeba? No cóż, pewnie są takie miejsca na świecie, gdzie odpowiedź jest negatywna, ale gdy myślę o moich niedawnych podróżach z Krakowa do Warszawy, kiedy to przez jakieś 60-80% czasu nie miałam zasięgu, to niestety muszę przyznać, że tak.

Więc kiedy potrzebujemy takiej formy pracy? Niestety jeszcze przez jakiś czas nie tylko w lesie czy w samolocie. Oczywiście nikt nie wyobraża sobie “pracy” z facebookiem w trybie offline, ale jeśli myślimy o aplikacjach, do których wprowadzane są dane (np. Evernote), to uniemożliwianie pracy użytkownikowi, bo jest on odcięty od sieci, nie wydaje się sensowne. Miejmy nadzieję, że to się niedługo zmieni, wi-fi będzie praktycznie wszędzie, a tam gdzie jej nie zaznamy, poratuje nas XG/LTE czy jakiś następca. Ale póki co, jeśli chcemy pracować z przesyłem dużej ilości danych, to wielu z nas wybrałoby opcję, by działał jedynie gdy mamy internet.

Czego więc potrzebuje aplikacja działająca offline? Przede wszystkim lokalnej bazy danych. Bazy która najczęściej jest spersonalizowana – zawiera jedynie dane dla konkretnego użytkownika, więc nie jest to kopia bazy globalnej.

offlineapp

A teraz najlepsze – siedzimy sobie w lesie, pracujemy nad naszym zbiorem danych i wszystko jest fajnie dopóki… jesteśmy offline. Bo jeśli chcemy z tych danych skorzystać na innym urządzeniu, to potrzebna będzie synchronizacja.

Jak ona się odbywa? Po pierwsze nasza aplikacja mobilna pobiera dane, których brakuje w stosunku do tego co jest w globalnej bazie danych. Można to zrobić np. używając timestampów. Po drugie do bazy globalnej należy wysłać lokalne zmiany wprowadzone na urządzeniu. W najprostszym przypadku rozpatrywanymi zmianami są utworzenie, usunięcie i zmiana stanu obiektów.

I tu pojawić się mogą konflikty. Na przykład skąd wiadomo które dane mają być zaakceptowane jako finalne? Te z serwera, czy lokalne? Można odpowiedzieć, że te które są nowsze, ale co jeśli zmiany w tym samym obiekcie zostały wprowadzone równolegle, na dwóch różnych urządzeniach? Które powinny zostać uznane za ostateczne, skoro zostały wprowadzone na podstawie stanu bazy globalnej?

W przypadku dodawania nowych obiektów częstą praktyką jest użycie lokalnych identyfikatorów na urządzeniach mobilnych. W trakcie synchronizacji, obiekty takie są rozpoznawane jako nowe, dodane do globalnej bazy danych, gdzie nadawane jest im globalne id. I tu pojawia się kolejny aspekt, który powinien być obsłużony w trakcie synchronizacji, czyli relacje między obiektami. Jeśli np. dodajemy nowy obiekt i obiekt z nim powiązany, to skąd wiadomo na którym id bazuje ta relacja? I co się stanie gdy połączymy nowy obiekt z już istniejącym? Jak serwer czy nawet nasza logika sobie z tym poradzi?

Aktualizacje

Aktualizacje są zawsze bardziej bolesne w przypadku aplikacji natywnych, dla których należy je wprowadzić na wszystkich platformach. Dodając do tego kwestie bazy danych, dochodzi tutaj wzięcie pod uwagę jej aktualizacji. Każda nowa wersja oprogramowania może skutkować zmianami w schemacie danych i potrzebą dostosowania lokalnych baz do globalnej. Jeśli więc planujesz częste update’y, lepiej to robić w responsive design, bo wiąże się to ze zmianą aplikacji i bazy tylko w jednym miejscu.

Podsumowując – łatwiej jest zbudować aplikację webową, natomiast jeśli chcemy stworzyć coś poważniejszego, nie obejdzie się bez aplikacji natywnych.

Rzeszów, Karotki i aplikacje mobilne

Jak już wcześniej wspomniałam 18. października odbyło się 3. spotkanie rzeszowskich Karotek. Tematem wiodącym miały być aplikacje mobilne i kwestie z tym związane, co w tym konkretnym przypadku sprowadziło się do dwóch aspektów: marketingu mobilnego i architektury. Ale to za chwilę…

Tamten piątek był dla mnie bardzo trudny. Za sobą miałam intensywny dzień, w nocy prawie nie spałam, a w perspektywie pozostawała podróż do Rzeszowa, stres prezentacji i kolejny długi wieczór. Każdy kto mnie zna, wie, że byłam o krok od znalezienia mniej lub bardziej wiarygodnej wymówki i pozostania cały dzień w łóżku by odespać wszystko co mnie już spotkało i co jeszcze miało mnie czekać. A jednak, zebrałam się i po południu zawitałam do stolicy województwa podkarpackiego.

Na szczęście spotkałam tam Olgę, organizatorkę GGC w Rzeszowie, która swoim entuzjazmem potrafi zarazić nawet taką marudę jak ja. Zorganizowała wszystko tak, iż mimo zmęczenia wykrzesałam nie tylko trochę, ale nawet całkiem sporo energii.

Pierwsze prezentację przeprowadziła Monika Mikowska – oczywiście w szpilkach z gigantycznym obcasem Uśmiech Monika ma niesamowitą wiedzę na temat marketingu mobilnego. Dowiedziałam się o wielu, mniej lub bardziej spełniających swoją funkcję, aplikacjach dostępnych w na różnych platformach. Jedna z nich (wg prelegentki jedna z tych mniej sensownych) mi osobiście bardzo się spodobała. Po raz kolejny przekonałam się jak seks dobrze się sprzedaje. Niestety nie ma jej na WP…

Moje wystąpienie miało dotyczyć budowy aplikacji mobilnych. Miałam pewien kłopot związany ze stopniem techniczności. Nie znałam backgroundu audytorium i nie wiedziałam na ile mogę poszaleć i jak nisko zejść. Przedyskutowałam to wcześniej z Olgą i postanowiłyśmy, że przedstawię słuchaczom szersze kulisy pracy programistycznej.

W efekcie zdecydowałam się na opis architektury aplikacji mobilnych. Skupiłam się na tych działających w trybie offline, bo responsive design z tej perspektywy sprowadza się do aplikacji webowej tyle, że na telefonie/tablecie. Aplikacje, które mogą działać gdy nie ma internetu, wprowadzają za to pewien ciekawy aspekt – synchronizację danych.

I o tym właśnie opowiadałam. Wciąż nie byłam pewna jaki poziom szczegółowości zapewni zrozumienie zarówno tego co ja mowie jak i złożoności samego tematu. Postanowiłam skupić się na nakreśleniu kilku kwestii, jakie należy rozważyć przy projektowaniu synchronizacji danych, w tym na obsłudze konfliktów. Opisałam jak się przechowuje dane w relacyjnej bazie danych i okrzyknięta zostałam ID girl. Podobno mówiłam zrozumiale, więc uważam to za swój wielki sukces Uśmiech Więcej o samej zawartości merytorycznej opiszę (jak obiecałam) w osobnym poście.

Sama organizacja wydarzenia miała dość kameralną atmosferę. Pochodzę z okolic Rzeszowa i miło było poczuć podkarpacką atmosferę. Żeby tego było mało, uraczeni zostaliśmy pysznym ciastem marchewkowym.

Po naszych prelekcjach nadszedł czas na postintelektualne pifffko. Miałam okazję zobaczyć piękny rzeszowski rynek i zjeść pyszny vyprazany syr (wybaczcie mnie puryści językowo ortograficzni). Monika co prawda miała lekki kłopot przy chodzeniu po kocich łbach, ale dała radę.

Wspomniałam, że dzień był ciężki dla mnie z powodu niewyspania. A ponieważ sen (a zwłaszcza jego brak) to dla mnie kwestia może nie życiowa, ale wpływająca na samopoczucie, poważnie obawiałam się o swój stan dnia następnego. Szczególnie, że znów położyłam się późno. Na szczęście Olga i jej współlokatorka okazały się na tyle gościnne i wyrozumiałe, by nie budzić mnie do 11. Naładowałam akumulatory i następnego dnia z humorem wróciłam do domu. Dzięki dziewczyny!