Gdzieś między Polską a Niemcami, a szczególnie w NRD

Twit Programmers of the Year (6)

Blog robi się powoli monotematyczny, dziś znowu o programowaniu, głownie na Androida.

Klient już czwarty tydzień załatwia papiery, a oczywiście terminy zakończenia poszczególnych etapów już ustalone i potem czasu będzie mało. No ale nie moje zmartwienie, ja zrobię co się da, ale tym razem o nadgodzinach mogą zapomnieć. Za to siedzę w domu i rozpracowuję prywatne programowanie pod Androida na koszt pracodawcy. Całkiem dobry układ. Jakbym był na własnym rozrachunku, to mogłoby boleć, a tak nie mam stressu (oczywiście poza stressem związanym z oddawaniem co miesiąc braterskiej części tego co klient płaci pracodawcy, ale coś za coś).

Do mojego nowego komputera dokupiłem porządny zasilacz. Dwa tej firmy (BeQuiet!) już w domu miałem, do serwera kupiłem nówkę, modularnego (znaczy kabelki dołącza się według potrzeby) serii 8 (im mniejszy numer, tym starszy, aktualne serie to 11), drugi to była używka dla syna, niemodularny serii 8 (syn ma komputer w normalnej obudowie mini tower, więc kabelki nie przeszkadzają specjalnie w przepływie powietrza). Teraz też nastawiłem się na używkę na eBayu, modularnego serii 7 lub 8. Prawie aktualne (serii 10) jako używki chodzą po 70-80 EUR, jak mocne to nawet wyżej. Serie 7 i 8 dają się kupić za jakieś 35-40 z wysyłką. Udało mi się wylicytować za zaledwie 31 z wysyłką, bo sprzedawca się trochę przechytrzył wystawiając cenę startową aż 25 EUR i nikt poza mną się nie zainteresował. A zasilacz jest z bardzo drogich serii high-endowych (Dark Power Pro P7), wygląda na nie używany (niemal wszystkie kabelki mają jeszcze oryginalne zawieszki), jak go obejrzałem to szczęka mi opadła. Już opakowanie wyraźnie różni się od tych tańszych (ma okienko, kabelki pakowane są indywidualnie w kartoniki), zasilacz jest trochę większy niż standardowy (znaczy pasuje jako ATX, tylko w jedną stronę jest trochę dłuższy, w moją małą obudowę wszedł bez problemu). Kabelków jest duży asortyment w różnych kombinacjach, wentylator zasilacza jest podłączany do złącza monitoringu na płycie głównej, a zasilacz może jeszcze sterować czterema dodatkowymi wentylatorami. Praktycznie go nie słychać, nawet z bliska. Super rzeczy, te zasilacze, polecam.

Decyzja o zrobieniu sobie komputera z 8GM RAM była bardzo dobra - system + Thunderbird + Firefox + inne drobiazgi + Android Studio + emulator biorą łącznie 6-6,5 GB, jeżeli ktoś ma zamiar próbować robić apki na 4GB to odradzam z góry, szkoda nerwów.

Wróćmy do programowania. Próbuję robić aplikację, i Android nie za bardzo mi się podoba. Znaczy API sporo potrafi, jest tam trochę niezłych koncepcji, ale wyraźnie za mało zastanawiali się nad usability. Bo wygląda to tak:

