manatlan a écrit 1590 commentaires

guy n'est pas exclusivement réservé au dev d'app android !

Une même application, marchera tout aussi bien sur windows, linux, mac ou autres. C'est juste une feature supplémentaire que de pouvoir, aussi, en faire un apk/android.

Accessoirement, côté backend, c'est du python (et pas du java)

Pour quelqu'un qui débute/bidouille en Python, quelles sont les limitations ?

Alors, c'est des contraintes plus liées à kivy/buildozer(p4a) qu'à guy. Je n'ai pas trouvé de liste exhaustive de ce qui marche ou ne marche pas. Mais globalement, il y a plus en plus de choses qui marchent ;-)

Tout ce qui est pure python ne devrait pas poser de problèmes. Tout ce qui utilise des binaires peut être problématique.

Peut-on en mettre plusieurs (par exemple la géolocalisation) ?

Tout à fait ! séparé par des virgules.
J'ai màj la doc pour pointer vers la liste exhaustive d'android

Sans hésiter … Faut partir avec un framework asgi !
Tom Christie est un (très) bon … et starlette un excellent choix (je l'utilise depuis 2ans).
Mais faut targetter un python >=3.7. Starlette n'est toujours pas 3.5 compatible.
Avec les micro tâches … tu peux faire tellement plus de choses, background task, socket, etc … sans sortir l'artillerie lourde (thread/multiprocess …)
Et c'est tellement plus naturel, que tu gagnes énormément en lisibilité/maintenance.
L'avenir est clairement ASGI …
Quant au choix de starlette vs responder … starlette est l'original, responder est une surcouche. Les gars de starlette répondent très vite et bien.

bon, j'ai réussi, après 3/4h de galères, à faire le tuto pour tester la compilation/installation de l'apk sur l'android.
Globalement, ça marche …
(ma plus grosse galère : j'ai du récupérer le répertoire "sources" pour le mettre dans le NDK android (sinon erreur cxx-stl/system) du buildozer)

mais à l'execution, la webview n'arrive pas à se connecter à la socket (sur xiaomi mi9 uptodate).

mais c'est le même résultat que l'apk du playstore.
(est-ce que ça marche chez qqu'un ?)

Donc, c'est ISO ;-)

Merci pour ce post assez clair.

J'édite une couche (https://github.com/manatlan/wuy) qui permet de réaliser "facilement" des GUI sur n'importe quelle plateforme. En utilisant principalement chrome, en mode "app" (un peu comme python-eel, mais en moins buggé).
Le GUI se fait "facilement", en html/js/css … et wuy propose une couche JS qui permet de discuter facilement avec la partie serveur, via des websockets. Côté serveur, une couche python permet de discuter facilement avec le GUI. Accessoirement, c'est très facile de générer un "exe" pour chaque OS. Mais ça necessite d'avoir chrome sur l'os hôté.
Alternativement, j'ai fait des tests avec cefpython3, pour embbeded chrome dans l'exe : ça marche à l'identique. (et permet de passer outre la necessité d'avoir chrome sur l'os hôte)

(accessoirement, avec une couche comme vbuild (https://github.com/manatlan/vbuild), il est très simple d'embedder une appli vuejs en python only)

J'aimerai porter cette solution sur android. J'ai un peu testé avec buildozer, mais je ne suis pas arrivé à mes fins. (Côté serveur python, j'utilise aiohttp).

Si je comprends bien, j'aurai 2 options :
- soit je fais, comme toi, j'utilise kivy, pour réutiliser la webview/android. et je devrai arrivé à m'en sortir avec tes infos ^. (en remplaçant tornado par aiohttp)
- soit je persiste et j'essai de buildozer avec cefpython3. (mais ce dernier n'est pas encore compatible android, je crois)

la soluce 1 me paraît plus simple maintenant …
SI j'ai des soucis : tu peux m'aider ?

Wuy aurait fait l'affaire très bien
https://github.com/manatlan/wuy

Juste un petit mot pour parler de vbuild qui permet de packager des vues, et de générer du JS … SANS NODEJS (python only)

Et tu peux même développer tes composants en python, ou en js, et ou les 2… et mixer le tout …

J'ai fait un outil de démo, pour comprendre :
https://manatlan.alwaysdata.net/vbuild/

En anglais j'aurai dit qqchose du style : which let you turn on your script into gui
Mon français n'est pas bon ;-)

Voilà le script originel :
https://github.com/TapTempo-Federation/TapTempo-python27/blob/master/TapTempo.py

Il a bien été "transformé" en GUI (cf dans le post en haut)

NB : la version wuy est plus courte/lisible que la version originelle ;-)

J'ai rajouté qques vrais exemples (des vraies app utilisables IRL):

https://github.com/manatlan/wuy/tree/master/examples

Dont:

• un WuyFreezer, un GUI pour freezer son app en standalone executable (marche sous toutes les plateformes)
• un frontend à 'du' pour chercher les fichiers qui prennent de la place dans son filesystem
• et le fameux taptempo ;-) (je ne m'en lasse pas, même si perso, j'utilise plutôt la version PWA sur mon smartphone ;-)

merci, suis content de donner du rêve ;-)

Je pense qu'on est plein de dev ayant la double compétence python/html-js. Du coup, ça a du sens que de pouvoir proposer le front en js, avec un back en py3. Avec un framework comme vuejs, on arrive rapido à faire des GUIs balaises.
Pour ma part, après avoir bien plongé dans les angular/riotjs/vuejs … refaire du GUI classique me semble fade.

J'ai patché … évitons le troll ;-)

Suis abonné aux articles de sam&max …et celui là, je ne l'avais pas retenu (certainement le titre … goto -> au revoir ;-)
Suis bien content que tu le ramènes ici (surtout un vendredi)

ça m'a fait découvrir "trio". N'étant pas fan d'asyncio : suis ravi ;-)
je vais potasser ça

Je pense que j'aurai passé plus de temps à tenter de le faire s’exécuter, et à comprendre son fonctionnement, que de re-coder "qqchose de similaire"

Voilà un patch pour s'approcher de l'original :

print "tapTempo : press any key (q for quit)"
t=[]
while getKey()!="q":
    t.append( datetime.datetime.now() )
    ll=[ (j-i).microseconds for i, j in zip(t[:-1], t[1:]) ][-5:]
    if ll: print "BPM:",60000000*len(ll)/sum(ll)

NB: j'ai juste décaler à droite, les 2 dernières lignes

J'ai essayé … mais impossible de faire des slice sur le deque … du coup, faut le reconvertir en list avant les slices ;-(

Du coup, ça alourdi le code ;-)

mmmmmmm …. J'ai juste fait qqchose de lisible ;-)

#!/usr/bin/python
# -*- coding: utf-8 -*
import sys,termios,tty,datetime

def getKey():
    fd = sys.stdin.fileno()
    old_settings = termios.tcgetattr(fd)
    try:
        tty.setraw(fd)
        ch = sys.stdin.read(1)
    finally:
        termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)
    return ch

