Archivi categoria: DOCUMENTAZIONE

La categoria contiene tutta la documentazione disponibile per la consultazione

DESIGN PATTERN

DESIGN PATTERN TUTORIAL – 1 – INTRODUZIONE

Inizia una serie di articoli dedicati ai principali design pattern della programmazione ad oggetti.

La prima cosa da fare è chiarire cos’è un pattern. Per pattern si intende un metodo preciso di svolgere un determinato lavoro, frutto dell’esperienza maturata. Esso, pertanto, costitusce un modo per risolvere un determinato problema, ma non è l’unico e starà al programmatore scegliere di volta in volta se affidarsi ad un pattern o ad una soluzione differente. Si tratta di valutare di volta in volta il grado di complessità della soluzione e scegliere la strada migliore.

In questo primo articolo vedremo una carrellata dei principali design pattern, che approfondiremo di volta in volta in articoli dedicati.

Adapter

Viene usato quando occorre adattare il nostro codice alle esigenze di un client, fuori dal nostro controllo.

Facade

Viene usato quando si vuole una interfaccia di alto livello che nasconde la complessità del sottosistema cui si appoggia.

Composite

Viene usato quando occorre modellare oggetti in cui alcuni elementi possono contenere gruppi di oggetti. Un tipico esempio è l’albero.

Bridge

Viene usato quando si vuole disaccoppiare una astrazione dalla sua implementazione. Un tipico esempio sono i driver.

Singleton

Viene usato quando si vuole che una classe abbia una sola istanza e un solo punto di accesso ad essa.

Observer

Viene usato per gestire il caso in cui più oggetti dipendono dal comportamento di uno specifico oggetto.

Mediator

Viene usato quando si vuole centralizzare le regole di interazione tra un gruppo di oggetti.

Proxy

Viene usato quando si vuole demandare ad un altro oggetto l’accesso alle proprie funzionalità.

Chain Of Responsability

Viene usato quando si vuole consentire a più oggetti di gestire una chiamata in sequenza, ognuno responsabile di una determinata azione

Builder

Viene usato quando si vuole spostare la logica della costruzione della classe al di fuori della classe stessa.

Abstract Factory

Viene usato quando si consente ad un client di poter istanziare oggetti che fanno parte di una famiglia di classi correllate

Prototype

Viene usato quando si istanzia un nuovo oggetto a partire da una già presente

Template Method

Viene usato quando si rimanda la definizione di un algoritmo ad una sottoclasse. Tipico esempio è l’interfaccia Comparator.

State

Viene usato quando si è in presenza di una logica a stati e la si distribuisce su più classi.

Command

Viene usato quando si incapsula una richiesta all’interno di un oggetto, che sarà invocabile da un client. Tipico esempio sono i menù.

Decorator

Viene usato quando si vuole estendere il comportamento di un oggetto esistente.

Iterator

Viene usato quando si vuole consentire ad un client di accedere sequenzialmente agli elementi di una collezione.

Alla prossima

ANDROID

ANDROID TUTORIAL – 4 – GESTIRE L’ACTION BAR

Nell’articolo di oggi vediamo l’utilizzo dell’action bar, il componente introdotto con Android 3.0 (Api level 11) e supportato con le versioni precedenti tramite la Support Library. L’action bar è un componente che svolge diverse funzioni: innanzitutto identifica l’app, permette di gestire funzioni contestuali alla navigazioni e di avere accesso immediato a funzioni trasversali come potrebbe essere il modulo search.

Nell’action bar sono individuate 4 aree funzionali con queste caratteristichie:

  1. contiene l’icona dell’app ed eventualmente il pulsante Up per tornare all’activity precedente
  2. permette di navigare tra i contenuti di un app
  3. contiene i pulsanti che si attivano in base al contesto
  4. è la cosidetta area di overflow, contiene in formato lista, le azioni che non sono visualizzabili per mancanza di spazio
Il numero di pulsanti visibili nell’action bar è determinato dalla risoluzione dello schermo, come regola non possono occupare più del 50% della larghezza e allo stato attuale le regole sono riassunte nello schema successivo:

Qualora lo spazio non sia sufficiente le azioni sono disponibili nell’area di overflow, oppure è possibile attivare una bottom area in cui tutto lo spazio a disposizione è occupato dalle azioni rimaste.

