The built-in tether support acts as a WiFi hotspot and router. This does a USB tether, and acts as a network proxy. Very different.

The biggest difference, from the carrier’s end, is that routing is pretty easy to detect; each packet that goes through the router, the time-to-live (TTL) field in the IPv4 header is decremented. In addition, there is NAT going on, and there are heuristics to detect that. There are ways around this using Linux’s iptables that can masquerade the routing/NAT, but I’m unaware of any mainstream implementations of this on Android, and it would require root. This app doesn’t; I’m like 90% sure it’s all done over ADB (Android Debug Bridge), which every Android device supports.

With the USB tether acting as a network proxy, there is simply no routing/NAT going on, so there is no way for the carrier to detect what’s going on. It just appears to be data coming from the phone.

Ottimo, penso anche che il meccanismo sia estendibile anche ad altre piattaforme, non si finisce mai di imparare dai commenti! Prossima mossa, vedere se veramente il tethering USB non viene scoperto dai carrier.

Per fare alcuni test ho usato il progetto KitchenSink, fornito da Titanium stessa come “banco di prova” per dimostrare quello di cui e’ capace. Effettivamente la meraviglia c’e’ stata, vedere la stessa identica app (a livello di sorgente JavaScript) girare su un Android e su un iPhone riprendendo aspetto e comportamenti tipici del sistema applicativo.

Titanium infatti crea un progetto in codice nativo (Android o iPhone) dal file Javascript di origine e quel progetto viene poi compilato per il dispositivo. Non ci sono quindi librerie grafiche intermedie di supporto e, a meno di personalizzazioni grafiche, il look’nd feel dell’applicazione realizzata e’ quello del particolare dispositivo dove si andra’ ad eseguire. Quindi conta molto la bonta’ del codice generato nella valutazione delle performance. Ovvio che nessun codice generato automaticamente per uno scenario medio-complesso puo’ essere allo stesso livello di un codice scritto a manina e ottimizzato per quella specifica esigenza, ma a volte le differenze sono trascurabili.

Purtroppo non e’ successo cosi’ per una delle viste di Titanium, composta da una ListView per Android o da una UITableView per iPhone un po’ complessa. Come si puo’ vedere dal video, le performance sono bassine su Android, sotto l’usabile, mentre rimangono soddisfacenti su iPhone.

http://www.youtube.com/watch?v=X2KVO3H7u7Q

Per fare le prove, ho usato l’ultima versione di KitchenSink trovata su GitHub, ho compilato l’applicazione Titanium con il mobile SDK 1.6.2 e i device sono un Samsung Galaxy Tab e un iPhone 4G. Ho ripetuto la prova su un Nexus One per sicurezza, ma il risultato e’ lo stesso.

Peccato, magari riprovo tra qualche mese per vedere se le cose sono migliorate.

In primis, si puo’ usare Notepad++ con un’apposito plugin che permettera’ l’autocompletamento del codice.

Se invece si cerca qualcosa di piu’ integrato, si puo’ passare ad Eclipse, utilizzando Aptana Studio ed alcune configurazioni aggiuntive. Aptana perche’ mette a disposizione un editor per file Javascript sia in versione standalone, sia come plugin per Eclipse, e perche’ di recente e’ stata acquistata proprio da Appcelerator, una mossa che fa presagire una futura forte integrazione tra i due.

Scaricato ed installato il plugin di Aptana per Eclipse, l’autocompletamento del codice piu’ essere ottenuto grazie a questo utile post in cui c’e’ un programma php per convertire le API doc di Appcelerator Titanium nell’header JavaScript. Per generare quello relativo al Mobile SDK 1.5.1 ecco cosa ho fatto:

wget http://jamesdlow.googlecode.com/svn/trunk/Eclipse/Aptana/Titanium/titanium.php
wget http://developer.appcelerator.com/apidoc/mobile/1.5.1/api.json
sudo apt-get install php-cli
php titanium.php > timobile.js

Il seguente video mostra invece come configurare Eclipse ed abilitare quindi l’autocompletamento:

http://www.youtube.com/watch?v=d10j2-tEgVY

Si puo’ inoltre configurare Eclipse per compilare il progetto, senza ricorrere al Titanium Developer. Questo post spiega in dettaglio come fare spiega usando un’external tool configuration dell’IDE e riprendendo lo script in Phyton che viene usato da Titanium per fare la build. Anche questo post puo’ dare una mano. Peccato che i comandi trovati non funzionino, almeno sulla mia installazione e per le build Android.

