wtorek, sierpnia 31, 2010

Czy ustalanie pozycji w Androidzie może kosztować?

Spać mi się chce, więc krótko będzie.

Z rozmów i dyskusji na Blipie wnoszę, że istnieją poważne rozbieżności co do tego czy w Androidzie ustalenie pozycji może kosztować.

Ja twierdzę, że może kosztować gdy location providerem będzie "network", a my będziemy podpięci do Internetu przez sieć komórkową.
W momencie gdy będziemy podpięci przez WiFi dostawca "network" może, a nawet powinien być bezpłatny.

Dlatego na szybko napisałem program, który to ma testować.

Oto kod jego najważniejszej aktywności:
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
LocationManager lm = (LocationManager)getSystemService(Context.LOCATION_SERVICE);
List<String> list = lm.getAllProviders();
StringBuilder sb = new StringBuilder();
for (String str:list) {
LocationProvider lp = lm.getProvider(str);
if (lp!=null) {
sb.append(str).append(" ").append(lp.hasMonetaryCost()).append("\n");
}
}
TextView tv = (TextView)findViewById(R.id.toster);
tv.setText(sb);
}

Sam program potrzebuje jeszcze tego by na głównym ekranie był element TextView o id "toster", oraz by w AndroidManifest.xml były odpowiednie permissiony (to przez to, że używamy lokalizacji, stąd potrzebne są pozwolenia ACCESS_FINE_LOCATION i ACCESS_COARSE_LOCATION.
Tu są źródła jakby kogoś to interesowało.

A tutaj sam plik APK (http://www.przemelek.pl/file/GPSTest.apk), który można zainstalować na telefonie.
Tutaj QRCode:



Teraz prośba :-)
Jak masz telefon z Androidem to zainstaluj ten program i podeślij mi informację o wyniku jego działania, wraz z informacją czy w momencie uruchomienia programu Twój telefon był zalogowany do sieci WiFi czy tylko do sieci komórkowej (i ważne czy miał skonfigurowanego APNa).

Program działa w taki sposób, że wypisuje wszystkie nazwy dostępnych location providerów, a obok nich to czy mogą być płatne czy nie. U mnie na G1 z Android 1.6 gdy jestem podłączony do Internetu przez sieć komórkową mam taki wynik:
network true
gps false

Co oznacza, że ustalenie pozycji przy pomocy sieci może kosztować, a przy pomocy GPS nie będzie nigdy kosztować.

Z góry dziękuję za wszelkie dane :-) [tu, na Google Buzz, na maila, whatever]


Podobne postybeta
AppInventor - pierwsze wrażenia i pierwsze programy :-)
Android, lokalizacja i koszty
Nie tylko IE6 powinno pójść do piachu, każdy Internet Explorer powinien!!!!
Zinwigiluj się sam ;-)
Niecne wykorzystanie refleksji... czyli jak poszukać tekstu w drzewie obiektów? ;-)

Notka miraż

Od dawna marzy mi się wpis na bloga pod tytułem "Ile waży kilo słonia?".

Problem jest tylko w tym, że nie mam pomysłu o czym by miała być ;-)

No bo kilo słonia waży 1 kilogram, niezależnie od tego co będziemy ważyli. Czy całego słonia o masie 1 kg (chyba jakiś słoniowy płód tylko tyle waży, bo rodzą się dużo większe), czy tylko np. kilogram ciosa, czy nawet kilogram powietrza z płuc słonia (choć to by było trudno zważyć ;-) no i musiałoby to być chyba parę słoni........ bo jak dobrze liczę to potrzebne byłoby 773.4 litra powietrza, a takich dużych słoni to nie robią (ha! podobno potrzeba do tego trochę ponad 2 słoni, bo jak wyczytałem w Internecie u ssaków tak zwykle pojemność przybliżona to 6% * masa ciała, gdzie te 6% ma jeszcze wymiar l/kg ;-), co daje dla słonia podobno 300 litrów, czyli 2.5 słonia potrzebujemy do zebrania 1 kg słonia w postaci powietrza w słoniowych płucach... problem natury filozoficznej tu jest czy powietrze w płucach słonia to słoń czy nie słoń? [gdzieś w tym miejscu powinien być chyba jakiś nawias zamykający dygresję w dygresji.......])]

Taki lifehack w nawiązaniu do dywagacji o nawiasach, jak się pogubiliście w nawiasach to je liczcie. (()()) to 1,2,1,2,1,1,0 czyli mamy dobrą ilość i chyba przechodzi też przebiegłe rzeczy jak ())( bo nam wyjdą ujemne liczby nawiasów.

Czasem ten słoń przechodzi w śledzie, i wtedy chciałbym zapytać na blogu "Ile waży kilo śledzi?". Ale wtedy też nie mam pomysłu o czym by to miała być notka ;-)

Dla pociechy powiem, że w głowie mi siedzi (i we fragmencie na karcie SD mojego telefonu też ;-)) jeszcze jedna notatka marzenie ;-) i na razie próbuje wymyślić jej szczegóły techniczne ;-)


Podobne postybeta
Drugi klasyfikator jako "sanity check"
Kilogram i ile to jest? To jest dopiero spór :-)
Jak walczyć z gigantycznym kodem w Java'ie, część 1.5 ;-) - czyli jak je się słonie ;-)
Java i Chrome OS....
1.3 σ w kierunku średniej ;-), czyli wcześniej wstaję

poniedziałek, sierpnia 30, 2010

Święta wojna - kolejna odsłona

No i najwyraźniej mamy kolejną odsłonę świętej wojny.

Dawniej była między Commodore i Atari, później między PC i Amigą, później jeszcze między Asus EEE PC i MSI Windem, a teraz mamy nową między Androidem i iPhonem.

Możemy się więc dowiedzieć, że Android ssie, albo że srajfon ssie. Że w Androidzie są niedorobione aplikacje, albo że w iPhonie firma traktuje użytkowników jak idiotów i tak dalej i tak dalej.....

To ja może od innej strony zaczną.

Nie lubię szpinaku. Ale wiem, że są ludzie którzy szpinak lubią. Nie czuję z tego powodu nad nimi moralnej wyższości, ani mi ich nie żal. Oni to lubią i dobrze im z tym.

Nie będę przekonywał ich, że są idiotami bo jedzą to zielone paskudztwo, które wcale nie jest takie zdrowe jak to onegdaj twierdzono.
Nie będę bo oni to lubią, a lubiąc to wcale mi nie szkodzą.

Nie rozumiem ich sympatii do szpinaku, nie podzielam jej, ale rozumiem, że oni mogą go lubić.
Wiem też, że to, że lubią szpinak nie oznacza niczego złego.
Od ludzie jak ja, tylko, że lubią szpinak.

Jeszcze z innej strony.
Podobają mi się kobiety. Nawet bardzo mi się podobają.
Ale akceptuję, że są faceci którzy wolą innych facetów. Nie rozumiem ich, ale tu jest ta sama sytuacja co ze szpinakiem. Nie czuję nad nimi żadnej moralnej przewagi, nie jest mi ich też żal. Dobrze im z tym i to jest fajne.

To samo jest z Androidem i iPhonem.

Ja lubię Androida. Podoba mi się. Spełnia moje wymagania.
iPhone i większość produktów Apple mi się nie podoba. Nie podoba mi się ich estetyka, wolę zdecydowanie użyteczny minimalizm w wykonaniu Google.
Ale nie czuję się z tego powodu lepszy od miłośników Apple, nie jest mi ich też żal.
Akceptuję ich wybór i cieszę się ich szczęściem.

Urok demokracji, pluralizmu, wolności, whatever, polega na tym, że ja mogę mieć swoje ulubione i ukochane rzeczy, produkty, książki, filmy, utwory, co tam jeszcze, a inni mogą mieć swoje.
Tak, cudzy wybór może mi się wydawać dziwny, mogę go nie podzielać, ale to nie moja sprawa. Puki ten ktoś mi z butami w życie nie wchodzi to nie jest mój problem.

A czy Android jest lepszy od iPhone'a, albo iPhone lepszy od Androida?

Tak.

Dla zadowolonego użytkownika Androida Android jest lepszy od iPhone'a, a dla zadowolonego użytkownika iPhone'a iPhone jest lepszy od Androida.

Jedni ze słodyczy lubią orzechy, inni czekoladę, a jeszcze inni golonkę i kotlet schabowy.

Nie da się zbudować obiektywnego rankingu w przypadku systemów operacyjnych dla telefonów, tak jak nie da się zbudować rankingu dla języków programowania, dla urody kobiet czy jakości życia. To są problemy wielowymiarowe i każdy ma swój własny zestaw wag i akceptowanych poziomów.

I po co o to kopię kruszyć?


Podobne postybeta
Święta wojna...
Nadmiar wyboru, to jest problem dla Androida ;-)
A różne takie...
Kolczatka ;-) czyli próbujemy zastąpić Dziobaka ;-)
Wegetarianizm kaizen - czyli ja bywać wegetarianinem bez zbytniego wysiłku ;-)

niedziela, sierpnia 29, 2010

Bloggeroid - polityka małych kroczków ;-)

