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.

NFC: tecnologia in un touch !

Pochi giorni fa, sul sito del corriere dell sera ho letto un articolo interessante, in cui il CEO della Nokia, ovvero il numero uno della compagnia finlandese Mr Kallasvuo, affermava che la competizione con gli attuali smartphone, Apple, Blackberry, etc, lì spingerà oltre la telefonia. In futuro si potranno effettuare pagamenti di bollette, acquisti in genere utilizzando il proprio telefonino.
E in effetti, poco tempo prima di leggere l’articolo, avevo esplorato il mondo dei nuovi telefonini Nokia che integrano una nuova tecnologia chiamata NFC.

Near Field Communication (NFC) è una tecnologia che fornisce connettività wireless bidirezionale a corto raggio (fino ad un massimo di 10 cm). La tecnologia NFC si è evoluta da una combinazione di identificazione senza contatto o RFID (Radio Frequency Identification – IDentificazione a Radio Frequenza) e altre tecnologie di connettività. NFC, contrariamente ai più semplici dispositivi RFID, permette una comunicazione bidirezionale: quando due apparecchi NFC (l’Initiator e il Target) vengono accostati entro un raggio di 4 cm, viene creata una rete peer-to-peer tra i due ed entrambi possono inviare e ricevere informazioni (fonte wikipedia). Al momento l’unico cellulare dotato di funzionalità NFC è il Nokia 6131.

Premesso che non mi interessa fare pubblicità del cellulare (non sono ancora sul libro paga della Nokia), al contrario voglio farvi vedere come la tecnologia (forse) cambierà i nostri modi di fare quelle cose che al momento sono scontate. Vediamo quali potrebbero essere:

touch-to-pay: avvicinando il cellulare sarà possibile utilizzarlo come una carta di credito. Le informazioni sensibili della carta sono memorizzate al suo interno in un elemento chiamato secure element. In sostanza funziona come una carta di credito senza contatto.E’ possibile visualizzare le informazioni informative classiche delle proprie transazioni.  

Il cellulare funziona come un biglietto senza il contatto. Basterà avvicinarlo ad un altro dispositivo capace di leggerlo per effettuare la validazione. Le informazioni sul biglietto o travel card sono memorizzate all’interno del secure element. Sarà ossibile ricaricare la propria travel card da dovunque ed in un qualunque momento e visionare la storia delle proprie validazioni.

Ovviamente non poteva mancare un servizio capace di far fruire di contenuti interattivi semplicemente avvicinando il cellulare ai dispositivi capaci di rendere tali servizi. Si pensi ad esempio a servizi di marketing interattivo che vengono attivati senza il contatto.

Ma c’è da fidarsi ?
E se dovessi perdere il cellulare ?
Ma soprattutto, cos’è questo secure element ?
Come ogni dispositivo tecnologico nuovo, secondo me, bisognerà aspettare prima di vedere una diffusione non dico capillare ma degna di nota. Non dimentichiamo, che in particolare il nostro paese, è un pò restio all’utilizzo di dispositivi o mezzi del genere per effettuare pagamenti. Molta gente preferisce il buon vecchio contante. Ciò nonostante sono fiducioso, dopo un’attenta campagna di marketing probabilmente qualcosa comincierà a muoversi. Chiaro che tutto dipende molto anche dalla diffusione dei cellulari che integrano funzionalità NFC, poco tempo fa la Sony Ericsson ha annunciato che dal 2010 tutti i suoi nuovi cellulari includeranno tali funzionalità, a dimostrazione che anche loro ci credono molto.
Il caso in cui si dovesse perdere il cellulare credo che sia molto simile al caso in cui si dovesse smarrire la carta di credito, in cui chiamando il numero verde si blocca la carta. Analogamente credo che chiamando il numero verde dell’operatore si provvederà al blocco del cellulare….sempre che ce né accorgiamo in tempo .

