uCoin-app : Android client app

Archives Mobile apps
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:

1 Like
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:

1 Like
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:

1 Like
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.

1 Like
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:

1 Like
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