Sviluppare Applicazioni per Nokia 6680

Da TondoWiki.

IN COSTRUZIONE! Qui pian piano scriverò cio che sto imparando..

Nota: l'IDE presentata e gli appunti seguenti riguardano solo la programmazione in Symbian/C++.

[modifica] Strumenti

Ecco gli strumenti necessari per avere un ambiente di sviluppo con il quale cominciare a scrivere delle applicazioni (vanno installati seguendo l'ordine proposto):

Nota: prestare particolare attenzione nella scelta della/e SDK corretta/e, leggete il paragrafo "Available SDKs" che spiega come effettuare tale scelta.

Per il 6680 va bene la versione "2nd Edition, FP 2, CW" Se si vuole realizzare una applicazione compatibile con tutti i 2nd Edition usare la "2nd Edition, CW" Se invece si vuole realizzare una applicazione compatibile con tutti i 3rd Edition usare la "3rd Edition, Maintenance Release"

[modifica] Files

Il primo problema che mi si è presentato è che aprendo Carbide.c++ e provando a creare un nuovo progetto mi sono ritrovato a dover mettere le mani in una buona dozzina di file senza capire a cosa servissero! Ecco un'elenco:

File di interfaccia delle classi.

.cpp

File di implementazione delle classi.

.hrh

File nel quale vengono raccolte tutte le costanti usate nel programma, per poterle usare all'interno di un qualunque altro file (.rss compresi) bisogna includerlo normalmente:

#include "Nome.hrh"

Esempio di un file .hrh:

#ifndef NOME_HRH
#define NOME_HRH

enum TNomeCommandIds
    {
    NomeCmdAppTest = 1,
    NomeCmdAppOpt,
    NomeCmdAppGo1
    };

enum TNomeQuelloCheVoglio
    {
    NomeAbc = 1,
    NomeDef
    };

#endif

.loc

File nel quale vengono raccolte tutte le stringhe usate nel programma, molto comodo e soprattutto fondamentale per la "localizzazione" del software, ovvero x tradurlo in altre lingue (questo aspetto verrà trattato eventualmente piu avanti). Per poter usare queste stringhe all'interno di un qualunque altro file (.rss compresi) bisogna includerlo normalmente:

#include "Nome.loc"

Esempio di un file .loc:

// LOCALISATION STRINGS

#define qtn_appl_test "Test"
#define qtn_appl_exit "Exit"

#define qtn_view1_option_item "Vai a view 2"
#define qtn_view1_option_item_opt "Impostazioni"

.rss

Nota: quando si dichiara una variabile, una classe, una costante è in ogni caso una buona norma rispettare le convenzioni standard

[modifica] Cartelle

Il nostro progetto è spesso suddiviso in varie cartelle, ecco in breve le principali e cosa contengono:

src

I file .cpp

inc

I file .loc, .hrh e .h

data

I file .rss

group

I file che contengono le informazioni per la compilazione del progetto (.mmp & .inf)

aif

I vari file con le icone del programma (x ora non vengono trattati)

install

I file .pkg e .sis (quando lo creerete)

[modifica] Coding Idiom

[modifica] Naming Convention

Capitalization

Il nome di una classe o di una funzione deve avere la prima lettera maiuscola. Se il nome è composto di più parole ognuna di esse deve cominciare con una lettera maiuscola.

class TMyClass;

I parametri delle funzioni e le variabili devono cominciare con una lettera minuscola. Se il nome è composto di più parole ognuna di esse deve cominciare con una lettera maiuscola (tranne la prima).

TMyClass myObject;

Prefixes

Le variabili membro non-static vanno precedute dalla lettera "i", ad indicare che è un'istanza della classe.

Tint iCount

I parametri delle funzioni vanno precedute dalla lettera "a", ad indicare che è un'argomento della funzione.

void MyFunction( Tint aParameter );

Le variabili automatiche non richiedono un prefisso.

for ( Tint x=0; x < 5; x++ )

Le costanti vanno precedute dalla lettera maiuscola "K".

#define KMaxItemLenght 32
const Tint KMinItemLenght 1

Il nome nelle enumerazioni va preceduto dalla lettera maiuscola "T". I membri nelle enumerazioni vanno precedute dalla lettera maiuscola "E".

enum TGameStates ( EPlaying = 1, EPaused, EFinished );

Suffixes
Underscores

[modifica] Type Definitions

Integers
Floating-point numbers
Characters
Boolean values

[modifica] Classes

C classes
T classes
R classes
M classes
Structs
Static classes

[modifica] Punti Chiave

Ci sono dei concetti fondamentali da sapere assolutamente in symbian/c++:

[modifica] TRAPs & Leaves

[modifica] The Cleanup Stack & Two-Phase Construction

[modifica] String and Descriptors

string & binary data sono trattati allo stesso modo
i dati possono risiedere in ogni memoria (ROM, RAM, stack of the heap...)
un oggetto di tipo descriptor mantiene puntatori ed informazioni sulla lunghezza per descrivere i dati che contiene. Alcuni descriptors includono anche la lunghezza massima.

Tutti i descriptors derivano dalla classe astratta TDesC. Sono divisi in 3 tipi:

Buffer descriptor: quando i dati sono parte del descriptore il descriptor è nel program stack: TBuf and TBufC
Heap descriptor: quando i dati sono parte del descriptore il descriptor è nell'heap: HBufC
Pointer descriptor: quando il descrittore è separato dai dati che rappresenta: TPtr and TPtrC.

TDes e TDesC sono classi astrattee non possono essere instanziate. Si usano principalmente come argomenti delle funzioni che manipolano string e binary data. In queste funzioni tu puoi fare:

const TDesC& per read-only string o data
TDes& per passare string o data che vuoi che possano essere modificati.

[modifica] altro

src\*.cpp file di implementazione, ovvero implementano il codice delle classi presentate nei file di interfaccia
inc\*.hrh = c'è bisogno di qualche costante che deve essere dichiarata nel sorgente di C++. Questo è l'utilizzo del file sorgente .hrh
inc\*.h = file di interfaccia delle classi create
- *App.h = The application has two purposes: create a document, and specify the UID of the application.
- *AppUi.h = (controller) We have to create the View in the usual ConstructL method
- *Container.h = (view) ConstructL reads text from resource, then create a windows, set his rect and activate it.
- *Document.h = (model) You HAVE TO create a document class if you wont open, create or edit a files.
- *View.h =
inc\*.loc = file nel quale vengono localizzate le stringhe
data\*.rss = file che definisce come la tua applicazione si si presenta, quindi l'interfaccia grafica..
data\*_caption.rss =
group\*.inf = build file
group\*.mmp = spiega al compilatore come sono distribuiti i vari file, quali deve andare a prendere..
aif\ = contiene le icone del nostro progetto e dei file che indicano il loro utilizzo..
install\*.pkg = pacchetto per le informazioni di installazione dell'applicazione

[modifica] Model View Control in S60

L'Avkon layer è un'estensione del Symbian OS Uikon layer. Avkon mette a disposizione funzionalità specifiche per i S60 2nd ed. tra le quali delle classi chiave da cui derivano tutte le applicazioni. Queste classi sono CAknApplication, CAknDocument e CAknAppUi.

Un'applicazione S60 consiste di quattro componenti distinti:

[modifica] Application

Classe derivata da CAknApplication, è il primo oggetto instanziato dalla tua applicazione. Una volta creato e responsabile dell'inizializzazione e della creazione del Document.

[modifica] Document

Classe derivata da CAknDocument.

[modifica] Application UI

Classe derivata da CAknAppUi, fornisce le funzionalità principali, responsabile della creazione dell'ultima parte dell'applicazione, la view.

[modifica] View

Quello che l'utente finale vede sullo schermo! Puo essere usata per visualizzare dati, o in casi piu complessi, per memorizzare dati introdotti dallutente.

[modifica] Appunti

La piattaforma S60 lavora sopra Symbian OS e rende disponibili agli sviluppatori un vasto e versatile set di API. L'UI layer in S60 è chiamato Avkon.

Drive names:

#include <PathInfo.h>
...
TFileName path = PathInfo::PhoneMemoryRootPath();
path.Append( PathInfo::ImagesPath() );

Altri drive names:

PathInfo::MemoryCardRootPath()
PathInfo::ImagesPath()
PathInfo::InstallsPath()
PathInfo::SoundsPath()

[modifica] I vari file

[modifica] application

#ifndef __S60TEST_APPLICATION_H__
#define __S60TEST_APPLICATION_H__

#include <aknapp.h>


class CS60TestApplication : public CAknApplication
{
public:  // from CAknApplication
  TUid AppDllUid() const;

protected: // from CAknApplication
  CApaDocument* CreateDocumentL();
};

#endif // __S60TEST_APPLICATION_H__

.cpp

#include "S60TestDocument.h"
#include "S60TestApplication.h"

// UID for the application, this should correspond to the uid defined in the mmp file
static const TUid KUidS60TestApp = {0x04545FF1};

CApaDocument* CS60TestApplication::CreateDocumentL()
{  
  CApaDocument* document = CS60TestDocument::NewL(*this);
  return document;
}

TUid CS60TestApplication::AppDllUid() const
{
  return KUidS60TestApp;
}

Nota: bene o male questo file non va piu toccato e rimane cosi..

[modifica] document

#ifndef __S60TEST_DOCUMENT_H__
#define __S60TEST_DOCUMENT_H__

#include <akndoc.h>

// Forward references
class CEikAppUi;
class CEikApplication;
class CS60TestAppUi;

class CS60TestDocument : public CAknDocument
{
public:
  static CS60TestDocument* NewL(CEikApplication& aApp);
  static CS60TestDocument* NewLC(CEikApplication& aApp);
  ~CS60TestDocument();

  CS60TestAppUi *iAppUi;

public: // from CAknDocument
  CEikAppUi* CreateAppUiL();

private:
  void ConstructL();
  CS60TestDocument(CEikApplication& aApp);
};


#endif

.cpp

#include "S60TestAppUi.h"
#include "S60TestDocument.h"

// Standard Symbian OS construction sequence
CS60TestDocument *CS60TestDocument::NewL(CEikApplication& aApp)
{
  CS60TestDocument *self=NewLC(aApp);
  CleanupStack::Pop(self);
  return self;
}

CS60TestDocument *CS60TestDocument::NewLC(CEikApplication& aApp)
{
  CS60TestDocument *self=new(ELeave) CS60TestDocument(aApp);
  CleanupStack::PushL(self);
  self->ConstructL();
  return self;
}

void CS60TestDocument::ConstructL()
{
}

CS60TestDocument::CS60TestDocument(CEikApplication& aApp)
:CAknDocument(aApp)
{
}

CS60TestDocument::~CS60TestDocument()
{
}

CEikAppUi *CS60TestDocument::CreateAppUiL()
{
  // Create the application user interface, and return a pointer to it,
  // the framework takes ownership of this object
  iAppUi=new(ELeave) CS60TestAppUi(this);
  return iAppUi;
}