corecoder.pl

Dlaczego na tym blogu nie ma komentarzy?

Bo taki ma być. Bo nie mam czasu czytać ani moderować komentarzy. Bo ci, którzy chcą ze mną pogadać potrafią znaleźć mój adres email i napisać do mnie. Bo wolę żebyś skomentował to, co napisałem na swoim blogu zamiast na moim. Bo tak lubię. Internet wszystko wytrzyma, moje fanaberie też.

Android SDK brzydko się rozkracza

Piszę to z ciężkim sercem, ale kilkumiesięczne doświadczenia z pracą z Android SDK nie dają mi wyboru. Google nie wie co to profesjonalne przygotowanie dokumentacji, pakietu SDK oraz programu developerskiego. O ile nie mogę się nachwalić Google App Engine SDK to niestety muszę powiedzieć, że Android SDK to nic innego jak wielka, parująca kupa g… Zanim napiszesz mi jaki głupi jestem krytykując Androida, przeczytaj ten akapit jeszcze raz i zauważ, że piszę o Android SDK a nie o samym systemie Android. To dwie różne rzeczy. Żeby nie było tak negatywnie zacznę od pochwały (no, może nie takiej oczywistej…)

Java czyli mogło być gorzej

Programiści rozpoczynający pisanie oprogramowania na Android'a od nauki Javy są podwójnie sfrustrowani, bo Java nie na darmo jest nazywana COBOL-em XXI w. Jej domeną są nudne, ale niezbędne do funkcjonowania współczesnej cywilizacji aplikacje, których zadaniem jest przetwarzanie danych dot. wydobycia i przetwórstwa ropy naftowej, prowadzenie systemów billingowych telekomunikacyjnych behemotów, czy systemów obsługi kont bankowych. Z tego powodu Java jest dla programistów piszących lub utrzymujących w ruchu oprogramowanie klasy enterprise tym samym czym kopalnia dla górnika i jego rodziny—jest jak matka. I dlatego ma tak wiele dzieci. Ta matka.

Jak żaden inny język programowania, Java zapewnia utrzymanie programiście i jego rodzinie; żywi niezliczone zastępy kierowników projektów, którzy języki programowania rozróżniają po długości nazw zmiennych i zagęszczeniu kodu na ekranie (Java dobrze wypada w tym rankingu, bo ma wysoki stosunek tekstu do tła, co daje pewność stałych bonusów w postaci korporacyjnej karty płatniczej i podróży na koszt firmy). Java to enterprise a enterprise to pieniądze. Takie prawdziwe, które można wydać w sklepie, a nie nadmuchane opcje na akcje w startupie. A tam gdzie są pieniądze, liczy się efekt końcowy a nie akademicki puryzm, co widać po chaosie w bibliotekach Javy. Kto próbował, ten wie. I od tego bałaganu nie udało się uciec twórcom bibliotek androidowych, bo na krzywych fundamentach krzywo się buduje.

Ten bałagan oraz ukierunkowanie na efekt końcowy (dostarczyć projekt na czas, nie ważne w jakim stanie) widać też w kiepskiej jakości dokumentacji. Javadoc już dawno nie jest wzorcem do naśladowania, ale jest wygodny dla programistów, którzy lubią kiedy im się wszystko kompiluje, nawet jeśli zamiast treści są puste miejsca. Testy przeszło? Przeszło. Pociąg w rowie? W rowie. A co było z unit-testami? Było 100% pass… Aha, to wszystko w porządku!