Per vedere quali sono gli script lanciati per la compilazione, ho eseguito Titanium Developer da una shell, ho lanciato il progetto e sono andato a controllare l’output sulla shell, ottenendo questa riga di comando per fare il build e il deploy sull’emulatore:
“/opt/titanium/mobilesdk/linux/1.5.1/android/builder.py” “simulator” “AskAQuestion” “/opt/android/android-sdk-linux_x86″ “/media/data/titanium/askaquestion” “it.rainbowbreeze.askaquestion” “7″ “HVGA”
Per capire il valore dei parametri, occorre sapere che ho installato Appcelerator Titanium sotto /opt/titanium, ho il mobile sdk 1.5.1, il mio progetto si chiama AskAQuestion, si trova nella cartella /media/data/titanium/askaquestion ed ha come application id it.rainbowbreeze.askaquestion. L’Android SDK e’ installato sotto /opt/android/android-sdk-linux_x86 e gli ultimi 2 parametri sono il livello di API del progetto (7) e risoluzione dell’emulatore (HVGA 320×480).

Con questi dati, da Eclipse:

Run -> External Tools -> Exernals Tools Configurations
Selezionare Program dall’albero a sinistra e poi il bottone “New launch configuration”
Name: Titanium Android Build
Location: /usr/bin/python
Working Directory: /opt/titanium/sdk/linux/1.0.0
Arguments: “/opt/titanium/mobilesdk/linux/1.5.1/android/builder.py” “simulator” “AskAQuestion” “/opt/android/android-sdk-linux_x86″ “/media/data/titanium/askaquestion” “it.rainbowbreeze.askaquestion” “7″ “HVGA”

Con l’emulatore avviato, basta lanciare l’external tool per avere la compilazione del programma per Android e il lancio automatico.

Buono sviluppo!

Innanzitutto l’importanza strategica di una decisione del genere: dal mio punto di vista Nokia negli ultimi anni avra’ anche prodotto nuovi telefoni, ma non e’ riuscita ad innovare sul software. Esattamente un anno fa annuncio’ al Mobile World Congress del 2010 l’alleanza con Intel per creare la piattaforma Meego, ma dopo 363 giorni esatti non si e’ visto un solo prototipo pronto per il mercato. Microsoft, dal canto suo, dopo aver lanciato Windows Phone 7, sta cercando con il massimo interesse sviluppatori che realizzino applicazioni per il suo nuovo sistema operativo, ma la diffusione sul mercato di quest’ultimo e’ ancora bassissima, quindi e’ poco appetibile. Entrambe hanno qualcosa che all’altra interessa, e sono interessate all’altra per qualcosa che gli manca: Nokia possiede device e utenti fidelizzati, Microsoft software e strumenti per lo sviluppo. Una collaborazione cosi’ perfettamente incastrata e simbiotica tra i due giganti e’ capace di grandi cose, se poi Nokia viene pure pagata da Microsoft per la partnership…

Stiamo parlando di due aziende che hanno una poderosa batteria di cannoni a disposizione dei reparti marketing e commerciale: con un’intelligente mossa che e’ andata oltre la visione a breve periodo che le vedeva concorrenti per le molliche del mobile (Symbian-MeeGo vs WP7),  qualcuno ha capito che nel medio-lungo periodo l’unione fa la forza, e che e’ inutile sprecare munizione una contro l’altra per prendersi gli avanzi, ma e’ molto piu’ profiquo impiegarle assieme per fiaccare la concorrenza (Apple e Android) e tentare di mordere la torta intera. Utenti, sviluppatori e partner commerciali si trovera’ il modo per convincerli, pubblicita’ dopo pubblicita’, iniziativa dopo iniziativa, mossa dopo mossa.

Dopo questo annuncio e a meno di strani cambiamenti, sono abbastanza convinto che Windows Phone 7 ora abbia tutte le carte giuste per diventare il terzo polo nel mondo dello sviluppo per mobile.

Poi certo, ogni grande allenza, se fatta nel mezzo di una battaglia, porta con se’ morti e feriti. Alcuni di questi potrebbero essere:

• Symbian: definitivamente relegato al mercato dei paesi emergenti. Non mi sembra una sconfitta, anzi, il consolidamento in una nicchia neanche tanto piccola. Certo, chi ha investito gli ultimi anni della sua formazione in questo sistema operativo potrebbe non essere felice, ma l’informatica e’ l’informatica, se non ti aggiorni pian piano ti estingui, purtroppo…
• QT, MeeGo e il l’open source in generale: anche se Nokia ha dichiarato che rimarranno come tecnologie di R&D, non ci vedo niente di buono, perche’ temo che quest’area possa essere a rischio non appena ci sara’ da chiudere qualche rubinetto o fare un po’ di refactoring aziendale. Tante promesse, tanti sforzi, tanto entusiasmo da parte di molti sviluppatori che fanno questo lavoro anche spinti da un’ideologia, e invece ora tutto e’ sprofondato in un oscuro tunnel senza luce al fondo. Uno strappo che non potra’ mai piu’ essere ricucito.
• Ovi Store: suppongo rimarra’ per i device Symbian, mentre tutto il nuovo verra’ veicolato dal Marketplace Microsoft, che subira’ forse qualche modifica, qualche integrazione, ma non perdera’ la sua identita’.
• Bing e Ovi Maps, Ovi Music Store e Zune Markeplace: cosa succedera’ a questi servizi ora duplicati? Si riuscira’ a trovare una profiqua integrazione oppure “ne rimarra’ solo uno”? A questa domanda proprio non so rispondere.
• Nokia: dopo anni di leadership indiscussa sul mercato hardware e software, dopo avre impiegato molte risorse per capire la strada da prendere, dopo abbondanti promesse e altrettanti ritardi, ha infine dovuto fare un umile passo indietro. Un doloroso cambio di rotta che ha portato ad un brusco calo del valore delle azioni. Solo il tempo decretera’ se questa mossa e’ stata vincente. Ora, per lo meno, la direzione e’ chiara e il colosso finlandese potra’ dedicarsi anima e corpo al consolidamento della propria posizione in due settori: produzione dei dispositivi e (multi)media company.
• Intel: un anno fa ha tentato di abbracciare anche il mondo del software, ma e’ tornata a casa fallendo nell’impresa.
• Samsung Bada: ormai non ha piu’ speranze, almeno per il mercato globale. La terza posizione sul podio della leadership per il mobile e’ stata conquistata, i posti sono finiti. Ma dopotutto qualcuno avrebbe dovuto dirle che nel 2010 l’idea di lanciare sul mercato un nuovo sistema operativo per mobile non era poi cosi’ acuta, in relazione al preciso periodo storico.

In definitiva, solo QT, il free software e tutto uno strascico di sviluppatori al seguito ci hanno veramente perso, senza averne una vera colpa a priori. Questo mi dispiace molto dato che sono sempre stato un sostenitore di quest’ottima tecnologia crossplatform per desktop e mobile da ormai diversi anni. Non credo ad un porting di QT per Windows Phone 7, quindi non vedo nuove, appetibili, prospettive di sviluppo. Ma la speranza e’ sempre l’ultima a morire.

Ho scaricato il runtime di Titanium Developer per Linux 64 bit. La versione corrente e’ la 1.2.2. L’ho scompattato e l’ho lanciato. Alla richiesta del percorso di installazione, sotto la mia home oppure in /opt/titanium, ho scelto la seconda opzione, e il programma si e’ chiuso senza altri segni di vita. Per farlo funzionare, sono stato costretto a far partire l’installer con
sudo ./Titanium\ Developer
eseguendo poi a fine installazione un cambio di permessi delle cartelle create con il comando
sudo chown -R rainbowbreeze:rainbowbreeze /opt/titanium

Scaricati i due pacchetti necessari, l’installer si chiude di nuovo con l’errore
symbol lookup error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_malloc_n
che sembra essere ben documentato e risolto:
cd /opt/titanium (oppure cd ~/.titanium se l’avete installato nella vostra home)
rm runtime/linux/1.0.0/libgobject-2.0.*
rm runtime/linux/1.0.0/libglib-2.0.*
rm runtime/linux/1.0.0/libgio-2.0.*
rm runtime/linux/1.0.0/libgthread-2.0.*

Superato anche questo ostacolo, ho rilanciato l’installazione, accettato le condizioni di contratto e mi trovo davanti un nuovo errore:
icedteanp plugin error: Failed to run /etc/alternatives/../../bin/java.  For more detail rerun “firefox -g” in a terminal window.
anche questo errore e’ documentato e risolto:
sudo aptitude remove openjdk-6-jre icedtea6-plugin
sudo aptitude install sun-java6-jre sun-java6-plugin sun-java6-fonts

Fatta la registrazione, l’applicazione e’ finalmente partita. Sono andato nella “Profile Perspective” per settare il path dell’SDK Android e non mi e’ stato riconosciuto correttamente dato che dalla versione 9 di questi ultimi il comando adb e’ stato spostato dalla cartella tools alla cartella platform-tools. Anche questo problema documentato e risolto della Getting Started, utile da seguire anche per fare altri settaggi al proprio sistema. Basta creare un link simbolico al file:
cd [SDK HOME]/tools
ln -s ../platform-tools/adb

