Dariusz [LocK] Łuksza

Kolejna porcja screenshot’ów z “pracy inżynierskiej”

Jak widać doszła obsługa menu, a w niej:

• My location – automatycznie centruje mapę na naszej pozycji
• Start scan(/Stop scan) – “włącza/wyłącza” wątek skanujący
• List AP – wyświetla listę wszystkich Access Point’ów które w czasie działania aplikacji znajdowały się w zasięgu
• Setting – wyświetla ustawienia aplikacji (ta pozycja wymaga jeszcze implementacji)

Trzy z czterech dostępnych akcji są oprogramowane, zostało mi jeszcze stworzyć odpowiednie menu z ustawieniami aplikacji.

Tak wygląda lista wszystkich “odkrytych” Access Point’ów, z lewej strony widać grafikę/piktogram opisujący jakość sygnału danej sieci (w założeniach jest też, żeby ten sam obrazek opisywał poziom zabezpieczeń danej sieci). Obok jest czytelna nazwa punktu dostępowego (czyli SSID). Punkty dostępowe rozróżniane są po BSSID czyli adresie fizycznym urządzenia, więc w szczególnych przypadkach na liście mogą pojawić się kilka pozycji o tej samej nazwie. W każdy element na liście można “kliknąć” i uzyskać widok szczegółowy.

Muszę się dowiedzieć o status licencyjny grafik dołączonych do Androida …

Ostatni screenshot, pokazuje wspomniany już “widok szczegółowy”. Mamy tutaj szczegółowe dane odnośnie wybranego punktu dostępowego. Jak można zauważyć widok ten wymaga jeszcze dopracowania, gdyż nie wszystkie dane są w pełni widoczne.

To na tyle, więcej za jakiś czas

Jakiś czas temu projekty jgit (czyli implementacja git‘a w java’ie) oraz egit (plugin do eclipse’a dodający wsparcie dla git’a) znalazły się w inkubatorze fundacji Eclipse. Dawno temu wyczytałem nawet, że git ma zastąpić CVS‘a na miejscu domyślnego systemu kontroli wersji w IDE … ale zanim to nastąpi upłynie pewnie jeszcze sporo czasu … nie mniej jednak już teraz można podejrzeć jak się mają rzeczy, co też właśnie w uczynię .

Może na początek kilka numerków 3.5.2 oraz 0.6.0.201002030558, nie nie są to numery dużego lotka . Pierwszy oczywiście opisuje aktualną wersje stabilną Eclipse, drugi zaś jest numerem wersji egit/jgit.

Pierwotnie stroną domową obu projektów było jgit.org (tutaj też znajduje się update site dla eclpse‘a) ale po przejściu projektu pod skrzydła Eclipse Fundation dostępne są dwie stronki eclipse.org/egit/ oraz eclipse.org/jgit/ na obu w sekcji download znajdziemy ten sam link do update site’u:

http://download.eclipse.org/egit/updates

Ja używam ciągle starego update site‘u:

http://www.jgit.org/updates

Z tego co sprawdziłem to podana wcześniej wersja jest dostępna tylko w drugim repo, możliwe że jest to jakiś nightly build czy coś “nie stabilnego” … nie wiem, u mnie działa ;>

W tym wpisie chciał bym omówić jak “podłączyć” nowy projekt pod git SCM (zakładając, że wcześniej nie współdzieliliśmy go w żadnym SCM‘ie). Jeżeli chodzi natomiast o dodanie istniejącego już projektu podpiętego pod jakieś git‘owe repo to robi się to przez File -> Import, nie ma do tego nowej perspektywy wszystko robią wizard‘y.

Tak więc dla przykładu zakładamy sobie nowy projekt GitTest, dodajemy tam jedną klasę Main z “standardowym”

System.out.println("Hello git!");