Szkoda, że Android SDK jest tak marnie udokumentowany i że Google nie chce go lepiej opisać. Szkoda, bo kto popracował przez 2-3 miesiące pisząc oprogramowanie dla systemu Android wie jak potężne jest to narzędzie. To na co pozwalają zamiary (moje, może nienajlepsze tłumaczenie rzeczownika "intents") mogę porównać tylko do zabawy w swobodną zamianę instalacji elektrycznyej, gazowej i wod-kan. w komedii Szczury Paryża. Z tym jednak zastrzeżeniem, że za pomocą Android SDK można na tej podstawie budować bardzo poważne rozwiązania. Jasne, że można to zrobić w 80% z iPhone OS SDK, ale łatwość z jaką pozwala to robić Android SDK jest porażająca. I to jest prawdziwa przewaga Androida nad iPhone OS. Kiedy pierwszy raz zdałem sobie z tego sprawę zakląłem pod nosem i pierwszymi słowami jakie przyszły mi do głowy były "Game over" (dla Apple iPhone i Microsoft Windows Mobile). Z powodu samych zamiarów oraz wielu innych perełek rozrzuconych po całym Android SDK jestem w stanie wybaczyć wybór Javy jako oficjalnego języka programowania dla Android OS. Nie przepadam za nią, ale rozumiem dlaczego tak się stało. Po prostu na rynku jest wielu programistów znających Javę. A bez programistów piszących oprogramowanie nie utrzyma się na rynku żaden, nawet najlepszy system operacyjny.

Bałagan na rynku Android OS

Przepraszam jeśli czegoś nie rozumiem, ale na którą wersję Android OS powinienem pisać swoje oprogramowanie? W chwili obecnej mamy na rynku kilka(naście?) milionów urządzeń działających pod kontrolą Android OS 1.1, 1.5, 1.6, 2.0 oraz 2.0.1. Pięć wersji systemu, kilka rozdzielczości ekranu (240 x 320, 320 x 480, 480 x 800, 480 x 854) dwie orientacje ekranu (pionowa i pozioma) i to wszystko w ciagu jednego roku? Czy ktoś w Mountain View dostał kreatywnej sraczki?

I dlaczego notatki na temat pisania oprogramowania na różne rozdzielczości ekranu nie zgadzają się ze stanem faktycznym? Dlaczego np. pomimo akceptacji opisu ekranu w wersji -large emulatory 800 i 854 nie odczytują go? Dlaczego muszę kupować kolejne urządzenia o różnych rozmiarach ekranu i z różnymi wersjami Androida aby mieć jaką taką pewność, że użytkownik zobaczy mój program tak, jak go zaprojektowałem? To po jaką cholerę mi ten emulator?

Możliwość wyboru jest rzeczą dobrą, ale nie na rynku konsumenckim, gdzie powinna być ograniczona i dobrze zarządzana jeśli chcemy odnieść sukces rynkowy. Tu Google jest ofiarą Open Source. To, co na rynku aplikacji serwerowych Open Source jest naturalne, czyli totalny bałagan w kwestii kontroli publikacji kolejnych wersji oprogramowania i związany z tym taniec z aktualizacjami, na rynku urządzeń konsumenckich po prostu się nie sprawdza.

Ktoś może powiedzieć, że Apple wypuściło w tym samym czasie więcej wersji iPhone OS i jakoś nikomu to nie przeszkadza. To prawda, ale Apple dokładnie kontroluje kanał dystrybucji aktualizacji i robi co tylko się da aby przebiegały one bezboleśnie. To nie Foxconn czy operatorzy sieci komórkowych decydują o tym, kiedy pojawi się aktualizacja, ale właśnie Apple.

To samo powinien zrobić Google. To nie HTC ani operatorzy sieci komórkowych powinni decydować o tym czy i kiedy użytkownicy dostaną oprogramowanie ale właśnie Google. HTC zrobiło świetną robotę przygotowując całkiem udane telefony, których naprawdę nie trzeba się wstydzić.(*) Co więcej, HTC Tattoo, czyli Android dla zwykłego użytkownika, bez blokady za ok. 1100zł jest sensowną alternatywą dla droższych smartfonów innych producentów. Wszystko to piękne, ale dlaczego HTC nie potrafi wypuścić aktualizacji do kolejnych wersji oprogramowania jednocześnie dla wszystkich telefonów? Czy liczy, że zrobią to spece od kastracji telefonów operatorzy? A może chodzi tu o klasyczne korporacyjne rozmycie odpowiedzialności? Google pokazuje palcem na HTC, HTC na operatorów, operatorzy na HTC, a HTC na Google? A użytkownik jest skołowany jak ten developer aplikacji na Symbiana, który za cholerę nie jest w stanie odgadnąć jakie plany ma Nokia i czy istnieje takie coś jak wspólny zestaw API dla przynajmniej 60% telefonów tej firmy?