Finalmente, ho scaricato il progetto di prova Kitchen Sync, l’ho lanciato selezionando come SDK “APIs 2.2″ (quello con le API Google, e non 2.2) e come Screen HVGA e ho iniziato a giocare un po’ con questo strumento di sviluppo. Un eventuale errore in fase di lancio dell’applicazione potrebbe essere causato dalla scelta di un livello di SDK “2.2″, “2.1″ o altri: dato che il progetto utilizza le API Android di Google, occorre avere installato un SDK che le supporti e lanciare il progetto usandolo al posto del pulito emulatore 2.2, 2.1 o precedenti. Qui un post sull’argomento.

Trovare invece tra i log della console di Titanium Developer la scritta
[ERROR] /opt/android/android-sdk-linux_x86/tools/apkbuilder
non dovrebbe dar problemi o spaventare.

Impressione finale dopo aver visto gli esempio di Kitchen Sync? FIGATA!!!!! Qual’e’ la prossima mossa per codarci un po’ sopra?

• La sospensione senza preavviso di connessioni gia’ in piedi sulla rete dati mobile
• L’impossibilita’ di accedere a quei servizi legati alla SIM. Ad esempio, un operatori telefonico potrebbe effettuano un accredito direttamente all’utente basandosi sulla SIM che genera il traffico. Con il Wifi, non si puo’ ottenere questa informazione.

Quindi, per quanto l’utilita’ di forzare l’uso della connessione dati mobile per raggiungere un certo indirizzo all’interno della proprio applicazione possa sembrare scontata, purtroppo Android non mette a disposizione nessuna API documentata e sicura per farlo, ma occorre passare per una serie di workaround che funzionano solo dalla versione 2.2.

/**
 * Enable mobile connection for a specific address
 * @param context a Context (application or activity)
 * @param address the address to enable
 * @return true for success, else false
 */
private boolean forceMobileConnectionForAddress(Context context, String address) {
    ConnectivityManager connectivityManager = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
    if (null == connectivityManager) {
        Log.debug(TAG_LOG, "ConnectivityManager is null, cannot try to force a mobile connection");
        return false;
    }

    //check if mobile connection is available and connected
    State state = connectivityManager.getNetworkInfo(ConnectivityManager.TYPE_MOBILE_HIPRI).getState();
    Log.debug(TAG_LOG, "TYPE_MOBILE_HIPRI network state: " + state);
    if (0 == state.compareTo(State.CONNECTED) || 0 == state.compareTo(State.CONNECTING)) {
        return true;
    }

    //activate mobile connection in addition to other connection already activated
    int resultInt = connectivityManager.startUsingNetworkFeature(ConnectivityManager.TYPE_MOBILE, "enableHIPRI");
    Log.debug(TAG_LOG, "startUsingNetworkFeature for enableHIPRI result: " + resultInt);

    //-1 means errors
    // 0 means already enabled
    // 1 means enabled
    // other values can be returned, because this method is vendor specific
    if (-1 == resultInt) {
        Log.error(TAG_LOG, "Wrong result of startUsingNetworkFeature, maybe problems");
        return false;
    }
    if (0 == resultInt) {
        Log.debug(TAG_LOG, "No need to perform additional network settings");
        return true;
    }

    //find the host name to route
    String hostName = StringUtil.extractAddressFromUrl(address);
    Log.debug(TAG_LOG, "Source address: " + address);
    Log.debug(TAG_LOG, "Destination host address to route: " + hostName);
    if (TextUtils.isEmpty(hostName)) hostName = address;

    //create a route for the specified address
    int hostAddress = lookupHost(hostName);
    if (-1 == hostAddress) {
        Log.error(TAG_LOG, "Wrong host address transformation, result was -1");
        return false;
    }
    //wait some time needed to connection manager for waking up
    try {
        for (int counter=0; counter<10; counter++) {
            State checkState = connectivityManager.getNetworkInfo(ConnectivityManager.TYPE_MOBILE_HIPRI).getState();
            if (0 == checkState.compareTo(State.CONNECTED))
                break;
            Thread.sleep(1000);
        }
    } catch (InterruptedException e) {
        //nothing to do
    }
    boolean resultBool = connectivityManager.requestRouteToHost(ConnectivityManager.TYPE_MOBILE_HIPRI, hostAddress);
    Log.debug(TAG_LOG, "requestRouteToHost result: " + resultBool);
    if (!resultBool)
        Log.error(TAG_LOG, "Wrong requestRouteToHost result: expected true, but was false");

    return resultBool;
}

In pratica, se non lo e' gia', viene attivata la connessione mobile grazie alla chiamata
startUsingNetworkFeature(ConnectivityManager.TYPE_MOBILE, "enableHIPRI")
per poi creare una route all'indirizzo da raggiungere che forza il passaggio sulla connessione mobile
requestRouteToHost(ConnectivityManager.TYPE_MOBILE_HIPRI, hostAddress)

