Symbian – Autostart di un applicazione su serie 9

Tempo fa in questo post ho scritto come realizzare un programma starter per Symbian serie 8, cioè un launcher di un’applicazione al boot del cellulare. Oggi invece volevo farvi vedere l’analogo su serie 9, la nuova serie di Symbian installata su molti dei cellulari Nokia attualmente in commercio. Premesso che al momento del post precedente la documentazione sull’argomento non era molta, oggi invece esistono molti siti dove è possibile trovare informazioni sull’argomenti, a partire dallo wiki della nokia dove c’è praticamente tutto, per finire sulla pagine di google .
Ma siccome le risorse in italiano non sono mai abbastanza allora volevo illustrare comunque la soluzione

A differenza della precedente versione con Symbian 9 è possibile realizzare l’autostart di un’applicazione usando il meccanismo dello "Startup Management List API" consultabile qui. L’idea di base di questa gestione consiste nel definire un file di risorse attribuendogli come nome l’UID del package che contiene l’applicazione. Tale file conterrà al suo interno alcuni dati di configurazione al fine di poter eseguire l’applicazione indicata all’avvio del programma. Vediamo in cosa consistono questi dati di configurazione:
 

1
2
3
4
5
6

#include <startupitem.rh> 
RESOURCE STARTUP_ITEM_INFO devme 
{ 
    executable_name = "!:\\sys\\bin\\devme.exe"; 
    recovery = EStartupItemExPolicyNone; 
}

Bene. Subito una piccola precisazione. Come vedete il valore di executable_name coincide con un path, quello di installazione dell’applicazione. Ha all’inizio un punto esclamativo che sta ad indicare la destinazione intesa come unità di installazione. Chi ha installato un’applicazione per symbian sa che ad un certo punto viene chiesto di indicare la destinazione su cui installare il programma, se la memoria del telefono o eventuali memorie esterne. Ecco il ! riferisce quella destinazione. Se si vuole, ad esempio, imporre l’installazione sulla memoria del telefono il ! verrà sostituito con C. 
Come vedete i dati di configurazione sono pochi e il commento viene da se.

Prossimo step consiste nell’aggiungere il riferimento del file appena creato all’interno del file di configurazione .mmp.

1
2

START RESOURCE ..\DATA\APP_UID.rss
END

Ed infine aggiungere le informazioni di configurazione nel file .pkg.

1

"$(EPOCROOT)Epoc32\data\z\private\101f875a\import\apps\APP_UID.rsc" -"c:\private\101f875a\import\[APP_UID].rsc"

Dove la prima parte della riga di configurazione indica il percorso delle SDK che si stanno utilizzando per la build corrente. Nel mio caso siccome sto usando Carbide come IDE posso utilizzare le variabili d’ambiente che mette a disposizione. Da notare che, mentre per un qualunque altro programma posso usare il ! per indicare la destinazione, per quanto riguarda l’autostart su serie 9 devo indicare C come destinazione…non solo, in aggiunta l’intero percorso dove vengono memorizzati questi tipi di file "C:\private\101f875a\import\".
Stay tuned, a presto.

Overloading del costruttore – REVIEWED -

Eh sì, devo proprio dirlo. Ho sbagliato !!! Non che non mi capiti mai, ma questa volta l’ho anche scritto sul mio blog, quindi DEVO riparare e salvare quello che ancora rimane della mia reputazione. L’errore è stato nel post in cui si parlava dell’overloading del costruttore, rimetto di seguito il giochino che avevo pubblicato:

1
2
3
4
5
6
7
8

public class OverloadResolver {
    public OverloadResolver(Object param) {
        System.out.println("Construttore con parametro Object");
    }
    public OverloadResolver(Object[] param) {
        System.out.println("Costruttore con parametro Object[]");
    }
}

La domanda era: "Qualcuno sa cosa succede se faccio questa chiamata:"

1
2
3
4
5

......
public static void main(String[] args) {
    OverloadResolver or = new OverloadResolver(null);
}
......

Ingenuamente mi son fidato. Nel senso che ho considerato buona la risposta che ho trovato nell’articolo che ho letto in internet, (in realtà volevo anche rispondere ora che so la risposta corretta, ma non riesco più a trovarlo, poi vi dico se lo trovo) e quindi non mi sono posto il problema di testarlo. Quando ieri, un caro vecchio amico, mi ha fatto gentilmente notare, e per gentilmente intendo a modo suo, che la risposta da me data non era quella giusta, in quanto diffidando dalla risposta ha testato l’esempio, e il risultato non era quello che avevo dato. Quindi, eseguendo l’esempio, il risultato è che viene richiamata la funzione:

1
2
3

public OverloadResolver(Object[] param) {
    System.out.println("Costruttore con parametro Object[]");
}

Perchè ? Il motivo lo incollo, così come l’ho trovato in internet, ovviamente sul sito della sun:

So the third rule is to choose the most "specific" method. The rule is: if any method still under consideration has parameter types that are assignable to another method that’s also still in play, then the other method is removed from consideration. This process is repeated until no other method can be eliminated. If the result is a single "most specific" method, then that method is called. If there’s more than one method left, the call is ambiguous. Suppose that you have the methods: f(float) f(double) In this case, the parameter types for the first method are assignable to the parameter types of the second method, that is, it’s legal to say: double = float through a widening primitive conversion. By contrast, saying: float = double is not valid without a cast. Based on this third rule, f(double) is removed from the set of possible methods to call, and therefore f(float) is called.

Morale della favola? La prossima volta non fidatevi degli articoli trovati in rete senza prima averli provato. Ciauu

Overloading del costruttore

1
2
3
4
5
6
7
8

public class OverloadResolver {
public OverloadResolver(Object param) {
System.out.println("Construttore con parametro Object");
}
public OverloadResolver(Object[] param) {
System.out.println("Costruttore con parametro Object[]");
}
}

Qualcuno sa cosa succede se faccio questa chiamata:

1
2
3
4
5

......
public static void main(String[] args) {
OverloadResolver or = new OverloadResolver(null);
}
......

Cioè se richiamo quel costruttore con parametro null, cosa viene richiamato nella classe di sopra ? Dai dai dai che lo sapete……e ditelo !!!!!! (magari qualcuno commenterà….chi lo sa!!!)