Aplikacja Androidowa zbudowana jest z Activities. Activity (upraszczając) to jest screen + kod do niego, ma to swój wieloetapowy lifecycle, można wydzielić sobie reusable kawałki GUI zwane Fragment. Fragment ma znowu swój lifecycle, trochę inny niż Activity. No i porządnego, pełnego diagramu tych lifecykli nie znajdziecie na http://developer.android.com, trzeba szukać gdzie indziej. Zasadniczy problem polega jednak na tym, że w Androidzie wszystko jest asynchroniczne, nie ma nawet czegoś takiego jak windowsowy dialog modalny. Nawet okienko w rodzaju Yes/No/Cancel jest niemodalne, aplikacja biegnie dalej i trzeba wszystko synchronizować we własnym zakresie. Nie byłby to aż taki wielki problem, gdyby nie to, że ma to również znaczenie podczas lifecycle Activity/Fragmentu. Na przykład mogą one wymagać uprawnień dostępu do jakichś serwisów (na przykład kamery). I jak praw nie ma to albo trzeba o nie interaktywnie zapytać, albo rzucić jakimś błędem. No ale to jest w trakcie startu, nasz kawałek jeszcze nie jest w żadnym stabilnym stanie! Nie da się zatrzymać startu, a o wyniku zapytania użytkownika (czyli czy w ogóle jest sens startować) dowiemy się dopiero później. Przecież to wcale nie chce współgrać ze sobą! Zacząłem więc kombinować jak powinna wyglądać architektura standardowej aplikacji, żeby to wszystko sensownie działało i to wcale nie jest proste. Poguglałem i widzę, że co bardziej kumaci deweloperzy też mają podobne uwagi i kombinują różne rozwiązania. Muszę jeszcze trochę poczytać, co proponują. Na razie znalazłem rady żeby robić Reactive Programming przy pomocy JavaRx, no jest to jakaś propozycja, ale nie jestem całkiem przekonany czy będzie to pasować do moich koncepcji.

Ale tak według mnie, to powinno być zadanie projektantów systemu! Jeżeli każdemu deweloperowi każemy wymyślać koncepcje, jak by tu ogarnąć chaotycznie zaprojektowany system, nie dając mu nawet szkicowych szablonów rozwiązań, to z góry można założyć, że minimum dziewięćdziesiąt kilka procent wymyślonych rozwiązań będzie marnych. Nawet jak deweloper jest ogólnie dobry, to dopiero po paru skończonych aplikacjach będzie wiedział, co robił źle. Co się dzieje jak nie ma patternów to ja widzę na codzień w pracy. Na moje oko to Androidowi brakuje jakiejś porządnej warstwy albo frameworku żeby łatwo dało się pisać bardziej złożone aplikacje. Bo proste quick and dirty idzie łatwo i przyjemnie, ale porządne, z pełną obsługą błędów i wszystkimi szykanami to duży problem. Powiedziałbym, że to prawie jak programowanie aplikacji windowsowych bez MFC. (Tylko nie bierzcie tego porównania zbyt dosłownie - API Androida jest znacznie bliższe MFC niż czystym Windowsom z ręcznie robionym event loopem, w końcu sporo lat minęło od tamtych czasów, tyle że API Androida jest o wiele bardziej skomplikowane niż windowsowe).

A tu jeszcze dokłada się fakt, że system jest w ciągłej zmianie. Nowe idee się pojawiają, stare zmieniają się (i to często więcej niż raz), jeżeli aplikacja ma chodzić na iluś wersjach wstecz to zaczynają się schody. Google dostarcza biblioteki robiące kompatybilność wsteczną, ale o dokłada tylko następny stopień złożoności - której trzeba użyć, a bez której można się obyć. A potem aplikacja na latarkę ma dwa megabajty, bo ciągnie ze sobą bez sensu ileś bibliotek kompatybilnościowych - nie są reusowalne w systemie, o nie. Ma to swoje uzasadnienie w koncepcji systemu (każda aplikacja to osobny user unixowy i nie ma sharingu czegokolwiek wprost między aplikacjami, zawsze musi to iść przez mechanizmy systemowe), ale skutki są niemiłe.

