Miałem ostatnio okazję przedstawiać na JAGu (Java Advanced Group, koło naukowe na Politechnice) prezentację dotyczącą frameworka Google Web Toolkit. W wielkim skrócie jest to technologia pozwalająca na pisanie JavaScriptowych programów z użyciem Javy i umieszczanie ich potem na stronach WWW.

Moim celem było przede wszystkim zainteresowanie obecnych frameworkiem Google'a przedstawiając - oprócz podstawowych informacji - także prostą aplikację wykorzystującą to rozwiązanie. Z wynikami mojej pracy można zapoznać się TUTAJ(temat 51), do czego serdecznie zapraszam :-)

W świecie internetowych technologii jednymi z najgorętszych tematów są mobilne wersje Opery, które przejęły komórkowy kawałek tortu niedostępny dla jej desktopowej odpowiedniczki. Niedawno norweska firma zajmująca się rozwojem przeglądarki udostępniła emulator, za pomocą którego możemy sprawdzić jak dana strona będzie wyglądała na ekranie urządzenia przenośnego.

Emulator wita nas rozdzieloczością, która przedstawiona jest jako najpopularniejsza w nowoczesnych smartfonach, jednak w prosty sposób możemy dostosować ją do swoich potrzeb. Kiedy już to zrobimy dostajemy możliwość poczucia, jakbyśmy naprawdę surfowali po sieci z poziomu telefonu - na stronach, które mają swoją wersje mobilne automatycznie jesteśmy na nie przenoszeni, pozostałe skalowane są do rozmiaru ekranu z możliwością powiększenia wybranego fragmentu. Co ciekawe, dla niektórych stron dostępna jest trzecia droga - mój blog wyświetlany jest w ten sposób, że na ekranie emulatora mieszczą się posty, natomiast ramka znajduje się po prawej stronie poza krawędzią ekranu. Nie miałem okazji oglądać wcześniej witryny na żadnym urządzeniu mobilnym i przyznam że efekt ten bardzo mnie ucieszył :-) Trochę gorzej ma się sprawa z wyświetlaniem podstron - nie zawsze wygląda to tak dobrze jak w komputerowej wersji przeglądarki.

No ale koniec dygresji o moich mobilnych wrażeniach - wspomnę jeszcze, że emulator daje możliwość korzystanie z popularnych narzędzi wbudowanych w Operę, takich jak Dragonfly czy widżety. Razem składa się to nie tylko na niezłą ciekawostkę, ale także na przydatne narzędzie pozwalające dostroić wygląd witryny do potrzeb urządzeń mobilnych. Nie oszukujmy się - to jedna z najszybciej rozwijających się gałęzi nowych technologii i nie można jej zlekceważyć.

Czekaliśmy na ogłoszenie wyników pierwszej rundy Imagine Cup z wielkimi nadziejami, ale i niepokojem - w końcu zdecydowaliśmy się na start dość późno i nie wszystko co w początkowym ambitnym planie sobie założyliśmy udało się zrealizować. Termin ogłoszenia wyników był dwukrotnie przekładany, a jeżeli dodamy do tego fakt, że parę dni temu (na kilka godzin!) pojawiła się informacja, że odpadliśmy, co mniej odporne osoby mogły bać się o stan swojego serca.

Ale ostatecznie udało się! Znaleźliśmy się wśród wybranych 150 ekip z 677 startujących, co automatycznie stawia nas w randze półfinalistów. My, czyli ja, Jakub Krajewski, Waldemar Korłub oraz Łukasz Koziel, 404 Entertaiment. Mamy teraz niecały miesiąc na dokończenie pracy, do 4 maja musimy rozszerzyć nasze demo i nadać mu postać gotowej wersji. Mało czasy, ale damy radę, jeszcze będzie o nas głośno :-)

Tym postem chciałbym rozpocząć tutorial dotyczący dynamicznie rozwijanego frameworka Microsoftu o nazwie XNA Game Studio. Sporo doświadczenia nabrałem pisząc wraz z zespołem grę na konkurs Imagine Cup, efekty będzie za jakiś czas można zobaczyć w gotowej produkcji. Zaznaczam już na starcie, że potrzebna Ci będzie podstawowa wiedza z zakresu programowania obiektowego, najlepiej w microsoftowym C#, a także wyszukiwarka internetowa (najlepszy przyjaciel każdego informatyka ;-)).