W ramach polityki małych kroczków wyrzuciłem starą "stronę" do wyboru postów i zastąpiłem ją taką jakąś bardziej przyjemną (dla mnie, nie wiem jak dla innych ;-)).



Dodałem także aktywność do czytania postów, bo po co od razu je ładować do edytora?



Teraz kombinuję z komentarzami.
Czasem jest tak, że przyjdzie jakiś spamerski komentarz i fajnie by go było móc skasować nie będąc przy komputerze :-) Dlatego teraz próbuję z tym walczyć.
Tutaj objawiła się wielka zaleta Bloggera :-) ponieważ komentarze są "pakowane" tak samo jak wpisy na blogu to ich pobranie łączy się tylko ze zmianą URLa na którym robi się GET.
To bardzo miłe :-)
Szczerze mówiąc to jak dodam kasowanie komentarzy to i postów, to nie będzie dużo roboty.

Minusem tego wszystkiego jest to, że Bloggeroid rośnie. Teraz "instalka" ma już około 64KB, przez co po instalacji zajmuje już 160KB (razem z danymi, sam program zajmuje 148KB).

Liczę, że w nadchodzącym tygodniu wydam wersję 1.3 z możliwością tworzenia i kasowania komentarzy i że zacznę prace nad 1.4, która miałaby zacząć nabierać ładniejszego wyglądu ;-) ale tutaj nic nie obiecuję ;-)


Podobne postybeta
Granica
ChromoPaskudztwo ;-) - czyli, pisanie aplikacji dla Chrome to pikuś :-)
Niech dadzą Darta dla Androida ;-)
Człowiek to dziwne zwierze....
ASUS EEE PC - szpanujemy wyniki ;-)

piątek, sierpnia 27, 2010

Polski słownik dla Androida niewiele pomaga :-(

Wczoraj na Blipie pojawił się opis jak dodać do słownika G1 polskie słowa i przez to przyśpieszyć pisanie przy pomocy klawiatury ekranowej.
Dodałem, ale nijak nie ma się to wygody, prawidłowe słowo pojawia się jako podpowiedz dopiero gdy się je całe wpisze. ;-)
Jednak klawiatura fizyczna jest o wiele lepsza.

To wyżej (bez linka ;-)) zostało napisane ręcznie przy użyciu klawiatury ekranowej w G1 i tego podpowiadającego słownika. Tak sobie to działa.
Tutaj instrukcja, może moim błędem jest to, że użyłem słownika z 3000 słów tylko, no i może powinienem raczej użyć słownika stworzonego na podstawie tekstów z bloga :-)
Może spróbuję :-)
Pomysł w każdym bądź razie z tym słownikiem świetny, ale niestety ja nie widzę żadnych plusów. Wcale mi nie pomógł w trakcie pisania tego tekstu wyżej, który ma jeśli dobrze liczę 49 słów, podpowiedź przydała się góra 3-4 razy. Może z czasem będzie lepiej?
Czas pisania tych 49 słów to z 2 minuty albo i dłużej (odczucie subiektywne, nie mierzyłem)



Podobne postybeta
Nexus S - wrażenia z boju ;-)
Oszukałem się ;-)
Darmowy hosting JSP
Kradziejski dekoder
Na co "idą" moje podatki?

Przeglądarka zawsze przydatna

Kiedyś do konwersji z jednego standardu kodowania polskich znaczków na inny używać trzeba było specjalnych programów. Sam sobie nawet kiedyś taki napisałem, rozpoznawał chyba z 20 standardów... ale teraz to niepotrzebne :-)
Wystarczy Firefox :-)
Bierzemy plik tekstowy, przeciągamy go do przeglądarki, i teraz tylko szukamy odpowiedniego kodowania znaków dla którego wszystko da się przeczytać :-)
Działa to też dla innych języków, tak np. przygotowywałem pliki dla OOo2GD dla chińskiego :-)



Podobne postybeta
LibreOffice - takie sobie
ShiftHappens - ciekawa prezentacja
Ficzer, za który lubię Linuksa ;-)
WebGL - dalsze zabawy
Chcę sankcji UE

środa, sierpnia 25, 2010

Lenie ;-)

Ciekawą, ale i smutną tendencję zauważam wśród developerów. Niechęć do pisania samemu.
Zamiast napisać własne 20-30 linii kodu do BASE64 używają gotowych bibliotek, które niosą ze sobą masę niepotrzebnego kodu i ważą po 0.5-2 MB.

Nie dziwota więc, że wszelkie TopCoder i podobne do znudzenia wykorzystują np. zadanie z pisaniem własnej arytmetyki czy to dla liczb rzeczywistych (dzielenie jest najdłuższe) czy dla macierzy.
90% odpadnie już na tym etapie... ale to smutne trochę.

I tak, wiem że o tym już pisałem i to nieraz ;-)


Podobne postybeta
3 plusy ;-)
~ - czyli "tak sobie"
Raspberry Pi + no-ip.org ;-)
SUVy ;-)
Zimowy zastój?

DRM Google wcale nie został złamany

Internet obiegła dziś wieść, że system DRM od Google wykorzystywany w Android Markecie został shackowany.........
Okazuje się jednak, że wcale nie :-)
Shackowano przykładowy sposób wykorzystania tego systemu. Google dostarczyło przykładowego kodu, i jeżeli developer wykorzystał ten przykładowy kod i go nie przerobił, a dodatkowo nie zobsfukował kodu swojej aplikacji to wtedy jego aplikacja jest podatna na taki atak.
Nie jest więc wcale tak strasznie, bo developerzy mogą spokojnie nadal z tego systemu DRM korzystać, muszą jedynie przerobić sposób jego wykorzystania i dodatkowo obsfukować kod.
A co do obsfukowanai kodu to Google to zaleca wszystkim osobom wykorzystującym ich DRMa [w każdym bądź razie teraz ;-)].
Dziwi tylko to, że potrzeba było prawie 24 godzin na to by na blogu dla developerów Android pokazała się o tym informacja.


Podobne postybeta
EEE Storage - czyżby nie dla wszystkich?
Testowanie upolskawiacza
CVS "złamany" :-)
Dwa narzekania ;-)
Skazany na urlop ;-)

wtorek, sierpnia 24, 2010

Bloggeroid 1.2 - zróbmy to ciut bardziej przewidywalne ;-)

Powiedzmy sobie szczerze, że wersja 1.1 Bloggeroida nie należała do najbardziej przewidywalnych, sam się dawałem jej zaskakiwać.
W wersji 1.2 z tego powodu jedyne zmiany to, poza poprawieniem błędu z obsługą odczytywania z karty SD w przypadku gdy na karcie SD nie było jeszcze katalogu Bloggeroida, zmiany związane z przepływem między poszczególnymi aktywnościami.

Od teraz główną aktywnością jest aktywność z treścią wpisu, wszystkie inne aktywności są "usługowe" w stosunku do niej i zmieniają jej zawartość.
Nie ma otwierania nowej aktywności do edycji postów na skutek wczytania zawartości starego posta.
Dodatkowo zrezygnowałem z nierozsądnego połączenia publikowania z zapisywaniem na SD, i wczytywania postów z bloga i z karty SD.
Wydaje mi się, że teraz jest to bardziej przewidywalne.
Powinien też być jeden "cukierek" czyli zapamiętywanie ostatnio użytego bloga.

Zapraszam do Android Marketu, albo do użycia tego QRCode'u:



Dzielcie się wszelkimi uwagami, może bez inwektyw jeśli można ;-)


Podobne postybeta
Zapamiętywanie haseł jest pokręcone ;-)
Prototypowanie dla Androida
Programiści są nieważni...
Trzy wielkie tajemnice Androida (od strony programisty)
Trudne powroty ;-)

Ładna piosenka z Buffy :-)

Jak znam życie to już kiedyś tutaj to wrzuciłem :-)

Najładniejsza piosenka z odcinak musicalowego z Buffy - Under Your Spell.
Niestety dźwięk i obraz są takie sobie.




Dla nieznających Buffy, śpiewa Tara, dziewczyna Willow. Willow to najlepsza przyjaciółka Buffy, która od jakiegoś czasu pełni rolę czarownicy ;-) Tara to też czarownica, ale taka z większymi tradycjami rodzinnymi.

Hmm.. chyba nawet kiedyś próbowałem tłumaczyć tą piosenkę ;-) Ale chyba lepiej, że tego nie zrobiłem ;-) Nie mam żadnego talentu w tym kierunku :-) (tłumaczenie miało być częścią transkryptu).


Podobne postybeta
Bored now.....
Ponowne oglądanie Buffy
Potworny kawałek ;-)
OAuth mnie denerwuje ;-)
Minisec

Empik w Bonnarce ssie

Chciałem dziś kupić sobie polskie wydanie najnowszej książki ze świata Endera autorstwa Orsona Scott Carda, czyli "Ender na wygnaniu'.
Czytałem ostatnio oryginał i mi się spodobał, to chciałem i polską wersję. Wydano ją podobnie 3 dni temu.
Poszedłem więc do Bonarki, która jest podobno największą galerią handlową w tej części Europy coby sobie tą książkę kupić. (btw. ci Polacy to musi być strasznie kulturalny naród, tak często do galerii chodzi ;-))