Dla ilustracji: Najstarsze urządzenie Androidowe jakie w domu mam, ma wersję Androida 4.1.2 (kryptonim: Jelly Bean, co to za US-amerykański pomysł, żeby nazywać wersje od jakichś obrzydliwych słodyczy, Lollipop, Marshmallow, rzygać mi się chce jak to czytam) to jest API numer 16. Logiczne więc, że chcę żeby moje apki chodziły przynajmniej od tej wersji. Ma to oczywiście również związek z wielkością rynku docelowego - w użyciu są urządzenia rożnych wersji, im wcześniej zaczynać, tym większa ilość potencjalnych klientów. Startując od API 16 pokrywamy jakieś 96% używanych na świecie urządzeń, im późniejsze API tym urządzeń mniej. Nadchodzący Android 8 (SDK i emulacja już jest, można sobie obejrzeć) to będzie API 26. W wersjach 4.x prawa dostępu były akceptowane przez użytkownika podczas instalacji, przy braku akceptacji aplikacja nie była instalowana. W późniejszych wersjach użytkownik był pytany dopiero przy starcie aplikacji i mógł odpowiedzieć tak albo nie, zależnie od humoru, a aplikacja mogła mu pokazywać wyjaśnienie, po co potrzebuje dostęp do tego. No i to oczywiście są kompletnie różne koncepcje, jednolite obsłużenie tego żeby chodziło w dowolnej wersji jest trudne. Ponieważ jest trudne, to Google wrzucił na GitHuba całkiem niezłą bibliotekę do tego (nazywa się easypermissions), zastrzegając sobie przy tym brak jakiejkolwiek odpowiedzialności i wsparcia, ale ja się pytam, dlaczego to nie jest wprost w API, a przynajmniej w SDK? I skąd początkujący developer ma wiedzieć, że takie rozwiązanie w ogóle jest, a nawet, że go potrzebuje?

Co do marnej obsługi wyjątków, na którą narzekałem poprzednio to powoli widzę, dlaczego nie dało się zrobić jej porządnie, z checked exceptions, ale oczywiście to nie jest komplement. Znalazłem natomiast, co można zrobić z nieobsłużonymi wyjątkami - jest taki serwis, do którego informacje o wyjątkach mogą być wysyłane. Nazywa się to fabric, wymyślił to Twitter, teraz należy do Googla. Ze dwie linie w programie, rejestracja w sieci i można mieć informacje o wszystkich nieobsłużonych wyjątkach w swojej aplikacji u dowolnego użytkownika z wszystkimi danymi (stack trace, sprzęt, czy rootowany, wersja systemu itd.). Do tego można mieć jeszcze life data o swojej aplikacji - ilu użytkowników używa jej w danej chwili, chyba nawet można wiedzieć co robią (jeszcze nie sprawdzałem tak dokładnie). Z jednej strony piękna rzecz przy developmencie, z drugiej to aż się zimno człowiekowi robi - przy każdym starcie aplikacji wysyłany jest do Google również AdvertisingId, co pozwala imiennie zidentyfikować każdego użytkownika z wszystkimi jego najprywatniejszymi danymi. Deweloper oczywiście tego nie dostaje do ręki, ale Google to ma. Podobno większość aplikacji używa tego fabrica, więc żadna różnica czy ja go użyję, czy nie - Google ma użytkownika na talerzu i tak. No i jeszcze trzeba zainstalować plugin u siebie, w Android Studio, i ten plugin zna każdy projekt w workspace. Kto zagwarantuje, że Google nie ogląda sobie tych projektów żeby wyłapać nowe idee i wejść z tym samym wcześniej?

Pamiętam hejt na Microsofta ćwierć wieku temu (Gates w mundurze SA, z flagą w której swastyka została zastąpiona logo Windowsów, na czele rzeszy SA-manów, pod hasłem "Ein Reich, ein Führer, ein OS") , pamiętam jak mieli koncepcje żeby Windowsy były na wszystkim (Windows for Pen, Windows for TV...), wczesne reklamy Apple sugerowały że Microsoft to Wielki Brat. No ale przecież najdalej posunięte pomysły MS to było małe miki w porównaniu z tym co robi "Don't be evil" Google. A Google jakoś nikt w podobny sposób nie karykaturuje.

Rysunek o MS  znalazłem tylko we fragmencie, pewnie pousuwali te całe ze względu na tekst.

Ein Reich, ein Führer, ein OS - to była gruba przesada