Infine vediamo in che modo i dati sensibili della carta di credito vengono memorizzati. Come già detto i dati vengono memorizzati all’interno del secure element un componente hardware che è integrato all’interno del cellulare. La dimensione della memoria dell’elemento è di 72Kb, in cui una certa dimensione è riservata per le applicazioni specifiche del cellulare. Mentre la memoria disponibile per le applicaizoni nella Java Card è di 65Kb.

Il Secure Element è governato da regole e procedure di sicurezza molto stringenti. Si trova in uno stato SICURO dal momento dell’acquisto del cellulare. Ci sono 2 differenti chiavi di autenticazione per accedere al secure element, una per l’accesso alla Java Card e l’altra per l’accesso alla Mifare 4k. Java Card soddisfa requisiti di sicurezza molto alti derivanti direttamente dal life-cycle dell’elemento stesso. A partire dal silicio usato per la costruzione del chip, al sistema operativo, al processo di costruzione e trasferimento dei dati al suo interno. Quando si acquista un cellulare il secure element contiene solo il dato segreto della chiave specifica del dispositivo.

Bene per ora direi che può bastare. L’argomento mi interessa molto, procedo con le mie esplorazioni di implementazione di applicazioni di prova, così da condividerle con chi, di passaggio o non, si troverà sulle pagine del mio blog. A presto…yo.

Cleanup Stack

Come 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ò generare.
    * eccezione L'oggetto non è leave-safe, dopo la creazione, in
    * caso di eccezione, né la memoria occupata sullo heap,
    * né 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ò 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à 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ì da poter recuperare la memoria
    * in caso di eccezione. */
    CleanupStack::PushL(cdevme);
    cdevme->InitializeL();
    ......
    ......
    /* Rimuovi dallo stackquando non è più 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 ?! 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.

Symbian – Auto start di un applicazione

Salve a tutti quei pochi, spero ancora per poco, che leggono il blog…ogni tanto un commentino potreste anche lasciarlo, siamo qui per quello !!! Volevo cominciare una, spero lunga serie di post su symbian, il famoso sistema operativo che gira su molti dei cellulati di ultima generazione (nokia, samsung, etc). Per il momento tralasciamo tutto quello che concerne il preliminare di symbian, e vediamo subito, senza perdere tempo, un programmino, o meglio uno scorcio di codice che permette di lanciare un applicazione al boot, ovvero quando si va ad accendere il cellulare.

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95

#include <apmrec.h>
#include <apmstd.h>
#include "cl_autostart.h" 
const TUid KUidemAclAutostart={0x09A770B5}; CclAutostart::CclAutostart():CApaDataRecognizerType(KUidemAclAutostart, CApaDataRecognizerType::ENormal) {
    iCountDataTypes = 1; 
} 
TUint CclAutostart::PreferredBufSize() { 
    // no buffer recognition yet 
    return 0; 
} 
TDataType CclAutostart::SupportedDataTypeL(TInt /*aIndex*/) const { return TDataType(); } 
void CclAutostart::DoRecognizeL(const TDesC& /*aName*/, const TDesC8& /*aBuffer*/) {} 
void CclAutostart::StartThread() { 
    TInt res = KErrNone; 
    //create a new thread for starting our application 
    RThread * startAppThread; 
    startAppThread = new RThread(); 
    User::LeaveIfError( res = startAppThread->Create(
        _L("Autostart starter"), CclAutostart::StartAppThreadFunction, KDefaultStackSize,
        KMinHeapSize, KMinHeapSize, NULL, EOwnerThread) );
    startAppThread->SetPriority(EPriorityNormal/*EPriorityLess*/); 
    startAppThread->Resume(); 
    startAppThread->Close(); 
} 
TInt CclAutostart::StartAppThreadFunction(TAny* /*aParam*/) { 
    //wait 5 seconds... 
    RTimer timer; 
    // The asynchronous timer and ... 
    // ... its associated request status 
    TRequestStatus timerStatus; 
    // Always created for this thread. 
    timer.CreateLocal(); 
    // get current time 
    TTime time; 
    time.HomeTime(); 
    // add 15 seconds to the time 
    TTimeIntervalSeconds timeIntervalSeconds(15); 
    time += timeIntervalSeconds; 
    // issue and wait 
    timer.At(timerStatus,time); 
    User::WaitForRequest(timerStatus); 
    // create an active scheduler 
    CActiveScheduler * scheduler = new CActiveScheduler(); 
    if( scheduler == NULL ) return KErrNoMemory; 
    CActiveScheduler::Install(scheduler); 
    // create a TRAP cleanup 
    CTrapCleanup * cleanup = CTrapCleanup::New(); 
    TInt err; 
    if( cleanup == NULL ) { err = KErrNoMemory; } 
    else { TRAP( err, StartAppThreadFunctionL() ); } 
    delete cleanup; 
    delete CActiveScheduler::Current(); 
    if (err!=KErrNone) User::Panic(_L("autostart"), err); return err; 
} 
 