print "tapTempo : press any key (q for quit)"
t=[]
while getKey()!="q":
    t.append( datetime.datetime.now() )

ll=[ (j-i).microseconds for i, j in zip(t[:-1], t[1:]) ][-5:]
print "BPM:",60000000*len(ll)/sum(ll)

la version ++ :

#!/usr/bin/python
# -*- coding: utf-8 -*
import sys,termios,tty,datetime

def getKey():
    fd = sys.stdin.fileno()
    old_settings = termios.tcgetattr(fd)
    try:
        tty.setraw(fd)
        ch = sys.stdin.read(1)
    finally:
        termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)
    return ch

print "tapTempo : press any key (q for quit)"
t=[]
while getKey()!="q":
    t.append( datetime.datetime.now() )

ll=[ (j-i).microseconds for i, j in zip(t[:-1], t[1:]) ][-5:]
print "BPM:",60000000*len(ll)/sum(ll)

#!/usr/bin/python
# -*- coding: utf-8 -*
import sys,termios,tty
from datetime import datetime

def getKey():
    fd = sys.stdin.fileno()
    old_settings = termios.tcgetattr(fd)
    try:
        tty.setraw(fd)
        ch = sys.stdin.read(1)
    finally:
        termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)
    return ch
t=[]
while 1:
    k=getKey()
    if k=="q":
        break
    else:
        t.append( datetime.now() )
t=t[-5:]
ll=[ (j-i).microseconds for i, j in zip(t[:-1], t[1:])]
print 60000/((sum(ll)/len(ll))/1000.0)

Pareil, c'est aussi mon éditeur préféré ;-)
J'avais tenté ATOM, mais j'ai fini sur VSCODE, plus fluide, et des plugins qui fonctionnent. (on ne se retrouve pas en carafe suite à une upgrade)
Il tourne sur win ou nux, ce qui permet de garder ses configs aux petits oignons.
Bref, idéal si on veut un peu plus lourd qu'un SciTE ;-)

Sans vouloir être méchant … et étant, en plus, un fan d'ubuntu(/desktop)

Je pense que c'est à des années lumières (plus sérieusement 10ans) de ce que fait un android (dernier cri) à l'heure actuelle (Avec des features comme google now, on tap, inbox, gcm, google play service, android auto, daydream, google pay, etc …)

