OraInOnda

Descrizione

Il sistema è formato da:

• un'applicazione per dispositivi mobile (inizialmente iphone, poi android) che permetta agli utenti di visualizzare i palinsesti tv ed effettuare un "zap" in tempo reale relativo ad un programma che stanno seguendo;
• da un web server che gestirà l'intero sistema;
• una pagina web "vetrina", che pubblicizzi semplicemente l'applicazione (almeno inizialmente).

L'utente che effettuerà uno zap manderà una notifica a tutti i suoi follower iscritti al servizio, condividendo con loro il titolo del programma che sta seguendo ed un commento. Gli utenti saranno in grado di cercare, invitare ed aggiungere nuovi amici e di visualizzare e commentare gli zap dei propri. L'aspetto sociale dell'applicazione è garantito dal fatto che per registrarsi e partecipare è necessario essere iscritti a facebook (in futuro si potrebbero integrare anche altri social o rendere l'iscrizione aperta semplicemente a tutti) e gli utenti registrati potranno invitare i loro amici presenti su facebook. L'applicazione avrà anche una componente "ludica", in quanto saranno previsti "obbiettivi da sbloccare" e "premi" di modo da coinvolgere gli utenti a giocare e ad interagire. Il meccanismo è simile a quello usato da foursquare, che ha raggiunto il successo unendo la componente sociale a quella ludica. Le principali problematiche da risolvere sono:

• recupero delle informazioni relative ai palisesti in maniera automatizzata e loro inserimento in db;
• interfacciamento con i meccanismi proprietari (apple e android) che consentono l'invio di notifiche remote;
• garantire interoperabilità tra piattaforme mobili diverse;
• eventuale replicazione dei database e dei server.

Mockup

Glossario

UTENTE: persona registrata a facebook (almeno come requisito iniziale) che si è iscritta al servizio. ZAP: nell'ambito di questo progetto si intende l'azione con la quale l'utente "segnala" ai suoi follower che sta guardando un programma che è correntemente in riproduzione in televisione e quindi presente nel palinsesto. FOLLOWER: con follower si intende un utente che ne segue un'altro (stile twitter..). FOURSQUARE: popolare applicazione che permette agli utenti di fare check-in presso i luoghi che visitano (o nelle loro vicinanze..). NOTIFICA REMOTA (PUSH NOTIFICATION): messaggio che appare nel dispositivo mobile, paragonabile ad esempio alla ricezione di un sms.

Casi d'uso

I casi d'uso relativi al sistema sono riassunti nel seguente schema.

Requisiti non funzionali

Tra i vari requisiti non funzionali che è bene rispettare, quelli che maggiormente dovranno essere tenuti in considerazione, senza ovviamente trascurare gli altri, sono:

• interoperabilità: il sistema deve permettere l'interazione fra piattaforme tecnologicamente diverse.
• scalabilità: il sistema non deve precludere possibili sviluppi futuri ne rendere questi difficili per colpa di scelte progettuali troppo ristrette o frettolose.
• usabilità: essendo un sistema social, deve essere facilmente usabile anche da un utente medio. Sarà fondamentale disporre di un'interfaccia grafica semplice ed intuitiva.

Architettura generale del sistema

Il seguente schema mostra come è stata pensata la struttura generale dell'architettura del sistema. Dallo schema si evince come le applicazione mobile dovranno interfacciarsi al sistema allo stesso modo, indipendentemente dalla piattaforma su cui sono sviluppate. Il componente principale del sistema sarà quindi il RequestManager, che avrà il compito di ricevere le richieste, verificare la loro correttezza ed eseguirle. Le richieste saranno di diversi tipi:

1. Semplici richieste di letture/aggiornamento di dati, con conseguente accesso al database;
2. Richieste con cui l'utente (l'applicazione) informa il sistema che deve mandare delle notifiche ai suoi follower.

Esempi:

1. Un esempio di richiesta relativa al primo tipo è quella con cui l'applicazione richiede la lista degli ultimi zap di un utente. Tale richiesta si tradurrà in una query in lettura al db.
2. Un esempio di richiesta relativa al secondo tipo è quando un utente fa uno zap, e quindi si presume che tale evento sia notificato a tutti i suoi follower.