void CclAutostart::StartAppThreadFunctionL() { 
    #ifdef __WINS__ 
    // This is the uid of the starter application, 
    // which you want to autostart. 
    const TUid starter_uid= { 0x05CCC0B0 }; 
    RApaLsSession ls; 
    User::LeaveIfError(ls.Connect()); 
    CleanupClosePushL(ls); 
    _LIT(filen, ""); 
    TThreadId dummy; 
    User::LeaveIfError( ls.StartDocument(filen, starter_uid, dummy) ); 
    CleanupStack::PopAndDestroy(); 
    #else 
    // Replace this starter.app with the app which 
    // you want to autostart. 
    TFileName fnAppPath = _L("\\system\\apps\\myapp\\myapp.app"); 
    RFs fsSession; 
    //file server session 
    User::LeaveIfError(fsSession.Connect()); 
    CleanupClosePushL(fsSession); 
    TFindFile findFile( fsSession ); 
    User::LeaveIfError( findFile.FindByDir(fnAppPath, KNullDesC) ); 
    CApaCommandLine* cmdLine = CApaCommandLine::NewLC(); 
    cmdLine->SetLibraryNameL( findFile.File() ); 
    cmdLine->SetCommandL( EApaCommandOpen ); 
    RApaLsSession ls; 
    User::LeaveIfError(ls.Connect()); CleanupClosePushL(ls); 
    User::LeaveIfError( ls.StartApp(*cmdLine) ); 
    // Destroy fsSession, ls and cmdLine 
    CleanupStack::PopAndDestroy(3); #endif 
} 
EXPORT_C CApaDataRecognizerType* CreateRecognizer()  { 
    CApaDataRecognizerType* thing = new CclAutostart(); 
    //start thread for our application 
    CclAutostart::StartThread(); return thing; 
} 
// DLL entry point 
GLDEF_C TInt E32Dll(TDllReason /*aReason*/) { 
	return KErrNone; 
}

Lo scorcio di codice di sopra, descrive una classe scritta in C++ per symbian, e realizza quello che tecnicamente si chiama un MDL, ovvero un particolare tipo di programma che viene riconosciuto da symbian e lanciato subito dopo la fase di boot con un ritardo che viene impostato da codice. Nel nostro esempio il ritardo è di 15 secondi. Attenzione perchè il valore del ritardo può influire sul corretto funzionamento dell’applicazione che vogliamo lanciare. Ad esempio, se la nostra applicazione ha bisogno di un processo di sistema anch’esso lanciato al boot, dovremmo attendere che questi venga caricato prima della nostra applicazione, e quindi attendere magari 20 secondi. Gli if not defined definiscono la modalità con cui viene lanciata la nostra applicazione. #ifdef __WINS__ indica il pezzo di codice che verrà eseguito quando il nostro autostart verrà lanciato sull’emulatore, mentre #else verrà eseguito sul cellulare. Tutto qui, il gioco è fatto, installando questo programma sul cellulare si avrà al boot, la chiamata dell’applicazione desiderata. Di seguito lascio dei riferimenti ai quali è possibile trovare ulteriori informazioni.

• Ottima risorsa sull’argomento e non solo…
• forum nokia