Posts tagged: symbian

Symbian – Autostart di un applicazione su serie 9

symbian_logoTempo 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.

Cleanup Stack

stackCome si dice: "prima il piacere e poi il dovere…", o una cosa del genere. Dopo il concerto meraviglioso, torniamo sulle pagine di devme, a parlare di cose informatiche spero interessanti. L’argomento di questo post parla di un concetto fondamentale del sistema operativo Symbian, il Cleanup Stack che ha a che fare con la gestione della memoria. Provate a immaginare quanto sia importante poter gestire al meglio una risorsa limitata come la memoria su di un cellulare, non appena la si comincia ad occupare per intero, le prestazioni decadono. Per questo motivo, esiste il Cleanup Stack, ovvero uno stack utilizzato per gestire quegli oggetti che potenzialmente possono generare delle eccezioni (Leave) e che quindi devono liberare la memoria occupata. Consideriamo ad esempio, una variabile locale puntatore ad un oggetto sullo heap, quando accade un eccezione (Leave) il puntatore viene distrutto senza liberare la memoria da esso referenziata, che diventa quindi non più utilizzabile, causando così un memory leak (perdita di memoria). Gli oggetti che non sono leave-safe, dovrebbero -o meglio devono- essere sempre inseriti all’interno del Cleanup Stack in modo da assicurare la loro effettiva distruzione in caso di eccezione. Ad esempio, gli oggetti symbian del tipo di dato C (C object type), sono sempre creati nello heap, non sono leave-safe e quindi vanno sempre inseriti all’interno dello stack. L’esempio seguente mostra alcuni casi di gestione della memoria:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
void DevMeUnsafeL() {
    CCDevme* cdevme = new (ELeave) CCDevme;
    /* Metodo InitializaL() potenzialmente pericoloso, pu&ograve; generare.
    * eccezione L'oggetto non &egrave; leave-safe, dopo la creazione, in
    * caso di eccezione, n&eacute; la memoria occupata sullo heap,
    * n&eacute; eventuali altri oggetti da lui referenziati verranno
    *  distrutti. */
    cdevme->InitializeL();
    delete cdevme;
}
void DevMeSafeButInefficientL() {
    CCDevme* cdevme = new (ELeave) CCDevme;
    /* Per evitare l'eventuale memory leak si pu&ograve; usare
    * la macro TRAPD, ma che per motivi di performance
    * dovrebbe essere evitata. L'uso eccessivo di TRAPD
    * attorno ai metodi non ottimizza la dimensione e la
    * velocit&agrave; del programma a run-time. */
    TRAPD(cdevme->InitializeL());
    delete cdevme;
}
void DevMeSafeL() {
    CCDevme* cdevme = new (ELeave) CCDevme;
    /* Inserisci all'interno del Cleanup Stack il referimento
    * all'oggetto creato cos&igrave; da poter recuperare la memoria
    * in caso di eccezione. */
    CleanupStack::PushL(cdevme);
    cdevme->InitializeL();
    ......
    ......
    /* Rimuovi dallo stackquando non &egrave; pi&ugrave; necessario
    *  il riferimento.*/
    CleanupStack::Pop(cdevme);
    delete cdevme;
}

Gli esempi di sopra mostrano alcune possibili gestioni della memoria su Symbian OS e i commenti all’interno degli esempio ne illustrano il funzionamento. E’ chiaro che l’ultimo esempio è il più efficiente dal momento che viene aggiunto nello stack il riferimento dell’oggetto creato e rimosso in caso di eccezione senza creare memory leak e quindi ottimizzando la gestione della memoria. In generale tutti gli oggetti all’interno dello stack vengono correttamente deallocati all’occorrenza, liberando la memoria occupata. La gestione della deallocazione viene fatta dal sistema operativo. Essendo il Cleanup Stack uno stack a tutti gli effetti, la sua gestione segue quella di uno stack normale, e cioè ad ogni Push corrisponde un Pop e l’ordine dei Pop è inverso all’ordine dei Push…..ma questo è già noto vero ?! :P Esistono altri metodi statici che possono essere usati della classe CleanupStack, si rimanda al file di include e32base.h presente all’interno delle SDK di symbian per la descrizione precisa della classe, oppure qui per dare un occhiata alla classe della versione 7.0 di symbian, forse un pò vecchiotta.

WordPress Themes