Application Android

[Azema]

J'aime bien cet échange car tu poses de bonnes questions.

Il serait surement très intéressant et constructif d'envoyer un mailing aux responsables de clubs, ainsi qu'aux responsables de ligues et de la fédération afin de leur expliquer le projet et de connaitre leurs besoins.

Je m'occupe de rassembler leurs coordonnées, écrire le mailing et de leur envoyer.

Par contre, je pense qu'il va falloir attendre un moment avant d'avoir un nombre de réponses suffisantes pour croiser les demandes.

Si tu as une idée du contenu du mailing, je suis preneur

En plus, j'ai l'application qui permet de réaliser les envois de mailings.

[jeje84-modelisme]

Tu devrais contacter vr84160 (Vincent Reynier), c'est lui qui créé le site de classement de ligue pour la FFVRC.
Il pourrait peut-être te donner des infos, des suggestions ...
http://www.ffvrc.fr/Ligues/classements.htm
http://www.ffvrcweb.fr/classements/

[Azema]

Salut jeje84-modelisme,

Je l'ai déjà contacté et il avait l'air d'être enthousiasmé par l'idée. Il doit normalement jeter un oeil au projet. Je devrais peut être l'invité à participer à ce post.

Merci pour l'info

[vr84160]

Effectivement je trouve ce projet très intéressant.

J'ai lu ce poste depuis ce matin et je trouve que les échanges y sont très enrichissants.

En effet il faut voir si les clubs et les ligues seraient motivées pour s'investir dans ce type de communication. Si tel est le cas cette application peut être un premier pas vers un lieu (site ou appli) où l'on peut trouver toutes les informations utiles. De plus je pense que cette initiative pourrait contribuer à la connaissance de ce sport auprès du grand public, ce dont nous avons grandement besoin !

Il est indéniable que nous avons du retard pour ce qui est de la communication et de l'utilisation d'internet. Mais le nouveau comité directeur de la FFVRC est conscient de ce problème et nous y travaillons activement

[jeje84-modelisme]

juste qqs questions :

- Si j'ai bien compris la première chose que tu veux faire est le développement de l'API, qui ensuite serra utilisé par les applications Android, IOS, WP7/8, BB10, Appli web...

- Quel est le langage de l'API ?

- Pourquoi du JSON et pas de l'XML ?

[Azema]

Effectivement, il s'agit bien de développer une API en premier.

Cette API servira au BackOffice Web pour commencer avec des droits d'écriture.

Ensuite, n'importe qui (ayant l'autorisation bien entendu) pourra utiliser les données pour les afficher, donc accès en lecture seule.

L'application Android sera une des applis, qui utilisera l'API pour obtenir et afficher les données, avec un peu plus de droits.

Le format de sortie n'est pas bridé, si tu peux formatter la sortie en JSON, tu peux aussi le faire en XML, voir même en (X)HTML pour des widgets par exemple.

Je n'ai pas encore décidé pour le langage, au boulot je développe en PHP5, mais je regarde aussi du côté du Python et du Ruby. Après peu importe le langage, c'est surtout le framework qui va être important, car il va devoir être facile à manipuler pour construire une bonne architecture, être rapide à l'exécution et facilement déployable sur les plateformes.

[jeje84-modelisme]

Tu pense pas que partir avec un langage bas-niveau serais mieux pour la performance ? du style C (idéalement) ou C++ ?

En tout cas si ton langage est C/C++ ou PHP5 il est possible que je fasse partie du projet

[Gai-Luron]

Moi m'en fiche du langage. De toute façon t'en connais un tu les connais tous. .
Même si je pense que le PHP, mysql et apache (du classique) serait le plus adapté. Apparemment un accès web serait l'option que tu as retenu et que j'approuve. Il y a aussi Ajax, mais j'avoue ne pas m'y être penché, je n'en ai jamais eu besoin.

Maintenant vr84160 devrait nous dire ce qu'il existe actuellement et ce qui manque. Après on peut travailler sur le cahier des charges et les fonctionnalités souhaitées et savoir ce qui est récupérable facilement.

A partir de là, on estimera le temps nécessaire et un calendrier.
Quelles sont les forces en présence afin de:
définir les fonctionnalités
définir le cahier des charges.
Donner les infos technique sur l'existant pour les interfaces.
programmer
saisir les données complémentaires.
etc...