Następnie na tak spreparowanym projekcie klikamy prawym myszy i wybieramy po kolei Team -> Schare Project… z dostępnej listy oczywiście wybieramy git. Jeżeli plugin znajdzie w jakimś katalogu nadrzędnym katalog .git (czyli miejsce gdzie git przechowuje swoje metadane) to zasugeruje podpięcie się pod już istniejące repo. W moim przypadku taka sytuacja nie występuje.

Zaznaczmy nasz projekt, klikamy w Create Repository, następnie w Next i oto wykonaliśmy odpowiednik git init … sam nie wiem co jest prostsze, chyba jednak wolał bym to zrobić z “palca”.

Skoro już zainicjalizowaliśmy nasze repo trzeba by je czymś wypełnić, czyli wykonać odpowiednik git add. Spokojnie, wszystko można wyklikać tak wiec zaczynajmy klikać ;>. Parawym myszy na pliku/katalogu który chcemy dodać (w moim wypadku jest tylko jeden katalog src) i poklei Team -> Add to version control.

Kolejny krok to git commit. Znowu to wyklikamy ;> Team -> Commit. Możemy teraz dodać komentarz do commit‘a jak również odznaczyć pliki które nie chcemy dodać do repo. Po kliknięciu w Commit nasze zmiany zostaną zapisane w repozytorium.

Jako że przez pomyłkę na dodałem cały projekt do commita (Team -> Add to version control) również “nie chciane pliki” takie jak .setting, .classpath oraz .project dodały się co commit‘a. W takim wypadku odpalamy widok Navigator i na każdym takim pliku wykonujemy po kolei operację Team -> Remove from version control, Team -> Add to .gitignore. Tak powstały plik .gitignore dodajemy do git‘a i commit‘ujemy (czyli: Team -> Add to version control, Team -> Commit).

Pora zrobić coś bardziej szalonego … zmieńmy zawartość Main.java ! Żeby za bardzo nie szaleć ja dodałem dodatkowy wykrzyknik na końcu “Hello git!” ;>. Zapisujemy zmiany. Eclipse automatycznie (podobnie z resztą jak to ma miejsce podczas korzystania z CVS‘a) informuje nas o tym, że względem repozytorium nasz plik jest zmieniony. Jak sprawdzić zmiany ? Nie ma czegoś takiego jak Synchronize with repository … ale jest za to: Compare with -> Git index. Moje „szalone zmiany” są widoczne jak na dłoni … albo jak kto woli “jak na CVS’ie”

Niestety na chwilę obecną nie dopatrzyłem się żadnych możliwości porównania całego projektu, jak to jest możliwe w CVS’ie. Trzeba porównywać każdy plik z osobna … jest to trochę męczące ale mam nadzieje, że w kolejnych wydaniach taka funkcjonalność zostanie “jakoś” zaimplementowana oraz dodana.

Po sprawdzeniu jakie zmiany, względem repo, wprowadziliśmy w naszym projekcie możemy śmiało wyklikać Team -> Commit na naszym zmienionym pliku. W ten sposób moje repo zawiera już 3 commit‘y ;>

Może teraz sobie po-branch‘ujemy. Prawie standardowo klikamy na projekt i wybieramy Team -> Branch… wyskakuje nam okienko w którym możemy dodać nową gałąź, zmienić jej nazwę oraz przełączyć się na wybraną gałąź. Aktualna gałąź jest pogrubiona oraz dodatkowo oznaczona przypisem (current). Klikamy w New branch nazwa jest praktycznie dowolna, ja nazwałem nowy branch jako “awesome-changes” , akceptujemy zaznaczamy nowo dodany branch i klikamy Checkout, żeby się na niego przełączyć. Prawda, że proste ?

Teraz jeżeli klikniemy na projekt prawym myszy i z menu wybierzmy Team -> Show in Resource History widzimy historię zmian w naszym projekcie.

Niestety na chwilę obecną plugin nie pozwala merge‘ować branch‘y … szkoda, trzeba to robić ręcznie z linii poleceń czyli git merge <target> <source>.

