iOS7: impressioni dopo 48h

apple-unveils-ios-7-1
Post veloce che non vuole raccontare per l’ennesima volta quali sono le novità di iOS7, per saperle leggete le recensioni su iSpazio: loro sono molto più precisi e bravi di me.
Scopo di questo post è raccontare le prime impressioni di utilizzo di iOS7.
Questa volta ho aspettato! E ho installato la versione definitiva del nuovo SO di Apple, saltando le fasi beta e GM.
E dopo 48 ore di utilizzo ecco le prime impressioni.

Aspetto grafico
Lo stacco con la precedente è netto. Cambio di stile. Può piacere o non piacere (a me piace) ma è praticamente la prima volta che Apple ridisegna completamente la grafica di iOS. Sempre più uniformata al mondo Windows Mobile, di primo acchito ci si trova un po’ a disagio con le nuove icone. Dopo qualche ora di utilizzo ci si sente a casa.

Control Center e Notification Center
Finalmente anche iOS ha un centro di controllo raggiungibile velocemente che contiene un set di funzionalità utili. Non si comporta esattamente come vorrei, ma non mi dispiace. Inutile il controllo per la musica.
Il notification center è “carino”: avrei preferito la possibilità di personalizzare i widget, mentre questa opzione è limitatissima. Probabilmente preferivo quello della vecchia versione.

Durata della batteria
Con tutte le funzioni che si abilitano di default è praticamente dimezzata. Se si vuole “giocherellare” un po’ con le nuove funzionalità di iOS, vale la pena tenere attiva la possibilità di aggiornamento dei dati, da parte delle applicazioni. Finito il periodo di gioco (a me non è ancora successo 🙂 ) penso si possa disattivare questa funzione che, francamente, consuma batteria senza dare in cambio grossi vantaggi.
A questo link è possibile trovare maggiori informazioni.

Siri
Interfaccia grafica a parte, che secondo me è peggiorata, il motore di Siri è nettamente migliorato. Anche collegato al sistema vivavoce della macchina è un valido aiuto per ascoltare, inviare SMS e email. Oggi anche l’Italiano è ben supportato e non si ha più la spiacevole sensazione di parlare con uno strumento programmato per prenderti in giro e non per aiutarti.

Maps
Mi sembra generalmente migliorato. Sto provando ad utilizzarlo come navigatore per vedere come si comporta.

Multitasking
Finalmente ci siamo riusciti: ci abbiamo messo un po’ ad accorgercene ma alla fine ci siamo persuasi (quelli di Cupertino in modo particolare) che il multitasking dei vecchi sistemi operativi era una roba inutilizzabile.
Scopiazzando da Windows e da Android anche iOS ha una cosa decente e degna di essere chiamata multitasking. Sono servite 7 major version di sistema operativo ma ci siamo riusciti.

Mail
Secondo me è incredibilmente migliorato. Non fa cose spettacolari, ma permette di gestire la propria posta elettronica in maniera comoda.

In generale….
A parte qualche baco, anche serio, ed altri che presumibilmente verranno scoperti mi piace.
Rispetto alle altre versioni è stato stravolto per cui bisogna farci un po’ di abitudine.

Dati pubblici: gli opendata

opendata

Date un po’ di dati ad un informatico e lo fare felice… Almeno questo è quello che succede a me. Avere una base di dati a disposizione mi fa subito pensare a come poterla usare e quale app(licazione) ci si può costruire sopra.

E questo “sfregolo” compulsivo da pressione di tasti mi è venuto quando sono venuto a conoscenza del progetto di Regione Lombardia sugli opendata che, lo ammetto, mi ha stuzzicato non poco la fantasia.

La pubblica amministrazione produce, raccoglie, elabora e diffonde una grande quantità di informazioni: gran parte dei documenti citati nei giornali, la gestione del territorio e dell’ambiente, molti rapporti tra privati e molte attività economiche si basano su informazioni elaborate dalle PA. C’è una quantità incredibile di dati pronta ad essere utilizzata di cui non si conosce l’esistenza.