(Tale richiesta è relativa anche al primo tipo, in quanto si vuole mantenere uno storico degli zap degli utenti, e quindi in seguito a tale richiesta avverrà anche una scrittura nel db).Per gestire e semplificare i rapporti col db si utilizzarà un modulo del Zend Framework. Per gestire l'invio di notifiche ai device si utilizzerà il NotificationCenter, che permetterà di inviare notifiche indipendentemente dalla piattaforma su cui gira l'applicazione mobile. Il suo compito sarà quello di fornire una "interfaccia standard" tramite la quale il sistema manderà le notifiche remote, senza preoccuparsi della piattaforma ricevente. Per effettuare l'aggiornamento dei palinsesti, verrà utilizzato un componente a parte, il PalimsestUpdater, che conterrà gli script necessari.

Architettura dei componenti del sistema

SERVER SIDE

Il diagramma mostra più nel dettaglio come è strutturata l'architettura. Il RequestManager ha il compito di ricevere le richieste dai client ed eseguirle, usando il modulo del ZendFramework per interagire con il database e il NotificationCenter per inviare richieste alle applicazioni mobili. Seguono alcuni diagrammi dell'interazione fra i vari componenti per meglio comprendere il funzionamento del sistema. Questo diagramma mostra come funziona il meccanismo di inserimento di dati nel database. In questo caso l'utente ha lasciato un commento ad uno zap.. L'applicazione mobile manderà i dati tramite una richiesta al RequestManager, che provvederà a demandare l'inserimento nel database al modulo dello ZendFramework usato per interfacciarsi al dbms. Ogni richiesta di inserimento dati seguirà questo meccanismo. Questo diagramma mostra come funziona il meccanismo di lettura di dati dal database. In questo caso l'applicazione richiede il palinsesto del giorno corrente.. Il meccanismo è analogo al precedente ed ogni richiesta di lettura di dati seguira questo meccanismo. Questo diagramma mostra il caso in cui un utente faccia uno "zap". Oltre al solito meccanismo di interazione con il database, vengono anche invocati i servizi del NotificationCenter, che provvederà a mandare una notifica relativa allo zap dell'utente ad ogni follower.

NOTIFICHE REMOTE:

L'invio di notifiche remote funziona ovviamente in modo diverso essendo le due piattaforme diverse..

• IPHONE