Maintenant, je peux comprendre qu'on soit plus intéressé par le côté "rien dans le cloud"(rien chez google) et vie privée sauvegardé, que par le côté bling bling et don des ses données privées aux tiers.

J'étais très fan de la v1, j'en ai fait beaucoup, vraiment beaucoup …
J'ai évidemment sauté sur la v2, et j'en suis arrivé, peu ou prou, aux mêmes conclusions.
La V2 est plus orienté composant (ce qui est une très bonne chose), ça m'a plus fait pensé à un react a la sauce angular. Mais la syntaxe est trop hiéroglyph'isé ;-), et le côté typescript transpilé m'a un peu refroidi aussi.
Alors, tant qu'à faire des composants, et ne voulant pas plonger dans react (jsx est trop abscons), je me suis lancé dans riotjs ; et c'est quasi du pur bonheur.
Certes, c'est moins cadré qu'un angular/react, mais ça laisse une plus grande liberté (très facile d'intégrer des libs tierces)
Certes, il faut rajouter des polyfills (fetch, promise …), car la lib étant très petite, elle n'intègre pas grand chose …
Mais j'ai vraiment trouvé ma lib composant, genre couteau suisse, que tu intègres très facilement partout …
Ces gars là ont trouvé/inventé la façon la plus simple/naturelle de réaliser des composants web.
Après la liberté impose quand même au dev de se faire violence pour faire bien (pour des gros projets).

Javascript ne va pas droit dans le mur ;-)

L'avenir est à WebAssembly sans conteste ! Mais JS restera là, à côté (compatibilité + petits trucs).

La transpilation "était" à la mode (coffee, typescript, dart, …) : pour apporter de la "facilité de dev".

Maintenant, pour aller encore plus loin, on va vers la compilation (vers le webasm) à partir de n'importe quel autre langage (que demander de plus ?!).

Certes, on fera moins de JS pure. Mais il restera à côté de webasm. Il reviendra à la place pour laquelle il était destiné, au début.

Mais sans l'être vraiment ;-)
Après tout c'est vendredi ;-)
Suis sous ubuntu, depuis 2005 (10ans déjà, mince !) … J'ai bien connu une migration de desktop, vers unity … Mais au final, c'est mieux maintenant !
Les gué-guères GNOME/gtk vs KDE/qt c'est du passé … "Linux", pour moi, c'est soit Android, soit ubuntu, ou soit les machines annexes (freebox, squeezebox, chromebook, TV, nas, etc…)
Ça fait bizarre de relire des posts comme celui ci, à notre époque ;-)
Ça fait longtemps qu'on n'a plus de problèmes sous Ubu ;-)

Peux tu donner les grandes lignes de ta config Serveur VPN sur la FBX ?
(et quel client vpn android tu utilises (natif? ?)

J'ai jamais réussi à le faire marcher : ça se connecte, mais la cnx data ne semble pas fonctionner …

Client chez free mobile, depuis 2012, avec le gros forfait 34/4G-20go (16euros).

En 4G : ça vient, ça vient … J'ai une barre au boulot, et une à la maison : débit plus que correct (même ainsi, ça reste bien plus rapide que la 3G)!

En 3G : c'est de plus en plus rare les endroits où on a rien (au pire de l'edge). Les débits sont corrects UNIQUEMENT SI tu es scotché sur une antenne FREE. Si tu es sur une antenne orange : tu n'as que le surf (mais faut oublier le playstore, youtube, les streaming mp3, etc ….).

Faut vraiment installer "NetStat"(android), qui t'affiche un icone "F" ou "O" suivant que tu sois sur une antenne FREE ou en itinérance Orange.
Et il FAUT FUIR les antennes ORANGE comme la peste ! (quand il n'y en aura plus, on aura plus de chance de scotché une antenne free de préférence ;-) )

J'apprécie énormément l'accès data "gratuit" dans les pays européens, très pratique. (manque la suisse, et c'est parfait!)

J'apprécie ENORMEMENT, la connexion EAP/SIM aux WIFI FREEBOX_SECURE : Où que tu sois, dans une ville : tu lances le WIFI, et ça se connecte sur la première freebox des environs (et il y en a partout !), sans authent. Et ça c'est très pratique, et ça peut remplacer le besoin data/3g/4g, modulo le fait qu'il ne faut plus bouger le temps de la cnx wifi ;-)

Mais c'est clair que : se séparer d'orange : autant dans les grosses villes : ça semble jouable. Autant ailleurs : j'ai de gros doutes ;-(
(Mais si d'après les stats : les phones freemobile scotchent à 58% sur du free … ça monte, ça monte)