J'avoue ne pas avoir trop de temps actuellement à consacrer à cela, mais j'apporterai mon aide du mieux que je peux en fonction du projet.
_________________
Ma classique est en plastique!

[Azema]

Je vois que tu as l'étoffe d'un meneur, c'est bien ça.

[Gai-Luron]

[docman95]

[biose]

Hello, je suis ce poste de prêt aussi, je développe sous Delphi depuis 12 ans maintenant, et je suis fan d'Android, si si ça existe

Alors forcément tout ça m’intéresse, bon j'avoue je bosse déjà presque 45h par semaine, et en dehors du boulot il faut s'occuper de la famille et enfin du modélisme, alors bosser en plus sur des applications tierces ça va être chaud mais... Par contre je connais pas mal de petit truc sur le dev et l'administration de base de données.

Je vais pas exposer mon CV mais en gros mes compétences sont:
- Delphi (pour les applications win32 c'est le top, d'ailleurs je crois que WinARC est développé avec)
- Firebird (pour moi c'est LE moteur de base de données relationnelle gratuit, même si PostgreSQL est pas loin...)
- Linux (quand je vois que certains de nos serveurs on plus de 600 jours d'uptime...)
- Tout ce qui est administration informatique (VPN, routage, monitoring, blablabla)

Voilà je bosse aussi sur du N-Tier avec SOAP et XML-RPC, je commence à faire aussi du NoSQL avec MongoDB même si sur ce genre de projet j'en vois pas l'utilité (sauf si demain le projet dépasse le million d'utilisateur )

Concertant l'application, en tant que pratiquant (et pas organisateur parce qu'à un moment il va falloir faire le distinguo), pour moi LES fonctionnalités indispensables seraient:
- Fiche Club/Circuit (adresse, téléphone, données GPS)
- Calendrier des courses (par ligue et nationnal)
- Inscription à une course
- Accéder au classement
- Communiquer avec d'autre gars du club (genre ce dimanche je vais tourner de 14h à 18h)

En fait presque tout existe déjà mais de manière sporadique, ça dépend des club, et rien n'est adapté à la mobilité.

Donc effectivement un endroit où tout serait accessible depuis un téléphone, une tablette ou un PC et de manière simple et rapide serait effectivement le top

Voilà si je peux aider dans certain domaine et la mesure de mon temps disponible vous pouvez compter sur moi


Enfin refaire le site de la FVRC, ce site est moyenâgeux, sérieux c'est quoi ces boutons en flash sur la gauche ?! on peut même pas cliquer dessus quand on sur un téléphone portable, et je propose aussi d'abandonner définitivement la police "Comic Sans MS"

[rupteur]

Bonjour,

Pour ce qui est du serveur je conseille de regarder du coté de Postgresql

c'est quand même d'un autre niveau que mysql/mariadb
surtout pour une appli nationale

et ceci n'est un troll !

après cela dépend aussi de l’hébergement et du codage de l'appli.

[Azema]

Je suis heureux de voir que ça bouge bien et que le projet ramène du monde.

Pour ma part, j'ai récupéré environ 220 adresses mail de clubs, j'ai commencé la lettre du mailing, elle devrait partir dans pas très longtemps. Pour ceux qui souhaiteraient la recevoir, vous pouvez m'envoyer votre adresse mail par MP.

Merci à docman95, pour sa proposition de nous prêter un serveur pour les tests, c'est sympa.

Merci à biose pour nous proposer son aide aux développements. L'apport d'un DBA n'est pas négligeable. Je pense que les relectures de code vont être houleuses

[rupteur]

Actuellement je teste google GWT.

codage en java et génération en javascript.
il n'y a donc plus de codage spécifique à une plateforme.

Accès identique depuis une tablette,un mac,un pc sous seven ou linux.
(puisque tout est interprété par le navigateur)

pour moi qui ne connais pas le javascript, j'avoue que c'est assez bluffant.

mais pour ceux qui maitrisent bien le html/css/javascript +diverses bibliothèques, ils risquent de le trouver limité (du moins le gwt de base)

Voilà, bon courage pour le choix.

[Gai-Luron]

Salut tous,
Effectivement ça démarre bien, espérons que sur la longueur ça tienne le coup.

Je voudrais juste faire un préambule avant de donner mon avis technique sur ce développement. Nous n’en avons pas réellement parlé, mais il me semble important que les choses soient dites. C’est le statut de ce(s) logiciel(s). Pour ma part il est essentiel que ce soit des logiciels open source et que nous n’utilisions que des logiciels ayant le même statut pour le développement. C’est une question de principe à laquelle j’aurais du mal à déroger.

Maintenant mon avis :
Base de données :
Je m’en moque un peu du moment que cela soit une base de donnée SQL et relationnelle. Les volumes vont être ridicules et le NoSQL est inutile.

Serveur :
Unix, Linux et c’est une chose à laquelle je tiens beaucoup. Stable, vrai multitâche, rapide. Il a fait ses preuves.

Serveur web :
Là aussi pas d’à priori si ce n’est les limitations et le type d’hébergement du serveur.

Langage :
Comme dit précédemment, je m’en moque un peu. De toute façon il n’y en aura pas qu’un seul, car il n’y aura pas qu’une appli. Ce sera en fonction si l’appli est en local sur l’ordi ou sur web. Je n’ai pas un souvenir mémorable de python, mais pour le reste tout me va.

Framework :
Un truc simple qui permet de créer des formulaires et des états facilement et de manière robuste. Je n’ai jamais utilisé ce genre d’outils pour le Web, je fais ça à l’ancienne à la main hormis le fait que j’ai piqué les templates à phpBB .

Nous en avons très peu parlé, mais il y a un point dont le choix va déterminer en partie les autres. Le type de serveur dont aura besoin l’appli:

Serveur dédié :
La solution qui satisfera le plus les développeurs, car on peut y faire ce qu’on veux. Par contre cela nécessite des connaissances informatiques un peu plus pointues. Cette solution ne me satisfait pas dans la mesure où je pense que la ou les applications devront pouvoir être déployées et maintenue par des personnes ayant peux de connaissances informatiques.

Mutualisé et clef en main :
On commande, on installe l’appli et ça marche. Il me semble que le développement dans cette optique est la meilleure car une telle appli fonctionnera sur un dédié ou un mutualisé.

Et c’est là que nous allons avoir des choix qui vont s’imposer d’eux même pour le langage et la base de donnée.

Que retrouve-t-on le plus facilement sur des serveurs mutualisés ? Je vais faire grincer quelques dents :
Apache, PHP et Mysql, parfois PostgreSQL.
Merde alors !

Voilà mon humble avis qui peut bien entendu être discuté, je ne prétends pas détenir la solution tout seul et plus on est de fous, plus on s’amuse.
_________________
Ma classique est en plastique!

[jullichten]

Hello,
J'apporte ma petite pierre à l'édifice car je suis, moi aussi, en plein développement d'une "application" orienté modélisme (j'en dit pas plus volontairement )

Je me suis posé les mêmes questions que toi : plateforme, technique, langage, ...
Quand je vois le nombre d'ail-phone autour de moi, développer juste pour android me parraissait restrictif.

Ma conclusion : je suis partis sur un site web, php5, en utilisant un framework css (bootstrap en l'occurence). C'est la, à mon avis, la solution la plus ouverte. Ca permet de faire un site visible partout et optimisable à souhait pour l'affichage mobile.

Niveau choix technique, je conseille d'utiliser des outils répandu. Autant j'aime le "vrai" dev (ex: site web en assembleur ) , autant je pense qu'utiliser une techno largement utilisé est judicieux. Regarde le nombre de tuto et autre ressources que tu peux trouver sur php et mysql. Tu es sur de n'être jamais seul sur un problème.

Pour mon appli, j'ai poussé le vice encore plus loin en utilsant Wordpress. C'est un outils super pour faire des sites et, bien utilisé, tu peux faire vraiment beaucoup de chose en utilisant des concept "déjà faits". Typiquement, ajouter du contenu à un site avec médias ou gérer des droits utilisateurs, on en a (quasiment) toujours besoin sur une appli web.

Bref, en tant que développeur web, si tu a besoin de mes services, je suis partant également pour t'aider (look, css, jquery etc..)

Voila, bon courage !

[Gai-Luron]

[MilacH]

erf ... y en a marre de ces codages bourrins sans saveurs qui vont partout avec html5 etc ...

Si ton but est de découvrir android, vas y fonce, fais l'appli en "dur" parce que c'est fun et facil.

Et puis, un serveur web ? sachant que sur la plupart des pistes les téléphones déconnes au niveau réseau, il serait mieux de ne faire qu'un miroir d'une bdd de temps en temps (tant qu'il n'y a pas d'infos personnalisée à rentrer).

Parce que rien de plus furstrant que de se retrouver dans le bled, vouloir utiliser l'appli pour avoir les coordonnées gps et ... ah bah merde j'ai pas le net.

Je dis ça je dis rien.

ah et ça évite de fournir un serveur d'appli aussi, parce que il faut le payer et le raccorder hein ^^ on oublie souvent ça.

En tout cas si il y a besoin d'un coup de main pour le dèv, n'hésites pas à demander !
_________________
Ce n'est pas l'arrivée qui compte, mais le chemin.
JQProducts, Picco, Spektrum, Savox, 6mik

[jullichten]

[Azema]

Pour le langage, je pencherai vers du PHP5 car il est très répandu et il y a beaucoup de monde à l'utiliser (bien ou mal telle est la question).

Pour le framework, à vrai dire je ne sais pas trop. J'avais des vues sur ZF2, mais je trouve qu'il est devenu très complexe. Symfony est très orienté IHM à mon avis, quoi d'autre ?

Pour le serveur SQL, un PostgreSQL ou un MySQL me paraissent être suffisants pour ce que l'on a à faire. Après c'est une question d'habitude, pour ma part j'ai développé un outil de gestion de version de BDD pour MySQL, alors pourquoi pas.

Pour le serveur Web, j'aurai une préférence pour Nginx car je le trouve plus costaud que Apache, bien que ce dernier a montré et montre encore aujourd'hui sa puissance.

Pour le serveur, je suis totalement contre l'idée de partir sur un serveur mutualisé. Quand je vois le projet dans son ensemble, je me dis qu'il est impossible de caser ça sur un mutualisé. Donc j'opte pour un serveur dédié à la sauce Kimsufi, du moins pour démarré (on verra par la suite en fonction de la demande).

Question OS, sans discuter ce sera du linux, après pour la distri je pense à une Debian, largement éprouvée.

Je suis aussi pour du code open source, sous licence BSD.

Si vous partez sur la création d'un site en assembleur, on se reverra dans une vingtaine d'années pour le déploiement

Je rappelle ma vision du projet:
Création d'une API Restfull (HATEOAS)
Création d'un BackOffice utilisant l'API
Création d'un FrontOffice utilisant l'API
A voir pour la création d'une appli Android spécifique ou utiliser le FrontOffice adapté à quasi toutes les plateformes (responsive design).

Le but de l'API est de pouvoir servir d'autres clients qui souhaiteront utiliser et/ou diffuser des données.

Pour la fameuse discussion au sujet de la connexion internet et des coordonnées GPS, pour ma part je récupère les coordonnées en partant de chez moi et pas une fois arrivé sur place.

[MilacH]

les markets mettent a jour tes versions automatiquement et faut adapter au contexte : y a pas deux nouvelles pistes toutes les semaines ^^
_________________
Ce n'est pas l'arrivée qui compte, mais le chemin.
JQProducts, Picco, Spektrum, Savox, 6mik

[jullichten]

[MilacH]

[Azema]

[Gai-Luron]

Salut,

Pour avoir eu un kimsufi sur Debian pendant un moment, je confirme que le pékin moyen, même informaticien, ne saura jamais gérer cela (sauf pour des conneries style serveur privé de fichiers vidéos pour éviter monsieur Hadopi). Maintenant s'il faut un ingénieur système pour gérer le bouzin, il est clair que je ne partirai pas sur ça même si je sais faire.
Le problème se posera tôt ou tard et crois en mon expérience quand les personnes compétentes et de bonne volonté iront voir ailleurs par choix ou car la vie les obligera, ceux qui restent seront dans une merde noire en cas de pépin sur le kimsufi pour une réinstall complète ou ne serait qu'une modif.

Pour moi, le dédié n'est pas la solution pérenne et n'est pas en rapport avec la faible charge qu'aura cette appli. Après si c'est pour se faire plaisir et le customizer à mort pour le coté "art" de la chose, je peux comprendre. Mais pour de la production d'une petite association (oui la ffvrc n'est pas une grosse association) cela me semble inopportun.

Gai-Luron
_________________
Ma classique est en plastique!

[Azema]

Ayant une petite expérience, décevante, des serveurs mutualisés, je préfère les dédiés.

Maintenant, nous pouvons très bien commencé avec du mutualisé et si cela ne suffit pas, on pourra passer sur du dédié.

[Gai-Luron]

[MilacH]

Il faut avoir conscience du besoin hein ...

Et le besoin en modelisme c'est une appli qui servira a 5 pekins et qui sera mise a jour tous les ans ... C'est pas la ligue 1 de foot non plus.

C'est pas pour te décevoir que je dis ça ... De toutes façons si tu comptes la distribuer autrement que gratis tu peux oublier ^^.

Mais comme c'est dit, il faut du simple, de toutes façons a part d"eventuels résultats et set up il n'y a rien à mettre à jour.

Et les sponsors ... bah demande à RCMag combien ils ont par rapport aux visites ... je pense de quoi payer le site et offrir des cadeaux mais pas plus ^^.

La vous êtes en train de définir du projet type J2EE à 50 jours de boulot et sans moyen (serveur). Alors qu'en fin de compte, ca se résume à une dizaine de table de BDD et 4 ou 5 pages.

En tout cas, si tu pars vers du web, lorgne vers le projet titanium. C'est html5 javascript qui se porte sur android ET ios.

Commence petit, si ca fonctionne améliore.

Tout ça c'est du conseil à la con. Peut etre que j'ai tort, peut etre raison, mais en tout cas je serais ravie de voir une petite appli pour remplacer le site horrible de la fvrc pour avoir des infos.
_________________
Ce n'est pas l'arrivée qui compte, mais le chemin.
JQProducts, Picco, Spektrum, Savox, 6mik

[biose]

J'ai l'impression que vous vous égarez un peu là... à la base Azema vient nous parler d'une application qu'il a en projet de développer pour les licenciés, les organisateurs et la FVRC...

Je pense qu'il faut remettre les choses dans l'ordre, il n'y a rien de plus simple que de migrer d'une base de données relationnel à une autre ou de changer de serveurs chez OVH si les DNS pointent sur les IP failover (et au pire si ça se passe mal il sera pardonné une coupure du service même pendant plusieurs jours)

De manière très personnel je partirais sur un WebService écrit en PHP (puisque c'est un langage assez simple, connu de beaucoup de personne et facile à déployer).

Coté framework, qu'est ce que vous appelez framework ? pour faire quoi au juste ?

Coté communication, ça peut être du Soap, du XML-RPC, du ReST, du JSon. Moi j'ai une petite préférence pour le Soap avec NuSoap (mais le projet semble plus trop avancer)

Coté BDD, comme j'ai dit je maîtrise très bien Firebird (peu rependu pour le web malheureusement), on l'utilise depuis 10 ans, et en interne je gère 3 bases qui dépassent les 12Go chacune, avec 63 tables, 133 procédures stockées et plusieurs millions d'enregistrement, et c'est d'une stabilité sans faille, c'est "mono-fichier" donc très facile pour la maintenance, il faut juste prévoir des backup/restore de temps en temps pour la compression.
Voilà maintenant je sais que PostgreSQL est très performant aussi. MySQL je vais pas m'attarder mais j'aime pas, et encore moins depuis que ça appartient à Oracle. "Ce que Oracle touche, Oracle le tue"

Voilà maintenant Azema je pense qu'il faut que tu partes sur ton projet "seul", que tu commences à travailler sur les bases, à implémenter quelques fonctions, et une fois que tout sera parti tout le monde va te suivre, parce que là chacun (et moi le premier) va vouloir te guider dans des choix techniques et ton projet verra jamais le jour... Ou alors avec des personnes qui vont te tourner le dos parce que tu auras pas suivi leur conseil de départ