Il progetto di Regione Lombardia parte proprio da questo presupposto: rendere disponibili in maniera facile ed immediata dati che, dopo una serie di verifiche, possono essere diffusi dalla Pubblica Amministrazione in un’ottica di riuso, secondo quando previsto dalle vigenti leggi (D. Lgs. 36/06 fra tutti).

Prima che un fatto tecnico, è un fatto di trasparenza e di risparmio. Poter riutilizzare per altri scopi, dati raccolti dalla PA (e quindi con denaro pubblico) è un vantaggio per tutti.

I problemi legati all’acquisizione di dati sono molti, fra i quali un ruolo importante è ricoperto dalla facilità di reperimento degli stessi e dalla possibilità di trattarli in maniera semplice.

Si, perché se anche un dato esiste in qualche archivio al quale è impossibile avere accesso, l’utilità dello stesso è nulla (considerazione ovvia ma da farsi).

Prendendo, probabilmente, spunto da queste e da altre considerazioni è nato il progetto degli opendata. Archivi di dati pubblici facilmente accessibili anche mediante protocolli SOAP/XML/JSON e in alcuni casi scaricabili nei formati XLS, CSV.

Nel caso di Regione Lombardia, il portale per l’accesso ai dati, si raggiunge attraverso l’indirizzo htts://dati.lombardia.it.
Sul portale è possibile trovare tutta la documentazione necessaria, la licenza con la quale i dati vengono distribuiti e le procedure/chiamate da fare per ottenerli nei vari formati.

Volete la lista dei luoghi dove è possibile pagare il bollo auto in lombardia? Eccola in formato JSON https://dati.lombardia.it/api/views/yg2u-75d9/rows.json

Il portale è stato realizzato attraverso l’uso della tecnologia di Socrata, azienda di Seattle specializzata nella pubblicazione di dati pubblici.

La licenza di distribuzione è la IOL: Italian Open Data License, creata appositamente per questo scopo. E’ possibile vederne i termini qui http://www.dati.gov.it/iodl/2.0/

Per incentivare l’uso dei dati pubblici è stato bandito un concorso: “OpenApp Lombardia” dedicato ai maggiorenni under 35 che desiderano mettersi in gioco realizzando web app o app per dispositivi mobili utilizzando i dati aperti. Le premesse sono ottime: la fase sperimentale del concorso si è conclusa recentemente e sono state ammesse 111 applicazioni.

Il caso della Regione Lombardia non è isolato. Gli opendata sono una realtà in continua espansione anche a livello nazionale: dati.gov.it è il portale nazionale di accesso. Il numero di basi dati messe a disposizione è in aumento e l’attenzione verso il progetto è alta. Stiamo a vedere.

iPhone 5 fra polemiche e prove sul campo


Vorrei provare a scrivere un articolo che non sfoci in polemica, vorrei provare a direi veramente quali sono state le impressioni d’uso di iPhone 5, dopo una settimana dall’acquisto.

Siamo tecnici, lasciamo perdere i campanilismi e vediamo veramente la parte tecnologica della novità, tutto il resto lasciamolo a chi non ha altri argomenti.

Look & Feel

Lo spessore diminuito, la scocca in alluminio e il pollice in più di schermo, si fanno sentire. La consultazione del calendario è più agevole e tutto sembra che abbia acquistato più spazio, anche se non è così.

Il peso è notevolmente diminuito. Il telefono, una volta fuori dalla scatola, va messo in una custodia: il retro in alluminio da l’impressione di essere delicatissimo e di graffiarsi al solo contatto della tela dei jeans.

Processore
E’ il piattoforte! Tutto risulta terribilmente veloce e fluido. Di studio ne hanno fatto. Usato in maniera pesante fa crollare terribilmente la durata della batteria.