Dostępna jest natomiast opcja nadpisywania poczynionych zmian. Przez Team -> Reset można wykonać reset wprowadzonych zmian do poziomu w wskazanej gałęźi.

To tyle mojego małego przeglądu, więcej informacji można znaleźć w User Guide EGit‘a.

Oto pierwszy screenshot z mojej pracy inżynierskiej

Aplikacja posiada już następujące funkcjonalności:

• Potrafi sprawdzić stan WiFi oraz w razie potrzeby sama go włączyć (nie pytając użytkownika o zdanie … bo po co ? jeżeli się uruchamia taką aplikację wiadomo, że sieć bezprzewodowa musi być włączona )
• Potrafi sprawdzić status usługi GPS oraz poprosić użytkownika o jej włączenie (ponieważ android może za zgodą użytkownika wysyłać dane lokalizacyjne go Google’a warto żeby użytkownik sam włączył usługę, ewentualnie wyłączył moją aplikację)

• Wyświetla aktualną pozycję użytkownika (to jest właśnie ta gwiazdka na środku ekranu)
• Automatycznie co pół sekundy skanuje eter w poszukiwaniu sieci bezprzewodowych.
• W prawym górnym rogu umieszczona jest licznik aktualnie wykrytych sieci
• W prawym dolnym rogu umieszczony jest licznik sieci które aplikacja “mniej więcej” zlokalizowała (ew. potrafiła zlokalizować)

Przewidywane funkcjonalności:

• Automatyczne wycentrowanie mapy na pozycję użytkownika (gwiazdkę)
• Dodanie możliwości konfiguracji (chociażby możliwość zmiany interwału skanowania)
• Obsługa przycisku “menu”
• Zapisywanie wyników aplikacji w “jakimś” formacie
• Kalibracja aplikacji
• Algorytm lokalizacji punktów na podstawie sygnału WiFi oraz lokalizacji użytkownika

Teoretycznie powinno już być z górki, gdyż już w miarę zaprzyjaźniłem się z SDK oraz API android’a. Największym wyzwaniem będzie główna część czyli implementacja (raz opracowanie) algorytmu pozwalającego na zlokalizowanie access point’a; jego zarysy już kłębią się mi w głowie z tym, że posiada on jeszcze kilka słabostek.

Zmiana platformy implementacyjnej znacząco przyśpieszyła prace nad aplikacją

Dziś w ciągu nie całych 2 godzin udało się mi wystartować cały projekt oraz uruchomić usługę Google Maps, GPS oraz zintegrować całość ze sobą. Jedyną rzeczą jaką (na razie) moja aplikacja wykonuje, jest umieszczenie markera (w postaci maskotki androida – robota) na odpowiedniej szerokości i długości geograficznej oraz przesunięcie w to miejsce mapy. Czyli aktualnie geo-lokuje telefon ;>

Całość wymaga jeszcze dopracowania, gdyż jest to tylko szybki szkic … ale posiada bardzo ważna cecha, DZIAŁA . Przede mną jeszcze sporo pracy:

• Ustalenie odpowiednich interface’ów
• Zaprojektowanie architektury aplikacji
• Obsługa wyjątków (reakcja na włączenie/wyłączenie GPS’u, WiFi itp.)
• Obsługa WiFi
• Reprezentacja zebranych danych na mapie
• Zapis całości w formie pliku wynikowego czy tez map w Google Maps

Na chwilę obecną tylko tyle przychodzi mi do głowy, pewnie jeszcze sporo rzeczy wyjdzie w “praniu”.

Do mojego zbioru przydatnych linków doszły dwa nowe elementy, głównie dzięki nim udało się mi tak szybko przebrnąć przez tą część

