Sebbene l'iPhone supporti JSON in modo nativo, AMF è un protocollo binario e suppone che utilizzi molta meno larghezza di banda. Pensi che usare AMF sia una buona idea?usa AMF invece di JSON su iPhone? (per servizi Web)
appena trovato questa libreria AMF nel cacao (Objective-C): http://github.com/nesium/cocoa-amf/
Ecco il famoso punto di riferimento che mostra AMF è più piccolo e più veloce di JSON + gzip in Flex: http://www.jamesward.com/census/
Palestra detto:
Gli esempi sopra riportati erano in AMF0, ma non credo AMF3 sarebbe molto diverso.
Questo non è vero. AMF3 può causare dati da 5 a 8 volte meno di AMF/JSON. AMF3 raggiunge questo facendo riferimento a ogni singolo elemento che è stato utilizzato una volta. Non solo stringhe. Qualsiasi oggetto, , comprese le chiavi, viene referenziato (con un offset) non appena è stato utilizzato una volta.
Su dataset di grandi dimensioni, fa una grande differenza.
differenza molto importante qui. AM3 dovrebbe essere contrassegnato come la risposta corretta qui ... hmm mi chiedo se posso modificare la risposta? –
Si potrebbe anche provare plist , un formato binario nativo. Qualsiasi formato, incluso AMF o anche plist XML, potrebbe essere ridotto tramite zip. zlib fa parte di iPhone.
thx, ma plist non funziona bene con la maggior parte dei server web. – Henry
Dovresti aggiungere abbastanza dettagli alla tua domanda per chiarire i tuoi requisiti. Domande vaghe ottengono risposte vaghe. Inizialmente, l'unica ragione per utilizzare AMF era ridurre la larghezza di banda, nel qual caso plistare con zip è una scelta migliore. – drawnonward
Capisco, non ho votato la tua risposta. – Henry
Non penso che AMF sarebbe significativamente più piccola di JSON. In effetti, può essere leggermente più grande in molti casi. Mi permetta di mostrare questo in un esempio:
negozi AMF la stringa "asdf" nel seguente formato binario:
0x12 /* type = string */
0x00 0x04 /* length */
'a' 's' 'd' 'f'
/* total: strlen(s)+3 bytes */
mentre i negozi JSON la stringa "asdf" in strlen (s) + 2 byte se ci non ci sono virgolette nella stringa.
negozi AMF l'oggetto JSON {"key1":"asdf","key2":"foo"} nel seguente formato binario:
0x03 /* type = object */
0x00 0x04 /* length of key1 */
'k' 'e' 'y' '1'
0x02 /* value type = string */
0x00 0x04 /* length of value1 */
'a' 's' 'd' 'f'
0x00 0x04 /* length of key2 */
'k' 'e' 'y' '2'
0x02 /* type of value2 */
0x00 0x03 /* length of value2 */
'f' 'o' 'o'
0x00 0x00 0x09 /* end of object */
/* total: 30 bytes, while the JSON string is 28 bytes */
Gli esempi sopra riportati erano in AMF0, ma non credo AMF3 sarebbe molto diverso.
L'unica funzionalità di AMF0 che può ridurre significativamente la larghezza di banda è che contiene un tipo di riferimento: se si invia lo stesso oggetto di grandi dimensioni due volte, il secondo oggetto sarà solo un riferimento alla prima istanza. Ma è un caso raro IMHO (e funziona solo per oggetti, non per archi).
Quindi vorrei raccomandare JSON (se vuoi davvero risparmiare sui byte, puoi comprimerlo con zlib o altro): è molto più semplice da leggere, ci sono molte più implementazioni e le specifiche sono chiare (mentre il Flash l'implementazione a volte è diversa dalla specifica - tutti ci piacciono Adobe;))
INTERESSANTE! Grazie. – Henry
ma non sta trasportando binario su HTTP più efficiente in qualche modo del testo? – Henry
Niente affatto! Forse quello a cui ti riferisci è che i dati testuali di una form_HTML_ sono URL codificati dal browser (ad esempio, sfugge il carattere dello spazio a% 20), il che aumenta la lunghezza. Ma non è necessario inviare i dati in questo modo su HTTP. E comunque, i caratteri testuali sono il sottoinsieme di "caratteri binari" (numeri compresi tra 0 e 255), quindi se invii un testo come dati binari, non può costare più di un "vero" dato binario! (in realtà, può accadere solo il contrario: alcuni protocolli richiedono che i dati siano inviati in caratteri ASCII, quindi i dati binari devono essere decompressi nell'intervallo di 7 bit ...) – gyim
Se si desidera utilizzare un protocollo binario, è possibile dare un'occhiata ai buffer del protocollo di Hessian o di Google. So per certo che l'iuta offre ottime prestazioni su iPhone.
in realtà è una buona domanda e non ho troppo. Ho partecipato a una sessione oggi al WWDC parlando di client/server con iPhone. E continuavano a dirci che i plinary binari erano molto più efficienti di JSON e XML, specialmente quando si trattava di analizzare il tempo. Ma il problema è che sto ancora cercando di trovare qualsiasi implementazione del plist sul lato server come protocollo remoto, mentre AMF ha molte implementazioni sul lato server: WebORB, ZendAMF, BlazeDS, ecc. Quindi, integrando AMF sul lato server è un gioco da ragazzi. Sfortunatamente, dal lato client, l'unica opzione che ho trovato è Cocoa AMF di Nesium, ma sfortunatamente non supporta l'autenticazione del set di canali e manca un generatore di stub sul lato client. Vorrei esaminarlo ma visto che non è un compito da poco e sono sicuro che molti sviluppatori di iPhone hanno già affrontato questo problema, voglio assicurarmi che non ci siano altre opzioni.
Fino ad ora, stavo usando Hessian con HessianKit, ma non supporta l'autenticazione e sta iniziando a essere una limitazione.Apple può dire tutto ciò che vogliono su Flash, ma almeno lo rendono molto facile connettersi a un server remoto.
nessuna implementazione di plist Java ancora? forse è il momento di iniziare un progetto open source. :) – Henry
Dipende certamente dai dati che si stanno trasferendo. Devo creare un'app mini-Census che faccia set di dati più piccoli. :) –
Assicurati di aver letto la risposta @ user562816, AMF3 dovrebbe essere molto più piccolo. –