Mappe
C’è spazio per il miglioramento. Il posizionamento sulla mappa è impreciso, capita facilmente di essere in strada e trovarsi mappati all’interno di edifici. In centri piccoli come il mio, il grado di immaturità delle mappe si fa sentire.
Buona la navigazione turn-by-turn, sostituisce di fatto i vari navigatori.
La visualizzazione in 3D, nelle zone appositamente mappate, è uno spettacolo. Il processore da il meglio di se stesso. Con l’inevitabile conseguenza di vedere drasticamente ridotta l’autonomia della batteria ed incredibilmente aumentato il consumo di traffico dati.

Integrazione con Google
Apple e Google devono aver litigato! Se l’account email è configurato come Google nativo, spariscono completamente le notifiche push sull’arrivo delle email.
Tra le opzioni di recupero delle email, sparisce completamente il recupero in modalità fetch per questo tipo di account!
Soluzione: configurare l’account Google in modalità Microsoft Exchange ed abilitare le notifiche nel centro di controllo.
Come se non bastasse, per qualche giorno i miei google calendar non erano disponibili sul telefono. In questi giorni sono misteriosamente ricomparsi.
C’è sicuramente bisogno di un patch.

Fotocamera
Buona la possibilità di fare foto con scarsità di luce. Non sono ancora riuscito a riprodurre il fenomeno degli aloni viola. Viste le dimensioni dell’obiettivo, non escludo che la cosa possa essere riscontrabile, come poteva del resto esserlo sugli altri telefoni della Apple (e su molti altri).
La qualità fotografica è generalmente migliorata.

Siri
E’ un bel giocattolo. Si intravede la possibilità di fare delle cose interessanti. Scrivere appuntamenti e aggiungere promemoria quando si guida è decisamente comodo. Dettare SMS e email non è così semplice, con un po’ di impegno ci si riesce.

Una zuppa….fantastica (a beautiful soup)

Dovrei aprire una sezione del blog che si chiama ‘il software salva…’ si, proprio quello!
Scenario: script in Python che prende i dati da un database, li normalizza e li inserisce nel backend di un’applicazione per mobile. I dati nel DB di provenienza sono scritti da un CMS, fra le altre cose sono farciti di tag HTML. Che fare? Prima della normalizzazione bisogna togliere tutti i tag. Una breve ricerca su google ed ecco trovata Beautiful Soup una classe Python che serve a fare il parsing di HTML e XML.
“Rubo” gli esempi della documentazione per dare l’idea di quanto potente sia. Prendiamo del testo con tag HTML:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
from bs4 import BeautifulSoup
soup = BeautifulSoup(html_doc)

html_doc = """
<html><head><title>The Dormouse's story</title></head>

<p class="title"><b>The Dormouse's story</b></p>

<p class="story">Once upon a time there were three little sisters; and their names were
<a href="http://example.com/elsie" class="sister" id="link1">Elsie</a>,
<a href="http://example.com/lacie" class="sister" id="link2">Lacie</a> and
<a href="http://example.com/tillie" class="sister" id="link3">Tillie</a>;
and they lived at the bottom of a well.</p>

<p class="story">...</p>
"""

Vogliamo estrarre tutti gli anchor che contiene? Ecco come:

1
2
3
4
soup.find_all('a')
# [<a class="sister" href="http://example.com/elsie" id="link1">Elsie</a>,
#  <a class="sister" href="http://example.com/lacie" id="link2">Lacie</a>,
#  <a class="sister" href="http://example.com/tillie" id="link3">Tillie</a>]

Vogliamo i soli link? Ecco come:

1
2
3
4
5
for link in soup.find_all('a'):
    print(link.get('href'))
# http://example.com/elsie
# http://example.com/lacie
# http://example.com/tillie

E, alla fine, ecco il mio caso: vogliamo togliere tutti i tag HTML? Ecco come:

1
2
3
4
5
6
7
8
9
10
11
12
print(soup.get_text())
# The Dormouse's story
#
# The Dormouse's story
#
# Once upon a time there were three little sisters; and their names were
# Elsie,
# Lacie and
# Tillie;
# and they lived at the bottom of a well.
#
# ...

Ma fa solo questo? No, fa molto di più, basta dare un’occhiata al sito per accorgersene.

comandi drush

Post veloce.
Ecco una lista dei comandi di drush che uso più frequentemente con la relativa spiegazione

Eseguire il dump del DB:

1
drush sql-dump > dump.sql

Svuota tutte le cache di Drupal

1
drush cc all

Esegue l’update dei moduli installati

1
drush up

Scarica la nuova versione di drush e lo mette nella home dell’utente fizban (crea in automatico la directory drush)

1
drush dl drush --destination=/home/fizban/

Uninstall di un modulo

1
drush pm-uninstall media_internet

Esegue le operazioni di cron

1
drush --root=/directory/del/sito --uri=www.ilsito.it --quiet cron

Che, se messo nel crontab diventa

1
10 * * * * /usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin COLUMNS=72 /usr/local/drush/drush --root=/directory/del/sito --uri=www.ilsito.it --quiet cron

Fare backup con uno script in bash

Non inizio il post dicendo che fare il backup è importante. Lo sappiamo…..

Lo inizio dicendo che ci sono 1.000 metodi per farlo. Come al solito molto dipende da quali dati dobbiamo mettere sotto backup, qual’è la frequenza di aggiornamento delle informazioni ecc, ecc.

Al backup ci si potrebbe dedicare un libro.

In questo post, proveremo a vedere come fare un semplice backup di un sito web (realizzato con Drupal o con MySQL + PHP) con frequenza giornaliera.

Nel caso il sito sia stato realizzato utilizzando Drupal possiamo usare DRUSH per fare il dump della base di dati.
Di seguito lo script

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#! /bin/sh

# configurazioni
#
#

# posizione di drush
DRUSH=/home/fizban/drush/drush

#directory www
WWW_DIR=/var/www/miosito

#dove mettere il file di backup
BCK_FILE=/home/fizban/backup/miosito

# inizio
#
#

cd $WWW_DIR

#crea la directory per il dump del SQL
mkdir -p $WWW_DIR/SQLDump

# esegue il dump del DB
$DRUSH sql-dump > SQLDump/dump.sql

# fa un tar.gz di tutta la directory HTML + SQL
tar cvfz $BCKFILE_`date +%F`.tar.gz $WWW_DIR

# cancella il file del dump
rm $WWW_DIR/SQLDump/dump.sql

## cancella i file più vecchi di 3 giorni dalla directory dei backup
find $BCK_FILE -type f -mtime +3 | xargs rm

Da notare la riga:

1
tar cvfz $BCKFILE_`date +%F`.tar.gz $WWW_DIR

Che crea un file ed aggiunge nel nome la data di esecuzione del backup.

In fine la riga:

1
find $BCK_FILE -type f -mtime +3 | xargs rm

Che ricerca nella directory dei backup file più vecchi di 3 giorni attraverso il comando find.

Infine l’uso di xargs, invece, permette di richiamare il comando ‘rm’ passandogli come argomento il nome dei file selezionati da find.

Se non abbiamo a disposizione drush (sia perché il sito non è stato fatto con Drupal o perché drush non è stato installato) possiamo modificare lo script nel seguente modo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
#! /bin/sh

# configurazioni
#
#
# posizione di drush
DRUSH=/home/fizban/drush/drush

# MySQL
MYSQLDUMP = /usr/bin/mysqldump          # posizione di MySQL
MY_USER = "username"                    # MySQL username
MY_PWD = "password"                     # MySQL password
MY_DB = "database"                      # Database MySQL da salvare

# directory www
WWW_DIR=/var/www/miosito