Siedem semestrów nauki już za mną, czas więc na napisanie pracy inżynierskiej … a czasu zostało nie wiele, bo do końca kwietnia. Tak więc czeka mnie teraz wzmożony okres ;>. Moje ambitne plany zakładają do końca lutego stworzyć aplikację na tyle, żeby można było rozpocząć badania (oczywiście w między czasie aplikacja będzie musiała być ulepszana). Cały marzec mam zamiar poświęcić na przeprowadzenie “badań naukowych”  oraz “napisanie” pracy.

Jeżeli wszystko pójdzie zgodnie z ambitnym planem to w połowie kwietnia powinienem złożyć gotową pracę … zobaczymy jak to wyjdzie.

W pierwotnej wersji moja praca inżynierska miała wiązać się z OpenMoko … niestety semestr walki z JNA nie przyniósł pożądanych efektów dlatego postanowiłem zmienić platformę na “bardziej dojrzałą” (zwłaszcza, że w między czasie nabyłem G1).

Taki obrót sytuacji spowodował, że na chwilę obecną nie posiadam nawet zarysu aplikacji ;>. Ale czym tu się przejmować, nie ma co biadolić czas zabierać się za robotę

IMHO bardzo dobrym quick-start’em jest ta dwugodzinna prezentacja. Zawiera ona dość przekrojową wiedzę potrzebną do tego żeby szybko wystartować z projektem; brakuje w niej opisu manifestu aplikacji, poziomów dostępu do danych i sprzętu … to będzie trzeba uzupełnić na własną rękę.

Oprócz tego standardową kopalnią wiedzy na temat androida jest strona developer.android.com, gdzie dostępne są prezentacje z Google I/O oraz inne sponsorowane przez Google jak również dostępna jest pełna dokumentacja.

W tym poście postaram się agregować wszystkie przydatne linki które okażą się pomocne podczas tworzenia aplikacji. Więc jeżeli interesujesz się tym tematem to zapraszam do zaglądania tutaj … podobnie jeżeli Ty posiadasz jakieś interesujące materiały nie krępuj się umieścić link do nich w komentarzu

• Tutorial pokazujący wykorzystanie widgetu MapView dostępnego w Google APIs (czyli dodatku do standardowego API androida)
• Szybki TUT jak rozpocząć “zabawy” z GPS’em

Dziś dzięki serwisowi develway.pl który dość nie dawno trafił do mojego  czytnika RSS, trafiłem na serwis devcheatsheet.com na którym to znajdują się  ściągawki (tzw. chetsheet’y) do wielu języków, framework’ów oraz narzędzi developerskich (nie które odnośniki są puste np. do GWT ale może za jakiś czas coś się tam pojawi).

Mnie w szczególności zainteresowały te pozycje:

• git
• eclipse
• lua
• pl/sql

Miłego ściągania ;>

Ponad rok temu wspominałem tutaj o blogu Mariusz Lipińskiego w kontekście SCJP. Od wspominanego wpisu minął ponad rok. W tym czasie Mariusz zdążył uzyskać certyfikat, a nawet opublikować dwa wydania własnej książki (pierwsze jest całkowicie darmowe, a drugie można kupić tutaj), dodatkowo na łamach bloga krótko opisuje każdy rozdział z Sun Certified Programmer for Java 5 Stury Guide.

Ja w tym samy czasie próbowałem moich sił z  Sun Certified Programmer for Java 6 Stury Guide (SCJP6SG), cóż ukazał się dokładnie jeden post o tym temacie (w sumie to nie ma się czym chwalić ), a natłok obowiązków związanych ze studiami i pracą nie pozwolił mi kontynuować tą serię wpisów.

Wspomniałem już wcześniej o książce Mariusza w formie drukowanej, dziś właśnie dotarł do mnie jeden jej egzemplarz. Objętościowo jest on nie do porównania z SCJP6SG. Jeszcze nie zagłębiałem się dokładnie w Przygotowanie do certyfikacji SCJP6 ale zakładam, że jest to odpowiedni wstęp jak i repetytorium przed i po zapoznaniem się z SCPJ6SG.

