uCoin-app : Android client app


#21

Merci pour tes réponses claires. ca roule ! :wink:


#22

OK, c’est déployé sur metab.ucoin.io. Quelques exemples, ça m’évite d’écrire de la doc :smile: :

Et comme demandé, tu trouveras pour chaque transaction le n° de block et la date/heure du block.

Allez, plus qu’à attendre l’appli Android ! :sunglasses:


#23

Est-ce prévu pour être une API disponible pour tout les noeuds ou être une API “haut niveau” ?


#24

Pour tous les noeuds.


#25

YahooOOo !
I will integrate that as soon as possible. Thanks !


#26

Il manque juste une méthode pour visualiser ce qui est en attente (envoi et/ou réception) sans avoir a récupérer tout l’historique. Je la publierai ce soir si j’ai le temps :slight_smile:


#27

Salut @cgeek
J’ai pu inétgrer l’historique en partie dans l’App.
Il me manque les UD… as tu possibilité de les ajouter dans l’historique ? Sinon, avec les IN/OUT de la WoT, pas facile de savoir rapidement les retrouver, avec les dates, etc.

Merci Merci !


#28

Pour les dividendes, il faut regarder de ce côté : http://metab.ucoin.io/tx/sources/HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk


#29

@cgeek oui, j’ai déjà essayé comme ca, mais les UD qui ont été consommés par des transactions n’y sont pas. Cela ne permet pas de reconstituer l’historique des opérations… (et par ailleurs, il y manque le “time”).

Désolé d’être aussi exigeant, mais avec les smartphones ont a des connexions limitées, alors il faut tout optimiser sinon les perfs sont vraiment mauvaise. (Pour arriver je bricole déjà bcp… et ca commence à être parfois long)


#30

Sur cutecoin on ne parse pas les DU non plus, l’api ne le permettant pas.


#31

Dans le même temps, si l’écran développé est “historique des transactions”, alors il n’y a pas lieu d’afficher les DU vu que ce ne sont pas des transactions.

Si par contre vous voulez développer un écran “flux monétaires” ou mieux “historique du solde”, je comprendrais le besoin. Dans ce cas, je pourrais ajouter le champ time dans http://metab.ucoin.io/tx/sources/[pubkey], ainsi que d’ajouter les URLs:

afin de vous laisser le choix de filtrer les données à rapatrier.

Qu’en pensez-vous, @kimamila, @Inso ?


#32

Les sources étant changeantes de block en block, je ne pense pas que ça soit une solution.

Il faudrait l’équivalent de ‘tx/history’… Par exemple, ‘du/history’ :slight_smile:


#33

Disons que si vous avez l’historique des transactions, alors vous avez nécessairement les DU consommés, donc non présents dans /tx/sources.

Mais bon, je comprends bien la volonté de disposer d’une API qui vous facilite la vie. Je ne vous en veux pas ! :slight_smile:


#34

Oui, c’est ca plutot :slight_smile:
En gros le besoin c’est de récupérer un DIFF des changements sur le compte. Après c’est à nous de recouper le truc si on veut.

Pour la solution, moi je suis pas trop fan d’avoir plein de fonctions différentes : chaque appel HTTP est long (établissement de la connection, parsing du résultat, etc). Il vaut mieux en avoir moins (même s’ils ont légèrement plus de données).


#35

Oui je comprends, après je ne peux pas partir du principe que mes clients sont tous des mobiles, j’ai besoin d’un minimum de cohérence dans l’API. Et rien n’empêche une autre API de voir le jour plus tard, focalisée sur les besoins mobiles.

Bref, un /ud/history comme évoqué par @Inso, ça te va aussi ?


#36

C’est une mauvaise idée de demander au serveur de faire plus en terme de calculs et de puissance, sous prétexte que le client mobile ne le peut pas. Ce n’est pas une approche modulaire.

Une approche modulaire serait de se dire : le mobile est plus proche d’un terminal passif que d’un serveur, étant donné l’écart de puissance. DONC, la solution, qui existe d’ailleurs dans quantité d’autres domaines, c’est de mettre en place un AMPLIFICATEUR intermédiaire pour les mobiles.

De la même façon que la difficulté pour gérer soi-même son propre serveur a une solution intermédiaire qui est l’hébergement mutualisé.

Donc tu peux très bien imaginer un serveur intermédiaire qui fait les calculs nécessitant de la puissance, connecté au réseau P2P uCoin, sur lequel ton mobile se connecte afin de donner des informations rapides à l’utilisateur. Serveur intermédiaire qui peut ensuite être pensé soit comme mutualisé soit comme individuel au choix de l’utilisateur.

Et tes problèmes sont résolus par modularité plutôt que se référer encore et toujours à la source (ce qui revient à une approche provoquant la centralisation). Le réseau P2P devrait lui être le plus light possible.


#37

Je pense qu’on s’achemine vers un réseau p2p avec des noeuds “pauvres” en API qui se concentreront sur la création des blocs et seront abandonnés par les applis clientes et des noeuds “riches” en API, qui utiliseront Elasticsearch et seront utilisés par les applis clientes.

Pour des raisons de sécurité, Elasticsearch doit être certifié et protégé par un noeud ucoin.
Mais si on trouve un moyen (plugin Elasticsearch en java) de “certifier” un serveur ES comme étant de confiance, on pourra même se passer du noeud ucoin, et l’appli cliente pourrait attaquer directement ES.


#38

J’approuve :thumbsup:

ElasticSearch ou autre chose, d’ailleurs.

Chaque noeud pouvant bénéficier de n interfaces réseau, toutes certifiées vu que le noeud signe cette déclaration d’interfaces, il peut très bien cibler entre autres un serveur ElasticSearch.

Si je prend par exemple mon noeud, on peut imaginer qu’il dispose d’une interface ES :

Version: 1
Type: Peer
Currency: meta_brouzouf
PublicKey: HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk
Block: 13878-000017F28765E1DFDF70BE3BCB1476C1C410FD94
Endpoints:
BASIC_MERKLED_API metab.ucoin.io 88.174.120.187 9201
ELASTIC_SEARCH elastic.metab.ucoin.io 80
JqUHLmSU6N7WFqnwU+p/bgCYwZdsYQQ2GPGkdv4qx5/AUoa4dFwGpSQUhZTMmvGOMt/5lEcGtJYSl/HGGkyfBg==

Est-ce que ça ne répond pas à la problématique ?


#39

Parfait ça. On interroge un noeud ucoin qui renvoie sur un explorateur de blockchain disposant d’une API “haut niveau”.
ES ou autre. J’achète ! :smile:


#40

On est d’accord, c’est pourquoi j’ai monté commencé à travailler sur une API haut niveau (serveur ES : http://data.ucoin.fr).
Mais chaque chose en son temps. Les premières versions des clients peuvent très bien exploiter l’API de base.

Malgré tout, justement pour simplifier l’API du réseau P2P, il me semble mieux (pour tous les clients d’ailleurs, pas que les smartphones) d’avoir une seule fonction d’historique qui renvoit toutes les opérations (dont les DU). Plus on fait de fonctionnalités différentes (ou découpées), plus ce sera dur à maintenir. Enfin je crois.

Bref, oui ca me va : je me vais débrouiller avec, t’inquiètes ! ;o)

Merci encore