# dove mettere il file di backup
BCK_FILE=/home/fizban/backup/miosito

#
# inizio
#

cd $WWW_DIR

#crea la directory per il dump del SQL
mkdir -p $WWW_DIR/SQLDump

# esegue il dump del DB
$MYSQLDUMP $MY_DB -u $MY_USER --password=$MY_PWD > SQLDump/dump.sql

# fa un tar.gz di tutta la directory HTML + SQL
tar cvfz $BCKFILE_`date +%F`.tar.gz $WWW_DIR

# cancella il file del dump
rm $WWW_DIR/SQLDump/dump.sql

## cancella i file più vecchi di 3 giorni dalla directory dei backup
find $BCK_FILE -type f -mtime +3 | xargs rm

Node.js: qualche considerazione

In un precedente post mi ero divertito a giocare un po’ con node.js. Si giocare è il termine giusto, ho provato a leggere qualche tutorial, installarlo e scriverci 10 righe di codice.
node.js logoL’idea che sta alla base del progetto è sicuramente interessante, creare un server performante e totalmente adattabile sulle esigenze del software che stiamo scrivendo. Bello anche il fatto che il server non venga appesantito da moduli che potrebbero essere solo potenzialmente usati: se il codice non utilizza primitive di un modulo, questo non viene caricato. Come dire, rispettiamo al massimo il concetto che “quello che non c’è non si rompe”.

Ma alla base del progetto c’è qualcosa che non mi convince. Partiamo dal presupposto che il server web è il software più esposto ai vari attacchi: è quello che sta proprio in frontiera, tutte le chiamate vengono in prima istanza gestite dal questo software. Se oggi usiamo Apache nella maggior parte delle installazioni, lo facciamo perché il software è sopravvissuto ai vari attacchi e alle varie traversie che, la storia insegna, hanno colpito questa categoria di software. Apache è stato creato a forza di “pezze” (‘a patchy’) messe su NCSA httpd.

Ma in generale tutta l’architettura LAMP ha una storia di successi ed insuccessi, che l’hanno portata ad essere quella che conosciamo tutti. Una della caratteristiche principali di questa architettura è che i vari compiti sono svolti da pezzi diversi di software. Pensiamo al semplice interprete PHP, la storia delle pagine dinamiche è vecchia come l’informatica. Abbiamo iniziato con i CGI e poi con la tecnologia SSI (Server Side Include), e alla fine la tecnologia che si è affermata è quella delle pagine dinamiche
I linguaggi più utilizzati per scrivere pagine dinamiche, oggi, sono: VBScript, Java, PHP e JavaScript.

In tutti questi casi la separazione fra il server web e l’interprete dei comandi è netta. Le ottimizzazioni di performance e di sicurezza sono in carico ad almeno due software diversi. Software scritti da gruppi di lavoro diversi.

In Node.js tutte queste cose sono fuse in un solo software che serve pagine statiche, elabora script… forse gli stiamo dando un po’ troppa responsabilità!

Qual’è il vero guadagno nel mettere in campo questa nuova tecnologia? La scalabilità? Penso che Apache e PHP abbiano dato prova più volte di essere scalabili senza grossi problemi. Le performance? Se Apache vi sembra troppo pesante provate a dare un’occhiata a lightttpd Pensate che il vostro sito web debba servire 10.000 client contemporaneamente (il problema del C10K)? Provate a dare un’occhiata a nginx che serve pagine per sitarelli dalle dimensioni di GitHub, WordPress.com, SourceForge.
L’idea di creare un server web ‘event driven‘ è vincente: nginx ne è la prova. Node.js aggiunge il fatto di implementare in maniera asincrona i meccanismi di lettura e scrittura (Asynchronous I/O).