Dotarłem do Bonarki, choć od złej strony, bo do Empiku miałem dobre 300 metrów (po drugiej stronie galerii jest, btw. to jest chyba największy budynek w jakim byłem w życiu... no może terminale we Frankfurcie, Monachium lub Los Angeles są większe, albo ten Hilton LAX, w którym mieszkałem w LA), przeszedłem ją całą, dotarłem do Empiku i tu amba.
Jakieś to małe i ogólnie nieładne, do tego książki nie było :-(
Z ledwością udało mi się znaleźć Świat Nauki i NIE, obsług też taka sobie, sprzedawca, który mnie obsługiwał jakiś dziwny głos miał (kastrat??). Ogólnie niefajnie.
Jeden plus to spacer, ale już wiem, że raczej Empiku w Bonarce nie odwiedzę.
W KRK zdecydowanie lepsze są Empiki w Galerii Kazimierz, Krakowskiej i na Rynku, dobrymi księgarniami, które znam są za to Matras w Galerii Krakowskiej i Matras na Rynku.



Podobne postybeta
Zaburzenie "pola przyczynowości" :-)
Walentynki
Lecę do Stanów... i co z tego? ;-)
Błeee
We Frankfurcie...

niedziela, sierpnia 22, 2010

Blue-Ray, DVD i takie tam

Ciekawa sprawa, za Harry'ego Potter'a na DVD (Lata 1-6) w Polsce zapłaciłem 298 czy 260 złotych. Wersja Blue-Ray kosztuje z tego co pamiętam więcej (500 złotych???). Ten sam Harry Potter na Blue-Ray na Amazon.co.uk po przeliczeniu na złotówki kosztuje jakieś 160 złotych, nawet z transportem to dużo mniej niż DVD w Polsce.
Ciekawe nie? ;-)

Aż się zastanawiam czy nie kupić sobie tych płyt i odtwarzacza Blue-Ray, ale powstrzymuje mnie to, że w tamtym roku kupiłem odtwarzacz DVD i szkoda by mi było by sobie tak sam stał ;-)

Ale jak zrobią Buffy na Blue-Ray to się mogę złamać ;-) Choć szanse są małe, Buffy była zawsze kręcona dla 4:3, a jak mi się wydaje takiego materiału się zbyt często, jeśli w ogóle nie publikuje w wersji Blue-Ray.

A tak z tego wszystkiego najlepsze jest to, że już kombinują nad następną technologią, która zastąpi Blue-Ray....



Podobne postybeta
396 m2 ekranu
Ikonki złe ;-)
Ukradli nam przyszłość....
3 sezon Buffy w Polsce ;-)
Nexus 7 sprzedaje się jak świeże bułeczki :-)

sobota, sierpnia 21, 2010

Bloggeroid 1.1 :-)

No i jest nowa wersja, tym razem 1.1.

Najważniejszym ficzerem jest możliwość nagrywania postów na karcie SD, oraz wczytywanie tych postów z SD.

Tutaj filmik pokazujący jak działa publikowanie postów w Bloggeroidzie:



A tutaj jak wygląda edycja istniejących postów z blogu i z karty SD :-)



Tutaj QRCode do Android Market :-)



Jeśli znajdziecie jakieś problemy to proszę o kontakt :-)


Podobne postybeta
Bloggeroidujemy ;-)
Wojna ze świętam, czyli o wyższości Świąt Bożegonarodzenia nad Wielkanocą ;-)
Geolokalizacja postu z obrazka, czyli nie taki Exif zły :-)
Programowanie jest stresujące
Bloggeroid 1.2 - zróbmy to ciut bardziej przewidywalne ;-)

Android i lokalizacja. Czego używać zagranicą?

Hmmm... taka zagadka ;-) W Androidzie istnieje możliwość pobrania lokalizacji, posłużyć mogą do tego różni dostawcy. Takim najbardziej zgrubnym jest sieć komórkowa, kolejnym sieci WiFi i w końcu GPS.
Dokładność idzie jak łatwo zgadnąć od góry, czyli najsłabiej przy sieci komórkowej, później WiFi i najdokładniej przy GPS.
Znów od strony dostępności jest zwykle tak, że GPS będzie działał praktycznie tylko na zewnątrz, ale praktycznie na powierzchni całej planety, WiFi w miastach i to zwykle tak w budynkach jak i na zewnątrz, a sieć komórkowa działa praktycznie wszędzie (gdzie jest ;-)) i to tak w budynkach jak i na zewnątrz.
Kolejną zmienną są koszty, GPS jest za darmo, w przypadku WiFi konieczna jest transmisja do serwerów Google, które zwrócą lokalizację, nie do końca wiem jak jest w przypadku sieci komórkowej... z kodu Chrome i Google Gears wnoszę, że tu też konieczny jest dostęp do sieci i komunikacja z serwerami Google.
I teraz zagadka ;-) znając to powyżej jakiego sposobu ustalania położenia używać najlepiej zagranicą?



Mnie wychodzi, że GPS jest najlepszy, bo gdy będziemy mieli wyłączony roaming danych i nie będziemy zalogowani do żadnej sieci WiFi to będzie dostępny jako jedyny... ale tylko na zewnątrz....
Czyli jak chciałbym dodać do Bloggeroida możliwość dodawania lokalizacji to trzeba by było dodać jeszcze możliwość jej ręcznego ustawienia.
To komplikuje sprawę ;-)
Szczególnie, że nie mając dostępu do transmisji danych mogę co najwyżej poprosić dostawców lokalizacji o podanie ostatniej znanej pozycji i zasugerować użytkownikowi wybór spośród nich...... bo z mapy nie może wybierać, przecież do jej używania potrzebna jest transmisja danych....
A znów używanie ostatniej znanej pozycji bywa dziwne, np. ostatnio byłem "przekonywany" przez jedną z aplikacji, że jestem w Częstochowie bo tam ostatni raz GPS złapał lokalizację (w innych miejscach telefonowi wystarczały sieć GSM i WiFi), gdy w rzeczywistości byłem w Krakowie.

No i mam zgryz ;-) Czyli prawie na pewno w wersji 1.1 Bloggeroida nie będzie lokalizacji.



Podobne postybeta
Polacy - naród paserów? ;-)
Android, lokalizacja i koszty
Bloggeroid 1.5.0 - czas lokalizacji ;-)
Śledzimy geolokalizację ;-)
Pensje programistów

piątek, sierpnia 20, 2010

wtorek, sierpnia 17, 2010

Jak wnuk za babcię płaci ;-)

Wiecie czemu ZUS nie ma pieniędzy na emerytury?
Bo ma ich po prostu za mało.

Emerytury kosztują nas 140 mld złotych rocznie. Żeby do ZUS trafiło tyle kasy każdy pracujący obywatel polski powinien odprowadzać około 1/4 swojej pensji na wypłaty emerytur dla obecnych emerytów.
Płynie tam zaś góra 20% naszych pensji... de facto mniej, bo blisko połowa z tych pieniędzy płynie do OFE, które kupują za nie obligacje, z których rząd bierze kasę na dofinansowanie ZUS :-)

No to nie dziwota, że system nie wydoli. Z pustego nawet ZUS nie naleje ;-)
Nasi emeryci żyją na koszt swoich wnuków i prawnuków.
Złe to nie jest, ale smutne, że większość ludzi nie wie jak to działa.



Podobne postybeta
2011 zaczęty ;-)
Polacy - naród paserów? ;-)
Wyrocznia od siedmu boleści
Jak się profesjonalnie kłamie
zVATowani 2

Znów o rozwiązywaniu krzyżówki

Nadal uważam, że najlepszym sposobem rozwiązania sprawy tego krzyża w Warszawie sprzed pałacu Prezydenckiego jest ignorowanie go.
Wymusić zdemontowanie, ale nie usuwać. Jak jego miłośnicy chcą to mogą go sobie nosić.
Już o tym pisałem.

I miałem rację ;-) pojawiły się pomysły pomnika upamiętniającego ofiary tej katastrofy.
Pomnika, który jak będzie to wygodne dla PiS to będzie zbyt mały, zbyt mało reprezentacyjny, zbyt nowoczesny, zbyt świecki, zbyt .... Innym razem będzie totemem kultu Lecha Kaczyńskiego.

I po co?

Ta katastrofa choć straszna dla rodzin ofiar dla państwa znaczyła niewiele. Największe konsekwencje miała śmierć Prezesa NBP.
Śmierć Prezydenta przyśpieszyła tylko nieuniknione czyli pożegnanie się Lecha Kaczyńskiego z fotelem prezydenta. Państwo spokojnie poczekałoby te 8-9 miesięcy bo w Polsce prezydent to tylko figurant, prawdziwa władza jest w rękach premiera.

Budowanie pomnika, szczególnie przed pałacem prezydenckim to budowanie pomnika PiS, a to głupie w sytuacji gdy 60-80% społeczeństwa nie chce na nich głosować.

No i hmm.. Narutowicz na pomnik w Warszawie czekał prawie 80 lat, w ogóle jedyny pomnik jaki mu wybudowano po jego śmierci stał w Bielsku, a powstał też tylko z przyczyn politycznych i to parę lat po jego śmierci.
A dla samego społeczeństwa śmierć prezydenta w zamachu i to z ręki polaka to jednak coś większego niż śmierć w katastrofie lotniczej.