Google musi wreszcie przejrzeć na oczy, zaakceptować smutny fakt, że są "źli" jak cała reszta systemu globanych korporacji i powykręcać parę rączek a jeśli trzeba—wysłać komu się należy koński łeb albo zdechłą rybę aby uporządkować ten cały bałagan. HTC sobie nie radzi, a operatorzy tylko czekają, żeby ktoś zdjął z nich ciężar użerania się z dziadostwem, które irytuje dział PR pytaniami o to "kiedy będzie Android 1.6 na HTC Magic?" Nikt nie chce zajmować się użytkownikiem końcowym, więc ten, kto to zrobi zdobędzie bogactwo, sławę i status na miarę Steve'a Jobsa. OK, trzeba będzie się schludnie ubrać i obciąć kucyk żeby wyglądać bardziej biznesowo. Ale chyba warto?

Siła Apple bierze się również z tego, że jest to z punktu developera w miarę jednolita platforma, co obniża koszty przygotowania oprogramowania. Dlatego Google powinno zabrać HTC oraz operatorom możliwość ingerowania w system, wyrzucić tandetne bajery typu Sense UI na śmietnik (Android 2.0 wygląda już znacznie lepiej) i publikować aktualizacje automatycznie, tego samego dnia, dla wszystkich. Skoro potrafi to Apple, potrafi to również firma, która zatrudnia samych geniuszy (np. takich, którzy na Google I/O 2009 opowiadają zebranym, że "documentation kinda sucks").

XML czyli niechciane tofu

Oglądałem kiedyś odcinek Bill Cosby Show pt. "27 and Still Cooking", w którym Bill chce przygotować żonie niespodziankę z okazji 27 rocznicy ślubu i sprowadza m.in. kucharza, który gotował im pierwszą wspólną małżeńską kolację. Niestety, kucharz postępuje zgodnie z najnowszą modą i dodaje do każdej potrawy kostkę tofu.

Robi się z tego niezłe zamieszanie, bo Bill nie może mu przetłumaczyć, że nie życzy sobie tofu i chce zjeść potrawy o tym samym smaku co dwadzieścia siedem lat temu. Zdesperowany zaczyna odławiać tofu z kotła, kiedy nie widzi tego kucharz. Przyznam, że podobne reakcje budzą się we mnie kiedy boję się otworzyć lodówkę, bo mam wrażenie, że czycha tam na mnie nowy dialekt XML.

Kiedy ktoś wciska mi XML do każdego zakamarka mojego programu wiem, że nie jest dobrze. Bierze się to z owczego pędu do obesrania ozdobienia wszystkiego znacznikami XML bez względu na to, czy ma to sens czy nie. Manifest aplikacji Androidowych naprawdę nie musi być otagowany. Pliki .ini albo tradycyjne pliki konfiguracyjne znane z systemów Unix/Linux są w zupełności wystarczające. Ale ponieważ mafia XML tako rzecze, nie da rady tego zmienić. Trudno. Skoro umiejętność pisania parserów w yacc lub bison zanika wśród absolwentów kierunków inżynierii oprogramowania, dostajemy XML-owego spaślucha. Co kto lubi, ale moim zdaniem SAX(y) to nie to samo co sexy.

Opis interfejsu użytkownika

