Sviluppo mobile cross-OS con .NET
Ultimamente mi sto cimentando nella programmazione per sistemi operativi mobile. In particolare, insieme ad un mio carissimo amico, stiamo tentando di concretizzare qualche progettino destinato al mercato degli smartphone.
Nella progettazione di queste soluzioni (beh si, non guardatemi male, io di solito inizio dalla progettazione e non scrivendo direttamente codice) abbiamo identificato la seguente architettura:
- Web Service esposti sul web contenti la logica di business
- Database server sul web server
- Applicazione mobile che richiama i servizi e si occupa essenzialmente della visualizzazione dei risultati e di gestire la UI
A questa organizzazione del lavoro, siamo giunti dopo aver analizzato i seguenti aspetti:
- Inserire la logica lato server ci permette di rendere il servizio disponibile su più tipologie diverse di client, cioè essenzialmente su più piattaforme
- Inserire la logica lato server ci permette di semplificare al massimo la logica lato client
- Inserire la logica lato server ci permette di programmare la logica in C# usando .NET, il che, fidatevi, è un enorme vantaggio
Il terzo punto in particolare va sottolineato perché se, come abbiamo intenzione di fare noi, si vogliono realizzare applicazioni su iPhone e iPad, è necessario imparare l'objective-c e buona parte della libreria Cocoa. Considerando che gran parte delle applicazioni per smartphone che riportano informazioni, lo fanno parserizzando selvaggiamente pagine HTML, volete mettere quando è semplice farlo utilizzando le API di .NET rispetto al SDK di iOS?
In realtà stiamo valutando anche la possibilità di scrivere le applicazioni lato client in C# utilizzando Monotouch. Questo ci permetterebbe di rendere l'applicazione facilmente "portabile" anche su Windows Phone 7 e, contestualmente, semplifica non poco effettuare operazioni come le chiamate ai web service che su iOS vanno praticamente costruite a manina. Pensate che nella roadmap di Mono è previsto perfino Monodroid per lo sviluppo in C# per Android :-)
8 commenti
L said
Mi piace questo post! :D
Fabio Zambetta said
Vai Raffaele,
Mono FTW! :-)
Ho avuto modo di provare Monotouch e devo dire che ne sono rimasto positivamente impressionato: per fortuna non e' piu' "fuori legge" (la Apple e' proprio assurda a volte) e quindi ha un futuro abbastanza roseo (l'idea di Android e' ottima e c'era gente che giustamente faceva notare come C#/Mono sarebbe meglio di Java su Android tout-court.
Tutto sommato ormai la Sun e' solo un nome e Java e', tecnologicamente parlando, vecchio sotto molti punti di vista.
Invece C# (via Mono o il CLR MS) e' moderno ed efficiente (basta provare Unity per rendersi conto di come persino videgiochi possano essere interamente scriptati in C#) ;)
Vifani said
Ciao carissimo, hai perfettamente ragione. C# è un linguaggio che ha avuto un'evoluzione incredibile e ci sono formalismi come le lamba expression e API come il DLR che lo rendono elegante ed estremamente flessibile.
Nicola Lozito said
Pero' sei di parte! :)
Battute a parte il discorso fila alla grande e ovviamente condivido praticamente tutta la linea. Poter massimizzare in campi molteplici lo stesso skill poi e' una manna dal cielo, minimizza tempi e costi, mica poco.
Mario said
Ricordo che ai tempi dello sviluppo con Windows CE (altri tempi) mettere più roba possibile sul server (o rendere più stupido possibile il terminale) era un must per riuscire a debuggare l'applicazione in tempi compatibili con la vita umana ;)
Nicola Lozito said
Beh la "stupidita'" del terminale e' da sempre un must, frenata solo - a mio modo di vedere - dalla poco capillare diffusione della connessione internet (always on o always-available). Se si da' per scontato quella allora si puo' instupidire del tutto il client (o quasi, chiaro che siamo sul generale) ;)
Luigi Navarra said
In effetti è un mercato interessante (ho sentito voci non personalmente verificate di un giro d'affari mondiale di circa 3 miliardi di euro lo scorso anno), l'idea di una architettura come quella descritta da Raffaele e senz'altro la più ragionevole ma sono d'accordo con quanto dice Nicola sulla disponibilità della connessione. Ad ogni modo se non ci rifacciamo ad un mercato esclusivamente locale e considerando le proiezioni di crescita dell'accesso alla rete di questi dispositivi senz'altro la appoggio. Sicuramente ci saranno della applicazioni che per la loro stessa natura devono essere pensate come stand-alone....immaginate una applicazione client-server che calcola i giorni di fertilità della vostra compagna quando siete in riva al mare e senza segnale :D :D :D
Vifani said
E' chiaro che l'architettura proposta vale per applicazioni informative che basano la loro utilità sul dare immediatamente disponibili informazioni che solitamente si sarebbe dovuto ricerca su internet con molti più passaggi. Oltre al fatto che è possibile definire molte funzionalità in più (immagino alle notifiche Push nel caso in cui i dati cambino in un modo tale da essere utile per l'utente conoscere tale cambiamento).
Un'applicazione come quella che dici tu Luigi fortunatamente per chi l'ha programmata, non ha di questi problemi... ma altri... tipo sbagliare il calcolo e far passare i guai alla coppia :D :D :D