A teraz czas spać ;-)


Podobne postybeta
Jak rozwiązać krzyżówkę? ;-)
Mistrzowie political fiction
Jak apokalipsa to nie w Warszawie ;-)
"Cud"
Nexus 4 me wants...

Cukierki, radosny chaos i takie tam, czyli Przemkowe rojenia ;-)

Nigdy nie marzyłem o tym by zostać architektem oprogramowania. Nie chodzi tylko o to, że to nudna robota jest (dla mnie, są osoby które się w tym realizują i mają świetne wyniki. Ale stanowią mniejszość), chodzi też o to, że jest to często robota bez sensu.

Bo opiera się na założeniu, że w przypadku oprogramowania da się projektować "od góry". Że można zbudować projekt oprogramowania i go zrealizować.
Nie można.

Ogólną koncepcję można, z zaznaczeniem, że się może zmieniać, ale całego softu nie.

Nie ma ludzi z tak dużymi głowami by byli w stanie zobaczyć wszystkie możliwe zależności bez zobaczenia prototypu.

Bo cukierki widać głównie od dołu ;-)

Cukierek to ułatwiajka gdy chodzi o interfejs użytkownika, albo sprytny pomysł, który załatwia za nas większość roboty.

Tak, część cukierków jest na poziomie architektury, ale giną tam w tłoku masy wymagań.

Kiedyś pisałem narzędzie które miało tworzyć pewną strukturę w bazie danych, dokładniej miało i nadal to robi i będzie robić przez kolejne lata ;-) tworzyć te pewne struktury często. W jednej bazie miało się znaleźć kilka tysięcy rekordów, które tworzą zamkniętą całość, a między tymi rekordami istnieją wzajemne powiązania, polegające na tym, że niektóre z nich są kluczami obcymi w innych tabelach.
Klasycznie trzeba by było stworzyć jakiś schemat tych zależności i zakodować go.
Ja zrobiłem inaczej. Dałem programowi wszystkie rekordy które ma włożyć [dla ułatwienia w postaci zrzutu z bazy jako serię INSERT INTO] i wstawiłem do niego zgadywajkę, która na podstawie nazwy pola zgaduje czy ma do czynienia z kluczem głównym czy obcym, czy może z danymi nie będącymi akurat kluczem ;-). Akurat w tej bazie było to proste.
Aha, zmiany w bazie odpadały.
I teraz program działa tak, że najpierw na szybko w pamięci buduje sobie mapę tabel, a w każdej z nich trzyma listę rekordów do włożenia. Bierze pierwszą tabelę z brzegu i próbuje ją włożyć do bazy, robiąc to sprawdza czy aby nie ma tam kluczy obcych, jak są to po prostu rekurencyjnie próbuje włożyć wszystkie rekordy tabeli z kluczami obcymi, jak tam są inne klucze obce to idzie dalej, aż dociera do tabeli, które nie mają kluczy obcych. Wkładając je do bazy zapamiętuje jakie mają teraz numery (tak, dodatkowe utrudnienie to constraints UNIQUE na numerach rekordów) i w razie gdzieś używany jest klucz obcy to prosta funkcja zwraca jego nowy numer.
De facto program robi sortowanie topologiczne i łazi po grafie zależności między tabelami, ale nie zna ich przed uruchomieniem ;-)
Cały engine powstał w 2-3 dni i działa od prawie 3 lat bez zbytnich modyfikacji.
Taki cukierek :-)

Gdyby projektować to od góry to byłoby tak z pół tony wzorców użyte, kodowanie byłoby nudne i smutne, a wszystko trwałoby kilka tygodni. Gdyby trafić na ambitnego architekta to skończyłoby się na użyciu specjalnego języka tylko do opisu zależności ;-)

Programy komputerowe się wyłaniają. Puki ich nie stworzysz nie wiesz do końca gdzie pójdą.

Ale jak się wszyscy upierają przed projektowaniem z góry to później nagle w trakcie kodowania okazuje się, że są sprzeczności, że trzeba je jakoś obejść.

Choć taki radosny chaos jaki ja lubię ma tę wadę, że nie wszyscy go lubią. Nawet większość go nie lubi ;-)
Wg. mnie lepiej się sprawdza, bo pozwala szybciej reagować, nie wymaga miesięcy przygotowań, które i tak idą często na marne w trakcie implementacji, bo się okazuje, że jednak się czegoś nie da, albo (co rzadziej, ale szczęśliwiej ;-)) da się prościej no i jest zabawniejszy.
No i trudno powiedzieć czy radosny chaos sprawdza się w dużych systemach.
Choć tu też jest to, że jak mi się wydaje lepsze są duże systemy, które powstają z masy małych programów i programików, niż takie które powstają w ramach WIELKIEGO NIESTETY WYSŁOWIONEGO PLANU.
Koszty naprawy czy nawet przepisania małego fragmentu SYSTEMU są niskie, koszty zmiany w kodzie SYSTEMU są wysokie. Bo jak coś spapramy w małym narzędziu to zawsze można szybko wrócić do starszej wersji, a cały system trudniej zmienić ;-)

O! Protokoły (albo protokóły ;-)) są ważne. Wg. mnie im prostsze tym lepsze.

Na koniec zastrzeżenia ;-) Prawdziwego [w mojej ocenie] architekta spotkałem raz, takich różnych tytularnych wielu. Ci lepsi nie decydowali o tym jak ma wyglądać aplikacja, a jedynie wytyczali ogólny kierunek implementację zostawiając developerom. W końcu developerzy to nie jest banda kretynów, a ludzie którzy znajdują się w wąsie krzywej Gaussa i różnica między nawet najmniej inteligentnym developerem, a architektem jest dużo mniejsza niż między nimi, a przeciętnymi ludźmi. W skrócie to zdolne bestie są.
Poznałem też "architektów", którzy nie powinni mieć nawet prawa zbliżania się do komputerów ;-)
Z obserwacji tych drugich jest więcej, na szczęście zwykle poza firmami gdzie ja pracuję :-) [z niechlubnym wyjątkiem poprzedniej, która upadła jakieś pół roku po tym jak z niej odszedłem :-)]

To wyżej może się zmienić, akurat dziś jestem w takim nastroju, jutro mogę uważać, że wszystko trzeba projektować i planować ;-) bo wszystko zależy od Eli, eli dane podejście będzie działało, eli nie będzie ;-)
Tu nie ma prawd objawionych ;-)


Podobne postybeta
U mechanika... czyli nudne pisanie o niczym dla zabicia nudy
Świat disco polo...
Ingress - to wciąga ;-)
Allegro to jest banda amatorów.
Terminatorowa refleksja ;-)

poniedziałek, sierpnia 16, 2010

niedziela, sierpnia 15, 2010

Bloggeroidujemy ;-)

Bloggeroid pobiera się tak sobie, jak na razie trochę ponad 400 instalacji jest.

Ale ponieważ i tak piszę go dla siebie to kombinuję jak mu dodać nowych funkcji ;-)

A, że jak dobrze pójdzie to we wrześniu wybiorę się na zasłużone wakacje do Afryki [takiej bliskiej i taniej, czyli Tunezji ;-)] to kombinuję nad kolejnym ficzerem. Czyli nad możliwością publikowania "do kolejki".
Tak by w momencie gdy telefon nie będzie w zasięgu żadnej sieci to publikowanie będzie polegało na wrzuceniu postów do kolejki, za to gdy telefon znajdzie się w zasięgu sieci to Bloggeroid będzie publikował te skolejkowane wpisy.

W zamyśle chodzi o to by mimo wyłączonej transmisji danych w roamingu można było blogować :-)

A teraz sobie próbuję napisać zapisywanie postów na SD [to już mam] i wczytywanie z SD [tego jeszcze nie mam ;-)]. Ale jak zwykle okazuje się, że problemem jest uczynienie tego wszystkiego spójnym ;-)


Podobne postybeta
Strzeż się
Bloggeroid - polityka małych kroczków ;-)
Czy nazwa miasta się wyśle? ;-)
Lekcja na dziś - żeby konfiguracja działała trzeba ją zapisywać i odczytywać ;-)
Bloggeroid 1.1 :-)

YouTube czy Vimeo?

Temat był już wałkowany wielokrotnie w sieci, ale sam też to chciałem sprawdzić :-)

Który serwis nadaje się lepiej do publikowania video w HD? :-)

Vimeo wygląda tak:

Untitled from Przemysław Rumik on Vimeo.



Minusem jest to, że trzeba czekać nawet 30 minut na to by film był dostępny, a dodatkowo mamy limit 500MB tygodniowo. Na filmy HD to nie jest dużo ;-)
Dodatkowo po osadzeniu na stronie nie mamy na niej materiały HD, żeby obejrzeć HD użytkownik musi wyjść z naszej strony i przejść na stronę Vimeo.

YouTube:


Film jest dostępny bardzo szybko, niemal zaraz po zuploadowaniu, a z czasem dostępne są wersje w wyższej jakości :-)
Możemy osadzić wersję HD na stronie.