E qui c'e' la funzione che permette di calcolare l'intero che corrisponde all'indirizzo da contattare

/**
 * This method extracts from address the hostname
 * @param url eg. http://some.where.com:8080/sync
 * @return some.where.com
 */
public static String extractAddressFromUrl(String url) {
    String urlToProcess = null;

    //find protocol
    int protocolEndIndex = url.indexOf("://");
    if(protocolEndIndex>0) {
        urlToProcess = url.substring(protocolEndIndex + 3);
    } else {
        urlToProcess = url;
    }

    // If we have port number in the address we strip everything
    // after the port number
    int pos = urlToProcess.indexOf(':');
    if (pos >= 0) {
        urlToProcess = urlToProcess.substring(0, pos);
    }

    // If we have resource location in the address then we strip
    // everything after the '/'
    pos = urlToProcess.indexOf('/');
    if (pos >= 0) {
        urlToProcess = urlToProcess.substring(0, pos);
    }

    // If we have ? in the address then we strip
    // everything after the '?'
    pos = urlToProcess.indexOf('?');
    if (pos >= 0) {
        urlToProcess = urlToProcess.substring(0, pos);
    }
    return urlToProcess;
}

/**
 * Transform host name in int value used by {@link ConnectivityManager.requestRouteToHost}
 * method
 *
 * @param hostname
 * @return -1 if the host doesn't exists, elsewhere its translation
 * to an integer
 */
private static int lookupHost(String hostname) {
    InetAddress inetAddress;
    try {
        inetAddress = InetAddress.getByName(hostname);
    } catch (UnknownHostException e) {
        return -1;
    }
    byte[] addrBytes;
    int addr;
    addrBytes = inetAddress.getAddress();
    addr = ((addrBytes[3] & 0xff) << 24)
            | ((addrBytes[2] & 0xff) << 16)
            | ((addrBytes[1] & 0xff) << 8)
            |  (addrBytes[0] & 0xff);
    return addr;
}

In ultimo, occorre aggiungere questi permessi all'AndroidManifest.xml

Con questo trucchetto si riesce ad indirizzare tutto il traffico verso uno o piu' indirizzi specifici. Ho notato che dopo 15-20 secondi di inattivita', la connessione mobile viene disattivata di nuovo.

Il codice e' testato su un Nexus One e su un LG Optimus ma, dato che le implementazioni sono specifiche dei vendor, non garantisco che funzioni su tutti gli altri device con Android, dalla 2.2 in su.

Personalmente ho fatto mio questo pezzo di codice, inglobandolo nelle Rainbowlibs e creando un controllo da usare bello che pronto nelle proprie applicazioni, la RainbowZoomableImageView, una specie di ImageView meno potente, che pero’ supporta il pitch-zoom out of the box, senza configurazioni aggiuntive.

Seguendo gli esempi proposti dalla libreria di Luke, ho creato la classe RainbowZoomableImageView.Img e la RainbowZoomableImageView che la utilizza, a cui ho aggiunto alcuni metodi di comodo, tra cui quelli per impostare l’immagine da visualizzare e per settare lo zoom manualmente, fondamentale per quei rari dispositivi che non hanno uno schermo o una versione di Android con il multitouch. Questi metodi sono assignImage(…) e incrementScale(…).

Come esempio di utilizzo di si puo’ buttare un occhio sull’activity ActImageFullScreen,java e sul relativo layout actimagefullscreen.xml di WebcamHolmes, un’altro progetto opensource che sto sviluppando.

La dichiarazione del layout e’ molto semplice, ed include solo il controllo personalizzato e quello per fare lo zoom



Mentre nell’activity, queste sono le parti salienti per gestire il tutto:

public class ActImageFullscreen extends Activity {

