Échanges techniques - contribution au développement

[stand by me]

Fil de discussions techniques à propos du développement de défifoot.

A la suite du fil "Nouveautés" de la section "Vos remarques".

1) Projet(s) perso

si certains veulent récupérer des données, je peux leur donner les accès à l'API. Il faut juste me dire les données attendues.

J'aurais effectivement besoin de récupérer des données.

Ensemble des données d'un match connaissant son identifiant.
Plus précisément - et dans un premier temps - je n'ai besoin que des pourcentages d'occasions de buts pour chacune des deux équipes.
C'est pour un compléter un outil de calcul de probabilités déjà existant.

Ensemble des caractéristiques techniques, physiques, mentales, et profil de progression d'un joueur connaissant son identifiant.
Ce serait pour une fonctionnalité liée à l'évaluation des niveaux d'un joueur.

J'imagine que ça doit pouvoir se faire avec une requête du genre

Code: Tout sélectionner

curl -u pseudo:password -X "http://defifoot.com/.../.../matchs/{id}"

Ici, ce ne sont que des données minimales récupérées en GET, mais si on avance il faudrait prévoir la disponibilité de tous les échanges du CRUD dans l'optique d'une application mobile...

2) Application mobile

Dans un premier temps, on peut développer un prototype vitrine qui permette de se connecter et de visualiser quelques données (nom du club, effectif, calendrier).
Dans un deuxième temps, réussir à interagir simplement avec le back Sporteo (renommer un joueur, programmer un entraînement).
Les choses compliquées en dernier (IHM tactique notamment).

Je te répond avec du concret, je me forme et c est pas mon métier, tu pourras critiquer le graphisme et tout le reste.
Une chose est sûre, c est que j'essaie
[ https://www.funny-stadium.com/forum/download/file.php?id=15473 ]

Développement en Kotlin (donc potentiellement multiplateforme).

On pourra partir sur un dépôt Gitlab...

3) Moteur et visu

oui il y a un dépôt GIT mais je préfère donner juste la partie nécessaire. Il y a une classe qui gère le moteur du match, je pense qu'elle est assez facile à comprendre. Je ne suis pas contre la fournir pour améliorer son fonctionnement, voir en établir un nouveau de A à Z.

Ok.

Pour le rendu visuel idem. L'idée de base est que le moteur génére un fichier XML avec toutes les infos du match. Ce fichier est ensuite lu par la visu pour rendre compte visuellement le match.

Ce serait intéressant de voir le processus de plus près, parce que les applets Java sont obsolètes dans les navigateurs actuels.
Il vaudrait mieux intégrer la visualisation directement dans le navigateur.
Quelle techno privilégier et comment faire, j'en sais trop rien (Javascipt ?), mais mieux vaut oublier l'applet java et passer à autre chose.

Edit : la visu nouvelle génération sera très probablement réalisée sous moteur Javascript, https://ourcodeworld.com/articles/read/ ... me-engines

[stand by me]

Pour un prototype d'application, nous avons plusieurs options :

Un développement 100% natif

C'est une option qui donne le maximum de potentiel à l'application puisqu'elle va pouvoir exploiter toutes les fonctionnalités de l'appareil.
Les inconvénients :
- demande le développement de plusieurs projets distincts (un pour chaque OS) dans des langages différents (donc plus long et difficile)
- on n'aura probablement jamais besoin d'exploiter toutes les fonctionnalités d'un terminal (caméra, microphone, géolocalisation...)

Un développement multi-plateforme IHM pur

C'est-à-dire qu'on ne va pas chercher à exploiter tout le potentiel d'un smartphone, mais adapter l'application à tout ce qui est pourvu d'un écran.
Par exemple avec Python :
- la bibliothèque Qt avec PyQt développé avec Qt Creator, permet l'édition de programmes multi-plateformes dont Android (https://www.learnpyqt.com/)
- le développement avec Kivy (https://kivy.org/doc/stable/gettingstarted/intro.html)
Je ne sais pas trop ce que ça vaut, ça m'a l'air intéressant mais un peu exotique...

Un développement multi-plateforme mobile

Ces 5 dernières années il est possible de fournir un même programme capable de tourner sur la majorité des OS mobiles.

- frameworks du style Ionic qui se basent sur les technos web (Javascript, Typescript) et qui sont en fait du web mobile déguisé en application (performances pas extraordinaires du coup et potentiel limité)
- React Native qui est un framework open-source multi-plateforme de chez Facebook. Basé sur Javascript ; utilisé par Instagram, Uber, Amazon, entre autres...
- un framework qui me semble le plus prometteur, c'est Flutter. Ça sort de chez Google donc c'est du solide et je pense que ça va vite décoller. C'est un langage à part, Dart, mais des centaines de widgets sont disponibles clés en main, pour être assemblés à sa guise. C'est très récent donc peu de références en dehors de la doc officielle, mais les retours sont globalement très bons (https://www.technologies-ebusiness.com/solutions/pourquoi-flutter)
Présentation de Flutter
- j'ai oublié Kotlin ! Le petit frère de Java est plutôt dédié à Android au départ, mais il est désormais possible de développer en multiplateforme.
Vers un nouveau modèle de mutualisation d’application mobile avec Kotlin/Native
https://blog.octo.com/un-tournant-mutualisation-mobile/
Par contre, ça risque de demander une certaine rigueur, puisqu'en fait, on gère le code en trois parties, les classes communes, les classes Android et les classes iOS.

Kotlin vs Flutter
Kotlin vs React Native
Comparatif Ionic / ReactNative

Au départ l'appli n'aura pas des tonnes de fonctionnalités différentes du site mobile (à part probablement l'envoi de notifications), mas on peut imaginer une vraie valeur ajoutée en intégrant par exemple un jeu en lien avec les entraînements...

Mon ressenti :

- React Native a été rendu populaire depuis 2015 faute d'outils disponibles. En tant que base Javascript, on reste dans un univers web, donc Sporteo pas trop dépaysé S'il y a déjà des connaisseurs de React dans les parages, c'est tout bon ! Les moins : petits soucis de performances (à cause de la "traduction" du Javascript vers le bas niveau lorsque tourne l'appli), demande de se familiariser avec React, à mon avis risque de mal vieillir...
- Flutter a l'air vraiment prometteur, bonnes performances, idée ingénieuse, je parie qu'il va percer d'ici 3 ans. Dart ressemble pas mal à Java. Mais manque de maturité pour le moment. Point fort en développement : le hot-reload.
- Kotlin : revient à développer pour Android en adaptant le projet à une version iOS. Android Studio = char d'assaut, lourd à piloter. Le prétendu multiplateforme se borne à iOS. Bien pour des dév connaissant déjà l'univers Android.
- Ionic et cie : mieux vaut laisser de côté.

Des avis ?