iCulture forum | iPhone, iPad, iPod touch, Apple TV en iOS

iCulture forum | iPhone, iPad, iPod touch, Apple TV en iOS (https://forum.iculture.nl/)
-   Ontwikkelen voor iOS (https://forum.iculture.nl/f133/development/f58/ontwikkelen-voor-ios/)
-   -   Technische beperkingen iPhone / SDK (https://forum.iculture.nl/f133/development/f58/ontwikkelen-voor-ios/82148-technische-beperkingen-iphone-sdk.html)

iBonkers 11-01-11 18:32
Technische beperkingen iPhone / SDK
 
Ik kijk hier al een tijd mee, maar nu toch echt m'n eerste post.

Ik ben onlangs begonnen met het developen van iPhone applicaties. We werken hier op het kantoor met de 80/20 regel, dus 20% van m'n tijd mag ik besteden zoals ik wil. Paar boeken gekocht en gaan met die banaan!

Op het werk hebben we een webapplicatie die we maken en onderhouden. Bij deze applicatie zit een SOAP api. Ik was dus aan het onderzoeken hoe dit het beste kon en kwam er al vrij snel achter dat als het om grote request ging dit niet de meest optimale manier is.

Ik ga hier dus iets voor schrijven dat gebruik maakt van de REST methode. 1 technische hobbel overwonnen dus!

Ik ben een pva/impact analyse aan het schrijven en mijn vraag is nu eigenlijk: zijn er nog meer (technische) beperkingen aan het iPhone SDK en/of hardware die ik mogelijk nog tegen kan komen?

The Unbelievable 11-01-11 18:35
Ik weet niet of je het gaat/kan gebruiken, maar de iPhone kan geen Flash gebruiken/afspelen.

Geno 11-01-11 18:49
Dan vraag ik me af waarom SOAP niet de meest ideale manier is?

iBonkers 11-01-11 18:59
Citaat:
Oorspronkelijk geplaatst door Geno (Bericht 626526)
Dan vraag ik me af waarom SOAP niet de meest ideale manier is?
Citaat:
Requests and responses can be short. SOAP requires an XML wrapper around every request and response. Once namespaces and typing are declared, a four- or five-digit stock quote in a SOAP response could require more than 10 times as many bytes as would the same response in REST.

SOAP proponents argue that strong typing is a necessary feature for distributed applications. In practice, though, both the requesting application and the service know the data types ahead of time; thus, transferring that information in the requests and responses is gratuitous.
http://www.devx.com/DevX/Article/8155/1954

Er zijn uiteraard altijd 2 kanten aan het verhaal, maar met grote request (zoals in het geval bij ons) is elke byte die je kan besparen welkom.

Geno 11-01-11 19:08
Ja, maar dat is niet specifiek gerelateerd aan de iPhone. Het is dus geen beperking van de iPhone of SDK. Dat is nu eenmaal zoals SOAP is ontworpen.

Je moet SOAP ook niet gebruiken voor kleine requests, daar heb je REST voor.

Als je van een web-service slechts kleine hoeveelheden data nodig hebt (de datum bv.), ben je beter af met REST (basic method calls).

Nikooos 11-01-11 19:20
Daarnaast lijkt het me slimmer om te kijken wat je wil bereiken en of de SDK daar de mogelijkheden toe biedt en hoe.

In plaats van eerst kijken wat alle beperkingen zijn, want dat lijkt me de omgekeerde wereld.

Want in principe is alles mogelijk, je moet soms alleen de juiste methode weten.

Whacko 12-01-11 11:28
Als je de app goed bouwt kan je SOAP prima gebruiken hoor. Gewoon alles asynchroon binnen halen, en een mooie "activity indicator" erop.

Mocht je trouwens nog tips nodig hebben voor SDK's:

SOAP: SudzC (alpha) | clean source code from your web services genereert code aan de hand van je wsdl. Volledig asynchroon, werkt prima. Met delegates etc. Maar je moet mogelijk de gegenereerde source wat aanpassen. (niet moeilijk hoor)
RESTKit: https://github.com/benoitc/restkit Erg uitgebreide api.


Alle tijden zijn GMT +2. Het is nu 02:05.