Pierwszym krokiem do rozpoczęcia zabawy z XNA jest ściągnięcie środowiska, w którym będziemy pisać grę. Najlepiej sprawdza się w tej roli Visual Studio, ale jeżeli akurat nie jesteś studentem, który może pobrać je za darmo, gigant z Redmont ma dla Ciebie darmowy, choć trochę mniej funkcjonalny zamiennik (Visual C# Express Edition). Ja dla wygody wybieram VS, ale wątpię żebyśmy trafili na wielkie różnice między nimi w trakcie pisania aplikacji. Następnie zaopatrzyć musisz się w sam framework, dostępny na stronie Microsoftu.

Kolejnym krokiem jest utworzenie projektu (File-> New-> Project). Przy wybieraniu szablonu (Template) należy wskazać najpierw Visual C#, a następnie wybrać XNA Game Studio w odpowiedniej wersji (najnowsza na ten moment to 3.1, choć trwają zaawansowane prace nad 4).

Teraz jesteśmy już w domu, w końcu trochę kodu do objaśnienia. Pisanie gry z użyciem XNA wymaga ogólnej zasady zrozumienia działania frameworka. Najważniejszą rzeczą jest podzielenie klasy Game1 na 6 zasadniczych części. Obszar z konstruktorem i zmiennymi mam nadzieję nie wymaga wyjaśnień, tuż za nim znajduje się Initialize, gdzie należy wywołać metody, które mają wykonywane przed uruchomieniem samej gry. Dalej mamy LoadContent, wywoływane raz w trakcie gry. Warto umieścić tu wszystkie elementy, które wymagają załadowania zewnętrznych elementów jak xmle czy grafiki, tak żeby potem nie obciążać komputera w trakcie rozgrywki. Odwrotnością do powyższej metody jest UnloadContent, służące do zwolnienia załadowanych zasobów. Pozostały jeszcze dwie najważniejsze funkcje - pierwszą z nich jest Update. Należy umieścić tu całą logikę gry, czyli obsługę tego, co ma dziać w jej trakcie. Podobnie jak w ostatniej metodzie, Draw (które służy do wyrysowania tego co ma pojawić się na ekranie) w Update następuje obsługa czasu, co dla gry w oczywisty sposób ma niebagatelne znaczenie. To nie jedyny związek pomiędzy tymi dwoma metodami - w trakcie rozgrywki są na zmianę wywoływane.

Tyle na razie, następnym razem zabierzemy się już za pisanie :-)

... a że tych oczu jest całkiem sporo, ciężko jest stworzyć witrynę o idealnym układzie; przeciwko nam będą min. różne przekątne monitorów, rozdzielczości ekranów czy szerokości menu przeglądarek. Pomóc w tej nierównej walce ma nam m.in. nowy google'owy projekt stworzony w ramach '20% czasu' przez z inżynierów firmy z Mountain View - Browser Size.

Potrzeba jest matką wynalazków - pracownicy Google nie byli zadowoleni z liczby osób, która wchodząc na stronę ich projektu Earth, wybierała przycisk 'Agree and download'. Za pomocą analiz statystycznych postanowili stworzyć nakładkę pozwalającą określić, jaka część ekranu jest widoczna dla użytkowników bez potrzeby przewijania. Efektem ich zabiegów jest właśnie Browser size . Całość jest banalnie prosta w obsłudze - wpisując URL żądanej witryny jesteśmy w stanie sprawdzić 'widzialność' komponentów.

Tworząc tę stronę nie korzystałem z google'owego narzędzia, jednak, jak można zauważyć, większość jej powierzchni znajduje się w obrębie 90% widoczności, podczas gdy to co najważniejsze - nawet 98%. Jak widać Browser Size nie jest niezbędny w pracy webdevelopera, ale dobrze sprawdza się jaka ciekawostka żeby spojrzeć na projekt z nieco innej perspektywy ;-)