I just started a GUI Client, for Android smartphones. Developpement use Android Studio (lastest version), and Android NDK (Native Developpement Kit) to be able to use TweetNaCl (a compact crypto library).
I need designers, testers and developpers. Who is interested ?
I am not a Android expert. I just started to develop on it, so be patient ! The first target is smartphones.
Main idea is to be able :
to manage a contact list, using (if possible) smartphone contacts
to lookup/sign someone
to paid someone (a store, …)
to paid from a smartphone to another, even if there is no Internet connection (like sending a signed transaction document ?)
to see transfer history, with a indicator when a transaction has been processed by the blockchain
balance
to manage multi-account. The idea is to never store salt/passwd of the main account (signed account for member with UD), but use attached accounts for daily transaction, with saved salt/passwd (because it’s boring to fill it for each payment !). e.g. once by month, you should connect with the main account and transfer your UD on secondary accounts. So if you loose your smartphone, you keep your main account secure.
The connection to the main account could also be asked automatically (when a transfer from secondaries account’s could not be done)
In another project, i think it could be usefull to send/receive SMS, for simple phone. This has been done for instance on cyclos (version 3 or 4). This should be achieved by a server application.
It is the kind of image that I want to touch to change the values !!
And the units have selectors, so we can display many referencing system to help our brain to better understand the power of a relative money system…
Je fait un clone j’essaye de faire un test mobile et tab note 10, peut être demain.
Sous Android, Cyanogen mod, avec Android Studio, Gradle et Eclipse last build et aussi peut être armhf Debian 7 et 8 pour Cutecoin et Android sunxi pour ta version Android …
cool ! ;o)
Surtout n’hésites pas à remonter tes remarques/modifs.
Pour info je suis en train de faire un gros merge, avec la branche de @smoul, notamment pour être compatible “material design”. (passage de certain écran en dialog, navigation entre les onglets par glissé droite/gauche, etc.). Bref ca promet !
J’attends avec impatience une évolution de l’API de @cgeek pour télécharger plus simplement les transactions d’un utilsiateurs. apèrs cela je pourrais releaser une version stable.
Attention par contre, certaines transactions sont mal indexées et apparaissent “vides”. Il me semble que cela se produit uniquement avec les transactions émises après que j’ai déployé cette fonction d’historique.
Mais déjà, tu peux faire tes développements !
edit : il manque certainement le n° de block et la date/heure. J’ajouterai certainement cette info bientôt.
Wahoo !!! Merci @cgeek : Noel est à Paques cette année
je regarde ca en fin de semaine prochaine (pas dispo avant) et te remonte mes remarques.
EDIT: j’ai regardé un peu, c’est vraiment excellent ! Effectivement, il va me manquer : le timestamp, le n° de block.
Autres questions :
Sinon, je ne vois pas à quoi sert le nom de la monnaie, répété à chaque transaction ? idem pour la version
Pour que les clients puissent faire de la mise à jour incrémentielle, est possible d’avoir un filtre ? Par exemple “à partir du block N” (à la mode elasticSearch : tx/history/?_search=block:N ?)
Un autre besoin est savoir si une transaction est passée dans la blockchain. Par exemple /tx/ ?
Enfin, quel tri est appliqué sur cette liste ? Est il garantie ? (je cherche tout les moyens pour éviter les retraitements inutiles des données)
C’est une version encore “brute” de l’API, je ferais bien en effet de virer le nom de la monnaie et le mettre à la racine de la réponse. Par contre pour la version, ça peut changer même si a priori c’est toujours 1 … donc je le laisse.
Sinon, pour répondre à tes autres questions, je prévois :
de pouvoir filtrer entre 2 blocks
de pouvoir filtrer entre 2 dates/heure (timestamps quoi)
de pouvoir lister les transactions en attente (sous le champ waiting par exemple, au même niveau que sent et received)
Pour le tri … il est chronologique (block). Mais tu ne devrais probablement pas faire confiance à ce tri. En plus, je ne crois pas qu’un tri Java soit très coûteux.