Ładniej wygląda "obrazek" w Vimeo, ale trakcie odtwarzania w HD moje oko profana nie widzi różnicy w jakości materiału między oboma serwisami ;-)
Wy coś widzicie? :-)


Podobne postybeta
Generowanie plików ePub z OpenOffice.org :-)
HD według TVN ;-)
Zła TV ;-)
Post-samochody ja
Dzielenie się z Bloggeroida...

"Prezencik" :-)

Skończyłem właśnie czytać A War Of Gifts: An Ender Story.
Miła :-) Jak Orson Scott Card zasługuje na plakietkę "fanatyk religijny" to poza tym ma jeszcze talent pisarski ;-)
To taka krótka książeczka, mająca niecałe 200 stron, ale małych i to z dużymi literami ;-) [dość powiedzieć, że jakieś niecałe dwie godziny temu byłem na 36 stronie, a wtedy do końca miałem koło 160], taka "opowieść wigilijna" w świecie Endera :-)
Zresztą ta książka to taki prezencik, kupiłem ją chyba z rok temu jako wypełniacz i "znalazłem" dopiero parę dni temu gdy przeczytałem pierwsze 36 stron. Miło tak książkę "znaleźć".
Teraz chyba zacznę czytać Ender in Exile, które jak mi się wydaje ma pojawić się w polskim tłumaczeniu.... nie wiem jednak skąd mi się to o tłumaczeniu przyplątało ;-)
No więc miałem prezencik, a i jakby ktoś miał pretensje, to zawsze mogę twierdzić, że ćwiczę angielski ;-)



Podobne postybeta
Książki, książeczki, książunie ;-)
Imperialna Ziemia - dobra książka
Ścisłowcy vs. humaniści
Empik w Bonnarce ssie
Knigi dobre :-)

sobota, sierpnia 14, 2010

Jak rozwiązać krzyżówkę? ;-)

Wiecie jak wg. mnie należy rozwiązać sprawę krzyża przed Pałacem Prezydenckim?

Po 15 sierpnia należy dopuścić "obrońców" znów do krzyża. Jak go tak lubią to proszę bardzo.
Wysłać też Straż Miejską z poleceniem by krzyż zdemontowali i jak chcą to niech go noszą, ale nie może być przymocowany. Jak tego nie zrobią, to znów użyć Policji do odsunięcia ich od krzyża, zdemontować, oprzeć ładnie o coś i znów dopuścić. Zasugerować też, że puki nie są manifestacją [a to chyba ustawa reguluje i zależy to od rozmiarów] to niech sobie łażą po okolicy z tym krzyżem.

Jednocześnie Prezydent i inni powinni powiedzieć, że NIE BĘDZIE ŻADNEGO POMNIKA w tym miejscu.
Jest tablica i NIE BĘDZIE w tym miejscu niczego innego.

Plusy są takie, że po pierwsze państwo dotrzyma swojej części umowy. Policja usuwając "obrońców" powiedziała im, że robi to na prośbę BOR w związku z imprezą na 15. Trzeba więc się z umowy wywiązać i dopuścić ich znów do ich zabawki.
Jednocześnie trzeba podkreślić, że oni z umowy się nie wywiązali. Jest tablica upamiętniająca katastrofę, a krzyż stoi [choć w tym momencie powinien już być noszony] nadal.

I koniec.

"Obrońcom" nie należy ustępować, ani tym bardziej czynić z nich męczenników.
Budowa pomnika to będzie ustępstwo, usunięcie siłowe ich i krzyża to będzie robienie z nich męczenników.
Moje rozwiązanie to po prostu zignorować. Wymusić stosowanie prawa, a to wymaga by mała architektura była budowana za zezwoleniem, zezwolenia nie ma, więc musi być zdemontowana, ale jak chcą ją nosić to proszę bardzo. Jednocześnie ich prawa obywatelskie będą uszanowane. Chcą robić za eksponaty w ZOO dla ludzi kursujących między imprezowniami? Ich wybór.


Podobne postybeta
Znów o rozwiązywaniu krzyżówki
30 baniek na piramidę
Krzyżowcy
Błeee
Jak zamachuję się na wolność wiary....

Choroba technologiczna

Spring, Tapestry, EJB, jQuery, JavaServer Faces, Java FX, Hibernate.......

Niektórzy słysząc te i podobne nazwy wchodzą w stany podejrzanej ekscytacji ;-)
Co drugie ogłoszenie o pracy zawiera co najmniej 2-3 takie hasła. Najlepsze, że zawiera je prawie zawsze całkowicie niepotrzebnie :-)
Głośne używanie Hibernate polega zwykle na tym, że ktoś tam coś napisał, ale i tak większość kodu używa zwykłego SQLa.
A i tak Hibernate jest chyba jedną z niewielu z tych "technologii", które są używane.

Problem tylko z tym, że większość "ekspertów" "znających" te technologie nie rozumie jak działają wątki, albo ma poważne problemy ze zrozumieniem która część kodu wykonuje się na serwerze, a która u klienta, albo tego jak w ogóle ten HTTP działa.

Stąd kochają "biblioteki" i uzasadniają to tym, że "nie będziemy wymyślać ponownie koła" ;-)

Kiedyś na GoldenLine była dyskusja o okienkach modalnych w JavaScript. Z kontekstu wynikało, że chodzi o 1 może 2 takie okienka w całej aplikacji webowej.
Zaproponowałem by po prostu napisać to samemu, bo sprawa do trudnych nie należy, a daje dodatkowo kontrolę nad całym rozwiązaniem.
I od razu oberwało mi się od masy "ekspertów", że ktoś na pewno lepiej ten kod napisał niż ja, że po co znów wymyślać koło i podobnych........
Trochę im zmiękła rura jak zapytałem ile zajmie nauczenie się biblioteki tak by mieć nad nią taką kontrolę jak w przypadku gdy zrobi się to samemu i część przyznała, że rzeczywiście w sytuacji gdy zrobienie czegoś samemu zajmie 2 godziny, a nauka nowej biblioteki zabierze 2 dni to sprawa użycia biblioteki nie jest warta wysiłku.

Większość bibliotek i technologii ułatwia rzeczy proste, a skomplikowane czyni jeszcze bardziej skomplikowanymi. Tylko niewielka z nich część osiąga poziom na którym pomaga zawsze.
Akurat z tych, które wymieniłem na początku większość osiągnęła ten poziom, z tym zastrzeżeniem, że większość ich użytkowników nie osiągnęła tego poziomu :-)

Programista webowy, który boi się używać sniffera/proxy jest po prostu złym programistą. Tak samo taki, który gubi się w debugerze.

Trzeba rozumieć problem i narzędzia, bo bez tego nic dobrego nie powstanie.
Bez talentu i ciężkiej pracy związanej z malowaniem mając nawet najlepsze narzędzia graficzne nie zbliżę się nawet o milimetr do Picassa ;-)

Dlatego Google, które pyta o to jaka jest złożoność obliczeniowa operacji put w HashMap'ie w Java'ie nie pyta o głupie rzeczy, a właśnie o takie, które powinien znać człowiek twierdzący, że zna Java'ę (pesymistycznie jest to O(n), optymistycznie O(1)).

I to by było na tyle ;-)


Podobne postybeta
User Interface... jak ja tego nie lubię...
Code review - najfajniejszy kawałek procesu ;-)
Nazwy
Czemu od 30 godzin nie piję Coli - Eksperyment ;-)
Disconnect, Facebook, PayPal i wykop, czyli 1 plus i 3 minusy ;-)

piątek, sierpnia 13, 2010

Android - nawet platofrma potrafi przeciwko Tobie knuć ;-)

Wrzuciłem już Bloggeroida do Android Market i okazało się, że część użytkowników ma problem z obrazkami, dużymi obrazkami.

Problem mógł występować w 2 miejscach, w trakcie uploadowania dużych obrazków do Picasa'y i w momencie przeglądania obrazków w "menadżerze obrazków".

W obu przypadkach wylatywały błędy "OutOfMemoryError: bitmap size exceeds vm budget".

W przypadku uploadowania obrazków problem był w tym, że chcąc sobie ułatwić obrazek przerzucałem najpierw do strumienia w pamięci, niestety oznaczało to problemy z dużymi obrazkami. Na G1 problemy pojawiały się przy obrazkach mających 4-6 MB, wcześniej tego nie zauważyłem bo G1 ze swoim aparatem 3.2 megapiksela po prostu nie produkuje tak dużych zdjęć :-)
Tego strumienia pamięciowego (dokładniej ByteArrayOutputStream) używałem bo mogłem łatwo pobrać rozmiar obrazka co było mi potrzebne do ustawianie nagłówka Content-Lenght.
No to wyeliminowałem użycie ByteArrayOutputStream i szczęśliwy, że mi tak szybko poszło odpaliłem program na G1...... i znów się wywalił :-)
Okazuje się, że Android robi dokładnie taki sam numer jak ja i wykorzystuje ByteArrayOutputStream, przez co nadal do uploadowania każdy z obrazków był wrzucany do pamięci, tym razem jednak nie przez mój kod, a przez kod Androida i efektem był ten sam błąd :-)
Rozwiązaniem okazało się użycie trybu chunked w połączeniu HTTP.

