J’ai le plaisir de vous annoncer qu’il est désormais possible de payer via Gecko !!
Early dev, n’envoyez pas des milliers de junes sur vos wallets, juste pour tester.
L’UX scan2Pay va complètement changer lorsque le maquettage Figma sera OK.
PS: Si vous avez un écran blanc au démarrage de l’app, veuillez supprimer les données de l’app avant de l’ouvrir (le format de stockage portefeuille à encore changé).
Attention cette version de ğecko utilise encore l’ancien format DEWIF, hors la spec DEWIF à été entièrement refondue.
Toutes les Ğ1 déposés sur un portefeuille ğecko deviendrons donc irrécupérables dans une prochaine maj !
J’indiquerai en gras lorsque qu’une mise à jour devient cassante sur les portefeuilles, il faut faudra alors transférer vos junes sur un wallet cesium avant de maj.
Je vais publier un fix demain soir pour régler plusieurs bugs provoquant des écrans blancs sur le dernier build, donc attendez ce gros fix avant de tester.
j’ai reglé pas mal de bugs sur la branche fixBugsAgain, mais pas finit, et je vais pas pouvoir trop coder d’ici la semaine pro, je suis actuellement chez scan, et on emménage vendredi, donc je met en standbye le dev d’ici là, sry.
Bravo en tous cas, j’ai testé, ca donne pleins d’idées 
(désolé j’ai besoin d’essayer de voir les idées en œuvre pour les comprendre)
J’ai pas mon PC donc je peux pas coder, mais je peux en profiter pour détailler un peu où j’en suis
Les écrans gris/blanc que vous pouvez rencontrer lors de certaines actions dans l’app sont principalement dû à mon système de fichier pour le stockage des config des portefeuilles locaux.
Je gère actuellement tout en file système:
0 et 1 sont des dossiers correspondant aux 2 coffres (Chest) par defaut dans Gecko.
Le coffre 0 est le coffre HD wallet, contenant les portefeuilles principaux (dérivations).
Le coffre 1 est le CoffreACesium, contenant différent portefeuilles Cesium, tous protégés par le même code secrêt.
Le code secret est donc propre au coffre, un différent par coffre.
les list.conf contiennet des lignes de ce format:
0:0:Mon portefeuille courant:3
0:1:Mon livret A:6
0:2:Un larfeuil pour les surprises:2
Col 1: numéro du coffre
Col 2: numéro du portefeuille dans ce coffre (Col1:Col2 = ID)
Col 3: Nom du portefeuille
Col 4: Numéro de dérivation (IndexNbr)
Et j’ai une classe qui parse cette liste et créer un objet de type portefeuille (merci @HugoTrentesaux )
Tout ceci fonctionne plutôt bien.
J’ai simplement encore quelques soucis avec le cycle de vie de ces fichiers, l’aspect async de la chose sur certains points, notamment lors de la suppression de tous les portefeuilles, ou de la première création de coffre en sortie de l’OnBoarding.
En général lorsque vous tomber sur un écran blanc, vous pouvez ferme l’app et la rouvrir, et ça fonctionne (pbm de async sur les filessystem), parfois non, dans ce cas c’est un mauvais format de fichier ou un fichier absent, mais ce deuxième cas devrait être plus rare, je fais de mon mieux pour que ce cycle de vie soit cohérent.
@kimamila Ce serait toi, qu’est-ce que tu utiliserais pour stocker les dewif et configs wallets (noms,ID,IndexNbr,defaultWallet,walletPicture, ect…) ? Est-ce que tu partirais sur du filesystème comme moi ? En JSON ou autre ?
Est-ce que tu partirais plus sur une mini DB local (SQLite, autre ?)
Edit: Voici le dernier APK qui date de 2 jours qui corrige déjà pas mal de bugs, en attendant que je corrige les derniers:
Le problème de la concurrence est bien connu quand on travaille sur un système en asynchrone. Il faut absolument identifier les accès concurrents (surtout en écriture) sur un élément commun aux threads.
Gérer la concurrence entre thread est un enfer dont je suis toujours resté loin (les locks, les signaux, les sémaphores, etc). Je conseille d’utiliser un système de persistance qui gère pour toi les accès concurrents. Il semble bien que SQLite le gère jusqu’à un certain point (50000 insert par seconde, d’après les développeurs), à vérifier sur un mobile.
En fait Dart n’est pas un language multi-thread, mais uniquement concurrent.
La page ebook à ce sujet:
Chiotte ils font chier avec leurs protections, c’est mieux comme ça:
Oui, j’avais compris (c’est la mode…). Cela ne change pas le problème. Le SPF (Single Point of Failure) est la cible de tes accès concurrents, que le client soit en multi-thread ou en asynchrone mono-thread.
Cela me fait penser qu’en asynchrone mono-thread, théoriquement, tu ne devrais pas avoir de problème de concurrence puisque les actions ne se font pas vraiment en parallèle, mais à chaque itération de la boucle d’évènement. Ça c’est côté client, mais je suppose que la fréquence des accès déborde le système de fichier et son cache et ses verrous d’écriture et que les requêtes sont dans des threads. D’où les problèmes.
Ah ben oui, c’est précisé dans le chapitre Running code in parallel de ton dernier lien. Le système lance des threads quand il est sollicité par Dart.
Sqlite est à tester, il gère une queue et limite les verrous en durée, ce qui suffit pour une fréquence basse. Le dernier commentaire du lien que je tai donné parle d’un nouveau mode WAF qui optimise les accès en écriture si il y a une forte fréquence en lecture. A regarder…
Bon code !
Hello !
J’ai tester cette dernière version!
Ça fait du bruit au démarrage ! Je suis pas fan
J’ai eu un blocage à la création de trousseau, la phrase de récupération ne s’affichait pas.
Au bout de 2 essai ça s’est débloquer tout seul.
Impossible d’ajouter un portefeuille césium.
J’essai en passant par paramètres, mon mot de passe est affiché (Super!) Dès que je commence la saisie le mot de passe change (Zut!)
Et puis après impossible de retrouver le portefeuille.
Voilà ce que j’ai constaté aujourd’hui.
De mon coté, l’application plante au démarrage.
Je vais virer le son de démarrage si connecté à un bon noeud en effet.
Les autres sons pourront être désactivés.
Ce bug m’intéresse car il n’est pas connu, j’irais voir les alerte Sentry lorsque j’aurait finit ma pause (je suis malade depuis 4 jours j’en ai marre j’ai hâte de reprendre).
Oui en effet les import Cesium sont cassé c’est normal, ce sera corrigé bientôt avec la bonne tenu des différents coffres 
Très bonne remarque, j’y avait pensé, mais en effet, il faut que je change ça, c’est pas intuitif.
Malheuresement nous n’avons toujours pas réussi à isolé le pbm de ton fairphone 1 @Candidesk8 , mais j’ai une piste.
Sais-tu me dire combien de place en stockage il te reste de dispo sur ton phone ?
Moi aussi j’ai hâte ! Tu nous mets l’eau à la bouche, je me sens frustré de ne pouvoir allez plus loin.
Bon rétablissement !
Est-ce que un cahier de test est prévu? Où on continue de tester à l’arrache ! 
130 Mo disponible
EDIT : j’ai fait du ménage et suis repassé à 1,57 Go (~ x 100)
J’ai ensuite refait une installation après avoir désinstallé l’appli, mais j’ai toujours le meme problème .
As-tu retéléchargé le APK depuis ton nettoyage ?
Une vidéo d’une heure sort bientôt pour présenter Gecko, pour aider à patienter 
Bonne idée ce cahier de test il faudra que je fasse ça !
Ok Candide ton error au démarage au dû au fait que ta version d’android n’arrive pas à lire le son de gecko de démarrage … Je règlerai ça.
Mais en attendant, je veux bien que tu retélécharges l’APK v0.0.1+26 pour me dire si tu arrives à générer un portefeuille, depuis ton nettoyage).
Merci
non j’ai relancé le APK présent dans mon répertoire de téléchargement ( gecko-0.0.2+4.apk )
Hors de question, c’est une des fonctionnalités principales ! Mais on peut mettre une option pour désactiver les sons en effet 
Oui c’est la fonctionnalité phare de l’app en effet, toute l’architecture a été construit autour de ça.
Mais je pense non utile et stressant d’entendre le son actuel à chaque démarrage Gecko a trouvé un bon noeud, il y aura un son uniquement en cas de pbm au démarrage.
Les autres sont ailleurs resteront, mais seront principalement pour les erreurs, et seront désactivable en tappant 3 fois sur le logo de l’écran d’accueil.
fait.
ecran blanc plus de 10s …