In definitiva, mi piace Node.js come progetto. Bella l’idea di dare a JavScript un posto un po’ più importante rispetto a quello di abbellire qualche pagina HTML. L’architettura di Node.js è ben pensata e in fatto di scalabilità promette bene. Mi spaventa un po’ la sicurezza intrinseca del prodotto e il fatto che lo studio e l’introduzione di questa nuova tecnologia in ambiente di produzione, non porta nessuna grossa novità.

node.js: un’introduzione

node.js logo
Per chi ancora non ne avesse sentito parlare, Node.js è un framework per l’utilizzo server-side di JavaScript, implementato su un motore JavaScrpit (il V8) scritto da Google.

Secondo gli sviluppatori del progetto, il linguaggio scelto è particolarmente adatto per gestire un web server, perché basato sugli eventi. Christopher Roach, in un suo articolo, sottolinea ad esempio come un server web trascorra la maggior parte del tempo ad aspettare l’esito di operazioni di I/O, quindi la possibilità di lavorare in modo asincrono tramite le funzioni di callback è una grande opportunità per aumentarne l’efficienza.

L’architettura di Node.js è modulare. Vi sono diversi moduli per compiere le funzioni più comuni di un server web. Questi possono essere utilizzati previa inclusione nel codice con il comando require:

1
2
var http = require("http"),  
    sys = require("sys");

Queste due istruzioni includono due moduli: il primo che implementa le funzioni per la comunicazione via HTTP mentre, il secondo, implementa il modulo per la comunicazione via terminale.

A questo punto possiamo creare il server con il metodo createServer, al quale possiamo passare delle funzioni anonime, che si attiveranno ogni qualvolta esso riceverà una richiesta dalla porta passata al metodo listen:

1
2
3
4
5
http.createServer(function(request, response) {  
    response.sendHeader(200, {"Content-Type": "text/html"});  
    response.write("fizban was here!");  
    response.close();  
}).listen(8080);

In questo brevissimo esempio, tratto da un tutorial di Devon Govett, viene creato un server in ascolto sulla porta 8080, che manda una risposta via HTTP con un header e codice HTTP 200.

Come è ormai tradizione consolidata, nei nostri progetti non utilizzeremo direttamente le API di Node.js. L’ecosistema che sta attorno al progetto ha creato una serie di framework che semplificano e velocizzano la scrittura di codice.

express.js è una conoscenza che dovrà fare chi è interessato a scrivere applicazioni webbased. Dalla filosofia molto simile a quella di Rails, express è un framework in sviluppo attivo molto utilizzato.
Fra le caratteristiche principali:

  • Supporto delle route (alla Rails)
  • Basato sulla logica MVC
  • Sviluppato per alte performance
  • Le configurazioni sono basate su ambienti (sviluppo, produzione, test….)
  • E’ dotato di eseguibili per la generazione delle applicazioni in modo veloce

Ecco l’esempio di prima, riscritto utilizzando express:

1
2
3
4
5
6
7
8
var express = require ('express');
var app = express.createServer();

app.get('/', function(req, res){
    res.send('Fizban was here');
});

app.listen(8080);

Express non è l’unico framework attivamente sviluppato, la lista è lunga. Guardando sul wiki di node.js c’è veramente da stupirsi vedendo quanta gente ha già implementato moduli. L’ecosistema che sta attorno al progetto è molto attivo.
Una chicca, vi piace la logica di Ruby on Rails ma non vi piace Ruby? Railswaysjs è modulo che fa per voi

Dove reperire informazioni:

  • Sul sito ufficiale di node.js
  • HowToNode blog con vari howto per realizzare progetti con Node.js

ios-static-libraries: librerie crittografiche pronte all’uso

Stanchi di cercare online le versioni di:

per i vostri progetti sugli iDevices per poi doverveli compilare? ios-static-libraries è il progetto che fa per voi. O meglio questo è il progetto che ha fatto per me 🙂

Il progetto fornisce:

  • uno script per la compilazione delle librerie citate
  • i binari delle stesse librerie pronti per essere utilizzati nei propri progetti