Tu mamy ciekawy przykład na niegłupi pomysł totalne spieprzony przez kolegów z tego samego zespołu. Ktoś pomyślał, że dobrze byłoby opisywać intefrejs użytkownika za pomocą zagnieżdżonych znaczników. Hurrra!

To nic, że Apple, Microsoft czy nawet REAL Software (producent pakietu REALbasic) potrafią dać programistom całkiem przydatne narzędzia do rysowania interfejsu, które przy okazji generują odpowiedni kod źródłowy. Rysowanie interfejsu graficznego za pomocą XML-a jest jak słuchanie malarstwa holenderskiego… takie rzeczy pasują na haju po magicznych grzybkach, ale na co dzień kiepsko się sprawdzają. Wiem, że XML można znaleźć w wielu innych narzędziach programistycznych, tylko że tam go nie widać. Nie musimy z nim pracować. Cały ten ambaras z XML-em przypomina mi sytuację z szynką. Jest uznawana za rarytas a to przecież kawałek zwierzęcej dupy. Dupa służy do srania, siadania w gnoju albo kurzu, ale nad tym się nie zastanawiamy nakładając kolejny plasterek na talerz. Niech podobnie będzie z XML-em. Niech sobie będzie, ale nie każcie mi w nim maczać palców.

XML w Androidzie ma sens z punktu widzenia szybkiego dostarczenia programistom narzędzia, które może jest prymitywne, ale działa. Przy okazji warto wspomnieć, że geniusze z Google nie wymyślili nic nowego, po prostu pożyczyli pomysły dotyczące hierarchii widoków i kontrolek znane z bibliotek UI Java, które to zresztą zostały zapożyczone z pakietu Tk, którego pierwsza wersja powstała w 1988. To nic złego, dobrze jest korzystać ze sprawdzonych rozwiązań nawej jeśli próbujemy dla niepoznaki omotać je grubą warstwą XML-a. To gdzie nagle rozchodzą się drogi programistów Google i zdrowego rozsądku to wizualizator UI, który nie daje sobie rady z opisem prostego UI i źle wyświetla w Eclipse i emulatorze Androida, wymuszając testowanie na prawdziwym sprzęcie bez gwarancji, że na innym modelu, z inną wersją Androida będzie to wyglądało tak samo.

Drugi problem to brak wiary w XML w samej drużynie Google. Jeżeli jeden z geniuszy nonszalancko oznajmia, żeby nie używać XML do opisu UI, to coś jest na rzeczy. Ano jest, bo mistrzowie klawiatury nie potrafili zrobić czegoś prostego, tj. kompilatora, który zamieniałby XML na strukturę, ktora jest bardziej wydajna po kompilacji do kodu pośredniego. (To zostało już nieco poprawione, ale reszta kuleje.)

Skoro dwaj ewangeliści Androida mówią, żeby tego nie używać, to znaczy, że a) to nie jest potrzebne, albo b) ktoś spieprzył implementację. Pytanie tylko gdzie był kierownik projektu, kiedy podejmowano decyzje o wykorzystaniu XML do opisu UI oraz co za błyskotliwy (sz)koder nie potrafi tego zaimplementować w tak ważnym z punktu jakości pracy z systemem module jakim jest interfejs użytkownika.

Te dwa przykłady potwierdzają moją tezę, że jeżeli ktoś nie potrafi wyjaśnić dlaczego chce zastosować gdzieś XML, to nie wolno mu na to pozwolić. Zwolnić, wysłać na długi urlop, wykupić weekend do willi Hugh Hefnera i dać otwartą linię kredytową na pokrycie kosztów party z króliczkami Playboy'a, ale nie pozwalać dorzucać XML-a bez powodu oraz dobrego pomysłu na implementację.

Eclipse IDE czyli proteza goni protezę

Z góry przepraszam fanów i developerów Eclipse. Ja wiem, że ten IDE ma wielki potencjał. I zawsze będzie go miał. Niestety, na komputerze z 4GB RAM, działając sam, nie potrafi płynnie przełączać między siedmioma otwartymi plikami. Po godzinie pracy czas przełączania dokumentów pozwala na spokojne zagotowanie wody na herbatę.