Passiamo alla nostra app e attiviamo la action bar. Nel nostro esempio l’app deve essere compatibile con dispositivi con Android 2.1, pertanto definiamo la nostra activity principale così

dove ActionBarActivity è una classe della Support Library disponibile nel package android.support.v7.app;

A questo punto l’action bar è già disponibile e mostra la nostra icona e nient’altro. Qualora volessimo rimuoverla è sufficiente nasconderla in modo semplice:

Adesso abilitiamo il pulsante di Up che consente di gestire la navigazione ed accedere alle funzioni precedentemente visualizzate. Per farlo sono sufficienti due comandi:

(abilita il comportamento sull’icona dell’app )

o

(abilita una icona dedicata )

Per gestire il comportamento occorre implementare il metodo onOptionsItemSelected(MenuItem item) nella nostra activity e in particolare per gestire l’evento occorre implementare qualcosa di simile:

In questo caso mi limito a chiudere l’app, quello che è importante notare è come il pulsante di Home sia identificato univocamente tramite la costante android.R.id.home

Se adesso volessimo aggiungere dei pulsanti occorre definire un menu in formato xml

Per gestire l’action bar Big G ci mette a disposizione un set di icone per gli usi più comuni disponibili qui. E’ interessante notare l’attributo showAsAction, che stabilisce il comportamento del pulsante. Big G consiglia di usare il valore ifRoom con cui consentiamo al sistema di spostare il pulsante nell’area di overflow qualora lo spazio non sia sufficiente.

A questo per abilitare il pulsante implementiamo il metodo onCreateOptionsMenu, in questo caso mi trovo all’interno di un fragment

@Override public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) { inflater.inflate(R.menu.action_list_market, menu); super.onCreateOptionsMenu(menu, inflater); }

e posso pilotare la sua comparsa tramite il comando setHasOptionsMenu, che mi permette di attivarlo in base alle mie esigenze.

Nel mio caso ho collegato il menù ad una lista in modo che si attivi alla selezione di un elemento.

ANDROID

ANDROID TUTORIAL – 3 – AGGIUNGERE UN BANNER

Nell’articolo vedremo come aggiungere un banner alla nostra applicazione usando il Google Mobile Ads Sdk. Il precedente SDK è stato dichiarato deprecato, pertanto da Agosto 2014 il supporto di Google viene interrotto e occorre aggiornare le nostre app per gestire il nuovo SDK basato sui Google Play Services. Con la nuova soluzione offerta da Google eventuali aggiornamenti saranno gestiti automaticamente dal device senza la necessità di rilasciare un nuovo apk, cosa che prima era necessaria per risolvere bug o godere di nuove funzionalità aggiuntive.

Come prima cosa dobbiamo installare e configurare il Google Play Sdk all’interno del nostro ambiente di sviluppo.

Avviate l’SDK Manager, selezionate la sezione Extras e selezionate le voci:

  • Google Play Services For Froyo
  • Google Play Services
Scaricate una versione compatibile delle librerie da integrare nel vostro emulatore.

Una volta che l’SDK è stato aggiornato dobbiamo integrare le librerie nel nostro ambiente di sviluppo. Avviamo Eclipse e usiamo l’opzione:

File > Import, select Android > Existing Android Code into Workspace

Selezionate la directory <android-sdk>/extras/google/google_play_services/libproject/google-play-services_lib/ ed effettuate l’import della libreria nel nostro workspace.

A questo punto create un nuovo progetto Android e integrate la libreria all’interno del progetto tramite la sezione Android del progetto.

Non resta che agganciare il nostro banner all’interno della nostra app. Secondo le best practices di Google il banner non deve essere invasivo, pertanto verrà collocato nel footer dell’app. Occorre dichiarare l’activity nel nostro manifest

e fornire i permessi per l’accesso internet

A questo punto è sufficiente instanziare l’oggetto Adview e il banner apparirà nella zona desiderata

Per testarlo occorre usare un adv con il supporto alle google api

ANDROID

ANDROID TUTORIAL – 1 – GESTIRE UN BANNER

Nell’articolo di oggi vedremo come gestire al meglio il banner pubblicitario all’interno della nostra app. Quello che vedremo ben si adatta anche a situazioni in cui si vuole che solo una parte dello scherma supporti lo scrolling.