Ein Reich, ein Führer, ein OS - to była gruba przesada

-----------------------------------------------------------------------------------------------------------------------

Dotyczy: ,

Kategorie:Programowanie

Komentarze: (14)

Twit Programmers of the Year (5)

W pracy skończył mi się projekt, inny dział chce mnie koniecznie do innego projektu, tym razem dla klienta z trójramienna gwiazdą, ale zanim papiery załatwią to jestem w domu na koszt firmy. Pierwszy raz w życiu nie mam bieżącego projektu. Całkiem fajnie - wyporządkowałem już pół piwnicy i dalej walczę z programistycznymi twitami od Androida.

 Miałem już wszystko poustawiane, w Eclipsie, domowy serwer Git-a, Jenkins, itd., wymyśliłem czym się pobawię na początek i zacząłem ściągać przykładowe aplikacje do analizy. Na początku wziąłem jakieś stare, i wszystko było OK. Potem zassałem coś aktualnego od Googla i nie poszło. Bo chciało mieć niejakiego Gradla, to taki nowy pomysł na make. To dołożyłem Gradla, ale dalej coś się nie zgadzało. To zaktualizowałem Android SDK i dopiero się zaczęło. Nic już się nie chciało kompilować. Po dłuższej chwili ciężkiej walki poczytałem co o tym piszą w sieci i wyszło, że Google wycofał się z supportu developmentu pod Eclipse w końcu zeszłego roku, a całkiem niedawno poprzestawiał coś w SDK tak, że w Eclipse nie ma już szans. Tylko Googlowe Android Studio. (Uprzedzając wypadki - jak się cofnąć z wersją SDK Tools, to Eclipse jeszcze działa, przynajmniej z projektami w starej strukturze).

Cóż było zrobić - zainstalowałem Android Studio. No i mać, mać, mać, ono na 4GB RAM pod Linuxem się ślimaczy! Mam wystartowany tylko browser (w końcu muszę mieć doku) i Android Studio i po chwili 1 GB w swapie. Tak się nie da pracować! O puszczeniu równolegle emulatora Androida mogę zapomnieć.

No i znowu - co zrobić, trzeba nowy komputer. Mojemu notebookowi 7 lat stuknęło, dotąd wystarczał, ale pamięci rozszerzyć się nie da. Ale teraz koncepcja będzie inna. Notebook ma w zasadzie tylko dwie zalety:

  • Wszystko jest w jednym kawałku i łatwo go przenieść albo zabrać ze sobą
  • Ma w środku UPS-a (w pierwszym świecie nie jest to jednak specjalnie potrzebne, sprawdzić czy nie USA)

Poza tym same wady, a największa to to, że musisz zaplanować i zapłacić już dziś, twoje potrzeby na jutro i pojutrze. Jak się nagle pojawi całkiem nowa, niezaplanowana potrzeba w sprzęcie, to notebook musi być nowy. A jak zaplanowałem moje potrzeby na jutro, to wyszedł mi notebook z kategorii 1000+ EUR. Sorry, ale nie. Nie przy takich wadach:

  • Jak wypasiony taki notebook by nie był, to i tak wszystko w nim jest w wersji spowolnionej w porównaniu z desktopem.
  • Klawiatura zawsze jest w niestandardowym układzie, nawet jak to jest 18''. Do tego klawisze o krótkim skoku, i od pewnego czasu wszyscy robią takie, żeby się nie dało wyczuwać granic miedzy nimi. Po podświetleniu bajerancko wygląda, ale dobrze pisać na tym się nie da. I zazwyczaj jest za wysoko.
  • Teoretycznie można podłączyć klawiaturę na USB, ale wtedy ekran wychodzi za daleko.
  • Można podłączyć drugi ekran, ale wtedy nie da się mieć klawiatury na środku (czytaj: Co chwilę trzeba kręcić głową), albo patrz punkt poprzedni.
  • Przy pracy kabelek i tak trzeba mieć, do prądu, nie wierzcie w reklamy o bezkabelkowej wolności
  • Podłączenie do serwera idzie przez WiFi (czyli trochę wolne), albo trzeba mieć drugi kabelek.
  • Te twity od notebooków wymyśliły sobie kiedyś dotykowe wyłączniki, zwłaszcza do WiFi. Autora rozwiązania należałoby dla przykładu rozstrzelać - w większości notebooków z jakimi miałem do czynienia bardzo łatwo jest dotknąć  tego wyłącznika przypadkiem, potem nagle nie ma połączenia z siecią i nie wiadomo dlaczego. Gdyby był mechaniczny, to by się  wyłączenie poczuło, a tak co i raz ciśnienie skacze.