Moje życzenie na rok 2010? Żeby ktoś wysadził w powietrze wszystkie repozytoria Eclipse na świecie. I zakazał pod karą dożywotniego odebrania dostępu do internetu odtwarzania tej kupy.

Pomysł na korzystanie z Eclipse IDE wydaje się z punktu kierownika programu genialny. Oto dostajemy wieloplatformowe środowisko programistyczne, do którego wystarczy podpiąć parę wtyczek i już będzie dobrze. A właśnie, że nie będzie. Eclipse IDE jest jedną z czarnych dziur, w których ginie zdrowy rozsądek (inne to XML, Ruby on Rails, wzorce projektowe, cloud computing, itp.). Pomysł był bardzo dobry, bo Eclipse miało być wieloplatformowym środowiskiem programistycznym tworzonym na zasadach Open Source. I jak często ma to miejsce w przypadku projektów Open Source, zbudowano wieżę Babel. Ta kupa kodu nie jest w stanie pracować na kompuerze z 4GB RAM i procesorze Intel Core 2 Duo 2.6GHz. Kto tu kogo robi w konia?

Moje rozwiązanie jest proste--odpalam Eclipse IDE, tworzę projekt a potem otweram ten sam projekt w TextMate. Czego nie mogę zrobić w TextMate, robię w Eclipse, a pisanie i modyfikacja kodu odbywa się teraz z szybkością błyskawicy. Z czasem zmodyfikuję Android TextMate Bundle tak, że Eclipse będzie mi niepotrzebne w 99% przypadków.

Eclipse jako najlepsze Open Source IDE? A pocałujcie mnie w dupę.

Niedorobiony Emulator

Szybka sonda, odpowiedz szczerze jak na spowiedzi, ile razy musisz oglądać następujący komunikat:

ActivityManager: Warning: Activity not started, its current task has been brought to the front

Teoretycznie komunikat powinine pojawiać się kiedy próbujesz uruchomić niezmodyfikowany program na Emulatorze. W praktyce pojawia się w sposób przypadkowy. Co robisz? Pewnie to, co ja czyli dodajesz i kasujesz spację a następnie ponownie odpalasz projekt na Emulatorze. Raz na 3-4 razy odpali nową wersję. Co 10-20 odpaleń trzeba restartować Emulator, bo coś mu się popierniczy i twierdzi, że ma rozdwojenie osobowości:

Emulator]emulator: ERROR: the cache image is used by another emulator. aborting

Komunikat pojawia się zwykle wtedy, gdy nie ma innego działającego Emulatora oprócz tego, z którym walczysz już od pół godziny.

Czasami Eclipse IDE daje sobie spokój i wyświetla komunikat o tym, że się nie doczekał startu Emulatora. Trzeba więc odpalać go ponownie"

Your App]emulator-5554 disconnected! Cancelling 'net.devguide.android.apps.yourapp.YourApp activity launch'!

A przy okazji, autorzy Emulatora zapomnieli, że biblioteki Carbon są już nieco przestarzałe o czym ostrzegają komunikaty przy starcie emulatora.

Warning once: This application, or a library it uses, is using NSQuickDrawView, which has been deprecated. Apps should cease use of QuickDraw and move to Quartz.

Hop, hop! Jest tam kto? Ktoś czyta te komunikaty? Czy wszyscy leją na to i debugują na darmowych G1/G2 rozdawanych googlersom?

Google to wyszukiwarka

O tym, jak silne zakorzenione w świadomości pracowników Google jest główne źródło dochodów firmy świadczy najlepiej to, że nie są oni w stanie podać łącza do wysłanego do marketu Android'a programu. Dokumentacja definiuje co prawda pół tuzina schematów łącz do wyszukiwania aplikacji, ale nie podaje przykładu łącza bezpośredniego… czy tak ciężko jest wygenerować łącze bezpośrednie w panelu publikacji appa? 