W tym roku nie ma już raczej szans żebym przystąpił do egzaminu … ale za to postaram się to zrobić w przyszłym

Kilka dni temu JetBrains udostępniło okrojona wersje (ładnie nazwaną Community Edition) swojego IDE dla Javy. Jako że nigdy nie miałem do czynienia z InteliJ postanowiłem zassać ową darmową wersję i sprawdzić jak się spisuje.

Niestety, używam dość egzotycznego window managera który zwie się Awesome. Posiada on funkcjonalność auto organizacji okien na pulpicie co jak się okazuje nie podoba się Javie 1.5 wzwyż. Winę za to ponosi zmieniony w JRE 1.5 backend do komunikacji z X-Window, JRE do wersji 1.4 korzystało z Motif, natomiast w późniejszych z Xtoolkit/XAWT które to nie jest kompatybilne z ICCCM (cokolwiek to znaczy ). Warto tutaj wspomnieć ze pośrednio może tutaj tez być winne JetBrains gdyż ciągle korzystają z AWT, a nie Swing‘a …

Rozwiązania ?
Są dwa. Pierwsze bardziej drastyczne uruchamiać InteliJ z wykorzystaniem JRE 1.4 – tego nie próbowałem ale teoretycznie powinno zadziałać. Drugie rozwiązanie posiada pewien haczyk, gdyż (jak się domyślam) 64-bitowa wersja Javy nie posiada wsparcia dla Motif; osoby posiadające 64-bitowe maszyny i systemy operacyjne z 64bitowa maszyna wirtualna ustawiona jako domyślną muszą dodatkowo zassać i gdzieś umieścić wersje 32-bitowa JDK/JRE. Oprócz 32-bitowej maszyny wirtualnej musimy dodać zmienna środowiskową AWT_TOOLKIT ustawiona na MToolkit. Ja zmodyfikowałem sobie plik bin/idea.sh dodając w linii 59 taki oto fragment:

# fixes for Awesome WM
export AWT_TOOLKIT="MToolkit"
IDEA_JDK="/ścieżka/do/jdk-x86"

Mimo, ze oficjalne ogłoszenie wyników GSoC09 odbyło się prawie dwa miesiące temu, dla mnie google’owe lato z kodowaniem zakończyło się dopiero parę dni temu kiedy to kurier dostarczył do mnie paczkę z koszulka i certyfikatem.

Co do samego projektu, to niestety nie udało mi się go skończyć w wyznaczonym terminie. Osobiście stopień zaawansowania oceniam na 75-80%. Mimo to Reinhard (mój mentor) uznał, że wykonałem na tyle dobrą pracę że ukończyłem pozytywnie GSoC.

Koniec Summer of Code nie oznacza dla mnie końca współpracy z developerami Cocoon’a, zwłaszcza, że nie wykonałem w pełni stawianych sobie celów. Dodatkowo na horyzoncie pojawiły się nowe interesujące pomysły na rozwój modułu monitorującego trzecią wersję Cocoon‘a.

Ostatnio pisząc o Summer of Code wspominałem o artykule traktującym o Spring JMX, miał on się ukazać w ciągu 2-3 tygodni … cóż nie udało się ale nie wydaje mi się by jego los był przesądzony . Wszystko jest ciągle kwestią czasu … jest to jedna z rzeczy którą chciałem zrealizować w czasie GSoC i ciągle pozostaje na mojej (dość, długiej(sic!) już) liście TODO.

Zapomniałem o jednej bardzo ważnej rzeczy … 90% napisanego przeze mnie kodu podczas GSoC znajduje się już w repozytorium ASF, a dokładniej mówiąc to jest tutaj. Natomiast całość kodu dostępna jest w archiwum znajdującym się pod koniec tej listy.

Today I publish newest version of cda2mc on github.

This version contains 2 new features:

1. it is possible to add CD information manually if CDDB does not contains information about it
2. if CDDB contains multiple entry’s for that particular CD you can chose one from list with one you want to use