Elle ne marche pas non plus avec l’autre.
Je passe sur le tél avec Android 4, pour voir
Ok, j’ai ouvert un ticket côté Gitea pour le soucis d’execution de l’APK sur mobile:
1 Like
Sur Android 4.3 ça démarre, ça demande la clé publique, et ça affiche l’historique des transactions.
1 Like
Alors je commence à regarder le binding Flutter/Rust et ça semble plutôt prometteur. Cela induira toutefois une limitation pour les utilisateurs de la pomme empoisonnée :
Seuls les appareils sous architecture 64bit seront supportés. Ce qui signifie que les iphone de 2013 et plus anciens ne seront pas supportés (iphone5c et précédents), ce qui représente moins de 5% des utilisateurs d’iphone et moins de 0,5% des utilisateurs de smartphone dans le monde.
De toute façon la pomme empoisonnée a officiellement abandonné le support des appareils sous architecture 32 bit, donc si vous avez un tel appareil il faut en changer. Et si vous voulez un appareil qui dure longtemps, fuyez la pomme empoisonnée qui est la championne de l’obsolescence programmée.
Android n’est pas concerné par cette limitation, les téléphones android sur architecture 32bit seront bien supportés, la version minimale requise étant Android 4.1 (limitation de Flutter en lui-même, aucun rapport avec Rust sur ce coup-là).
2 Likes
Oui c’est bien ça fait que globalement Ḡecko ne sera pas compatible avec les smartphone avant 2013 (Android 4.1: 2012).
Pour ceux qui veulent du retro-compatible il faudra développer des apps full-natives.
C’est super que la binding Rust s’annonce bien!
Bon j’arrive à générer un mnemonic en Rust puis à l’afficher dans une app Flutter, c’est un bon début 
4 Likes
Je viens d’ajouter la génération du trousseau de clés à partir du mnemonic :
ps: astuce donnée par un ancien collègue de boulot: capturer quelques secondes de son écran dans un fichier GIF pour pouvoir partager une courte animation sans avoir besoin de faire une vidéo. Perso j’utilise peek 
5 Likes
Voila j’ai bindé tout le nécessaire pour générer un wallet avec code pin, signer, et pouvoir changer de code pin (et j’ai également ajouté le dico français pour les mnemonic) :
Cette App de démo faite à l’arrache me sert juste à tester mon binding, ça ne sera jamais intégré à Ğecko. Ce qui sera intégré c’est uniquement le package flutter exposant les fonctions de cryptographie, je ne compte pas toucher à l’UI de Ğecko 
@poka maintenant la prochaine étape c’est d’intégrer mon package flutter dans Ğecko, le plus simple c’est de l’ajouter directement dans le dépôt git, je peux soumettre une PR ?
Je ne peux pas «publier» ce package pour 2 raisons :
- La commande publish ne publie pas les fichiers dans le
.gitignore, or il faut joindre les binaires généres sinon ça ne peut pas fonctionner. Et hors de question de faire suivre par git des binaires générés (bonjour l’explosion de la taille du dépôt, et puis se serait sale). D’ailleurs il y a aussi du code de binding auto généré, nécessaire pour le fonctionnement du package mais pas suivi par git. - Les packages flutter publiés sont limités à 10Mo après une compression gzip, or ça dépasserait, car le binaire est généré en 6 exemplaires (1 pour chaque architecture supportée), et que chaque exemplaire du binaire inclus les dicos mnemonic.
2 Likes
Wahou génial j’ai hâte de tester ça !!
Oui bien sûr tu peux faire une PR, je ne sais pas si on peut faire une PR sur une branche particulièrement (une nouvelle branche) (j’ai jamais l’occasion de gérer des PR) ?
Je ne ne comprends pas au sujet des binaires, je croyais que le code Rust de rs-dubp-lib serait directement dans le dépôt, comme une dépendance, et compilé à la première exécution et à chaque fois qu’il y a eu modification de la lib Rust ?
Mais bon ça m’arrange ainsi, ça veut dire pas besoin de cargo dans la stack de Ḡecko ?
Ben c’est le principe même d’une PR (où MR selon l’école).
Oui c’est bien comme ça que ça va fonctionner si on place le package flutter directement dans le dépôt de Ğecko.
Si, mais tout ce fait en une seule commande heureusement, et puis je vais te faire un README 
1 Like
Okok je trépigne de voir tout ça avec un README qui va avec lol
J’ai testé mon binding sur mon vieux samsung mini S4 sous Android 4.4.2 (je n’avais testé que sur émulateur jusque-là), et j’ai eu un problème, mais j’ai réussi à le résoudre et maintenant ça fonctionne
C’était un problème dans la configuration de la compilation, et plus précisément dans le réglage du paramètre ANDROID_PLATFORM_VERSION, qui indique la version de la plateforme Android pour laquelle on cross-compile.
Les versions de plateforme Android (aussi nommés API Level), sont backward compatible, donc un réglage trop «récent» ne devrait en théorie poser aucun problème.
Sauf que, en pratique llvm ne compile pas avec les mêmes options selon la version de la plateforme, notamment pour optimiser le binaire final.
À partir de la version 23, Android supporte les GNU_HASH, une manière plus optimisée de hasher certaines données dans un executable.
Mais mon vieux samsung mini S4 (API level 19), ne sait pas gérer les exécutables avec des GNU_HASH 
Après quelques recherches, je me suis rendu compte que cette «option» de compilation ne peut pas être choisie, c’est llvm qui choisi automatiquement la meilleure option en fonction de la plateforme cible :
Donc la seule solution, c’est de cross-compiler pour une plateforme Android de version inférieure à 23. J’ai choisi 22, et ça a fonctionné !
La contrepartie, c’est que les binaires générés sont en théorie «moins» optimisés pour les téléphones récents. Dans la pratique je n’ai pas constaté de différence sur l’émulateur Android, donc je ne pense pas que ça se sente à l’usage.
Et si c’était vraiment gênant, on pourrait toujours livrer 2 apk, un pour tels récents et un de «compatibilité».
L’autre contrepartie, c’est si l’on voulait utiliser une fonctionnalité d’Android apparue après la version 22 de leur API, par exemple le capteur d’empreintes digitales, on ne pourrait pas, à moins de maintenir et livrer plusieurs variantes de Ğecko, ce qui serait beaucoup de boulot en plus.
Et puis si l’esprit c’est d’être compatible avec des vieux téléphones, ça me semblerait pas très cohérent d’utiliser des fonctionnalités d’android ultra récentes comme la reconnaissance faciale et co 
À part l’appareil photo pour scanner un qrcode, prévois-tu d’utiliser d’autres fonctionnalités matérielles @poka ?
1 Like
Je songeais au capteur d’empreinte digital, tout en me demandant si c’était réellement possible car il faudrait stocker le code pin quelque-part qui serait débloqué par validation digital, ce qui est un non sens, peut être serait il chiffré lui même par notre propre empreinte qui aurait un hash, je nje sais pas, je ne maîtrise pas du tout le sujet donc c’est vraiment juste des réflexions que j’ai pour du long terme, mais aucunement nécessaires en soit.
A part ça, je songe à la possibilité de pouvoir imprimer des factures ou reçus via une imprimante connecté en wifi sur le système, mais je pense que l’API 22 doit le faire sans soucis, et encore une fois ce n’est pas une priorité.
Enfin je me pose des questions sur l’utilisation de NFC. Est-ce que des paiements via RFC seraient possibles/intéressants ? Je ne pense pas grâce au système de QRCode, mais il faudrait approfondir le use case, là encore ce n’est pas une priorité selon moi.
Donc globalement je ne vois aucun soucis à utilise l’API 22 au lieu de 29, sous réserve que ce n’ait pas d’impact considérable sur les performances pour les smartphones plus récents, et que ce ne soit pas bloquant dans l’utilisation de certains widgets Flutter.
Je pense qu’on peut partir là dessus et de toute façon je verrais bien au fur et à mesure si c’est bloquant/gênant ou non 
1 Like
Je ne maîtrise pas non plus, il faudrait creuser. Après c’est toujours possible de maintenir et développer 2 variantes de Ğecko et donc de livrer 2 apk, un pour tels récents et un pour tels anciens, c’est juste plus de boulot.
Oui ça c’est pas dépendant de l’API Android, car pas lié au système Android en lui-même.
NFC c’est bon c’est pris en charge depuis l’API 19
Évidemment, on est sur la même longueur d’onde là-dessus
1 Like
En revanche je crois qu’en dessous de l’APK 28, le compilation n’utilise pas encore androidX, ce qui en effet pourrait avoir un effet non négligeable sur les performance des smartphone plus récents et à venir.
Mais comme tu dis, on peut partir sur API 22, et plus tard voir pour build différentes versions, voir même forker en 2 projets qui prendraient des tournures différentes pour les smartphones récents, en fonctions des développeurs et du contexte.
Il n’y a pas d’espoir que cette limitation saute à l’avenir avec l’évolution de llvm ?
Non. En revanche, j’ai l’impression que cette limitation concerne uniquement le code Rust, car je n’ai pas changé la configuration du projet Flutter pour résoudre le problème.
En gros, je pense que le code Dart peut être buildé pour l’API 29 et que c’est juste le binaire Rust qui subira la limitation, à tester
Ah ok… J’ai dû mal à comprendre comment mais pourquoi pas ^^
Je suis en train de tester de build Ḡecko actuel sur l’API 22 pour voir.
Si ça ne concerne que le code Rust et que l’app reste sur l’API 29 c’est tout bon, d’autant que la partie Rust s’exécute dans son propre Isolate, ça n’aura aucun impact sur le reste de l’app.
1 Like
Ouch, ça ne veut pas compiler sur l’API 22. J’ai des tones d’erreurs, toutes liés à des widgets UI de Flutter, pourtant jusqu’alors très minimalistes…
Je crois qu’en dessous de l’API 28, j’aurais dans tous les cas pas mal de changements à faire pour adapter 
1 Like
Le code Rust est compilé en tant que bibliothèque dynamique (fichier .so), donc c’est un binaire indépendant, donc il peut très bien être compilé pour une version d’Android différente.
D’ailleurs je vois que sur mon app de test le param compileSdkVersion vaut toujours 28. Donc je confirme que je nous ai fait peur pour rien, la limitation ne s’applique qu’au code Rust, je partage mes réflexions en même temps que ma compréhension avance 
1 Like