Sulle modalità per integrare un banner, rimando al sito di AdMob, recentemente acquisito da Google, dove potete scaricare l’SDK da integrare.

E’ mio interesse mostrare le modalità per integrare il banner all’interno dell’app, in modo da rendere l’operazione facile e indolore.

Approccio Dichiarativo

E’ possibile inserire direttamente il seguente blocco xml all’interno del nostro layout. Il parametro keywords deve essere valorizzato con l’ID Editore rilasciato da AdMob all’atto della creazione del profilo della nostra app.

In questo modo alla visualizzazione del nostro layout verrà anche visualizzato il banner. Con questo approccio, se vogliamo avere il banner in più activity della nostra app, dobbiamo inserire il blocco in ogni layout relativo all’activity.

Approccio Programmatico

E’ possibile gestire il banner programmaticamente, ovvero instanziare l’oggetto e configurarlo in uno dei metodi legati al ciclo di vita della nostra Activity, tipicamente il metodo onCreate.

Con questo approccio possiamo strutturare le nostre classi in modo da rendere trasparente per le nostre activity l’invocazione del banner, ad esempio tramite una activity astratta responsabile della gestione del banner, da cui ereditare le activity responsabili della logica della nostro app.

Tipici Problemi

Il problema che si può riscontrare è la mancata visualizzazione del banner. Fortunamente i log di Android ci danno tutte le indicazioni sulle possibili cause. Un motivo può essere il layout con spazio insufficiente per mostrare il banner e questo avviene tipicamente su dispositivi con display piccoli, dove abbiamo previsto di usare del padding. In questo caso l’errore che Android mostra è Not enough space to show ad! Wants: <320, 50>, Has: <270, 430>. Il problema si risolve agganciando il nostro banner al layout con una dimensione sufficiente a contenere il banner.

Altro problema è la posizione del banner, che può essere infelice o nella posizione non attesa. Per assicurarci la posizione desiderata possiamo usare il RelativeLayout e posizionare il banner nella posizione desiderata. Nell’esempio di sotto ho posizionato il banner in basso rispetto al container e l’oggetto ScrollView al di sopra del banner. In questo modo garantiamo la visualizzazione del banner nella posizione desiderata.

 

JOOMLA

JOOMLA – TUTORIAL – CREARE UN COMPONENT – FRONT-END

In questo articolo definiamo la parte pubblica del nostro componente. Essa presenta due punti di accesso, uno che consente di avviare una chat con l’operatore previa registrazione e una pagina di gestione delle chat accessibile per l’operatore.

Come già visto per il modulo di amministrazione definiamo il file liveassistant.php che costituisce l’entry point del nostro modulo:

Il file definisce il controller che viene definito nel file controller.php presente nella stessa directory:

Nel file definiamo la classe LiveAssistantController che estende la classe JController. I metodi definiti sono privi dell’implementazione, ognuno potrà scegliere l’implementazione che più preferisce, sia basata su file system che su base dati. La soluzione prevista salva le chat su file system in formato xml riducendo al minimo l’accesso al db.

A questo punto definiamo le view per la parte pubblica e le agganciamo alle voci del menu. Per fare questo è sufficiente aggiungere un file xml nella directory com_liveassistant\site\views\client\tmpl, che definisce il valore della voce del menù:

L’utente potrà aggiungere una voce di menù che punti alla view relativa, stabilendone le regole di accesso. Possiamo rendere l’esperienza più piacevole per l’utente realizzando un modulo dedicato.

Come il componente il modulo presenta un file descrittore xml che descrive la struttura del modulo e definisce l’entry point del modulo, nel nostro caso è il file mod_lvieassistant.php

<?

La sezione config definisce i parametri di configurazione del modulo, nel nostro caso è definito un parametro di tipo radio button che consente di stabilire il tipo di modulo da mostrare. (modulo client o modulo operatore).

Prossimamente rilascerò il package complessivo LiveAssistant, che comprenderà sia il componente che il modulo.

JOOMLA

JOOMLA – TUTORIAL – CREARE UN COMPONENT – BACKEND

Nell’articolo di oggi realizzeremo il backend del nostro componente, usando il pattern MVC (Model View Controller). Per chi non lo conoscesse si tratta di uno dei pattern più usati nello sviluppo software, che prevede la separazione della logica di business dal modello di rappresentazione dei dati.

