OpenMokoFramework/it
From Openmoko
Il Framework OpenMoko è un insieme di librerie che definiscono l'aspetto e lo stile standard delle applicazioni OpenMoko.
Contents |
Descrizione
Questa sezione mostra una piccola descrizione sulle librerie del framework OpenMoko e le loro dipendenze.
Una versione stampabile (PDF) è disponibile qui.
Contenuto
Questa sezione descrive la mappa delle librerie OpenMoko a seconda delle varie funzioni.
libmokocore
Funzioni fornite:
- Invio di messaggi fra le applicazioni OpenMoko
- Incapsulamento di dbus device API
- accendere/spegnere dispositivi
- conoscere/impostare luminosità/volume/ampiezza di segnale
- Esempio: l'applicazione Dialer manda un segnale dbus all'applicazione Contatti quando una chiamata con Tizio è stata completata.
- Leggere/scrivere dati di applicazione persistenti
- Esempio: Configurare preferenze
- Esempio: Salvare lo stato dei Preview Widgets aperti/falliti quando si esce dall'applicazione Contatti.
Utilizzi:
- dbus per i segnali fra applicazioni
- gconf per archiviare dati e preferenze di sessione per un'applicazione
- Usate libgconf-bridge per applicazioni statiche.
API:
| TODO: definire API (See: To-Do List) |
libmokonet
Funzioni fornite:
- High-Level Connection Queries (Connessione ad alto livello)
- Esempio: A quali peer possiamo inviare un file [non importa se via Internet o Bluetooth]?
- Esempio: Ci torviamo in una zona fisica definita? [ad esempio il nostro ufficio]
- Domanda: OpenMoko supporta più percorsi di rete concorrenti? Ad esempio la mia applicazione di chat comunica via GPRS, ma il browser (o qualsiasi altra app di trasferimento dati) si connette tramite bluetooth? Il punto è che, anche con la connettività Bluetooth attiva, può essere meglio connettersi ad Internet con GPRS, per evitare di troncare connessioni TCP a lungo raggio? Ma dovremo lasciare all'utente questa scelta, in caso che il GPRS sia molto costoso (nazioni diverse, progetti diversi) dovunque l'accesso Internet sia a tempo.
Utilizzi:
- libgsm
- libgpsd
- bluez-libs
API:
| TODO: definire API (See: To-Do List) |
libmokopim
Funzioni fornite:
- Una conveniente API di alto livello per fare richieste a dati PIM (Personal Information Management)
- Esempio: Prendere la lista di contatti da Addressbook
- Esempio: Quali contatti sono nel gruppo 'foo'
- Esempio: Visualizzare l'history di un determinato contatto
Utilizzi
- Embedded Evolution Data Server interfaccia per gestire l'archiviazione PIM
| TODO: definire API (See: To-Do List) |
libmokoui
Funzioni fornite:
- Widgets ad alto livello basati su GTK+ per l'aspetto comune di OpenMoko
- Esempio: barra di menu, barra degli strumenti
- API per controllare lo stato di InputMethod su X11
- Esempio: Quale tipo di input è stato scelto per ultimo?
- Esempio: InputMethod è correntemente visibile o no?
- API per avviare eventi UI (ad esempio suonerie, vibrazione, ...)
- Esempio: Lancia la suoneria d'allarme
- Esempio: Vibrazione per dieci secondi w/ Modello *--*--*--*
Utilizzi:
Contenuti:
Application & Windows
- MokoApplication -- Base Class per Applicazioni OpenMoko Applications
- MokoWindow -- Base Class per OpenMoko Appplication Windows
- MokoPanedWindow -- Base Class per la Main Window di applicazione per lo stiletto
- MokoFingerWindow -- Base Class per Main Window per applicazioni avviate col dito
Contenitori
- MokoFixed -- Classe per widgets che riempiono la mappa di pixel e il widgets dello sfondo (analogo a GtkFixed)
- MokoAlignment -- Class for widgets che riempiono la mappa di pixel e il widgets allineato dello sfondo (analogo a GtkAlignment)
Preview Widgets
- MokoPreviewWidget -- Abstract Base Class per OpenMoko Widgets/it#Preview Widgets
- MokoMessagePreview -- Implementa il widget Message Preview
- MokoPicturePreview -- Implementa il widget Picture Preview
- MokoCallPreview -- Implementa il widget Call Preview
- MokoAudioPreview -- Implementa il widget Sound - Recording
- MokoDateTimePreview -- Implementa il widget Date&Time Preview
Field Widgets
- MokoFieldWidget -- Implementa il field widget OpenMoko
| TODO: Decidere se una classe implementa più tipi di field widget o se vogliamo avere più classi (See: To-Do List) |
Widgets di barre
- MokoMenuBox -- Implementa la Barra di menu di OpenMoko che comprende il Menu applicazioni e il Menu filtri
- MokoToolBox -- Implementa la Barra degli strumenti di OpenMoko che comprende il Widget di ricerca e i Bottoni di azione
Widgets di liste
- MokoNavigationList -- Implementa il widget della Lista di Navigazione di OpenMoko
- MokoDetailsList -- Implementa il widget della Lista dettagli di OpenMoko
Widgets speciali
- MokoFingerWheel -- Implementa il widget Finger Scrolling (scorrimento con dito) che si trova nell'angolo in basso a sinistra di una MokoFingerWindow
- MokoFingerToolbar -- Implementa il widget Finger Toolbar che si trova nell'angolo in basso a destra di una MokoFingerWindow
Dialog comuni
- MokoBanner -- Implementa il Dialog informazioni
- MokoConfirmationDialog -- Semplice dialog da usare come Dialog di conferma, Dialog di notifica chiamate, ...
- MokoInputDialog -- Semplice dialog da usare come Data Entry Dialog
- MokoFileDialog -- Implementa il Dialog di apertura file
| TODO: Definire le API e l'intero albero di dipendenze (See: To-Do List) |
Piano implementativo
Questa sezione descrive il procedimento di implementazione delle librerie del core OpenMoko.
L'idea di base è che le funzionalità e le API delle librerie OpenMoko sono application-driver, ovvero un'API è aggiunta proprio nel momento in cui ne beneficiano più di una singola applicazione.
Significa anche che possiamo sviluppare il framework OpenMoko in parallelo alle applicazioni principali. Ad esempio, l'utilizzatore più importante del Preview Widgets e' l'applicazione Contatti, comunque questi widgets saranno sicuramente utili allo stesso modo nell'applicazione Calendario.
Ci sono persino componenti come la Barra dei menu che sarà una parte di praticamente ogni applicazione stylus di OpenMoko.
In breve, sto progettando di pubblicare un progetto delle API entro la prima settimana di ottobre e quindi lo Shanghai Lab inizierà a sviluppare le applicazione mentre io sto supportando la ristesura delle funzioni riutilizzabili dalle applicazioni all'interno delle librerie.
Per favore ricordate che la comunità Open Source è molto pignola quando si tratta di librerie. Se vogliamo che l'utente medio usi il nostro telefono, è quindi importante fornire un'eccellente usabilità e aspetto esterno, mentre se vogliamo che la comunità open-source adotti la nostra piattaforma, allora il nostro framework applicativo deve essere:
- chiaro
- conciso
- consistente
- il più semplice possibile
- il più riutilizzabile possibile



