Suite à une première expérience de développement libre pour Android, je souhaiterai amorcer maintenant un projet un peu plus utilitaire : un annuaire de formules localisable et collaboratif.
Je souhaiterai associer trois fonctionnalités principales :
un annuaire de formules thématiques (maths, géométrie, stats, ingénieur, finance…) utilisant une représentation mathématique graphique usuelle.
un assistant qui permet d'appliquer la formule en sélectionnant l'inconnue, en saisissant les valeurs des autres variables et les unités.
enfin une fois qu'une première version de l'appli sera utilisable, un site collaboratif permettant d'ajouter des formules, des descriptions et des illustrations, en gérant la localisation.
J'ai réalisé une maquette préliminaire de ce à quoi cela pourrait ressembler au niveau de l'appli :
https://www.fluidui.com/editor/live/preview/p_A2BuFGKgUdlaVNxBm3X4kvRlMzaVWIxD.1386012639855
(Cliquer sur Géométrie détails / Surface détails / Cône détails / Calculer pour voir l'enchaînement d'écrans)
Le projet est encore en phase d'étude initiale, et les choix techniques ne sont pas figés. A priori le développement se fera en Java avec le SDK standard pour l'essentiel de l'interface, utilisera sqllite pour le stockage des formules et de l'historique d'usage.
Pour l'affichage des formules je compte utiliser Mathjax dans une webview (exemple ici)
Pour les formules qui doivent être extensibles par l'utilisateur, l'hypothèse actuellement est de s'appuyer sur un langage de script comme beanshell qui s'embarque a priori facilement dans les applis Android et des bibliothèques java comme commons-math et Jscience.
A priori la licence sera double Apache 2 / GPL 3.
Si un projet similaire existe déjà je serai très intéressé de le découvrir…
# Double licence?
Posté par reno . Évalué à 3.
J'avoue ne pas comprendre l'intérêt des doubles licences, peux-tu expliquer ton choix?
De mémoire on peut faire tout ce qu'on veut avec du code Apache 2, donc je vois pas trop ce que la GPLv3 va avoir comme conséquence..
[^] # Re: Double licence?
Posté par chansen . Évalué à 1.
En effet, normalement la licence Apache 2 devrait suffire.
J'ai un doute néanmoins si quelqu'un voudrait emprunter un module Apache 2 pour l'intégrer dans son projet GPLv3, est ce possible sans accord de l'auteur du module Apache 2 ?
# MathJax ?
Posté par Crash . Évalué à 1.
Pour avoir pas mal travaillé avec MathJax, et bien qu'étant la seule librairie en javascript capable de faire des miracles, ces miracles ont un prix.
En effet, sur certaines versions d'Android, tu vas avoir des problèmes de support, de lenteurs, que dis-je de grosses lenteurs en fait. Sans parler des problèmes de caractères qui ne s'affichent pas dans la webview, alors qu'ils sont bien présents dans les fonts de Mathjax. Et puis 30Mo à embarquer directement dans ton application que pour ça ?
Pourquoi donc partir sur une webview ? N'existe-t-il pas des moyens natifs plus performants et plus fiables pour afficher des équations sous Android ?
[^] # Re: MathJax ?
Posté par chansen . Évalué à 1.
L'intérêt d'utiliser une vue web et Mathjax est leur portabilité. On peut espérer réutiliser les mêmes mécanismes pour le site voir sur d'autres OS mobiles..
Il me semble que les smartphones et Android progressent vite, et si je veux bien croire que ton expérience a été mitigée, cela ne sera peut être plus le cas à l'avenir : les devices propulsés par les versions 4.x me sont plus performants que ceux sortis sous Gingerbread, le renouvellement est rapide… Enfin en 4.4 les webview seront des vues chromium, ce qui devrait résoudre bcp de problèmes.
Je vois bien sûr plein de façon d'afficher ces équations autrement en faisant du pré rendu, mais on perd l'aspect dynamique : par exemple on pourrait avoir un mode ou les valeurs des paramètres saisies sont "injectées" en temps réel dans la formule, et cela n'est pas possible si l'on ne dispose que d'une formule pré rendue.
Lors du build de l'application, on pourrait avoir une tâche qui convertit les formules Mathjax en PDF puis en SVG et l'application pourrait utiliser les SVG pour l'affichage. Les SVG seraient bcp plus volumineux que l'équation d'origine en latex/mathml ou asciimathml, et donc cela ne ferait pas forcément maigrir l'appli. Rien n'empêche de faire deux versions, une pur Mathjax et une embarquant les SVG pour la rétrocompatibilité.
Pour démarrer le projet, on va cibler Android 4.2 en utilisant Mathjax, et on s'adaptera si on rencontre les problèmes que tu indiques.
J'espère que l'on pourra faire un chargement initial de Mathjax et de ses fontes, et réutiliser ensuite toujours la même webview sans avoir à recharger Mathjax.
[^] # Re: MathJax ?
Posté par groumly . Évalué à 2.
Yen a quelques un qui ont essaye, ils en sont quasi tous revenu.
Ya pas de mal a faire une webapp, mais si c'est pour faire ca, pourquoi s'emboucanner avec une distribution native? Tu te retrouves avec les pire des deux: des mauvaises perfs et une mauvaise experience, et des problemes de distribution.
Le probleme c'est que les besoins evoluent plus vite que le matos. Quand un telephone sort, les gains sont immediatement bouffes soit en calcul pur, soit en confort pour le developeur.
Et vu l'ebullition du milieu, la tendance est pas prete de ralentir.
Le desktop est passe par la aussi, et ca lui a prit un bail pour se stabiliser.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: MathJax ?
Posté par chansen . Évalué à 1.
La webapp ce sera après pour alimenter en données l'application mobile.
J'ai cru comprendre d'après tes autres commentaires que tu développais dans le mobile et que tu ne conseilles pas les frameworks de compatibilité. Pourtant certains ont l'air de bien marcher pour les jeux, mais je comprends que les perfs viennent de l'implémentation hardware d'open gl, ce dont mon appli n'a pas l'utilité pour l'instant.
Dans notre cas d'affichage de formules, il y a peu de composants existant à part au niveau des navigateurs. As tu une alternative à proposer à part renoncer à l'affichage dynamique ?
[^] # Re: MathJax ?
Posté par groumly . Évalué à 4.
Mon point est le suivant: soit tu fais une webapp, soit tu fais une appli native.
Dans le premier cas, MathJax est probablement très bien, ou pas, j'en sais rien, je suis pas l'actualité JS/html5. Pour les perfs, t'attends pas a des miracles. JS est lent et peu réactif pour l'UI, c'est un fait. Ca marche, mais c'est treeeeees loin de mes standards perso. Apres, chacun ses standards.
Dans le deuxième, fuit les webviews comme la peste: ca performe très mal et c'est un merdier a maintenir. Je develope pas sur android, donc je peux pas te dire ou aller voir. Perso j'irais du cote de TextKit ou CoreText sur iOS, mais c'est pas ta plate-forme, donc ca va pas t'avancer des masses.
Pour les SDK cross plateforme, je pense effectivement que c'est du gâchis d'utiliser ca. Tu te limites au dénominateur commun des plateformes, ce qui est un peu dommage pour du natif. Tu ne peux pas t'adapter au design language des plateformes non plus, ce qui est encore plus dommage. Ya un SDK multiplateforme qui marche bien, ca s'appelle le web.
Ma position est simple la aussi: si tu supportes une plateforme, tu le fais bien. Jetter en pâture un build pour machin parce que "ca marche" c'est ni fait ni a faire et un manque de respect pour tes utilisateurs.
Si supporter chaque plateforme est absolument primordial, alors t'es suffisamment gros pour avoir des equipes dédiées a chaque plateforme.
Si t'es petit, tu peux vivre sur une seule plateforme, et t'as pas besoin de t'emmerder avec du multiplateforme.
Si t'es petit et que tu veux supporter plusieurs plateforme mais t'en a pas les moyen d'avoir des equipes dédiées, c'est que tu te disperses dans des futilités et tu ferais mieux de te concentrer sur une plateforme.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.