  private final static float ZOOM_INCREMENT = 0.1f;
  private static final int DIALOG_PROGRESS = 10;
  private static final int OPTIONMENU_SHOWHIDE_ZOOM = 10;
  private RainbowZoomableImageView mImage;
  private ActivityHelper mActivityHelper;
  private ZoomControls mZoomControls;

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    //make the view fullscreen
    requestWindowFeature(Window.FEATURE_NO_TITLE);
    getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN);
    setContentView(R.layout.actimagefullscreen);

    //load the image
    mImage = (RainbowZoomableImageView) findViewById(R.id.actimagefullscreen_imgMain);
    mImage.setBackgroundColor(Color.BLACK);
    //choose how to obtain the bitmap with the image
    Bitmap bitmap = ... //BitmapFactory.decodeStream(fis);
    mImage.assignImage(getResources(), bitmap);

    //link zoom press with image in/out zoom
    mZoomControls = (ZoomControls) findViewById(R.id.actimagefullscreen_zoomcontrols);
    mZoomControls.setOnZoomInClickListener(mOnZoomInClickListener);
    mZoomControls.setOnZoomOutClickListener(mOnZoomOutClickListener);
  }

  @Override
  protected void onPause() {
    mImage.onPause();
    super.onPause();
  }

  @Override
  protected void onResume() {
    super.onResume();
    mImage.onResume(getResources());
  }

  private OnClickListener mOnZoomInClickListener = new OnClickListener() {
    public void onClick(View v) {
      mImage.incrementScale(ZOOM_INCREMENT);
    }
  };

  private OnClickListener mOnZoomOutClickListener = new OnClickListener() {
    public void onClick(View v) {
      mImage.incrementScale(-ZOOM_INCREMENT);
    }
  };
}

Facile, no? ;)

Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml’s <application> tag, which will cause that class to be instantiated for you when the process for your application/package is created.
There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way.

Sembra quindi il posto giusto, e piu’ elegante di un singleton, per mettere le nostre variabili globali quando non occorre fare cose troppo complicate e per inizializzarle al primo avvio dell’applicazione, mediante override del metodo OnCreate() della classe base. Qualcosa del genere:

La classe App.java

package it.rainbowbreeze.singleton;

public class App extends Application {
public static int myGlobalStaticValue;
public int myGlobalValue;

  @Override
  public void onCreate() {
    super.onCreate();
    myGlobalStaticValue = 10;
    myGlobalValue = 20;
  }
}

La modifica all’AndroidManifest.xml

E la chiamata da fare in un metodo qualunque di un’Activity, ad esempio:

//access to static field
int value = App.myGlobalStaticValue;
//access to non static fields
int value = ((App)context.getApplication()).myGlobalValue;

Da principio tutto funzionava, poi pero’ mi sono accorto di un problema non banale: che di tanto in tanto le variabili persistite in questo modo non mantengono il loro valore, soprattutto dopo che l’applicazione rimane in background per parecchio tempo o si fanno nel frattempo diverse altre cose col dispositivo.

Basito da questo comportamento, mi sono messo a cercare in giro, ed ecco che escono fuori le prime conferme, di cui riporto un estratto:

Consider a case – your app goes into the background because somebody is calling you (Phone app is in the foreground now). In this case && under some other conditions (check the above link for what they could be) the OS may kill your application process, including the Application subclass instance. As a result the state is lost. When you later return to the application, then the OS will restore its activity stack and Application subclass instance, however the myState field will be null.

This was an unplesant surprise for us in production. Believe me Android kills processes, it just depends on RAM state and other factors described in the documentation. It was a nightmare for us so I just share my real experience. Well we did not have this on emulators, but in real world some devices are ‘overloaded’ with apps, so killing a background process is a normal situation. Yes, if user then decides to get the app up into foreground – the OS restores its stack including the Application instance, however there will not be your static data you count on unless you persisted it.

In pratica, anche il contenuto dell’Application, come quello di ogni altro static singleton, puo’ venire ripulito dal sistema operativo. Come fare quindi per ovviare a questo problema?

Le soluzioni, ovviamente, possono essere le piu’ disparate: se si tratta di dati che non cambiano, occorre controllare ogni volta che non siano nulli e inizializzarli di nuovo all’occorrenza, mentre se si tratta di dati che possono cambiare nel ciclo di vita dell’applicazione, ci sono le SharedPreferences o altri meccanismi utili per persisterli e ricaricarli quando necessario.

Per farlo in maniera elegante e abbastanza generalizzata, mi e’ piaciuto il consiglio Dianne Hackborn di usare dei lazy-loading singleton, buoni per entrambe le situazioni. Ecco un veloce esempio

class Singleton {
  static final Object mLock = new Object();
  static final Singleton mInstance;

  private Singleton(Context context) {
    //init or reload your data here
  }

  static getInstance(Context context) {
    synchronized (mLock) {
      if (mInstance == null) {
        mInstance = new Singleton(context);
      }
      return sInstance;
    }
  }

  private int mMyValue;
  public int getMyValue() {
    return mMyValue;
  }
  public void setMyValue(int newValue) {
    mMyValue = newValue;
    //or choose another way to persist the data, via a Shared Preference, for example
  }
}

Se non e’ necessaria, si puo’ anche togliere la referenza al Context nel getInstance().

