Soluzioni consigliate per l'integrazione di iOS con .NET, al livello di servizio

Le applicazioni iOS girano su dispositivi vincolati, che è la prima cosa da tenere in mente. Questi dispositivi vincolati sono in realtà abbastanza efficienti, ma considera quanto segue:

• XML non è banale da analizzare. Se le richieste sono piccole e il carico utile dei dati non è strutturato, non c'è alcun beneficio inerente all'utilizzo di SOAP.
• Apple ha ragionevolmente stabilito grandi aspettative su quanto sia reattivo un'applicazione web vincolata, l'elaborazione deve essere molto veloce.
• Domanda per te: iOS ha un buon supporto SOAP, o devi eseguire il rollover?
• I servizi di stile REST (ad esempio semplici richieste / post HTTP con risposte XML, JSON o di testo normale) sono in genere di basso impatto e facili da codificare su client e server.
• Come intendi / hai bisogno di implementare la sicurezza?

Ciascuno di questi punti e domande può aiutarti a trovare la risposta giusta per la tua applicazione. Non ne so abbastanza dell'API iOS per parlare del supporto per la messaggistica basata su SOAP, ma è qualcosa che devi considerare. C'è qualcosa di intrinsecamente sbagliato in SOAP? Non necessariamente, ma in alcuni casi è come cercare di uccidere una vespa con un martello. Otterrà il lavoro ma il danno collaterale è significativo.

Avrai bisogno di qualcosa che sia facile da invocare ed elaborare sulla tua piattaforma di destinazione. Questo principio non cambia se decidi improvvisamente di fare app Android oltre alle app iOS. La tua conclusione potrebbe cambiare, ma il ragionamento per arrivare a quella risposta sarà lo stesso.

In qualità di sviluppatore .NET con diverse app iOS (alcune delle quali utilizzano un back-end .NET), sconsigliamo di utilizzare i servizi Web SOAP a meno che non si abbiano esigenze molto specifiche che possono essere soddisfatte solo mediante l'utilizzo. p>

Se la domanda è solo il trasferimento dei dati avanti e indietro, ti suggerisco di utilizzare JSON poiché è quasi al 100% di dati e molto facile da scrivere e analizzare. A seconda dei tuoi dati, potresti scoprire che l'utilizzo di XML complica la dimensione (e quindi il ritardo) di ottenere i tuoi dati a livelli inaccettabili. Ciò che potrebbe non essere visibile su un PC multicore può spesso non essere pratico su un dispositivo mobile. Sfortunatamente, anche se il dispositivo è molto meno capace, gli standard delle persone sono in genere anche superiori.

Quello che ho fatto è creare una pagina ASPX che analizzi i parametri della stringa di query per determinare la richiesta e poi scrive nuovamente nel flusso di risposta un file JSON. In effetti, in un caso, il server ha colpito un feed RSS, estrapola l'XML e lo inserisce in un formato JSON (memorizzato nella cache locale) prima di restituirlo al dispositivo solo per accelerare il processo.

Questo processo è in realtà molto semplice sia dal server che dalle prospettive di sviluppo dell'app. Questo potrebbe non funzionare per la tua situazione, ma funziona molto bene per me.

JSON o POX è probabilmente l'opzione migliore. E c'è un bel po 'da dire solo per servire il JSON su IHttpHandlers dedicati o su una semplice app ASP.NET MVC. Ma potresti anche usare i collegamenti WCF e webHttp se ti senti più a tuo agio.

iOS dici ... quindi un'applicazione mobile? Quali sono le probabilità che la tua app un giorno venga trasferita su Android, RIM, WP7 o altri client ancora da inventare?

Cercherò di rimanere agnostico sul client dove possibile, quindi il mio istinto sarebbe quello di andare per un API REST restituendo XML e / o JSON. Non escluderei WCF, ha un ottimo REST stry al giorno d'oggi, ma avendo usato ASP.Net MVC per un paio d'anni, lo vedrei per primo.