I tak dalej. Więc nowa koncepcja: skręcę sobie desktopa wykorzystując część elementów które już mam (zasilacz, karta graficzna, dysk z notebooka (bo miałem w nim dwa)), tylko Linux. Pracuję na stole, komputer będzie na półce, do monitora pociągnę jakieś 3,5 m kabelka i będę mógł pracować jak dotąd, a po robocie odstawić monitor na półkę i mieć wolny stół. I tak:

  • Obudowę kupiłem taką samą jak do serwera. Przy okazji się okazało, że Cooltek nie jest jej producentem, robi je firma Jonsbo i oni mają jeszcze kilka innych wariantów małej, zgrabnej obudowy na płytę w formacie MicroATX i zasilacz ATXowy. Niestety żadna z nich nie ma miejsca na dysk optyczny, ale to nic, później dokupię zewnętrzny na USB.
  • Wentylator zasilacza z piwnicy hałasuje przy starcie, ale potem się uspokaja. To też nic, wkrótce kupie używany zasilacz firmy BeQuiet. One są takie świetne, że naprawdę nie warto kupować nówki sztuki, paroletnia używka chodzi kolejne lata bez zarzutu. A nówki tanie nie są.
  • Kupiłem najtańszą płytę główną jaką się dało, za 40 EUR (po przeczytaniu testu, z którego wyszło że nie ma różnicy w prędkości między tą, a znacznie droższymi).
  • Procesor też był najtańszy (za niecałe 30 EUR). I tak według indeksów prędkości jest dwa i pół raza szybszy od tego z notebooka, a jeszcze różnica w prędkości busa, VT (Virtualisation Technology) support, ...
  • 8GB RAM DDR4 nie daje się kupić za bezcen.
  • Dysk 2,5'' z notebooka jest całkiem spoko, jest i tak dwa razy szybszy od tego, który był tam oryginalnie.
  • Kupiłem set klawiatura/mysz bezprzewodowe, Cherry, teraz wreszcie daje się pisać w tempie i bez zmęczenia.
  • Monitor miał być 22'' (bo tyle miejsca jest na niego na regale), miał mieć VGA, DVI i HDMI + głośniki i wyjście na słuchawki. Tu wyszło, że w rachubę wchodzi tylko jeden model Iiyamy. Też jest spoko.
  • Do monitora pociągnąłem cztery pięciometrowe kabelki (zasilanie, HDMI, audio i USB, USB musiał być z repeaterem). Kabelki owinąłem razem taką spiralą, w sumie jest to jak jeden grubszy kabel, handling jest świetny.
  • Dałem sobie spokój z Windowsami, i tak coraz rzadziej w ogóle bootowałem na Win. A używałem raptem ze trzy programy bez odpowiedników linuksowych (IrfanView, Picture Shark, Elster Formular, ...), teraz się okazało, że dały się bez problemów zainstalować pod PlayOnLinux

W sumie całość, włącznie z kabelkami kosztowała 350 EUR, czyli jakąś jedną trzecią tego co poszłoby na notebooka. Chodzi super, jak wcześniej emulator Androida startował ponad cztery minuty, to teraz poniżej 30 sekund. Instalacja drivera do nVidii była nietrywialna i nie dla początkujących linuksiarzy, ale nie jestem początkującym linuksiarzem. Za to teraz emulowane urządzenie Androidowe chodzi w takim samym tempie jak prawdziwe (o ile nie szybciej).