Stąd lekcja, jeżeli na Androidzie masz zamiar wrzucać duże ilości danych przez HTTP to najlepiej rób to w trybie chunked, wystarczy na obiekcie typu HttpURLConnection wywołać metodę setChunkedStreamingMode(int) z wielkością "kawałka".

Drugi problem widoczny był w "menadżerze obrazków". Tutaj błąd leciał od razu z Androida, a dokładniej z BitmapFactory.decodeStream(InputStream), używanego do stworzenia bitmapy, z której powstać miała ikonka.
Poczytałem po sieci i okazało się, że tu dobrze jest użyć pewnej sztuczki, polegającej na wywołaniu metody BitmapFactory.decodeStream(InputStream,Rec,BitmapFactory.Options).
Kod wygląda teraz tak:

BitmapFactory.Options options = new BitmapFactory.Options();
options.inTempStorage = new byte[16*1024];
options.inSampleSize=4;
Bitmap bitmap = BitmapFactory.decodeStream(is, null,options);


Najważniejsze wydaje się być to inSampleSize=4, które powoduje, że Android dekoduje obrazek do wymiarów 1/4 oryginału [czyli ma on 16 razy mniej pikseli niż oryginał].

No i proszę, człowiek się uczy całe życie :-)


Podobne postybeta
Wredne Google Docs
Chrome2ChromeV2 na GitHub :-)
Piszemy sobie Bloggeroida dla Androida ;-)
Niewyspanie - złe skutki niechciejśpizmu ;-)
Lenistwo w działaniu, "piklujemy" Androida ;-)

środa, sierpnia 11, 2010

Bloggeroid 1.0 :-)



No i stało się :-) Bloggeroid w wersji 1.0 trafił właśnie do Android Marketu :-)

Jeśli chcesz go zainstalować, do czego gorąco zachęcam :-) to tutaj link, który otworzy Ci go w Android Market :-)



Bloggeroid ma być prosty. Pierwszym ekranem który zobaczysz jako użytkownik będzie okno pozwalające na napisanie posta, w końcu po to zwykle będziesz otwierać aplikację do blogowania ;-)

Co możesz zrobić przy pomocy Bloggeroida?

Oto lista:
  • napisać post,
  • dodać obrazki do posta,
  • zdecydować gdzie w treści postu mają być te obrazki,
  • użyć prostego formatowania (**pogrubiony**, __pochylony__),
  • opublikować post na dowolnym ze swoich z blogów w Bloggerze,
  • używać wielu kont Bloggera,
  • publikować posty jako szkice,
  • edytować opublikowane już posty,
  • przeglądając galerię użyć Bloggeroida do "podzielenia" się obrazkami.


Wszystko zaś działa dość stabilnie i co ważne zajmuje mało miejsca na telefonie [użytkownicy G1 powinni być z tego powodu szczęśliwi :-)], bo aplikacja po zainstalowaniu zajmuje mniej niż 120KB.

Zapraszam więc do pobierania :-)


Podobne postybeta
Bloggeroid - wersja 1.0 tuż, tuż ;-)
Piszemy sobie Bloggeroida dla Androida ;-)
Nie kłóć się z użytkownikiem! ;-)
Google+ & Blogger - mój pomysł ;-)
OOo2GD 3.0.0 - eksportowanie do Google Docs bez konwersji :-)

niedziela, sierpnia 08, 2010

Bloggeroid - wersja 1.0 tuż, tuż ;-)


Przygotowuję się do wydania finalnej wersji 1.0 Bloggeroida i do opublikowania jej w Android Market'cie.
Pierwszy krok czyli zgłoszenie do Android Market i wpłatę wpisowego mam już za sobą ;-) Na chwilę obecną kosztowało mnie to 75.88 PLN, ale cena może ulec lekkiej zmianie bo transakcja nie jest jeszcze w pełni zaksięgowana ;-)

Czym jest Bloggeroid?
To prosty klient Bloggera, który pozwala na pisanie i publikowanie wpisów na blogach w Bloggerze, Bloggeroid wspiera wiele kont, dlatego jeżeli mamy np. 2 konta Google w każdym po 3 blogi to Bloggeroid daje nam możliwość blogowania na dowolnym z blogów podpiętych do kont :-)
Bloggeroid pozwala na wysyłanie obrazków, dodatkowo daje narzędzia do "zarządzania" obrazkami. Autor wpisu decyduje w którym miejscu wpisu obrazek ma się znajdować w treści postu. Same obrazki publikowane są w albumach Picasa'y.
Bloggeroid pozwala także na używanie prostej "wikiskładni", w której **tekst** spowoduje, że w finalnym poście tekst zostanie pogrubiony, a __tekst__ pochylony.
Do tego Bloggeroid pozwala na edycję istniejących wpisów na blogach, edycja może odbywać się w formacie "wikiskładnia" + HTML, lub w czystym HTMLu.
Bloggeroid jest także mały, wersja instalacyjna zajmuje mniej niż 50KB, a po zainstalowaniu zajmuje mniej niż 120KB pamięci telefonu :-)
Bloggeroid jest też stabilny. Znam co prawda jedno miejsce gdzie można go "wywrócić", ale mała szansa by się to często udawało :-)
Bloggeroid wymaga Androida 1.5 [choć jak przypuszczam mógłby być też używany na starszych wersjach systemu].
Do tego wszystkiego dostępny jest w wersji polskiej i angielskiej :-)

[do obrazka wkradł się jeden błąd, który został już poprawiony ;-)].

Jeśli ktoś chciałby pobrać to zapraszam do Android Market'u, gdzie trzeba szukać używając tekstu Bloggeroid, albo można po prostu użyć tego QR code'u :-)




Podobne postybeta
Bloggeroid 1.0 :-)
OO.org i Google Docs bez konwersji są tuż tuż ;-)
Google ma dziś zły dzień? ;-)
Javozagadka ;-)
Sztuczki tropiciela błędów, part 4

AppInventor - tego się da używać :-)

Po ostatnich poprawkach Google AppInventor for Android staje się już realnym narzędziem do robienia prostych programów.

Wróciłem do mojego projektu Planu Lekcji. Dzięki naprawieniu przez Gugielków [mała dygresja, jak pracowałem w Motoroli to zwano nas Motorolanami, w Google pracowników zwą Googlerami, jednak po polskiemu ładniej brzmi wg. mnie Gugielki :-)] komponentu TinyDB nie trzeba już inicjalizować kluczy w "bazie" przed ich użyciem. To pozwala na wyrzucenie brzydkiego guziczka init.
Okazuje się również, że w dość łatwy sposób można sobie zmieniać rozmiary komponentów.....

Dzięki temu Plan Lekcji w wersji AppInventorowej wypiękniał :-)



Dodatkowo pokusiłem się o dodanie mu funkcjonalności, która wcześniej wydawała mi się nieosiągalna, czyli domyślnego wyświetlania planu na aktualny dzień :-)
Tu pojawił się problem, bo zegar co prawda podaje numer dnia tygodnia, a nawet i nazwę, ale jeżeli używamy numeru dnia tygodnia to "po angielsku" tydzień zaczyna się od niedzieli, a gdy użyjemy nazwy dnia to niestety będziemy mieli ją w języku interfejsu...... Co można zmienić i już chyba wiem jak :-) ale to pozostawmy na następną wersję ;-)
Teraz problemem było przeliczenie z dni tygodnia liczonych "po angielsku" na takie nasze, tak by to poniedziałek był pierwszym dniem tygodnia.
Trochę to program skomplikowało :-) "kod" wygląda teraz tak:



Jeśli spojrzycie na drugi "moduł" programu to najstraszniej wygląda tam przeliczanie numeru dnia tygodnia "po angielsku" (1 to niedziela, 7 to sobota) na nasze (1 to poniedziałek, a 7 to niedziela).
Głowy nie dam, że dobrze to liczę, ale późno jest ;-) użyłem "wzoru":

Dnum_pol=((Dnum_eng+6) modulo 7)+1


i jest to chyba najtrudniejszy kawałek "programu".
Ten kod wykonywany jest w obsłudze zdarzenia Timera, chciałem go wykonywać w trakcie inicjalizacji ekranu, ale działało to dziwnie, więc zastosowałem sztuczkę polegającą na tym, że kod wykonuje Timer ustawiony na 10 ms, który zaraz po rozpoczęciu wykonywania kodu jest wyłączany.

Ostatni "moduł" to ustawianie zawartości pola tekstowego tym co odczytane zostanie z bazy i ustalanie nowego rozmiaru dla pola tekstowego tak by guziczki wyglądały ładniej na ekranie.
Ten ostatni "moduł" jest procedurą, która wywoływana jest tak ze zdarzenia wyboru elementu z listy jak i pod koniec obsługi Timera.

Nadal nie jest to wybitnie skomplikowany program, ale AppInventor pokazuje już tutaj swoje pazurki. Niezły efekt przy stosunkowo małym wysiłku.
Choć trzeba znać nadal programistyczne sztuczki, jak ta z dniem tygodnia [i nie chodzi nawet o przeliczenie, a o to, że nie każdy musi wiedzieć, że się w ogóle da to odczytać :-)].