Altri vantaggi dei singleton: la loro modularita’, l’inizializzazione che viene fatta solo quando serve, mentre nel caso dell’Application viene fatta all’avvio dell’applicazione, rallentandone i tempi di caricamento. Poi certo, l’Application.onCreate() rimane un punto di importanza cruciale per tutta una serie di compiti da fare solo e solamente all’avvio dell’applicazione, prima di caricare ogni altra cosa. A voi la scelta di come suddividere il codice nel migliore dei modi.

C’e’ qualche feedback di chi l’ha usato? E’ davvero cosi’ efficiente come mostrato nel video?

Esiste un modo per risolvere completamente il problema, che permette di capire qual’e’ il giusto idVendor da aggiundere al file .rules di udev, indipendentemente dal device in uso.

per prima cosa, occorre lanciare il comando
lsusb -v | grep idVendor

l’output restituito potrebbe essere il seguente:
idVendor           0x1d6b Linux Foundation
idVendor           0x045e Microsoft Corp.
idVendor           0x1d6b Linux Foundation
idVendor           0x1d6b Linux Foundation
idVendor           0x05c6 Qualcomm, Inc.
idVendor           0×5986 Acer, Inc

Ora, staccando il device e rilanciando il comando, ho visto che la riga che cambia e’ la seguente
idVendor           0x05c6 Qualcomm, Inc.
che contiene quindi l’idVendor che mi serve per configurare udev.

Ho quindi aggiunto al file
/etc/udev/rules.d/51-android.rules
la seguente riga
SUBSYSTEM==”usb”, SYSFS{idVendor}==”05c6″, MODE=”0666″
e adb visse felice e contento!

Il procedimento, assieme ad una trattazione molto piu’ ampia sull’argomento, e’ spiegato in questo post.

Per questa prima edizione milanese (l’idea e’ di replicare a Roma, poi forse Bologna e Torino) l’idea che avevo era quella di parlare ai developer un po’ del futuro del mobile, perche’ avere a che fare con una tecnologia no sempre significa avere anche una visione su di essa. Tra i relatori ho quindi chiamato Leandro Agro’ e Luca Mascaro: il primo ci ha fornito prospettive su qualche caldo tema emergente: self-traking, Internet of Things, spime e massive data collection. Il secondo ha mostrato esempi di applicazione del paradigma “less is more” e del leonardiano “La semplicita’ e’ l’estrema perfezione” nel mondo del mobile.

Abbiamo chiuso io e Matteo, con un intervento sulle principali caratteristiche delle piattaforme di sviluppo per mobile, giusto per capire in quali campi le une sono meglio delle altre e un accenno a quali tool permettono di realizzare applicazioni cross-platform e in che dominio.

Che dire, sono stato molto soddisfatto dell’evento, se non altro perche’ ho ricevuto feedback positivi sul format. Sicuramente ci siamo dovuti tarare “in corsa” con i tempi dettati dagli orari milanesi (e dalla difficolta’ di spostamento, pur avendo scelto un posto vicino alla fermata della metro)

Prossima tappa, 27 Gennaio a Roma, OppioCaffe’. Non mancate se siete in zona!

Qui potete trovare la registrazione dell’evento.

Questa e’ una presentazione fatta da Leandro che riassume abbastanza bene gli argomenti trattati durante il workshop:

Quella di Luca:

E quella di Matteo e mia:

Infine, da parte di Leandro, qualche link per approfondire gli argomenti da lui trattati:
-http://www.slideshare.net/leeander/surfing-the-thirdwave
-http://www.slideshare.net/leeander/massive-data-collection-1238180
-http://www.slideshare.net/folletto/the-widenoise-project

Una precisazione. Non vengono consiredate tutte le versioni di Android inferiori alla 1.6 (quindi dalla 1.5 in giu’), dato che i miei programmi non la supportano e quindi non ho statistiche di questo tipo.

Innanzitutto iniziamo con la diffusione del sistema operativo:

Come si puo’ vedere, la versione attualmente piu’ diffusa e’ la 2.1, ma anche la 1.6 si difende bene, con conseguente disperazione di noi programmatori. Questo principalmente a causa dei produttori di device che non rilasciano aggiornamenti alla piattaforma, ma piuttosto forzano all’acquisto di un nuovo dispositivo dopo neanche un paio d’anni di utilizzo del vecchio, se si vuole restare al passo con i tempi.

Passiamo poi alla risoluzione dello schermo:

Tranne una lieve predominanza della risoluzione 480×800 (quella del Nexus One e dall’HTC Desire, ad esempio), il resto del panorama si fa molto variegato, con le prime, timide apparizioni anche di risolulzioni piu’ adatte ad un display di un tablet che di uno smartphone (1024×600 e 640×480).

Insomma, dati alla mano, e’ proprio vero che programmare per Android deve tenere conto di tante variabili, troppe a volte!

