I resigned from HttpsUrlConnection and made directly communication using sockets. However, it didn’t solve problem – every call to SSLSocket.getSession() took the same 5 to 10 seconds as before.

Finaly, I found solution. There is a bug in Android prior to 4.0 version, which makes reverse DNS lookup for every https request. So, when you have no access to dns servers, it takes long time. To fix problem you can use code from:

http://code.google.com/p/android/issues/detail?id=13117#c14

Voila!

InetSocketAddress bindInetAddr = new InetSocketAddress(bindAddr, bindPort);
DatagramSocket ssdpUniSock = new DatagramSocket(bindInetAddr);

The second line causes InvalidArgumentException error. Fortunately, the solution exists and is quite simple. Instead of creating an instance of DatagramSocket, you can obtain in from DatagramChannel and then bind an address:

DatagramChannel channel = DatagramChannel.open();
DatagramSocket ssdpUniSock = channel.socket();
InetSocketAddress bindInetAddr = new InetSocketAddress(bindAddr, bindPort);
ssdpUniSock.bind(bindInetAddr);


Voila, done!

Poniżej krótki opis widocznych na zdjęciu urządzeń, zaczynając od lewej strony:

Od razu na początek interesująca ciekawostka: “devopment platform” od Qualcomma. Zbudowany na jednordzeniowym procesorze Snapdragon MSM8655 taktowanym zegarem 1.2GHz i z 1GB RAM w środku, na zewnątrz wygląda jak prototyp smartfona z końca ubiegłego wieku (brakuje tylko wystającej antenki). Pozory jednak mylą i jest to niezła, zeszłoroczna maszyna z systemem w wersji 2.3. No ale w kieszeni się nie mieści :)

Kolejny smartphone, Galaxy S, charakteryzuje się tak jak i inne produkty Samsunga kiepsko działającym automatycznym dostosowywaniem jasności ekranu. Jasność ekranu zmienia się co chwilę w zbyt dużym zakresie i jak dla mnie jedynym prawidłowym rozwiązaniem jest wyłączenie tej funkcji. Jednak sam ekran to już inna bajka – 4”, 480x800px i cukierkowa kolorystyka – po prostu super! Aktualnie używam tego telefonu na co dzień, i sprawdza się prawie tak dobrze jak… iPhone 3GS w którym niestety ducha wyzionął moduł GSM.

Trzeci telefon, to jednocześnie pierwszy smartphone, jaki wszedł w moje posiadanie i na którym zaczynałem realizować swoje pierwsze projekty. Samsung Galaxy Spica (i5700) – zaktualizowany do systemu 2.1 i z ekranem o rozdzielczości 320x480px. Dosyć słabe urządzonko na którym android wyraźnie się dusi i krztusi, ale dzięki temu, pisząc soft, baczniejszą uwagę zwraca się na kwestie optymalizacji.

Kolejny model to HTC Wildfire z systemem 2.2, który w odróżnieniu od Samsunga S, w celu korzystania z radia FM nie wymaga włożonej karty SIM (SIC!!!). Choć sama jakość odbiornika jest bardzo niska, Samsung w tym samym miejscu odbiera dużo lepszy sygnał. Jak na niepozorny wygląd, telefon te działa całkiem żwawo – wydaje się, że nawet sprawniej od i5700. Być może wynika to z niewielkiego ekranu o rozdzielczości 240x320px i przekątnej 3.2”, dzięki któremu jest mniej pikseli do rysowania :)

Pora na Chińską zabawkę z okrągłym przyciskiem (Apple nie pozwie o to producenta?) i piękną obudową w kolorze kości słoniowej. Mini tablet o przekątnej 6.9” napędzany przez Androida w wersji 1.6 działającym na 128MB Ramu, a za “feeling” i interakcje z użytkownikiem odpowiada opornościowy(!) ekran dotykowy pracujący w rozdzielczości.. hmm, nie wiem jakiej. Co ciekawe okrągły przycisk na obudowie jest JEDYNYM fizycznym przyciskiem w tym urządzeniu (nie ma on przycisku włączenia, blokady, powrotu, głośności ani żadnych innych). Idea Jobsa stała się realna dzięki chińczykom :) Ale tak czy siak, toporna to maszyna, baaardzo toporna.

No i w końcu “gwiazda wieczoru” czyli tablet mogący śmiało konkurować z Ipadem2: Samsung Galaxy Tab 10.1 z systemem 3.1. Wszystko świetnie, tylko dlaczego nie ma on wbudowanego normalnego portu micro-USB? Znowu kolejny rodzaj kabelka niezbędny na podorędziu. A tabletu nie trzeba opisywać – jest prawie tak dobry jak to piszą w internecie, jednak płynność interfejsu użytkownika wciąż pozostaje w tyle za pierwszym ipadem.

Wiodła spokojny żywot aż w końcu trafiła na ekrany telefonów.

Z dumą prezentuję pierwszą własną produkcję na telefony z systemem android – gra Epe Eater, do znalezienia w oficjalnym markecie w promocyjnej cenie $1.99. Będąca remakiem klasyki z PRLu, została wydana ponownie na miarę XXI wieku. „To prawdziwy łamacz palców, po którym długo będziesz leczył obolałe stawy. Czeka na Ciebie kilkadziesiąt poziomów, globalny ranking graczy, świetna muzyka i wielka przygoda.”

Gra została wydana pod szyldem świeżo powołanej marki Shakescreen, czyli kooperacji świetnego grafika i równie świetnego programisty. Jak to mówią – firma mała ale jara. :)

Aktualnie trwają prace nad wersją na telefony iPhone, jak i rozważania nad wydaniem wersji pod Windows Phone 7 Phone.

Vibrator v = new Vibrator();