Ale oczywiście nie obyło się bez spotkań z programistycznymi twitami. Na przykład: klawiatura bezprzewodowa chodzi z baterii i oczywiście nie ma LEDów do capslocka i numlocka. Żeby wiedzieć jaki jest ich stan, trzeba mieć jakiś kawałek programu. No i na Linuxa w zasadzie jest taki, sztuk jeden. Obsługuje on wszystkie trzy klawisze, ale miejsce do pokazywania jest tylko jedno. A przy każdej zmianie pokazuje się na ekranie notyfikacja. To jest tak głupie i niepraktyczne, że nie wiem nawet jak to skomentować. Poradziłem sobie instalując taki kombajn, co na bieżąco wykresy wszelakie pokazuje (zajętość pamięci, obciążenie procesora, temperatury, swap, transfery dysku, ...)  i jeszcze krawaty wiąże i usuwa ciążę, ale jak powyłączać wszystko inne, to można go mieć za wskaźnik tych locków. Też głupota, ale co zrobić.

Następny problem jest, że mój komputer stoi teraz prawie za mną i żeby zobaczyć diodę od HDD to muszę się obrócić. Programu do pokazywania symulacji takiego LED-a na ekranie nie ma. W zastępstwie można najwyżej pokazywać wykresiki transferu do dysku, robi to również ten kombajn, co pokazuje locki. Dobre chociaż to.

A teraz Android Studio, to w zasadzie jeden wielki twit.  W sieci spotkałem wypowiedzi, że jest lepsze od Eclipsa, bo to co w Eclipsie szło ciężko, to tu idzie łatwo. Sorry, ale nie mogę tego potwierdzić. Zgoda, ono ma dobre chęci i chce na każdym kroku ułatwić, podpowiedzieć i zapobiec błędom. Tyle że skutek jest taki, że żeby zrobić całkiem podstawowe rzeczy to trzeba program wykiwać robiąc je na boku, w czym innym. Na przykład:

  • Jak chcieć założyć testy, czy to jUnitowe, czy na urządzeniu, trzeba umieścić je w bardzo konkretnych katalogach. I tych katalogów NIE DA się utworzyć w GUI Android Studio! Trzeba zrobić to normalnie, na dysku, czy to w CLI, czy w jakimś file managerze, ale nie w Android Studio!
  • Jeszcze gorzej: Nawet jak te katalogi utworzyć, to ich w Android Studio nie widać, dopóki nie ma w nich jakiegoś pliku! Czyli trzeba utworzyć tam jakiś plik, nawet pusty, dowolnym narzędziem, dopiero potem da się cokolwiek z tymi katalogami zrobić! To już nie Twit of the Year, to Twit of the Century!
  • Menu kontekstowe pozwala na utworzenie najmniej pięćdziesięciu różnych klas obiektów, ale nie tych, które są potrzebne - na przykład absolutnie podstawowe pliki build.gradle. I znowu trzeba je zakładać czymś innym.
  • AS reaguje standardowo tylko na klawisze kursora, a nie na te z bloku numerycznego. Można zamienić na te z bloku numerycznego (a ja zaczynałem od klawiatury AT i umiem tylko na tych), ale wtedy klawisze kursorowe są ignorowane. No mać, to aż takie trudne, żeby reagować na dwa różne?

Muszę przyznać, że chociaż import projektów Androidowych z Eclipsa działa dobrze. Ale dalej jest gorzej:

Chciałem przećwiczyć cały proces aż do Jenkinsa i ślicznych wykresów tendencji. Więc do zaimportowanego z Eclipse starego przykładu dorobiłem lokalne testy jUnitowe, takie byle by jeden był OK, a drugi failed, zacheckinowałem do Gita, puściłem build na Jenkinsie. No i wszystko cacy, tyle że protokołu z testów nie było. No i zaczęło się grzebanie. Okazuje się, że to dłuższa historia, pełna twitów. Sam muszę sobie to trochę uporządkować.

  • Jeżeli dobrze zrozumiałem, to Google przez długi czas uważało, że zautomatyzowane testy mają sens tylko na urządzeniu albo w emulacji. Jakiekolwiek unit testy na pececie były be  (facepalm!)
  • Ponieważ ludzie tak nie uważali (szacun), powstał niezależny framework do testowania na pececie zwany Robolectric.
  • Niedawno Google trochę pomroczność przeszła i zaakceptowali i wprowadzili do struktury projektu lokalne testy jUnitowe. Niestety, jednocześnie coś się pozmieniało i z Robolektrikiem są jakieś problemy (chyba na podobnej zasadzie jak z Eclipsem, to pewnie wykańczanie konkurencji).
  • Problem z raportami z jUnita polega na tym, że w Eclipsie raporty robił specjalny task Anta, którego nie zrobiono w Gradlu dla Androida.
  • W Gradlu można by ustawić generację raportu jUnita, ale tylko dla kawałka czysto jUnitowego. Ustawienie jUnit gryzie się z ustawieniem Android i nie da się ich użyć jednocześnie.
  • Podejrzewam, że dałoby się zrobić osobny build.gradle w katalogu testów lokalnych i tam ustawić że to jUnit, ale jeszcze jestem słaby w Gradlu i będę musiał trochę popróbować.

Przyznacie chyba, że testy automatyczne nie pozostawiające po sobie protokołu są jakieś takie nie ten tego...

 Ale teraz wyśmieję każdego, kto powie że Google zatrudnia świetnych programistów.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy: ,

Kategorie:Programowanie

Komentarze: (17)

Twit Programmers of the Year (4)