Update: Come segnalato da Lorenzo, anche Tweetdeck ha fatto un’analisi simile alla mia… Con risultati altrettanto incasinati :(

Aggiungere alla TextView l’attributo android:autoLink=”web”. Se il testo contenuto al suo interno e’ riconducibile ad un indirizzo web, questo verra’ automaticamente mostrato in blu con la sottolineatura tipica di un hyperlink e se ci si clicca sopra verr’a aperta la URL corrispondende nel browser. Seguono alcuni esempi.

<TextView
  android:layout_width="fill_parent"
  android:layout_height="wrap_content"
  android:text="www.rainbowbreeze.it"
  android:autoLink="web"
/>
<TextView
  android:layout_width="fill_parent"
  android:layout_height="wrap_content"
  android:text="http://www.rainbowbreeze.it"
  android:autoLink="web"
/>

Se invece si vuole ottenere un effetto piu’ complesso, tipo una parola all’intero di una frase che, se cliccata, conduce ad un sito web, allora occorre inserire un po’ di codice, oltre all’xml. Partiamo definendo la TextView

<TextView
  android:id="@+id/lblClickable"
  android:layout_width="fill_parent"
  android:layout_height="wrap_content"
/>

E poi all’interno del codice

TextView lblClickable = (TextView) findViewById(R.id.lblClickable);
String htmlText = "Link to my <A HREF='http://www.rainbowbreeze.it'>site</A>";
lblClickable.setText(Html.fromHtml(htmlText));
//needed to enable click on the link
lblClickable.setMovementMethod(LinkMovementMethod.getInstance());

L’effetto che si ottiene e’ il seguente.

Fonte : StackOverflow

http://www.youtube.com/watch?v=l_l1q37VLWo

Modalita’ discovery automatica di altri giocatori presenti, collezionare trofei che fanno aumentare la propria reputazione da mostrare e da giocarsi contro gli avversari… Fantastico, se prima la scusa di un ritardo ingiustificato poteva essere: “Scusa, sono venuto a piedi e per strada ho incontrato un amico che non vedevo da tanto tempo e siamo rimasti a parlare un po’“, domani potrebbe diventare qualcosa tipo “Scusa, mentre venivo qui ho dovuto difendere la cintura del campione del quartiere da un tipo che mi ha sfidato, non potevo non suonargliele quattro!“

Ad esempio, l’USB VendorID da usare con un Nexus One, dato che non e’ quello HTC di default, ma bensi’ 18d1. Occorrera’ quindi aggiungere, nel file /etc/udev/rules.d/51-android.rules questa riga

SUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666"

Aggiungendo i vari device supportati otteniamo:

#Acer
SUBSYSTEM=="usb", SYSFS{idVendor}=="0502", MODE="0666"
#Dell
SUBSYSTEM=="usb", SYSFS{idVendor}=="413c", MODE="0666"
#Foxconn
SUBSYSTEM=="usb", SYSFS{idVendor}=="0489", MODE="0666"
#Garmin-Asus
SUBSYSTEM=="usb", SYSFS{idVendor}=="091E", MODE="0666"
#HTC G1 and others
SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"
#HTC Nexus One
SUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666"
#Huawei
SUBSYSTEM=="usb", SYSFS{idVendor}=="12d1", MODE="0666"
#Kyocera
SUBSYSTEM=="usb", SYSFS{idVendor}=="0482", MODE="0666"
#LG
SUBSYSTEM=="usb", SYSFS{idVendor}=="1004", MODE="0666"
#Motorola
SUBSYSTEM=="usb", SYSFS{idVendor}=="22b8", MODE="0666"
#Nvidia
SUBSYSTEM=="usb", SYSFS{idVendor}=="0955", MODE="0666"
#Pantech
SUBSYSTEM=="usb", SYSFS{idVendor}=="10A9", MODE="0666"
#Samsung
SUBSYSTEM=="usb", SYSFS{idVendor}=="04e8", MODE="0666"
#Sharp
SUBSYSTEM=="usb", SYSFS{idVendor}=="04dd", MODE="0666"
#Sony Ericsson
SUBSYSTEM=="usb", SYSFS{idVendor}=="0fce", MODE="0666"
#Sony Ericsson
SUBSYSTEM=="ZTE", SYSFS{idVendor}=="19D2", MODE="0666"

Un po’ accortezze varie che potrebbero far comodo in caso di problemi:

• Ricordardi di abilitare il debug mode sul dispositivo come descritto nella guida
• Rilanciare UDEV per rendere attive le modifiche: sudo restart udev
• Rilanciare l’adb per prendere il carico il nuovo device: adb kill-server seguito da adb start-server