Gphone.pl - Google Android, Apple Iphone, smartfone, technologie mobilne

Wieści z Mountain View głoszą, że Googleapps są teraz dostępne przez streamowany interfejs (streamlined mobile interface) – nowe UI pozwala na używanie usług typu Gmail, Google Calendar, Google Docs, Reader, Notebook, Bloger, News z komórek Iphone i odtwarzacza Ipod Touch. Użytkownicy mogą więc sprawdzić maile, dodać adres do ulubionych czy ogłosić nową notatkę przełączając się między aplikacjami nie czekając nawet sekundy na przeładowanie.

Szybkie, sprawne wyszukiwanie z dostępem do News, Graphics, Local, sugestii wyszukania z wykorzystaniem zaledwie jednego ruchu palcem. Jest także dostępny widok miesiąca oraz dnia dla Google Calendar, który pozostaje w trybie ‘always-in-sync’. Nowa jakość usług którą docenią posiadacze dotykowych gadgetów Apple’a wchodzi ukaże się w kolejnych 16 nowych wersjach językowych, od szwedzkiego po chiński – jak donosi Ulf Waschbusch, Product Marketing Manager, w Google mobile teamie.

Nowy interfejs można przetestować między innymi do zarządzania własną firmą dzięki usługom Google Apps for your domain lub innych narzędziach – wystarczy odwiedzić w swoim Iphone lub innym smartphonem stronę http://www.google.com/m/a/

Otwartość Androida, ADC i wielka pompa, jaka towarzyszyła udostępnieniu pierwszych wersji SDK owocują ogromnym rozkwitem pomysłów. Widzieliśmy już nowatorskie aplikacje, takie jak Enkin czy Kudostar, powstałe w ramach konkursu ADC, które zapewne zmienią oblicze technologii mobilnych i podniosą poprzeczkę oczekiwań użytkowników co do aplikacji.

Pomysłowość developerów oraz determinacja Google w zdobywaniu zainteresowania Androidem wśród błyskotliwych programistów zaprowadzi nas być może do zupełnie nowatorskich rozwiązań. Podczas gdy w technologiach webowych zaciera się granica pomiędzy aplikacjami klienckimi a serwerami, pomiędzy desktopem a terminalem, podobny proces zachodzi pomiędzy PCtem a urządzeniami mobilnymi.

Jednym z dobitnych przykładów tego jest powstanie iJetty - popularnego, miniaturowego serwera web’owego Jetty w wersji dla Androida. Dzięki iJetty możemy własny telefon zamienić w serwer internetowy. Może on hostować aplikacje AJAXowe lub Comet, statyczne strony HTML a także usługi webowe, zaimplementowane jako Servlety w Javie. Pojawienie się iJetty nie przeszło w sieci bez echa.

Dzięki iJetty można będzie np. nosić swojego bloga i stronę internetową dosłownie we własnej kieszeni. Ale co ciekawsze, można będzie także kontrolować swój telefon zdalnie, przez internet, bez Bluetooth, IRDA czy USB, prosto ze swojej przeglądarki internetowej! Powstał nawet mały Google Gadget, dzięki któremu można wyświetlać ekran swojego telefonu bezpośrednio na stronie startowej iGoogle! Teraz zamiast podłączać telefon do komputera, można będzie po prostu przesłać do niego zdjęcia i muzykę tak, jakby się wysyłało maila. I w drugą stronę, równie łatwo będzie można ściągnąć z niego zdjęcia czy nakręcone wideo, a nawet zajrzeć do kontaktów czy wysłać SMSa. Jeśli telefon zagubi nam się w pokoju, można będzie się z nim połączyć i np. uruchomić MP3 Player, dzięki czemu szybko odnajdziemy telefon.

Z punktu widzenia programistów, sprawa jest jeszcze ciekawsza. Ponieważ jeszcze przez kilka lat połączenie z siecią z telefonu będzie miało dość ograniczoną przepustowość, developerzy chcieliby część kodu wykonywać bezpośrednio na urządzeniach, zamiast na serwerze, aby użytkownik nie musiał czekać na reakcje aplikacji zbyt długo. iJetty pozwoli na implementacje fragmentów usług po stronie klienta, dzięki czemu poprawi się user experience.

Wprowadzenie technologii webowych na platformy mobilne pozwoli na stworzenie bardzo zdecentralizowanych sieci P2P i komunikatorów opartych o wszechobecny protokół HTTP. Taki mobilny anonimowy FreeNet. Tego typu zdecentralizowane sieci odporne są na katastrofy. Internet udowodnił już wiele razy, że w razie kataklizmu doskonale nadaje się jako niezawodna platforma komunikacyjna, w przeciwieństwie do sieci GSM. Wykorzystując, oprócz połączeń internetowych przez GSM, WiFi oraz Bluetooth, można stworzyć rozproszoną, zdecentralizowaną, samo-organizującą się sieć. Urządzenia, którym udało się połączyć ze stacjami bazowymi telefonii komórkowej, mogłyby służyć jako routery i umożliwiać innym dostęp do sieci poprzez WiFi.

