Discussion :

[masterskp]

Bonjour,

j'ai créé un site web (PHP, Mysql), il y a un moment déjà, et au moment d'ecrire une deuxieme version (surtout avec moins d'erreurs lol), je me suis mis en tete de creer une appli android qui serait liée à mon site. Je ne connaissait rien à java ni à android, donc j'ai beaucoup lu, etc...

Mon site est hébergé en mutualisé sous CPanel et j'ai un double probleme qui a la meme cause.

1 j'ai une applet java qui devait avoir acces à ma DB
2 une appli android qui fait aussi des acces db (select insert update uniquement).

En developpement sur une copie locale de ma db pas de probleme tout fonctionne.

Par contre quand je tente l'acces à ma db hebergée, ça coince pour des raisons de securité. En fait je dois valider à la main dans le panneau de controle les IP autorisées à acceder à ma db. Pas du tout approprié pour des applets ou des apk...

J'imagine que je ne suis pas le premier à avoir ce probleme.

Y a t il moyen de m'en sortir sans changer d'hebergeur ou faut-il aussi prendre un hebergeur java/mysql?

Si je dois changer d'hebergeur, connaissez vous un hebergeur fiable et serieux qui fait à la fois, java, php et mysql et qui ne poserait pas ce genre de probleme?

Les bouquins, la technique c'est bien beau mais on ne parle pas de ce genre de cas. Les gens qui developpent des appli connectées à des DB distantes, comment font ils?


merci de votre aide

[nicroman]

Je ne comprends pas trop.... tu essayes d'accéder directement à la base de donnée ? dans ce cas c'est normal, aucun hébergeur sérieux n'ouvrira un accès direct à une base de donnée depuis internet....

On tombe systématiquement dans le même schema 3-Tier que pour le web:
CLIENT <===> SERVEUR <===> Base De Donnée

Dans le cas du "web", on a:

BROWSER ===(http)===> SERVEUR <==MySQL==> Base De Donnée
<==(html)====

Dans le cas d'une "application" on a exactement la même chose, sauf qu'on ne retourne pas du HTML mais en général quelque chose de plus "parsable" pour le client (JSON, XML, ...)

C'est pour cette raison que j'insiste systématiquement sur le fait qu'une application qui ne fait que de l'accès DB à distance ne *sert à rien*... Puisque "l'application" nécessite d'être toujours "online", autant avoir cette application en HTML directement... Un joli HTML5/AJAX permettra d'avoir une appli "quasi" native sur tous les téléphone du marché.

Par contre, dès qu'on veut pouvoir travailler "offline", ou utiliser les caractéristiques spécifiques des appareils (widgets, alarmes, interaction avec d'autres parties du système,...) alors on part sur une application vraiment native...

[masterskp]

Bonjour,

Merci du conseil. Je pense que je vais devoir explorer un peu dans ce sens, car il est vrai que je ne connais pas les limitations de JSON.

L'idée est de pouvoir interagir entre le site et le smartphone, en utilisant les capteurs disponibles. Par exemple, un utilisateur pourrait prendre une photo et mettre à jour directement le site. Et en meme temps pouvoir consulter les photos que les autres utilisateurs ont deposé sur le site.
Et aussi pouvoir ouvrir une session cam en se servant de la camera frontale de son telephone, sans que l'utilisateur ait besoin de savoir si son correspondant est devant son pc ou devant son telephone. (que ce soit pour du flux direct, ou pour deposer une video sur le site)
Or pour arriver à ça, je dois pouvoir avoir acces à des éléments du style, tel user est connecté ou non à un moment précis...

De plus je ne sais pas si JSON (ou rest dont on m'a aussi parlé) peuvent passer des photos ou des fichiers video, etc...

[nicroman]

De plus je ne sais pas si JSON (ou rest dont on m'a aussi parlé) peuvent passer des photos ou des fichiers video, etc...

JSON et REST sont deux concepts orthogonaux... je suis un fervent pro-REST ^^

D'abord REST n'est pas un "protocole" en soit, c'est la philosophie originelle du protocole HTTP. Session-less, object-oriented.... En HTTP on a les informations suivantes: {VERB} {URI} {PARAMETERS} {HEADERS} {DATA}
En REST ca se traduit par: effectue l'opération {VERB} sur l'objet {URI} avec comme données {DATA} dans le context {HEADERS}.
Le {VERB} peut être un des "verbes" classiques de HTTP: GET (pas de DATA, pas de modification), POST (nouvelles données), PUT (modification de données), DELETE, mais aussi n'importe quoi de sensé, par exemple CHECK, UNCHECK, etc...

La réponse à la commande REST n'est pas "prédéfinie" et peut souvent être modifiée par les {PARAMETERS}...

Exemple:
GET /voitures?filter.places=4&output=json
Va bien récupérer la liste des voitures (GET /voitures), mais en filtrant celles à 4 places, et en sortant le résultat comme du JSON.

GET /voitures?filter.places=4&output=xml
Va faire exactement la même chose avec une sortie en XML.

[nicroman]

Au passage on remarquera qu'il est extrêmement difficile de faire du REST avec PHP...

En effet:

GET /voitures (liste des voitures) => ok
POST /voitures (ajout d'un voiture) => ok
PUT /voitures/### (modification de la voiture ###) => l'URI est variable
DELETE /voitures/### (modification de la voiture ###) => l'URI est variable

et transformer en DELETE /voitures?id=### fait que ce n'est plus du REST (identification par les parametres)