A tutaj aplikacja do pobrania :-) [rozmiar to około 1 MB, niestety AppInventor nadal z tym przegina ;-)].
Tutaj źródła [te dla odmiany malutkie, mają mniej niż 4KB :-)]


Podobne postybeta
AppInventor - pierwsze wrażenia i pierwsze programy :-)
Czy się stoi czy się siedzi.... kamerka w laptopie jako detektor tego czy biurko jest w trybie stand czy sit ;-)
Androidowe boje... ale nie takie morskie ;-)
Na "nie" ;-)
Raport z prac nad ubogą krewną Playtypusa, czyli Kolczatką :-)

Androidowe boje... ale nie takie morskie ;-)

Dalej walczę z Bloggeroidem i mam problem.
Albo ja czegoś w platformie jaką jest Android nie rozumiem, albo jest w niej "pewne" niedopatrzenie.
Chciałbym pewną czynność, dokładniej pobranie postów z bloga, robić "z tyłu" aktywności. Gdy pierwszy raz wyświetla się nam aktywność powinien pojawić się "progress", a później lista postów z bloga. Ponieważ chcemy uniknąć pretensji Androida, że blokujemy na zbyt długo wątek UI to wszystko dzieje się w oddzielnym wątku, który robi swoje i w końcu zamyka progress i wyświetla pobraną listę postów....... ale, ale jak ktoś nam złośliwie zmieni orientację ekranu to aktywność ginie, ale wątek sobie leci nadal, i jak już skończy to próbuje zamknąć okienko, którego nie ma, a to powoduje pretensje Androida.... OK, tu możemy założyć zabezpieczenie, ale i tak dane się zgubią. To też by można było przeżyć, ale jeżeli ktoś bez opamiętania będzie latał telefonem i ciągle zmieniał orientację to zima, w końcu poleci OutOfMemmoryError bo po prostu te wątki ciągnące, plus pobrane dane i inne podobne rzeczy mogą przekroczyć ograniczenia na stertę/zrobić coś równie głupiego.
To czego potrzebuję to możliwość odpalenia z aktywności czegoś w oddzielnym wątku co zrobi swoje i odda sterowanie do aktywności nawet jeżeli ta aktywność zginie, ale wróci "na wierzch" jakaś inna tego typu.
Jedyne co przychodzi mi do głowy to coś takiego, że w aktywności będę miał statyczne pole w którym będę trzymał referencję do oddzielnej klasy, w której będzie szalał wątek i na końcu wywoła metodę z przekazanego mu obiektu, a aktywność przy tworzeniu będzie od razu wołała na tej trzymanej statycznie klasie metodę, w której zarejestruje się na wołania z tego obiektu.......
Ale to takie fuj.
Myślałem o serwisie i bindowaniu do niego, ale jakoś nie czuję bluesa.
A to się musi dać jakoś rozsądnie zrobić.

Z innych rzeczy :-) Google ostro pracuje nad Google AppInventor for Android. Naprawili TinyDB i obsługę sensorów :-)
Dzięki temu moja aplikacja do obsługi sensora już działa :-)
Wg. jej wskazań przyciąganie ziemskie u mnie w domu to 9.5 m/s2, wg. wzorów empirycznych powinno to być właśnie 9.81 m/s2.
Chętnie poznam wyniki innych osób :-) Tutaj link do aplikacji, w celu wykonania pomiaru należy telefon położyć na płaskiej powierzchni i sprawdzić wyniki dla ZAccel.
Tak wygląda źródło aplikacji "sensorowej" :-)



Plan Lekcji też jest już prostszy :-)


Podobne postybeta
I jak "po bożemu" zrobić updatowanie widoku na podstawie danych z sieci w Androidzie?
Modale nie takie dobre dla Androida ;-)
Raport z boju z Androidem ;-)
O tym w czym iOS jest lepszy od Androida
Sprawdzanie zdjęcia ;-)

piątek, sierpnia 06, 2010

AppInventor - pierwsze wrażenia i pierwsze programy :-)

Dostałem 2 dni temu czy jakoś tak zaproszenie do Google AppInventor for Android.
Zacząłem się bawić i zacząłem pracować nad projektem, który "obiecałem" w swojej aplikacji o konto [nie wiem czy akurat "za to" mi przyznali konto, bo kilka razy na ten adres próbowałem uzyskać zaproszenie [na inne też ;-)]], czyli postanowiłem spróbować napisać tą samą aplikację przy pomocy AppInventor'a i Java'y i porównać wrażenia.

Programem będzie Plan Lekcji.

Layout wersji dla AppInventora wygląda tak:



Idea jest taka, by po kliknięciu w guziczek u góry pokazywała się lista wyboru z nazwami dni tygodnia, a po wybraniu którejś z wartości pokazywać się będzie zapisana w bazie pod kluczem z nazwą tygodnia "notatka" będąca planem lekcji na dany dzień. Plan lekcji będzie pokazywał się w polu tekstowym pod guziczkiem do wyboru.
Danych dostarczy użytkownik klikając na odpowiedni dzień, wpisując dane w polu tekstowym i klikając na Save.

Kod AppInventorowy aplikacji wygląda tak:



Program "mówi":
po wybraniu opcji z listy wyboru (ListPicker1) ustaw tekst wyświetlany przez listę wyboru na wybraną opcję,
następnie ustaw zawartość pola tekstowego (TextBox1) przy pomocy wartości pobranej z bazy (TinyDB1) spod klucza równego wybranemu z listy (ListPicker1) tekstowi (tak naprawdę temu co wyświetla lista jako wybraną opcję, ale to to samo dzięki wcześniejszemu krokowi),
w końcu ustaw nazwę okna (Screen1) na wybrany tekst.

oraz:

W momencie przyciśnięcia guzika (Button1) zapisz do bazy (TinyDB1) pod kluczem równym wybranej z listy wyborów opcji (ListPicker1) treść z pola tekstowego (TextBox1).

Banał, prawda? :-)

Jest "małe" ale, w obecnej wersji AppInventor'a jest błąd, powodujący, że pobieranie z bazy wartości spod kluczy pod które nigdy nic nie zapisano wyrzuca błąd:



Mają to naprawić w tym lub przyszłym tygodniu :-)

Dlatego dla testu dodałem jeszcze jeden guziczek, który będzie inicjalizował naszą bazę.



Tu już jest trudniej niż w poprzednich blokach programu.
Najpierw mamy użycie pętli forEach, czyli "dla każdego", w tym przypadku dla każdego var z elementów naszej listy z dniami tygodnia (ListPicker1) zapisujemy do bazy (TinyDB1) pod kluczem będącym nazwą dnia tygodnia (w zmiennej var) nazwę tego dnia (z tej samej zmiennej).

Czas wykonania: Trudno powiedzieć dokładnie, ale nie więcej niż 30 minut :-) i to tylko przez to, że to "pierwszy raz".
Rozmiar: trochę ponad 1MB.
Poziom trudności: bardzo łatwy
Wymagana wiedza: niewielka

Działająca aplikacja nie jest zbyt piękna ;-)



Ale działa :-)
Dla mnie jako dla programisty wykonanie tej aplikacji było banalne, dla zwykłego człowieka powinno nie być zabójczo trudne :-)

Teraz wersja w Java'ie :-)

Zaczynamy od Layout'u:


Nasza aplikacja składa się z dokładnie 1 aktywności, w której jedyny istotny kod jest w metodzie onCreate():
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
List<String> list = Arrays.asList("Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday".split(","));
final Spinner spinner = (Spinner)findViewById(R.id.Spinner01);
final EditText editText = (EditText)findViewById(R.id.EditText01);
final SharedPreferences prefs = getSharedPreferences("plan", Context.MODE_PRIVATE);
ArrayAdapter<String> adapter = new ArrayAdapter<String>(this, android.R.layout.simple_spinner_item, list);
adapter.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item);
spinner.setAdapter(adapter);
spinner.setOnItemSelectedListener(new OnItemSelectedListener() {
public void onItemSelected(AdapterView<?> arg0, View arg1,int arg2, long arg3) {
String str = (String)spinner.getSelectedItem();
String content = prefs.getString(str, str);
editText.setText(content);
PlanLekcji.this.setTitle(str);
}
public void onNothingSelected(AdapterView<?> arg0) {
// TODO Auto-generated method stub
}
});
Button button = (Button)findViewById(R.id.Button01);
button.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
String str = (String)spinner.getSelectedItem();
String content = editText.getText().toString();
prefs.edit().putString(str, content).commit();
}
});
}


I to by było na tyle ;-)

Wygląda tak:


Wg. mnie lepiej :-)

Rozmiar: niecałe 15KB.
Czas wykonania: około 15-30 minut, z "kradzieżą" kodu z moich innych projektów.
Poziom trudności: dużo wyższy niż w przypadku AppInventora.
Wymagana wiedza: Po pierwsze trzeba znać Java'ę, ale także API, trzeba też wiedzieć jak zainicjalizować listę wyboru dni, co takie oczywiste nie jest.

Program w Java'ie wykorzystuje łącznie 3 klasy, jedną główną PlanLekcji, oraz 2 anonimowe.