Oczywiście, zrobienie z telefonu prawdziwego serwera to kiepski pomysł: ograniczone zasoby pamięci, powony procesor i niska przepustowość wyczerpią baterie i zapchają system, jeśli będzie chciało z niego korzystać więcej niż zaledwie kilku odwiedzających naraz.

iJetty jest już aplikacją stabilną. Brakuje w niej jednak możliwości dynamicznego ładowania aplikacji webowych przygotowanych jako pliki .war. Nie działają też ClassLoader’y. Webtide i Google jednak zapowiadają rozwiązanie tych niedogodności w najbliższym czasie. Webtide jednak nie jest jedynym, który idzie w tym kierunku: Nokia stworzyła Raccoon – port popularnego serwera Apache na telefony komórkowe oparte o S60 3rd Edition. Więcej o Raccoon można przeczytać tutaj.

Czym jest XMPP?

XMPP jest protokołem, który pozwala budować sieci komunikatorów internetowych. Szerszemu gronu użytkowników technologia ta znana jest jako jabber. Protokół pozwala przesyłać wiadomości, informacje o kontaktach i ich statusach, a nawet pliki i media (np. VoIP).

Jedną z największych zalet samego protkokołu XMPP jest możliwość “zaembedowania” go wewnątrz protokołu HTTP, dzięki czemu udaje się omijać firewalle, co daje mu przewagę nad innymi rozwiązaniami jak np GaduGadu czy ICQ. Użycie HTTP odbiega od standardowego modelu: zwykle klient HTTP wysyła żadanie do serwera, serwer je przetwarza i wysyła odpowiedź do klienta, po czym zamyka połączenie. Taki model nie nadaje się do implementacji usług typu chat, toteż zmodyfikowano go tak, że serwer po wysłaniu odpowiedzi nie zamyka połączenia. Na trwającym nadal połączeniu może dosyłać do klienta dochodzące wiadomości, zmieny statusów jego kontaktów itd. Gdyby nie to, klient musiałby co kilka sekund pytać się serwera o nowe wiadomości i update kontaktów.

Tę ciekawą funkcjonalność ostatnio wykorzystuje się do budowania usług webowych, wymagających ciągłego dostępu do informacji. Można np napisać aplikację webową wyświetlającą bieżące kursy akcji – wystarczy zrobić klienta XMPP, który otwiera połączenie do usługi, a serwer wysyła zmiany cen na bieżąco, dzięki czemu klient takiej usługi zawsze będzie poinformowany natychmiast. Podobny model oferuje technologia Comet.

XMPP jest przez wielu widziany jako “następca HTTP”, albo przynajmniej jego rozszerzenie i dlatego powołano XMPP Standards Foundation, organizację mającą na celu propagowanie, standaryzowanie i wynajdywanie nowych możliwych zastosowań tej technologii.

Google dodaje XMPP

Wielu developerów ucieszyło się, gdy w Android SDK znalazła się obsługa XMPP. Zaczęły powstawać aplikacje oparte na załączonych w SDK bibliotekach. Uznawano nawet pewną przewagę Androida nad innymi techonologiami właśnie ze względu na wbudowaną możliwość komunikacji poprzez XMPP.

Google wyrzuca XMPP i wstawia GTalkService

Ku zaskoczeniu (i głównie rozczarowaniu) entuzjastów Androida, Google zdecydował się w najnowszym SDK zamienić XMPP na GTalkService. Spowodowało to popsucie kodu istniejących już aplikacji. Ale co gorsza odebrano to jako sygnał, iż Google rezygnuje ze wspierania XMPP na Androdzie. Powodów może być kilka, mowi się np o tym, że Google woli GTalka domyślnie na telefonach wyposażonych w Androida, zamiast darmowego jabbera, inni wskauja na to, iż operatorzy GSM mogą być niezadowoleni, jesli ich użytkownicy zamiast wysyłać płatne SMSy zaczną przesyłać wiadomości jabberem.

Oczywiście, developerzy mogą używać istniejących już bibliotek takich jak Smack, ale to zwiększa rozmiar aplikacji, ponadto wielu programistów uważa, iż tak fundamentalna funkcjonalność powinna być częścią SDK, co ułątwiło by sam proces projektowania i implementacji aplikacji.

Ostatecznie okazało się, że głównym powodem, dla którego Google zrezygnował z XMPP jest ogromne zużycie baterii do jakiego dochodzi, gdy telefon jest cały czas połączony z serwerem. Telefon utrzymując otwarte połączenie zużywa sporo energii na obsługę komunikacji radiowej. Ponadto XMPP oparty jest o XML, przez co komunikaty są niepotrzebnie duże. Jest to problem samego XMPP, a jego rozwiązaniem może się okazać specjalna, być może binarna wersja protokołu XMPP zoptymalizowana na platformy mobile.

Tymczasem uczestnicy projektu OpenIntents podjęli już pierwsze działania mające na celu zreimplementowanie wyrzuconego fragmentu API.