(from http://www.raywenderlich.com/3443/apple-push-notification-services-tutorial-part-12)

1. An app enables push notifications. The user has to confirm that he wishes to receive these notifications.
2. The app receives a "device token". You can think of the device token as the address that push notifications will be sent to.
3. The app sends the device token to your server.
4. When something of interest to your app happens, the server sends a push notification to the Apple Push Notification Service, or APNS for short.
5. APNS sends the push notification to the user's device.

• ANDROID

(from http://code.google.com/android/c2dm/index.html)

1. The user launches your app on their Android device. You call the C2DM registration method.
2. After the user has logged in, Google provides a registration ID to uniquely identify the device. You must send that ID to your servers and store it so you can communicate with the user.
3. You send a message to the user using their registration ID. This consists of a POST to the Google C2DM service.
4. The user's device receives the message and you handle it.

Il NotificationCenter sarà quindi progettato in modo tale da rendere l'invio di notifiche trasparente alla piattaforma che riceverà la notifica.

MOBILE APPLICATION SIDE:

Le applicazioni mobile saranno relativamente semplici. Non dovranno fare altro che fare richieste http al sistema, ricevere le risposte e presentarle in apposite view personalizzate, oltre che essere predisposte alla ricezione di notifiche. Il problema più complesso da gestire è l'aggiornamento dei dati presenti nel database interno all'applicazione, come ad esempio mantenere consistente l'elenco dei canali e dei programmi con quello del db. Si potrebbero inoltre mantenere anche i dati relativi agli amici e agli zap (oltre che tutti gli altri..) in un db interno, permettendo all'utente di visualizzare tali dati anche quando non è collegato ad internet, ma ciò complicherebbe notevolmente la gestione della consistenza di tali dati. Perciò inizialmente si decide di memorizzare solamente i dati relativi ai palinsesti e si riserva tale opportunità al futuro, nel caso l'applicazione prenda effettivamente piede.

Modello dei dati del sistema

SERVER SIDE

Il seguente schema mostra come sono state costruite le tabelle relative al db del sistema (non vengono riportati i diagrammi intermedi). In rilievo:

• Si è scelto di mantenere uno storico degli zap di ogni utente, dei commenti relativi agli zap, dei programmi e delle notifiche.
• I rapporti fra gli utenti, ovvero chi segue chi, viene memorizzato tramite la tabella following.
• Le notifiche vengono memorizzate in una tabella. Questo permetterà:
  • alla applicazione mobile di mettere in evidenza eventuali notifiche non lette, che altrimenti andrebbero perse;
  • in futuro si potrebbe pensare di estendere la gestione del proprio profilo tramite applicazione web (es: tipo facebook..), e avere uno storico delle notifiche potrebbe essere utile.

MOBILE APPLICATION SIDE

Per la rappresentazione dei dati è stata creata una classe che gestisce il protocollo di comunicazione con il server. I vari oggetti (controllers) dovranno quindi interfacciarsi a questa per mandare/ricevere dati al server. Il Comunicator è il componente dell'applicazione mobile che ha il compito di effettuare le varie richieste al server e presentare le risposte decodificate ai vari controllers, che provvederanno poi ad aggiornare le view in base ai risultati e ai dati ricevuti dal server. Il seguente diagramma schematizza il flusso di una generica operazione che fa una generica richiesta al server. Esempi:

• Caso di un inserimento di un commento:

L'applicazione recupera da una view il testo del commento che l'utente vuole mandare. Il controller provvede a passare al Comunicator oltre al testo del commento, tutte le altre informazioni necessarie (come ad esempio l'id dello zap a cui il commento si riferisce, l'id dell'utente che lascia il commento, ...). Il Comunicator provvederà quindi ad effettuare la richiesta remota ed informerà l'applicazione del successo o meno dell'operazione.

• Caso di una lettura del palinsesto:

L'applicazione chiederà al Comunicator di effettuare la richiesta. Il Comunicator provvederà a decodificare la risposta ricevuta dal server, e a restituire dei dati contenenti l'elenco dei canali, dei programmi, ..

Tecnologie di riferimento

Per quanto riguarda lo sviluppo delle applicazioni mobile:

• ios sdk
• database interno sqlite
• facebook api

Per quanto riguarda la parte sever:

• linguaggio php
• database mysql
• server lamp
• xmltv, per reperire le informazioni relative i palinsesti
• facebook api

Formato di trasmissione dei dati:

• JSON

Per quanto riguarda il "sito vetrina":

• html5 - css3 - jquery

Sviluppo e Deployment del sistema

Lo sviluppo del sistema è stato suddiviso in due fasi:

• Sviluppo della parte lato server
  • Installazione e configurazione VPS
  • Installazione e configurazione software necessario (client ftp, ssh, XMLTV, Zend, ..)
  • Deployment dei componenti lato server
  • Testing di ogni richiesta verso il db

• Sviluppo della parte lato client
  • Acquisizione delle competente necessarie (Obj-C)
  • Testing delle api di facebook per l'acquisizione dei dati necessari
  • Sviluppo dell'applicazione
  • Testing (ancora in corso) del corretto funzionamento

Principali problemi affrontati

Aggiornamento giornaliero dei palinsesti

Per fare in modo di avere ogni giorno il palinsesto dei programmi relativi ai vari canali aggiornato è stato implementato un cron (PalimpsestUpdater) che viene fatto partire ogni notte, e che ha il compito di recuperare i dati necessari da XMLTV, elaborarli, ed inserire i dati utili nel database del sistema.Lato client, è stato fatto in modo che il palinsesto venga scaricato solo una volta al giorno, cosi da ridurre i tempi di attesa dell'utente e la banda dati utilizzata. Una volta scaricato, il palinsesto viene salvato nel database SQLite interno all'applicazione e, quando l'utente richiede nuovamente di consultare il palinsesto, non verranno fatte richieste al server.Particolarmente tedioso è stato risolvere i problemi legati all'elaborazione dei dati restituiti da XMLTV, in quanto non sempre "formattati" correttamente.

Sicurezza

Essendo il sistema di interazione basato su richieste HTTP, è stato necessario implementare un meccanismo di sicurezza per impedire eventuali richieste non autorizzate che avrebbero permesso ad eventuali soggetti esterni di recuperare e/o modificare "dati personali" degli utenti del sistema. Il sistema è basato su token che vengono generati e controllati ad ogni richiesta.

Backup

Per garantire un veloce ripristino del servizio in caso di attacco/guasto, è stato inoltre predisposto uno script che quotidianamente provvede a fare il backup di tutti i file/cartelle presenti nella vps e del dump del db, e li trasferisce in un secondo server, per poter cosi ripristinare il tutto velocemente.

Conclusioni

Attualmente l'applicazione mobile è in fase di testing. Si prevede di terminare tale fase nel prossimo mese e sottoporla quindi all'approvazione di Apple. Il bacino d'utenza si prevede (e si spera..) sia abbastanza ampio. In caso di riscontro positivo, in futuro si prevede di estendere i servizi offerti attualmente e di proporla anche per la piattaforma Android.