Nel pattern MVC sono presenti le seguenti 3 componenti software:

  • model –> responsabile della gestione del dato (offre i metodi di accesso/modifica al dato)
  • view    –> responsabile della rappresentazione del dato
  • controller  –> gestisce le richieste degli utenti invocando gli oggetti adatti di volta in volta.
In Joomla le classi che implementano il pattern MVC sono:
  • JModel
  • JView
  • JController

Nel nostro caso il compito del componente di back-end sarà quello di gestire i parametri di configurazione del servizio chat, pertanto realizzeremo i seguenti moduli software:

  • un componente Model che offre i servizi di lettura e scrittura sulla tabella descritta nel precedente articolo
  • un componente View che presenta il dato all’utente
  • un componente Controller responsabile di gestire il modello di navigazione e le operazioni richieste dall’utente

Per ogni componente Joomla definisce due entrypoint, uno per la parte pubblica del sito e uno per la parte di amministrazione. Per il componente di amministrazione Joomla definisce entry point un file chiamato componentname.php, disponibile nel path administrator/components/com_componentname/componentname.php.

Nel nostro progetto l’entry point è il file administrator/components/com_liveassistant/liveassistant.php.

All’interno di tale file è presente la regola di definizione del controller

La prima chiamata impedisce l’accesso diretto al file, le chiamate successive definiscono il controller e la regola di redirect in base al parametro task. Joomla cerchà la definizione del controller in un file controller.php presente nella stessa directory dell’entry point. In tale directory viene definita la classe LiveAssistantController che estende JController

In assenza di un task specifico il controller invocherà il metodo display, in modo da invocare la view responsabile della visualizzazione del dato. Joomla cerca le view disponibili nel path component/com_[component_name]/views/[name of view]/, nel nostro caso component/com_liveassistant/views/liveassistant/. Le view sono definite in file view.[view_mode].php, dove il view_mode indica il formato della view, nel nostro caso html.

La nostra view contiene il seguente testo

La View è responsabile di costruire la pagina, in particolare essa aggiunge il titolo alla pagina e alla toolbar e gestisce l’aggiornamento dei parametri della chat. Essa invoca il file tmpl/default.php responsabile di mostrare i dati e i pulsanti per aggiornare i dati. Inoltre nella view sono visibili le chiamata al model. Come si può vedere il model non è espressamente indicato, ma è una classe vhe viene inizializzata cercano la classe LiveAssistantModelLiveAssistant che estende la classe JModel. Tale classe fornisce i metodi di lettura e scrittura al db, come si può vedere nell’estratto

 

Nel prossimo articolo realizzeremo la componente di front-end.

JOOMLA

JOOMLA – TUTORIAL – CREARE UN COMPONENT – BASE DATI

Continuiamo la realizzazione del nostro componente di chat definendo la base dati. Nella nostra soluzione la base dati viene usata per conservare i parametri di configurazione della chat e consentirne l’aggiornamento tramite la componente di amministrazione.

Vediamo prima il modello ERD

Gli attributi della tabella sono:

  • id              –> chiave primaria
  • enabled     –> indica se la chat è attiva
  • frequency   –> indica la frequenza in secondi con cui il client deve verificare l’aggiornamento dei dati
  • directory    –> indica la posizione dove verranno salvati le chat
  • mail           –>indica la mail dell’operatore cui verranno inviate le notifiche di richiesta help
  • title            –>indica il titolo della pagina della chat
Definito il modello ERD occorre preparare gli script sql con cui popolare la base dati. Nell’articolo precedente abbiamo definito uno script di installazione e uno di disinstallazione.
  • install.mysql.utf8.sql
  • uninstall.mysql.utf8.sql

Lo script di installazione prevede i seguenti comandi:

In coda alla creazione è previsto l’inserimento in tabella dei valori di default.

Lo script per la disinstallazione prevede semplicemente la rimozione della tabella:

 

Nel prossimo articolo vedremo come realizzare la compoennte MVC per gestire i parametri della configurazione.

JOOMLA

JOOMLA – TUTORIAL – CREARE UN COMPONENT – STRUTTURA