Google powinien odseparować dział Androida od reszty firmy, bo to szkodzi na głowę. Microsoft zrobił to z działem Xbox i nieźle na tym wychodzi.

Freakshow tylko za opłatą

Oglądając materiał wideo z sesji Google I/O 2009 dochodzę do wniosku, że dobrze Apple robi trzymając swoich geniuszy na krótkiej smyczy i pokazuje ich światu tylko za opłatą na specjalnych sesjach WWDC po uprzednim praniu mózgu (i koszul). Wystawianie na scenę człowieka, który potrafi w chwili szczerości spierniczyć wysiłki działu marketingu nie jest dobrym pomysłem. Bo szczerość jest piękna, ale nie chcemy słuchać szerych wyznań programistów, którzy spierniczyli narzędza, którymi posługujemy się na co dzień. Chcemy być uwiedzeni jak studentka przez 30-latka i nie żałować ani chwili. Zamiast tego dowiadujemy się, że jak coś źle napiszemy (a piszemy, bo dokumentacja "jest trochę do dupy" jak mówi jeden z ewangelistów Androida z Google) to się na nas ten czy inny mastach z Google obrazi… Czas dorosnąć bo Android SDK brzydko się rozkracza…

(*) Wczoraj wróciłem z hali targowej galerii handlowej "Plaza" w Lublinie gdzie zaobserwowałem klasyczną scenkę w salonie Play. 50-letni pan tak długo udawał, że nie może się zdecydować na HTC Hero, że w końcu zaczęły go do tego przekonywać żona, córka i sprzedawczyni. W końcu uległ. Lepszego dowodu na to, że para HTC/Android osiągnęła status Walkmana i na dobre zaistniała w świadomości zwykłego użytkownika nie trzeba.

AWK(1) żyje i ma się dobrze

Przyznam, że sprawa jest trochę głupia. Przy całym natłoku narzędzi, bibliotek, filtrów, itp. błyskotek do przetwarzania dokumentów tekstowych stary, poczciwy AWK bije większość z nich na głowę. Powinienem wiedzieć. AWK przeżuwa na naszych serwerach 20 000 000+ dokumentów dziennie. Tak, napisałem "ponad 20 milionów." Większosć filtrów piszę właśnie w AWK, potem w Pythonie, PHP i Perl-u. Potem Python pisze dane do CouchDB, SQLite, i Redis-a. I to jest właśnie siła Unix-a i oprogramowana Open Source. Mogę dopasować zestaw narzędzi do zadania, które mam wykonać a nie na odwrót.

Dwa boty na święta w prezencie od localolo.com

Czy maszyny, rośliny, a nawet wszelkiego rodzaju materia nieożywiona może się z nami komunikować? To pytanie zaprząta umysły ludzi od wieków. Programiści Tom Taylor i Tom Armitage znudzeni czekaniem na odpowiedź napisali jakiś czas temu boty monitorujące obiekty w przestrzeni kosmicznej, które mogłyby zagrażać Ziemi (@lowflyingrocks) oraz powiadamiająe o tym co robi most Tower Bridge w Londynie (@towerbrdige).

Zainspirowany ich pracą napisałem boty, które tłumaczą to, co publikują @lowflyingrocks i @towerbridge na język polski a potem publikują swoje tłumaczenia na serwisie blip.pl (^lufawkrzokach i ^towerbridge).

Oba boty mają swoje strony internetowe: lufawkrzokach.pl i towerbridge.pl.

Goodbye, Facebook

Po ostatnich problemach z ochroną prywatności zlikwidowałem moje konto na serwisie Facebook.

Polishwords WIKI

O, kurcze! Ktoś wpisał mnie do Polishwords WIKI.

Dziękuję!