się nie powiedzie. Aby otrzymać obiekt Vibrator, potrzebujemy użyć metody getSystemService, którą znajdziemy w klasie android.content.Context.

Vibrator v = (Vibrator) context.getSystemService(Context.VIBRATOR_SERVICE);

Ale to nie wszystko, jeżeli nie chcemy otrzymać wyjątku na klatę, powinniśmy w pliku AndroidManifest.xml zaznaczyć, że aplikacja będzie używała wibratora. W tym celu do tego pliku dopisujemy:

    <uses-permission android:name="android.permission.VIBRATE"/>

Dla jasności cały przykładowy plik AndroidManifest.xml:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="kubik.game.antris"
      android:versionCode="1"
      android:versionName="1.0">
    <uses-permission android:name="android.permission.VIBRATE"/>
 
    <application android:icon="@drawable/icon" android:label="@string/app_name" android:debuggable="true">
        <activity android:name=".Antris"
                  android:label="@string/app_name"
				  android:theme="@android:style/Theme.NoTitleBar.Fullscreen"
				  >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
<uses-sdk android:minSdkVersion="7"></uses-sdk>
</manifest>

Zrobione. Teraz już możemy wibrować:

Vibrator v = (Vibrator) context.getSystemService(Context.VIBRATOR_SERVICE);
v.vibrate(500); //wibruj pół sekundy

Pierwszy z nich to stworzenie własnego handlera do komunikatów:

class RefreshHandler extends android.os.Handler {
 
       @Override
       public void handleMessage(Message msg) {
           NaszaKlasa.this.update();
       }
 
       public void sleep(long delayMillis) {
           this.removeMessages(0);
           sendMessageDelayed(obtainMessage(0), delayMillis);
       }
};

oraz w NaszaKlasa (nie mylić z nk.pl) odpowiedniej metody, którą handler będzie wywoływał:

public class NaszaKlasa extend View {
    private RefreshHandler mRedrawHandler = new RefreshHandler();
 
    public void update() {
       mRedrawHandler.sleep(100);
    }
}

Aby zainicjować cykliczne wykonywanie się metody update() należy ją pierwszy raz wywołać “ręcznie”; następnie będzie ona wywoływana co zadany interwał czasu (w przykładzie co 100ms) z poziomu klasy RefreshHandler.

Drugi, to użycie klasy java.util.Timer – ten sposób wydaje się początkowy bardziej oczywisty, jednak jest o tyle niewygodny, że wymaga rozszerzenia naszej klasy o TimerTask. Do mojej aplikacji wybrałem więc pierwsze rozwiązanie, jednak wcale nie będę zaskoczony, gdy okaże się, że istnieje inne, lepsze rozwiązanie. Z jednej strony dokumentacja androida mówi, że jednym z głównych celów, do których są używane handlery, jest “wykonywanie pewnych zdarzeń w przyszłości”, a ponieważ jest to klasa z API androida, więc powinna być odpowiednio zoptymalizowana do zadań, które wykonuje. Z drugiej strony, do takich celów zwykle używało się właśnie klas podobnych do klasy Timer, ale może pora na zmianę przyzwyczajeń. :)

O handlerach poczytacie więcej w dokumentacji: http://developer.android.com/reference/android/os/Handler.html

public void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       setContentView(R.layout.main);
}

Niepokoić może odwołanie do obiektu R i wyświetlany na starcie błąd R cannot be resolve. Kilka minut zajęło mi rozwiązanie tej zagadki, a więc teraz w kilka minut spróbuję napisać jej wyjaśnienie :)

Otóż, podczas budowania projektu, automatycznie w folderze gen/ tworzona jest klasa R, zawierające statyczne definicje wszystkich obiektów, które umieścimy w folderze res/. Ponieważ dopiero co utworzyliśmy nowy projekt, więc klasa R nie została jeszcze wygenerowana i stąd na ekranie widzimy błąd. Wystarczy jednak zbudować projekt i po problemie.

Do czego służy ta klasa? Otóż dzięki niej, możemy odwoływać się do obiektów umieszczonych w folderze res/. Dajmy na to, że do folderu res/drawable/ mamy wrzucony obrazek ball1.png – wtedy w klasie R zostanie utworzony odpowiedni wpis:

public final class R {
    public static final class drawable {
           public static final int ball1=0x7f020000;
    }
}

Teraz, aby użyć gdzieś w kodzie nasz obrazek, wystarczy odwołać się do obiektu R.drawable.ball1, np. w taki sposób:

ImageView i = new ImageView(this);
i.setImageResource(R.drawable.ball1);

No, to było takie wytłumaczenie totalnego laika dla laików :) Więcej o zasobach można poczytać pod adresem http://developer.android.com/guide/topics/resources/index.html oraz w dokumentacji http://developer.android.com/reference/android/content/res/package-summary.html.

Jak na razie pomogło dopisania do eclipse.ini (znajdujący się w głównym katalogu, w którym zainstalowano eclipse) ustawienia:

-XX:MaxPermSize=256m

tak wygląda obecnie u mnie cały plik eclipse.ini:

-startup
plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519
-product
org.eclipse.epp.package.jee.product
--launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XX:MaxPermSize=256m
-Xms40m
-Xmx512m

Jednak skutecznym rozwiązaniem, które pozwoli zapomnieć o tym komunikacie jest ustawienie wersji kompilatora Javy dla projektu: Project -> Properties, wybieramy zakładkę Java Compiler i włączamy opcję Enable project specific settings oraz odpowiednio ustawiamy Compiler compliance level.

Eclipse zainstalowany, SDK zainstalowane, no to jazda.

Dokładną instrukcję instalacji środowiska znajdziecie pod adresem http://developer.android.com/sdk/index.html.