Consumare webservice in ObjectiveC

Scrivendo applicativi per mobile può succedere facilmente di dover accedere a webservice. Nativamente iOS non mette a disposizione primitive ad alto livello per farlo, ma ci sono una serie di librerie sviluppate da terze parti che permettono di utilizzarli senza nessun problema.

Le primitive messe a disposizione dalla Apple sono un po’ troppo a basso livello, sulla rete ci sono molti progetti che le usano per scrivere librerie che permettano allo sviluppatore di accedere ai dati in maniera molto più semplice.

Lo scenario classico è questo: dobbiamo accedere ad un servizio mediante http(s). Il formato di ritorno è un JSON opportunamente formattato.

Per l’esempio possiamo usare i dati prodotti da quest’altro post nel quale si parlava di come fare chiamate REST in PHP.

Iniziamo facendo la chiamata al webservice. Sia che debba fare una chiamata REST, o che ne debba fare una classica passando parametri in GET o POST, normalmente al progetto aggiungo la libreria ASIHTTPRequest che, come dice il nome, permette di fare richieste in HTTP.
A differenza delle primitive messe a disposizione da ObjectiveC, ASIHTTPRequest ne implementa altre a livello più alto che rendono molto più semplice fare request in HTTP.

Tornando al nostro esempio: questa è la chiamata che dobbiamo fare:

1
http://webservices.corradoignoti.it/nomeservizio/showAllArticles

Ammettendo che la risposta sia di solo testo (nel nostro caso è un JSON) e che la velocità di download sia tale da permettere l’esecuzione della request in foreground, questa lo stralcio di codice da usare:

1
2
3
4
5
6
7
8
9
10
- (IBAction)getStringFromURL:(id)sender
{
NSURL *url = [NSURL URLWithString:@"http://webservices.corradoignoti.it/nomeservizio/showAllArticles"];
ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url];
[request startSynchronous];
NSError *error = [request error];
if (!error) {
NSString *response = [request responseString];
}
}

Se non si sono verificati errori, alla fine delle chiamata la variabile response conterrà il JSON di risposta del server.
E’ possibile eseguire la stessa chiamata ma in background, utilizzando questo codice:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
- (IBAction)getStringInBackgroundFromURL:(id)sender
{
NSURL *url = [NSURL URLWithString:@"http://webservices.corradoignoti.it/nomeservizio/showAllArticles"];
ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url];
[request setDelegate:self];
[request startAsynchronous];
}

- (void)requestFinished:(ASIHTTPRequest *)request
{
NSString *responseString = [request responseString];
}

- (void)requestFailed:(ASIHTTPRequest *)request
{
NSError *error = [request error];
}

La documentazione di ASIHTTPRequest può essere recupera sul sito della libreria, nella sezine “How to use

In entrambi i casi responseString conterrà il JSON di risposta del servizio, per esempio questo:

1
2
3
4
5
6
7
{
"id": "3",
"type_id": "1",
"protocollo": "26137",
"oggetto": "Bando affidamento fornitura carburanti.",
"testo": "Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper     suscipit lobortis nisl ut aliquip ex ea commodo consequat."
}

Anche per questo compito ci sono mille soluzioni. Nel caso di Tweetee, per fare il parse delle risposte di Twitter, ho optato per json-framework. Libreria molto snella, che permette di accedere alle informazioni contenute in JSON come se si trattasse di dizionari di Objective-C.

Che si traduce in qualcosa di simile a questo:

1
2
3
4
5
6
7
8
9
10
- (NSDictionary *) parseJSONData:(NSData *)data {

SBJSON *jsonParser = [SBJSON new];
NSString *jsonString = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
NSDictionary *dict = (NSDictionary*)[jsonParser objectWithString:jsonString];
[jsonString release];
[jsonParser release];

NSString *testo = [dict objectForKey:@"testo"]
}