W pracy kończy mi się walka z programistycznymi twitami, przynajmniej w tym projekcie. Startuje powoli następny, oczywiście znowu o stopień trudniejszy (teraz będzie dużo wariantów z różną funkcjonalnością i procesor z symmetric multicore). No ale trzeba oszczędzać i pewnie mnie przy nim nie będzie, przynajmniej na początku (pewnie zawołają mnie dopiero jak się zacznie walić i palić) . Zobaczymy gdzie teraz trafię.
Ale za to w domu zabrałem się za eksperymenty z Androidem. Na początek spróbowałem działać z sensorami i też od razu natknąłem się na mnóstwo twitów:

  • Na początek zrootowałem swojego tableta (Acer Iconia A700). Nawet łatwo poszło.
  • Wgrałem mu custom recovery, całkiem fajnie działa
  • Wgrałem też mu custom system (CyanogenMod). Tu był problem - jest dużo programów instalujących ten system na zrootowanym urządzeniu, tyle że całkiem niedawno ten projekt przemianował się (na LineageOS) i w ogóle coś się pozmieniało i te starsze wersje zginęły z sieci. Żaden z instalatorów nie działa. Na szczęście znalazłem gdzieś w sieci odpowiedni kompilat (samemu skompilować jeszcze mi się nie udało) i wgrałem go na tableta. I to jest dobre, oryginalny Android ślimaczył się już straszliwie, a ten chodzi całkiem przyjemnie, można było wywalić cały bloatware i ma to parę funkcji więcej.
  • Pisałem wcześniej o problemach z emulatorem Androida, dałem sobie z nim spokój. USB debugging chodzi bardzo dobrze. Potem kupię sobie parę używanych urządzeń z różnymi rozdzielczościami.
  • USB debugging chodzi, tyle że nie na moim telewizorze. Philips ma politykę, że ich telewizory są nierootowalne, soft można instalować tylko z Google Play, a USB debugging mimo że można odblokować, to nie chodzi (tu jeszcze potencjalny problem połączenia USB-A z USB-A). Chociaż ostatnio trochę odpuścili, po niedawnym updacie opcja instalacji z innych źródeł się pojawiła, i co nieco narzędzi poinstalowałem. Debugging ma móc chodzić przez Ethernet, podobno komuś się z tym modelem telewizora udało, mi jeszcze nie. W ogóle to motywacja Philipsa jest "Bo jak zbrickujesz sobie telewizor za 2500 EUR to będziesz płakał" - tyle że mój telewizor był tańszy od mojej komórki i niewiele droższy od mojego tableta. Uprzedzając pytanie: Nie, nie mam komórki za 2500+.
  • No to zacząłem od tableta. Na początek postanowiłem zapoznać się z obsługą sensorów. Jest do tego mnóstwo przykładowego kodu w sieci.
  • Analiza kodu i zależności fizycznych pokazała, dlaczego niemal wszystkie (o ile nie wszystkie) programy robiące za kompas są do niczego. Przyczyny są dość skomplikowane, ale do pojęcia. Objaśnię je, bo to ciekawe:
    • Niemal każda komórka ma akcelerometr, którym można ustalić kierunek "w dół" (to tam, gdzie statycznie mamy przyspieszenie 1g), żyroskop do obrotów i magnetometr, pokazujący kierunek na magnetyczną północ
    • GPS podaje geolokalizację urządzenia, ale nie w którą stronę jest obrócone, więc GPS się do kompasowania nie nadaje.
    • Magnetometr podaje kierunek wprost (przez Ziemię) do bieguna magnetycznego.  Znaczy to jest (jak u nas) jakieś 40º do poziomu.
    • Duża część programów na kompas bierze po prostu składową magnetyczną w płaszczyźnie urządzenia, relatywnie do jego osi Y. Ale jak trzymać urządzenie w ręku i pochylić je trochę do siebie, to ta płaszczyzna ustawia się paskudnie blisko prostopadłości do żądanego wektora, całą dokładność szlag gwałtowny trafia i kompas kręci się na chybił-trafił.
    • Sytuację może poprawić użycie kombinacji  sygnałów z akcelerometru i magnetometru.
    • W zasadzie coś takiego jest dostępne jako wirtualny sensor pozycji urządzenia, tyle ta funkcja zrobiła się deprecated lata temu (od v2.2.x, około 2010).
    • Ponieważ nowe rozwiązanie wymaga jednego calla więcej i trochę zrozumienia (słowo kluczowe: quaternion), prawie nikt nie jest w stanie tego pojąć i prawie wszyscy robią to po staremu.
    • Nawet po nowemu, to pokazuje kierunek na północ magnetyczną, a nie na "prawdziwą" północ.
    • Znając geolokalizację (z GPS-u) można od systemu dostać wartość poprawki żeby pokazać prawdziwą północ, ale nie znalazłem jeszcze ani jednego przykładu żeby ktoś to zrobił. Ja też jeszcze nie załapałem w którym momencie trzeba wykonać jaką operację na quaternionach, ale dojdę do tego.
    • Nawet jak zrobić to dobrze, pokazywany kierunek będzie zakłócany przez zewnętrzne pola magnetyczne.
    • Generalnie wszystkie te programy są zrobione maksymalnie prosto - obracają obrazek igły kompasu zależnie od danych z sensora. Nie będzie to sensownie działać (nawet porządnie zrobione) jak nie trzymać komórki poziomo. Mam pomysł znacznie lepszego interfejsu użytkownika. I jeszcze parę innych pomysłów na aplikacje związane z kompasem.
    • Dlaczego cała ta kombinacja składowych do orientowania się na prawdziwą północ nie jest dostępna jako proste API?
  • Jeszcze generalna uwaga co do API Androida: W całym tym API nie są w ogóle deklarowane wyjątki jakie funkcje mogą rzucać (deklaracja throws). Jak dla mnie to jest zupełnie podstawowy brak w designie - nieprzemyślana obsługa błędów.

Ładnie się zaczyna. Ciekawe jak będzie dalej.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy: , ,

Kategorie:Pomyślmy, Programowanie

Komentarze: (24)