P.S. Chociaż ciągle mam swój ulubiony mikrofon i fajny interfejs audio, mój powrót do regularnego podcastingu nie nastąpi w najbliższym czasie. Moje zdrowie nie pozwala na to. Ostatni miesiąc był całkiem dobry, ale brak przewidywalności stanu moich górnych dróg oddechowych nawet na kilka najbliższych godzin poważnie komplikuje moje plany nagraniowe. Chęci są, materiał też, ale niewielu chciałoby tego słuchać. Na razie będę wyżywał się tutaj.

Czyszczenie danych

W ramach projektu localolo.com współpracujemy z kilkudziesięcioma dostawcami danych. To naprawdę wspaniali ludzie, którzy rozumieją zyski płynące z dzielenia się danymi z tymi, którzy potrafią je przetworzyć na korzyść wszystkich (użytkownik dostaje pożyteczne informacje, dostawca dociera do odbiorcy przez localolo.com, a my mamy przy tym okazję też zarobić i tworzyć rzeczy nowe). Bez nich, localolo.com nie miałoby 500,000 wpisów w bazie danych w niecały miesiąc. A to dopiero początek.

Jedynym problemem na jaki napotykamy jest czyszczenia danych z kilku tuzinów formatów. Wewnętrznie składujemy je w formacie UTF-8, ale nasi partnerzy często jeszcze nie korzystają z UTF-8, albo dane nie są wolne od znaków spoza zakresu dozwolonego przez UTF-8. Jeden czy dwa wpisy to nie problem, ale kiedy próbujemy zautomatyzować import kilkunastu tysięcy plików źródłowych, musimy czyścić dane w brzydki sposób, za pomocą zestawu własnych skryptów na pisanych w Pythonie. Na razie to nie problem, ale zastanawiam się nad przepisaniem ich w Erlangu, bo możnaby wtedy zastosować parę ciekawych sztuczek z przetwarzaniem równoległym. Im dłużej o tym myślę, tym bardziej podoba mi się ten pomysł.

Prezentacja: iPhone OS – Strategie dla deweloperów

Bardzo mili ludzie z Auli Polskiej zaprosili mnie do zaprezentowania moich strategii biznesowych związanych z wydawaniem aplikacji na iPhone OS. Ponieważ mieliśmy trudności ze zsynchronizowaniem kalendarzy, prezentacja nie odbyła się w tym roku, ale mam nadzieję opowiedzieć o moich pomysłach w styczniu 2010.

Ponieważ prezentacja zmieni się do tego czasu, pomyślałem, że zamiast wyrzucać do kosza to, co miało być tłem do mojego wystąpienia w listopadzie, opublikuję slajdy tu a na styczeń przygotuję coś nowego.

iPhone Apps - Strategie Dla Developerów

View more documents from jacekartymiak.

Pomysł na prezent pod choinkę

Chcesz zrobić prezent ulubionemu projektantowi? Mam niespodziankę dla wszystkich, którzy wolą pracować w sposób tradycyjny, z ołówkiem w ręku. UI Stencils oferuje tylko trzy produkty, ale za to jakie: szablon do projektowania interfejsu aplikacji i stron www dla urządzeń iPhone / iPod Touch; szablon do projektowania interfejsu stron WWW dla komputerów oraz blok papieru do szkicowania z nadrukiem elementów okna przeglądarki Firefox.

Odwzorowanie barw na urządzeniach mobilnych

Problemem z jakim często się spotykam jest różnica w odwzorowaniu barw na ekranie monitora i iPhone'a. Z tym problemem radzę sobie eksportując różne wersje interfejsu użytkownika do programu iPhoto a potem synchronizuję je z urządzeniami testowymi (iPhone, iPod Touch i HTC Magic / myTouch / Tattoo / Hero). Wygląd grafiki sprawdzam przy jasności ekranu ustawionej na 50%. Potem koryguję wartości gamma dla plików przeznaczonych na platformy iPhone OS i Android.