Iniziamo una serie di articoli mirati alla realizzazione di un componente che offre una funzionalità Live Assistant da integrare nel nostro sito Joomla 2.5, intesa come funzionalità di supporto chat per gli utenti del sito.

La componente amministrativa consente di configurare le caratteristiche delle chat mentre la componente front-end presenta due funzioni separate:

  • per gli utenti guest deve essere possibile l’avvio di una chat
  • per gli operatori autorizzati deve essere possibile gestire le chat avviate
La configurazione delle chat viene salvata all’interno del database, mentre le chat vengono salvate su file system, in modo da minimizzare gli accessi al database.
Creiamo la nostra directory com_liveassistant e all’interno di essa definiamo il nostro file manifest che definisce la struttura del nostro componente e le operazioni da effettuare in sede di installazione.

 

 
I primi tag sono descrittivi e contengono i dati dell’autore.
Il tag <install> contiene gli script sql che devono essere lanciati in sede di installazione, solitamente contiene gli script sql per la generazione delle tabelle.
Il tag <uninstall> contiene gli script sql che vengono lanciati in sede di disinstallazione, solitamente contiene gli script sql per la rimozione delle tabelle.
Il tag files individua l’insieme di file che costituiscono le funzioni del front-end. Tramite l’attributo folder è possibile specificare un path relativo e al suo interno specifichiamo file e directory da copiare nel nostro front-end
Il tag administration individua l’insieme di file che costituiscono le funzioni del backend.
Il tag languages individua i file per la localizzazione del nostro componente, nel nostro caso stiamo localizzando in italiano e in inglese.
In base a quanto definito nel nostro manifest il nostro componente presenterà la seguente alberatura:
Accedendo alla cartella site è visibile la seguente struttura dati
Mentre accedendo alla cartella admin è visibile la seguente struttura dati
Come potete vedere è presente il file index.html in ogni cartella al fine di minimizzare i rischi di un hacking basato sulla conoscenza del file system del nostro sito.
Compattando la directory principale in formato zip possiamo installare il nostro componente su joomla ottenendo questo effetto
Nel prossimo articolo imposteremo la base dati.
JOOMLA

JOOMLA – TUTORIAL – CREARE UN PACKAGE

Inizio una serie di articoli dedicati a Joomla, mirati alla realizzazione di estensioni per joomla. I vari articoli faranno riferimento alla versione 2.5 di Joomla, che è attualmente la versione a supporto LUNGO PERIODO, in attesa dell’uscita della versione 3.5, come è ben visibile in questo articolo.

Per estensione si intende un addon che aggiunge funzionalità al comportamento base di Joomla.

Si distinguono 3 tipi di estensioni che offrono diversi tipi di funzionalità:

  • plugin
  • modulo
  • componente
Il plugin implementa della funzionalità che si attivano al verificarsi di determinati eventi. Ad esempio alcuni plugin offrono l’inserimento di gallerie in articolo invocandoli tramite tag: {tag}nome_gallery{/tag}, altri invece completano le informazioni scambiate con il server tramite query aggiuntive.
Il modulo è un elemento di contenuto e occupa posizioni ben precise all’interno del nostro sito. Un esempio di modulo è il menù di navigazione.
Il componente è un elemento che aggiunge nuove funzionalità al nostro sito. Esempio di componenti sono le gallery fotografiche, linkabili tramite una voce del menù.
Le estensioni vengono installate su Joomla tramite file zip che contengono i sorgenti e il  file descrittore xml che contiene le indicazioni per una corretta installazione.
E’ possibile raggruppare le estensioni in un unico artefatto detto package. Il package presenta un descrittore xml che contiene le informazioni relative le estensioni all’interno del nostro package.
Immaginiamo di voler realizzare un sistema live assistant, un sistema di chat per gli utenti del sito. In questo sistema sono presenti un componente per la gestione delle chat e un modulo per l’accesso alla funzionalità. Pertanto il nostro package si presenterà come un file zip contenente un descrittore xml pkg_liveassistant.xml e una directory packages contenente gli zip dell’estensione componente e dell’estensione modulo.
Vediamo più in dettaglio la struttura del nostro descrittore:

I tag evidenziati descrivono le estensioni presenti all’interno del package.

Nei prossimi articoli vedremo come realizzare il nostro componente e il nostro modulo.