Snelle versie:
Gebruik een tussenlaag van een webservice die draait op een openbare host die u beheert (mogelijk, maar niet noodzakelijk de databasehost). Stel openbare webservicemethoden bloot om het beperkte werk te doen dat u wilt toestaan en niets anders.
Verwante vragen:
- Driver JDBC PostgreSQL met Android
- Hoe verbinding maken met een PostgreSQL-server via JDBC in Android?
Implementatie-opties
Persoonlijk zou ik een Java-toepassingsserver gebruiken zoals Apache Tomcat of JBoss AS 7 en ik zou mijn webservicemethoden schrijven met behulp van JAX-RS om een mooie API in REST-stijl te produceren die mijn app kan gebruiken. Dat is waar ik bekend mee ben en het werkt goed, maar je hebt veel opties, waaronder implementaties van:
-
REST-achtige API's (Java's JAX-RS impluleert Jersey en RESTEasy, verschillende andere langs-tools) die HTTP-verzoeken gebruiken en JSON- of XML-antwoorden produceren.
-
SOAP met WSDL, de klassieke "webservice"-laag. In Java gedaan met onder andere JAX-WS. De meeste talen hebben tools voor SOAP+WSDL, maar het is nogal waardeloos om mee te werken, vooral op af en toe verbonden apparaten zoals mobiele telefoons.
-
XML-RPC als je van pijn houdt
Er zijn enkele JAX-RS quickstarts op de JBoss AS 7 quickstarts lijst; zoek gewoon naar "JAX-RS". De " " quickstart is handig, maar misschien niet ideaal als je niet bekend bent met de basis van JBoss AS 7 en Jave EE 6. Voor de JAX-RS-specificaties ben je beter af met een Jersey- of RESTEasy-tutorial zoals dit of dit .
Belangrijke overwegingen
Gebruik indien mogelijk HTTPs en als de toegang niet openbaar is, gebruik dan een geschikt HTTP-authenticatieschema zoals HTTP Basic auth over HTTPs. Elke fatsoenlijke implementatie van webservices biedt authenticatie-opties of ondersteunt die van het platform waarop het draait. Weersta de verleiding om uw eigen authenticatie en gebruikersbeheer te implementeren op de webservicelaag, u zal het verpesten; gebruik de auth op de HTTP-laag die al is geschreven en getest. Dit vereist mogelijk het gebruik van iets als Apache's mod_auth_pgsql , JBoss AS 7's JDBC-beveiligingsdomeinen, enz. Het enige geval dat ik zou overwegen om niet de juiste HTTP-authenticatie per gebruiker uit te voeren, is waar ik mijn gebruikers om veiligheidsredenen niet hoef te scheiden, het kan me alleen schelen dat het mijn app is die toegang heeft tot de server , dat wil zeggen als mijn beveiligingsvereisten vrij zwak zijn. In dit geval zou ik een vaste gebruikersnaam/wachtwoord gebruiken voor de hele app en mogelijk een X.509-clientcertificaat als Android ze ondersteunt.
Onthoud dat, ongeacht hoe u dingen beveiligt, alle inloggegevens bekend zijn bij de gebruiker of triviaal kunnen worden geëxtraheerd uit een .apk, dus u moet er nog steeds van uitgaan dat iedereen toegang heeft tot uw webservicemethoden, niet alleen uw app. Schrijf ze dienovereenkomstig.
Doe niet stuur SQL vanuit uw app via een webservice-aanroep naar de server en retourneer de resultaten als JSON. Dit is afschuwelijk onzeker, maar ook lelijk en onhandig. Schrijf een webservicemethode voor elke afzonderlijke taak die u door de app wilt laten uitvoeren en bewaar de SQL op de server. Denk eraan om geparametriseerde queries te gebruiken en wees voorzichtig met andere SQL-injectierisico's. Deze webservicemethoden kunnen een of meer zoekopdrachten gebruiken om een enkel antwoord te produceren - u kunt bijvoorbeeld een 'Klant'-record en alle bijbehorende 'Adres'- en 'Contact'-records verzamelen en het resultaat retourneren in een mooi JSON-object op het Android-apparaat kan verbruiken, waardoor talloze trage en onbetrouwbare netwerkrondreizen worden bespaard.
Wat u ook gebruikt, zorg ervoor dat u uw webservice-aanroepen in een achtergrondwerkthread doet en de gebruikersinterface niet blokkeert. Wees voorbereid op time-outs en fouten, en op de noodzaak van nieuwe pogingen. Test uw app door intermitterend verbindingsverlies, hoge latentie en hoge mate van pakketverlies te simuleren en zorg ervoor dat deze bruikbaar blijft.