Na samym końcu wersja w HTML5, która powinna działać też np. na iPhone'ie czy iPad'zie ;-) (ale nie działa na moim G1 :-( bo w nim nie ma HTML5)

Która wygląda tak [tutaj, zrzut z ekranu emulatora udającego Nexus One]:



Ładna nie jest, choć faktem jest, że jej uładnienie byłoby najprostsze, bo w HTML'u mamy niemal pełną kontrolę nad layoutem strony.

Kod źródłowy wygląda tak:
<html>
<body>
<script>
function change(elem) {
var str = localStorage[elem.value];
if (str==null) {
str = elem.value;
}
document.getElementById("content").value=str;
}
function save() {
var str = document.getElementById("select").value
var content = document.getElementById("content").value;
localStorage[str]=content;
}
</script>
<select id="select" onchange="change(this)">
<option>Monday</option>
<option>Tuesday</option>
<option>Wednesday</option>
<option>Thursday</option>
<option>Friday</option>
<option>Saturday</option>
<option>Sunday</option>
</select><br />
<textarea id="content" rows="10" cols="10"></textarea><br />
<button onclick="save()">Save</button>
</body>
</html>


Rozmiar: 713 bajtów
Czas wykonania: 10 minut [mnie to tyle zajęło!]
Trudność: łatwe
Potrzebna wiedza: znajomość HTML/JavaScript.

A teraz sekcja downloadów :-)
Plan Lekcji w wersji z AppInventora [1MB]
Plan Lekcji w Java'ie [15KB]
Plan Lekcji w wersji HTML
"Źródła" wersji z AppInventor
Źródła wersji w Java'ie

Podsumowując, jak na razie AppInventor nie wprowadza rewolucji dla programistów, ale daje w ręce trochę bardziej zwykłych ludzi narzędzie do tworzenia prostych programików prostą metodą drag&drop. Robi to niestety kosztem ograniczenia funkcjonalności i wpływu na wygląd aplikacji wynikowej. Ma też jak na razie trochę błędów. Np. wspomniany już tu błąd działania TinyDB, oraz błąd polegający na złym odczytywaniu danych z akcelerometru :-)
Jeszcze kilka miesięcy i będzie to potężne narzędzie do zabawy, a może i do pracy :-)

[prawie 3 w nocy i mi się spać chce ;-)]


Podobne postybeta
Czy ustalanie pozycji w Androidzie może kosztować?
Jak "okradłem" Google Readera ;-)
"Kodowanie" na Chrome OS ;-)
AppInventor - tego się da używać :-)
Python for Android vs. AppInventor - 2:0 ;-)

wtorek, sierpnia 03, 2010

Lenistwo w działaniu, "piklujemy" Androida ;-)

Znów mnie dopadło lenistwo i nie chce mi się kodować :-)
Przez to zamiast użerać z jakimś rozsądnym sposobem serializowania obiektów w Bloggeroidzie po to by przekazywać je w Intentach popełniłem to w najbardziej prymitywny i prosty sposób.

Żeby przesłać obiekt z jednej aktywności do innej, lub do/z serwisu używamy intent.putExtras(String,byte[]), a do odebrania intent.getExtras.getByteArray(String).

Nasz obiekt musi implementować Serializable, i jego członkowie też.

Tutaj dwie użyteczne metody ;-)

public static byte[] toByteArray(Object obj) throws IOException {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(obj);
return baos.toByteArray();
}

public static<E> E toObject(byte[] arr) throws StreamCorruptedException, IOException, ClassNotFoundException {
ByteArrayInputStream bais = new ByteArrayInputStream(arr);
ObjectInputStream ois = new ObjectInputStream(bais);
return (E)ois.readObject();
}


Do toByteArray(Object) przekazujemy nasz obiekt do serializacj, pobierając zaś obiekt z toObject(byte[]) dostajemy to do czego przypisujemy wynik działania tej metody [tu uwaga, jak przypiszemy do czegoś innego to wyleci ClassCastException i tyle będzie zabawy :-)].

Btw. Pythonowe piklowanie brzmi lepiej niż serializacja, której nawet słowniki ortograficzne nie znają.

Jak na razie próbowałem z kilku-kilkunastobajtowymi obiektami i działa, sterta procesu rośnie, ale niewiele ponad to co Android daje w standardzie. Choć udało mi się dotrzeć już do 11MB, a to jednak dużo :-)

Ktoś zna bardziej "koszerny" sposób?


Podobne postybeta
Refleksje i serializacja w Java'ie - podstawy i obalanie mitów ;-)
Zinwigiluj się sam ;-)
Wredne Google Docs
Toperz ;-) czyli OCR + Android odsłona 2 albo któraś tam
Niecne wykorzystanie refleksji... czyli jak poszukać tekstu w drzewie obiektów? ;-)

poniedziałek, sierpnia 02, 2010

Z placu boju z Bloggeroidem ;-)

Dwa największe problemy jakie mam z Bloggeroidem na chwilę obecną to, po pierwsze jak zmienić HTMLa w opublikowanych już postach w mój format udający wiki ;-), po drugie serializacja.
Serializacja np. listy postów pobranej przed chwilą z bloga.
Trochę głupio ściągać tą listę za każdym razem... trzeba by było jakoś zapisać te dane. Albo zserializować do Stringa, albo trzymać w jakimś objekcie globalnym... albo oszukać :-) Zapisać listę obiektów do ObjectOutpuStream otwartego nad ByteArratOutputStream'em i zapisać tablicę bajtów do outState w onSaveInstanceState (metoda w aktywności wołana przez Androida gdy system kładzie naszą aktywność, a powinna być ona później znów dostępna).

Wydaje się, że ta ostatnia metoda to nie jest to ;-) ale ma plusa bo szybka ;-)



Podobne postybeta
Co ładniejsze?
Przepis na szybkie programy ;-)
Nexus S - wrażenia z boju ;-)
Otwarty umysł - definicja ;-)
Wersja 2.0.0 OOo2GD już jest :-)

Plusy dodatkie i plusy ujemne, czyli co może być złego, a co dobrego w AppInventorze :-)

Nie mam jeszcze konta w Google AppInventor for Android, czekam nadal, ale mam już chyba jakieś wnioski ;-)

Pierwszy taki, że jest pewne niebezpieczeństwo w tej aplikacji. Można sobie zrobić krzywdę przez wykorzystanie płatnych usług, albo zamienić telefon w maszynę utrudniającą komuś życie.
Ktoś wkurzony na swoją ex-połówkę będzie mógł chyba dość szybko wyklikać aplikację dzwoniącą pod wybrany numer w dziwnych porach, albo non-stop... z drugiej strony wtedy zapewne druga strona będzie mogła napisać aplikację zrzucającą wszelkie połączenia od tamtej osoby ;-) Dzieciak chcący wygrać "motór" czy innego iPoda w konkursie SMSowym może wpaść na pomysł wyklikania aplikacji do wysyłania SMSów o pełnej godzinie.

To mi przypomina to, że gdy pisałem sobie wtyczki do Gadu-Gadu to napisałem też Skryptusia, w którym zablokowałem np. możliwość wysyłania przez skrypty wiadomości do osób które się do nas nie odezwały. Chodziło mi o to by uniemożliwić powstawanie botów atakujących jakieś numerki ciągłym spamowaniem. Ale przez to ograniczyłem możliwości aplikacji tylko do reagowania na to co się do niej mówiło....
Google ma ten sam dylemat tylko jakiś milion razy większy ;-)

To wyżej to jedno niebezpieczeństwo, które widzę w Google AppInventor for Android. Plusów jest więcej ;-)

To nikt inny jak użytkownicy wie najlepiej czego potrzebują. To może być laboratorium, które posłuży do przetestowania wielu głupich pomysłów, z których niektóre mogą stać się użyteczne.
Ja bym nigdy nie widział potrzeby w pisaniu aplikacji, która będzie odpowiadała na wszystkie SMSy, które otrzyma [w zamyśle autora, gdy jeździ na rowerze to chciałby żeby osoby piszące do niego SMSy były informowane, że nie może odpisać bo jest zajęty], ale przypuszczam, że wielu ludzi nie będzie mogło żyć bez takiej aplikacji.

Zalety edukacyjne są oczywiste, ale i parę nieoczywistych jest ;-) Np. teraz nic nie będzie stało na przeszkodzie napisaniu aplikacji, która co np. 10 minut albo co godzinę będzie robiła zdjęcie. Albo codziennie o tej samej porze. Wystarczy wtedy taki telefon postawić przy oknie i mamy piękny film pokazujący ruch Słońca, czy coś podobnego.

Tak w ogóle. To mnie się marzy [od dobrych 8 lat] takie coś podobne do AppInventora, ale działające na telefonie/PDA :-)
Pojawia się pomysł albo potrzeba i w 5-10 minut wyklikuje się niezbyt skomplikowaną aplikację.
Problem jest "tylko" z interfejsem ;-) Bo nie umiem wymyślić dobrego ;-)

Aha, Google, dajcie to zaproszenie ;-) miejcie litość ;-)


Podobne postybeta
Twitter
Planetarium czy Plebania?
Historia +1
Heurystyka dostępności a strach przed imigrantami
AppInventor - pierwsze wrażenia i pierwsze programy :-)