Ğecko is a mobile ĞDev wallets management client developed in Flutter/Dart.
Download last version: Ğecko ĞDev (last build) - #58 by GeckoBuilds
This topic serves as discussions about its development, as well as user support.
1 Like
J’ai installé la version v0.0.6+1008
J’ai tenté de récupérer mon compte avec le mnémonique. Mais j’obtient une autre clé.
Je ne sais pas si c’est normal ou si je me suis trompé en saisissant ma phrase de récupération.
Le format court des adresses à changé, il n’est plus affiché en 3 parties avec le checksum à la fin, mais juste début…fin comme sur polkadot.js
Le checksum est déjà intégré à ce format.
Tu es sûr que ce n’est pas ton problème ?
Non ce n’est pas ça.
J’avais 7 gdev sur mon compte. Je ne les vois plus, donc je suis sur un autre compte.
Peut être une erreur de saisie, mais comment vérifier ce que j’ai saisi. Est ce possible ?
Bon je vois qu’il y a encore une nouvelle version.
Je vais donc recommencer. 
1 Like
Bon j’ai installé la v0.0.7+1001
Je tente de récupérer mon compte, je saisis le mnémonique, et j’ai encore une autre clé. Qui n’a rien à voir avec les précédentes.
J’ai pourtant fait bien attention en saisissant mon mnémonique…
Bon je n’arrive pas à accéder à nouveau coffre.
Alors je refais la récupération, et là j’ai le coffre que j’ai eu sur la version v0.0.6+1008 mais pas celui sur lequel j’avais 7gdev.
Je supprime ces coffres, et je recommence. Et je retrouve bien le même compte que j’ai eu la deuxième fois.
Je suppose que cette restauration n’est pas compatible avec la version avant la v0.0.6+1008
Je viens d’ajouté un écran pour voir sa phrase de restauration dans les paramètres du coffre:
Tu ma forcé à vérifier, et en effet il y avait un gros bug depuis quelques builds, les mnemonics importés n’étaient pas ceux affichés lors de la création mais d’autre généré dans l’ombre juste après l’écran…
C’est corrigé, j’ai dû changer ma façon de gérer l’état de l’écran de génération.
Vous devez supprimez tous vos coffre et réimportez les avec les builds supérieurs à 0.0.7+4
4 Likes
J’ai installé la version v0.0.7+4.
J’ai voulu restaurer mon coffre, la première fois il m’a ressorti le compte qui ne fonctionne pas : 14KiiHkN8EGBaC9K3Yh73LRwGLczy4afXqaic1Q44LKwXTev
Impossible d’accéder à ce coffre je saisis le mot de passe et rien ne se passe.
Je refais l’import, je retrouve le compte qui semble désormais le mien avec cette phrase de restauration et j’ai un coffre accessible.
J’ai essayé de reproduire l’erreur, mais impossible. Même en desinstallant re-installant.
Donc mon compte semble bien être 5FPRZxVJGSzi8f8o5ue6uBbnQidMGm2XTLrESiQhWFJRLwdC
En fait j’ai réussi à reproduire l’erreur en de-installant et re-installant sans passer par oublier mes coffres avant la désinstallation.
…
Maintenant j’essaie de faire un virement, (merci Éloïs) cela semble fonctionner, mais après quelques secondes j’ai une erreur Time Out. Est-ce normal à ce stade du développement ?
1 Like
Aaah c’est bon j’ai compris ton pbm.
C’est le format de cette address que tu donnes qui ma mis sur la voie.
Elle commence par 14 et non 5 comme le voudrait le prefix 42 de la ĞDev.
C’est un bug du SDK polkawallet que j’utilise. Il manque un await quelque par de leur côté (du moins c’est ce que je pense avoir identifié comme étant la source du bug) ce qui fait que lors de la génération de l’address à partir de la seed, l’address affiché est d’abords avec le préfix de Kusama, ce qui donne ce type d’address.
Dans mon code j’ai donc un sleep 0.02 qui attends donc 20 milliseconds que le prefix soit bien appliqué au KeyPair généré, avant de retourner le résultat.
Si ce delay n’est pas suffisamment long sur ton téléphone, le prefix du KeyPair n’est toujours pas chargé, le portefeuille est donc enregistré avec la mauvaise address.
Dans ton cas, le delay est à la limite, ce qui fait que le résultat est aléatoire (les bugs qu’on préfère).
J’ai augmenté ce delay à 50ms en attendant, mais il faut que je règle le problème en amont.
1 Like
Bon et bien finalement j’ai corrigé le problème à la source, plus de sleep du tout 
C’était bien 2 await qui manquait dans le code du SDK, que j’ai corrigé sur la version forké que je maintiens: https://github.com/poka-IT/sdk/commit/3dcfaa00f8e53e33346332d7a1e3612b1cd03b0:
fix: await for updatePubKeyAddressMap() to finsh before return result… · poka-IT/sdk@3dcfaa0 · GitHub
Le gars qui maintient cette lib n’accepte toujours pas ma merge request faites le 16 février et que j’amende depuis …
Il serait temps qu’il se bouge parce-ce que ça commence à faire pas mal de bugs que je lui corrige.
3 Likes
Je vois que tu ne l’as pas explicitement taggé, il a certainement oublié ta PR depuis le temps, il faut le tagger en lui demandant gentiment s’il pense pouvoir merger ces fix bientot
1 Like
Le problème c’est qu’il a bien vue ma MR, depuis il a fix manuellement des pbm de dépendances sur sa branch dev, mais qui étaient déjà fix dans ma MR.
Mais pas tout, il restes des bugs fixes importants dedans.
Ca fait des mois que je push sur cette branches pour fix.
Il doit pouvoir fetch uniquement les commits qui l’intéressent dedans non ?
Voilà je viens de le tagguer.
2 Likes
Que veux tu dire par là ?
L’écran t’affiche un timeout au bout de 12s, mais tu constates que le paiement a bien été effectué quand tu va voir le solde de ton portefeuille ?
Si c’est le cas non ce n’est pas normal à ce stade du développement.
Quel était le montant de ce virement, de quelle addresse vers quelle addresse stp ?
J’ai mis le timeout à 12s, ce qui correspond au passage de 2 blocs.
Si Duniter ne renvoi toujours aucune réponse au bout de 12s ce n’est pas normal.
N’est-ce pas @elois ? Est-ce qu’il est possible qu’un extrinsic se termine avec succès après 12s d’exécution ?
Il peut y avoir plusieurs raisons coté duniter-v2 pour lesquelles cela arrive:
- La souscription RPC ne garantit pas de retourner la notification, il se peut que tout se passe très bien mais que le serveur RPC ne retourne aucune notification, c’est toutefois censé être très rare, ça arrive généralement quand le serveur RPC est surchargé de requêtes, il va alors skip des notifications pour prioriser le traitement d’autres requêtes.
- La réponse vient quand l’extrinsic est introduit dans 1 bloc, ce qui nécessite que ce dernier arrive dans la pool d’un nœud qui va forger un bloc. Plus il y a d’authorités, plus ça peut être long. Je ne sais pas combien de blocs il faut attendre en moyenne selon le nombre d’authorités, on va le voir par l’expérience, ce serait chouette que quelqu’un fasse des stat là-dessus
- L’extrinsic expire avant de pouvoir être inclus dans un bloc (ne peut arriver que si la blockchain est surchargée)
- L’extrinsic deviens invalide avant de pouvoir être inclus dans un bloc (par exemple si un autre extrinsic du même issuer avec le même nonce passe entre-temps).
- Si l’exécution de l’extrinsic panic ou par en boucle infinie.
- Peut-être d’autres cas possibles auxquels je ne pense pas
À priori, seule la raison “panic ou boucle infinie” constitue un bug, pour savoir si on est dans ce cas il faut rééxécuter l’extrinsic localement contre le même state, ce qui est possible avec des outils de testing comme try-runtime, mais ça demande du développement coté node/host pour pouvoir l’utiliser (c’est dans ma roadmap).
EDIT: @poka note aussi que même si le serveur RPC t’envoie bien la notif, il est possible que ta lib RPC où ton wallet Ğecko ne relaye pas la notif dans certains cas pour “whatever reason”, ça peut être notamment des problèmes de gestion de l’asynchrone 
2 Likes
Bonjour,
Est-ce Gecko fonctionne sur Linux ? Je n’ai pas de tél. android ni apple.
Non c’est un client mobile uniquement.
Des travaux pourront être fait plus tard pour le rendre compatible PC ou web, mais pas avant un moment je pense.
Il te faut utiliser Tikka sur PC
(edit: A noter qu’il doit en théorie être possible de lancer Ğecko sur Windows 11, étant donnée qu’ils prétendent que les app Android sont désormais executablent nativement, mais j’ai pas testé… A quand pour Ubuntu?)
1 Like
J’essaie de faire un virement vers D9D2zaJoWYWveii1JRYLVK3J4Z7ZH3QczoKrnQeiM6mx
J’ai cherché Éloïs, j’ai sélectionné le compte, j’ai tapé sur « faire un virement » (les deux flèches).
J’ai mis un montant de 10 gdev, je tape sur « envoyer le virement » je saisis le mot de passe, j’arrive sur l’écran « envoi en cours » j’ai la flèche qui tourne, et au de quelques secondes (12 environ) j’ai l’erreur Time Out. Et mon solde n’a pas bougé, toujours 47 gdev.
Et devoir taper sans arrêt mon mot de passe, c’est assez casse pieds, est-ce que ça va rester comme ça ?
Perso je trouve ça bien que chaque client se spécialise pour certains types de plate-forme uniquement, ça permet de monter en qualité et donc de fournir une meilleur expérience utilisateur.
Je pense que les développements sur Ğecko devraient se concentrer exclusivemet sur l’UX mobile, et les développement sur Tikka exclusivement sur l’UX desktop.
@poka pour les personnes ayant un mobile qui est sur un os libre, ce serait bien d’avoir une version linux mais dont l’UX et l’interface reste conçue pour les écrans mobiles, tu voit ce que je veut dire ?
2 Likes
Moi je vois parfaitement et ça répondrait à mon besoin vu que mon tél actuel est sous Linux. Il y a aussi des widgets qui adaptent leur comportement selon la taille de l’écran. Donc possible en théorie de servir les deux mondes.
1 Like
Ahahah ok j’ai compris le problème …
C’est ma faute: Ce que je vous ai pas dit c’est qu’actuellement Gecko en encore connecté au noeud GVA d’elois, mais en scrède… Du coup si tu recherche n’importe quoi d’autre qu’une address gdev, comme le pseudo “elois”, la recherche va tapper dans GVA et Cs+, donc de la G1.
Et je n’avais tout simplement pas remarqué que tout le workflow de paiement semble fonctionner comme si tout allait bien, oklm, et tenter de payer des ĞDev vers des comptes Ğ1, jusqu’au timeout car c’est une address invalide pour Duniter je présume.
C’est drôle, mais je vais retirer totalement GVA et Cs+ pour les prochains builds, et limiter la recherche…
… je m’y était attaché, j’ai passé du temps dessus ^^
3 Likes
Si je comprend bien, si une adresse (clé publique) ne commence pas par 5, elle ne correspond pas à la gdev.
D’où l’intérêt de toujours indiquer les clés publiques concernées quand on signale un comportement inattendu.
2 Likes