Docs Beeware Org FR Latest
Docs Beeware Org FR Latest
Docs Beeware Org FR Latest
Version 0.1.dev90+gdcb5cd9
Russell Keith-Magee
2 C’est parti ! 5
2.1 Tutoriel 0 - Préparons-nous ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Tutoriel 1 - Votre première application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Tutoriel 2 - Rendre les choses intéressantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Tutoriel 3 - Emballage pour la distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Tutoriel 4 - Mise à jour de votre application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 Tutoriel 5 - Rendre votre application mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7 Tutoriel 6 - Mettez-le sur le web ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.8 Tutoriel n° 7 - Démarrer cette (troisième) partie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.9 Tutoriel 8 - Le rendre lisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.10 Going further . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
i
ii
BeeWare Documentation, Version 0.1.dev90+gdcb5cd9
Cette version du didacticiel a en partie été générée par une traduction automatique. Nous savons que ce n’est pas la
solution idéale, mais nous avons estimé qu’une mauvaise traduction valait mieux que pas de traduction du tout.
Si vous souhaitez nous aider à améliorer la traduction, n’hésitez pas à nous contacter ! Nous avons un canal
#translations dans Discord ; présentez-vous et nous vous ajouterons à l’équipe de traduction.
BeeWare n’est pas un produit, un outil ou une bibliothèque unique - c’est une collection d’outils et de bibliothèques,
chacun d’entre eux fonctionnant ensemble pour vous aider à écrire des applications Python multiplateformes avec une
interface graphique native. Il comprend :
— Toga, une boîte à outils de widgets multiplateforme ;
— Briefcase, un outil pour empaqueter les projets Python en tant qu’artefacts distribuables pouvant être envoyés
aux utilisateurs finaux ;
— Des bibliothèques (telles que Rubicon ObjC) pour accéder aux bibliothèques natives des diverses plates-formes ;
— Des versions pré-compilées de Python pour les plateformes où les programmes d’installation officiels de Python
ne sont pas disponibles.
Dans ce tutoriel, nous utiliserons tous ces outils, mais en tant qu’utilisateur, vous n’aurez besoin d’interagir qu’avec
les deux premiers (Toga et Briefcase). Cependant, chacun de ces outils peut également être utilisé séparément. Par
exemple, vous pouvez utiliser Briefcase pour déployer une application sans utiliser Toga comme boîte à outils GUI.
La suite BeeWare est disponible pour macOS, Windows, Linux (avec GTK) ; pour des plateformes mobiles telles qu’An-
droid et iOS ; et pour le Web.
3
BeeWare Documentation, Version 0.1.dev90+gdcb5cd9
C’est parti !
Prêt à essayer BeeWare par vous-même ? Créons une application multiplateforme en Python !
Avant de créer notre première application BeeWare, nous devons nous assurer que nous disposons de tous les prérequis
pour le fonctionnement de BeeWare.
La première chose dont nous avons besoin est un interpréteur Python fonctionnel.
macOS
Linux
Windows
Si vous utilisez macOS, une version récente de Python est incluse dans Xcode ou dans les outils de développement en
ligne de commande. Pour vérifier si vous l’avez déjà, exécutez la commande suivante :
$ python3 --version
Si Python est installé, vous verrez son numéro de version. Sinon, vous serez invité à installer les outils de développement
en ligne de commande.
Si vous êtes sous Windows, vous pouvez obtenir l’installateur officiel à partir du site web de Python. Vous pouvez
utiliser n’importe quelle version stable de Python à partir de la 3.8. Nous vous conseillons d’éviter les versions alpha,
beta et release candidates à moins que vous ne sachiez vraiment ce que vous faites.
Si vous êtes sous Linux, vous installerez Python en utilisant le gestionnaire de paquets du système (apt sur De-
bian/Ubuntu/Mint, dnf sur Fedora, ou pacman sur Arch).
5
BeeWare Documentation, Version 0.1.dev90+gdcb5cd9
Vous devez vous assurer que le Python du système est Python 3.8 ou plus récent ; si ce n’est pas le cas (par exemple,
Ubuntu 18.04 est livré avec Python 3.6), vous devrez mettre à jour votre distribution Linux vers quelque chose de plus
récent.
La prise en charge du Raspberry Pi est limitée pour le moment.
Si vous êtes sous Windows, vous pouvez obtenir l’installateur officiel à partir du site web de Python. Vous pouvez
utiliser n’importe quelle version stable de Python à partir de la 3.8. Nous vous conseillons d’éviter les versions alpha,
beta et release candidates à moins que vous ne sachiez vraiment ce que vous faites.
Il existe de nombreuses façons d’installer Python. Vous pouvez installer Python via homebrew. Vous pouvez utiliser
pyenv pour gérer plusieurs installations de Python sur la même machine. Les utilisateurs de Windows peuvent ins-
taller Python à partir du Windows App Store. Les utilisateurs ayant une formation en science des données pourraient
préfèrer utiliser Anaconda ou Miniconda.
Si vous êtes sous macOS ou Windows, peu importe comment vous avez installé Python – ce qui compte c’est que
vous puissiez lancer python3 à partir de l’invite de commande/terminal de votre système d’exploitation, et obtenir
un interpréteur Python fonctionnel.
Si vous êtes sous Linux, vous devez utiliser le Python fourni par votre système d’exploitation. Vous pourrez réaliser
la majeure partie de ce tutoriel en utilisant un Python non système, mais vous ne pourrez pas empaqueter votre
application pour la distribuer à d’autres.
Fedora
$ sudo dnf install git gcc make pkg-config rpm-build python3-devel gobject-introspection-
˓→devel cairo-gobject-devel gtk3 libcanberra-gtk3
Arch, Manjaro
$ sudo pacman -Syu git base-devel pkgconf python3 gobject-introspection cairo gtk3␣
˓→libcanberra
OpenSUSE Tumbleweed
˓→module
Nous allons maintenant créer un environnement virtuel – un « bac à sable » (sandbox) que nous pouvons utiliser
pour isoler notre travail sur ce tutoriel de notre installation Python principale. Si nous installons des paquets dans
l’environnement virtuel, notre installation principale de Python (et tout autre projet Python sur notre ordinateur) ne
sera pas affectée. Si nous provoquons un désordre complet dans notre environnement virtuel, nous pourrons simplement
l’effacer et recommencer, sans affecter aucun autre projet Python sur notre ordinateur, et sans avoir besoin de réinstaller
Python.
macOS
Linux
Windows
$ mkdir beeware-tutorial
$ cd beeware-tutorial
$ python3 -m venv beeware-venv
$ source beeware-venv/bin/activate
$ mkdir beeware-tutorial
$ cd beeware-tutorial
$ python3 -m venv beeware-venv
$ source beeware-venv/bin/activate
C:\...>md beeware-tutorial
C:\...>cd beeware-tutorial
C:\...>py -m venv beeware-venv
C:\...>beeware-venv\Scripts\activate
Votre compte Windows n’a pas les autorisations nécessaires pour exécuter des scripts. Pour y remédier :
1. Run Windows PowerShell as Administrator.
2. Exécutez set-executionpolicy RemoteSigned
3. Sélectionnez « O » pour modifier la politique d’exécution.
Une fois que vous avez fait cela, vous pouvez exécuter à nouveau beeware-venv\Scripts\activate.ps1 dans
votre session PowerShell d’origine (ou dans une nouvelle session dans le même répertoire).
Si cela a fonctionné, votre prompt devrait maintenant être modifié – il devrait avoir un préfixe (beeware-venv). Cela
vous permet de savoir que vous êtes actuellement dans votre environnement virtuel BeeWare. Chaque fois que vous
travaillerez sur ce tutoriel, vous devrez vous assurer que votre environnement virtuel est activé. Si ce n’est pas le cas,
relancez la dernière commande (la commande activate) pour réactiver votre environnement.
Si vous utilisez Anaconda ou miniconda, vous êtes peut-être plus familier avec l’utilisation des environnements
conda. Vous avez peut-être aussi entendu parler de virtualenv, un prédécesseur du module intégré venv de
Python. De même pour les installations de Python – si vous êtes sous macOS ou Windows, peu importe comment
vous créez votre environnement virtuel, tant que vous en avez un. Si vous êtes sous Linux, vous devriez vous en
tenir à venv et au Python du système.
Nous avons maintenant mis en place notre environnement. Nous sommes prêts àcréer notre première application Bee-
Ware.
Tout d’abord, nous devons installer Briefcase. Briefcase est un outil BeeWare qui peut être utilisé pour empaqueter
votre application afin de la distribuer aux utilisateurs finaux – mais il peut également être utilisé pour démarrer un
nouveau projet. Assurez-vous d’être dans le répertoire beeware-tutorial que vous avez créé lors duTutorial 0, avec
l’environnement virtuel beeware-venv activé, et exécutez :
macOS
Linux
Windows
Si vous rencontrez des erreurs pendant l’installation, c’est très certainement parce que certains des prérequis du
système n’ont pas été installés. Assurez-vous d’avoirinstallé tous les prérequis de la plateforme.
Il est important que vous utilisiez python -m pip, plutôt qu’un simple pip. Briefcase doit s’assurer qu’il a une
version à jour de pip et de setuptools, et une simple utilisation de pip ne peut pas se mettre à jour d’elle-même.
Si vous voulez en savoir plus, Brett Cannon a publié un billet de blog détaillé sur ce sujet.
L’un des outils de BeeWare est Briefcase. Briefcase peut être utilisé pour empaqueter votre application afin de la
distribuer aux utilisateurs finaux, mais il peut également être utilisé pour démarrer un nouveau projet.
Commençons notre premier projet BeeWare ! Nous allons utiliser la commande new de Briefcase pour créer une appli-
cation appelée Hello World. Exécutez la commande suivante à partir de votre invite de commande :
macOS
Linux
Windows
Briefcase nous demandera quelques détails sur notre nouvelle application. Pour les besoins de ce tutoriel, nous utilise-
rons les éléments suivants :
— Formal Name (Nom formel) – Acceptez la valeur par défaut : Hello World.
— App Name (Nom de l’application) - Acceptez la valeur par défaut : helloworld.
— Bundle - Si vous possédez votre propre domaine, entrez ce domaine en ordre inverse. (Par exemple, si vous
possédez le domaine « cupcakes.com », entrez com.cupcakes comme bundle). Si vous ne possédez pas votre
propre domaine, acceptez le bundle par défaut (com.example).
— Project Name (Nom du projet) - Acceptez la valeur par défaut : Hello World.
— Description - Acceptez la valeur par défaut (ou, si vous voulez être vraiment créatif, trouvez votre propre
description !)
— ** Author** (Auteur) - Entrez votre propre nom ici.
— Author’s email (adresse email) - Entrez votre propre adresse email. Elle sera utilisée dans le fichier de confi-
guration, dans le texte d’aide, et partout où un email est requis lors de la soumission de l’application à un app
store (magasin d’applications).
— URL - L’URL de la page d’accueil de votre application. Encore une fois, si vous possédez votre propre
domaine, entrez une URL sur ce domaine (y compris le https://). Sinon, acceptez l’URL par défaut
(https ://example.com/helloworld`). Cette URL n’a pas besoin d’exister (pour l’instant) ; elle ne sera utilisée
que si vous publiez votre application dans un magasin d’applications.
— License (Licence) - Acceptez la licence par défaut (BSD). Cela n’affecte en rien le fonctionnement du tutoriel,
donc si vous avez des opinions fortes à ce sujet, n’hésitez pas à en choisir une autre.
— GUI framework (framework d’interface utilisateur graphique) - Acceptez l’option par défaut, Toga (la boîte à
outils GUI de BeeWare).
Briefcase va alors générer un squelette de projet que vous pourrez utiliser. Si vous avez suivi ce tutoriel jusqu’ici, et
accepté les paramètres par défaut tels que décrits, votre système de fichiers devrait ressembler à quelque chose comme
ceci :
beeware-tutorial/
beeware-venv/
...
helloworld/
CHANGELOG
LICENSE
pyproject.toml
README.rst
src/
helloworld/
app.py
__init__.py
__main__.py
resources/
README
tests/
helloworld.py
__init__.py
test_app.py
Ce squelette est en fait une application pleinement fonctionnelle, sans avoir rien à ajouter d’autre. Le dossier src
contient tout le code de l’application, le dossier tests contient une suite de tests initiale, et le fichier pyproject.
toml décrit comment empaqueter l’application pour la distribuer. Si vous ouvrez pyproject.toml dans un éditeur,
vous verrez les détails de la configuration que vous venez de fournir à Briefcase.
Maintenant que nous avons une ébauche d’application, nous pouvons utiliser Briefcase pour l’exécuter.
Entrez dans le répertoire du projet helloworld et faites démarrer le projet en mode développeur (ou dev) par briefcase :
macOS
Linux
Windows
(beeware-venv) $ cd helloworld
(beeware-venv) $ briefcase dev
(beeware-venv) $ cd helloworld
(beeware-venv) $ briefcase dev
Appuyez sur le bouton de fermeture (ou sélectionnez Quitter dans le menu d’application), et c’est terminé ! Félicitations,
vous venez d’écrire une application native et autonome en Python !
Nous avons maintenant une application fonctionnelle, s’exécutant en mode développeur. Nous pouvons maintenant
ajouter notre propre logique pour que notre application fasse quelque chose d’un peu plus intéressant. DansTutoriel 2,
nous allons ajouter à notre application une interface utilisateur plus utile.
Dans leTutoriel 1, nous avons généré une ébauche de projet capable de s’exécuter, mais nous n’avons pas écrit de code
nous-mêmes. Jetons un coup d’œil à ce qui a été généré pour nous.
Dans le répertoire src/helloworld, vous devriez voir 3 fichiers : __init__.py, __main__.py et app.py.
__init__.py marque le répertoire helloworld comme un module Python importable. C’est un fichier vide ; le simple
fait qu’il existe indique à l’interpréteur Python que le répertoire helloworld définit un module.
Le fichier __main__.py marque le module helloworld comme un type spécial de module - un module exécutable. Si
vous essayez d’exécuter le module helloworld'' en utilisant ``python -m helloworld'', le fichier
``__main__.py est l’endroit où Python commencera à s’exécuter. Le contenu de __main__.py` est relativement
simple :
if __name__ == "__main__":
main().main_loop()
Il importe la méthode main de l’application helloworld, et s’il est exécuté en tant que point d’entrée, il appelle la
méthode main(), et démarre la boucle principale de l’application. La boucle principale est la façon dont une application
GUI écoute les entrées de l’utilisateur (comme les clics de souris et les pressions sur le clavier).
Le fichier le plus intéressant est app.py - il contient la logique responsable de la création de notre fenêtre d’application :
import toga
from toga.style import Pack
from toga.style.pack import COLUMN, ROW
class HelloWorld(toga.App):
def startup(self):
main_box = toga.Box()
self.main_window = toga.MainWindow(title=self.formal_name)
self.main_window.content = main_box
self.main_window.show()
def main():
return HelloWorld()
import toga
from toga.style import Pack
from toga.style.pack import COLUMN, ROW
Tout d’abord, nous importons la boîte à outils toga, ainsi que quelques classes et constantes utilitaires liées au style.
Notre code ne les utilise pas encore, mais nous les utiliserons bientôt.
Ensuite, nous définissons une classe :
class HelloWorld(toga.App):
Chaque application Toga possède une seule instance toga.App, représentant l’entité en cours d’exécution, c’est-à-dire
notre application. L’application peut gérer plusieurs fenêtres, mais pour les applications simples, il n’y aura qu’une
seule fenêtre principale.
Ensuite, nous définissons une méthode de démarrage startup() :
def startup(self):
main_box = toga.Box()
La première chose que fait la méthode de démarrage est de définir une boîte principale. Le schéma de présentation de
Toga est similaire à celui du HTML. Vous construisez une application en construisant une collection de boîtes, chacune
d’entre elles contenant d’autres boîtes, ou de véritables widgets. Vous appliquez ensuite des styles à ces boîtes pour
définir la manière dont elles utiliseront l’espace disponible dans la fenêtre.
Dans cette application, nous définissons une seule boîte, mais nous n’y mettons rien.
Ensuite, nous définissons une fenêtre dans laquelle nous pouvons placer cette boîte vide :
self.main_window = toga.MainWindow(title=self.formal_name)
Cela crée une instance de toga.MainWindow, qui aura un titre correspondant au nom de l’application. Une fenêtre
principale est un type spécial de fenêtre dans Toga - c’est une fenêtre qui est étroitement liée au cycle de vie de l’appli-
cation. Lorsque la fenêtre principale est fermée, l’application se termine. La fenêtre principale est également la fenêtre
qui contient le menu de l’application (si vous êtes sur une plateforme comme Windows où les barres de menu font
partie des fenêtres).
Nous ajoutons ensuite notre boîte vide au contenu de la fenêtre principale et demandons à l’application d’afficher notre
fenêtre :
self.main_window.content = main_box
self.main_window.show()
Enfin, nous définissons une méthode main(). C’est elle qui crée l’instance de notre application :
def main():
return HelloWorld()
Cette méthode main() est celle qui est importée et invoquée par main__.py. Elle crée et retourne une instance de
notre application HelloWorld.
C’est l’application Toga la plus simple possible. Bous allons ajouter notre propre contenu à l’application, et faire en
sorte qu’elle fasse quelque chose de plus intéressant.
ò Note
Ne supprimez pas les imports en haut du fichier, ni le main() en bas. Vous n’avez besoin de mettre à jour que la
classe HelloWorld.
Modifiez votre classe HelloWorld dans src/helloworld/app.py pour qu’elle ressemble à ceci :
class HelloWorld(toga.App):
def startup(self):
main_box = toga.Box(style=Pack(direction=COLUMN))
name_label = toga.Label(
"Your name: ",
style=Pack(padding=(0, 5)),
)
self.name_input = toga.TextInput(style=Pack(flex=1))
button = toga.Button(
"Say Hello!",
on_press=self.say_hello,
style=Pack(padding=5),
)
main_box.add(name_box)
main_box.add(button)
self.main_window = toga.MainWindow(title=self.formal_name)
self.main_window.content = main_box
self.main_window.show()
main_box = toga.Box(style=Pack(direction=COLUMN))
Le système de mise en page intégré à Toga s’appelle « Pack ». Il se comporte en grande partie comme CSS. Vous
définissez des objets dans une hiérarchie - en HTML, les objets sont <div>, <span>, et d’autres éléments DOM ;
dans Toga, ce sont des widgets et des boîtes. Vous pouvez ensuite attribuer des styles aux différents éléments. Dans ce
cas, nous indiquons qu’il s’agit d’une boîte COLUMN - c’est-à-dire qu’il s’agit d’une boîte qui utilisera toute la largeur
disponible, et qui augmentera sa hauteur au fur et à mesure que du contenu sera ajouté, mais qui essaiera d’être aussi
courte que possible.
Ensuite, nous définissons quelques widgets :
name_label = toga.Label(
"Your name: ",
style=Pack(padding=(0, 5)),
)
self.name_input = toga.TextInput(style=Pack(flex=1))
Ici, nous définissons un Label (widget de texte) et un TextInput (widget de saisie de texte). Les deux widgets sont
associés à des styles ; le Label aura un espace de 5 px à gauche et à droite, et aucun espace en haut et en bas. Le
TextInput est marqué comme étant flexible, c’est-à-dire qu’il absorbera tout l’espace disponible dans son axe de mise
en page.
Le TextInput est assigné en tant que variable d’instance d classe. Cela nous permet d’accéder facilement à l’instance
du widget, ce que nous utiliserons dans un instant.
Ensuite, nous définissons une boîte pour contenir ces deux widgets :
La name_box est une boîte comme la boîte principale, mais cette fois, c’est une boîte ROW (rangée). Cela signifie que
le contenu sera ajouté horizontalement, et qu’il essaiera d’être le moins large possible. La boîte a également un peu de
padding (espace) - 5px sur tous les côtés.
Nous définissons maintenant un bouton :
button = toga.Button(
"Say Hello!",
on_press=self.say_hello,
style=Pack(padding=5),
)
Le bouton est également doté d’un espace de 5 px sur tous les côtés. Nous définissons également un handler - une
méthode à invoquer lorsque le bouton est pressé.
Ensuite, nous ajoutons la boîte de nom et le bouton à la boîte principale :
main_box.add(name_box)
main_box.add(button)
Le reste de la méthode de démarrage est identique à la précédente : définition d’une fenêtre principale et attribution de
la boîte principale en tant que contenu de la fenêtre :
self.main_window = toga.MainWindow(title=self.formal_name)
self.main_window.content = main_box
self.main_window.show()
Notre dernière action est de définir le gestionnaire du bouton. Un gestionnaire peut être n’importe quelle méthode,
générateur ou co-routine asynchrone ; il accepte le widget qui a généré l’événement comme argument, et sera invoqué
chaque fois que le bouton est pressé :
Le corps de la méthode est une simple instruction d’affichage (print). Cependant, elle interroge la valeur actuelle de
l’entrée name et utilise ce contenu comme texte à imprimer.
Maintenant que nous avons effectué ces changements, nous pouvons voir à quoi ils ressemblent en relançant l’applica-
tion. Comme précédemment, nous utiliserons le mode développeur :
macOS
Linux
Windows
Vous remarquerez que cette fois-ci, briefcase n’installe pas de dépendances. Briefcase peut détecter que l’application
a déjà été exécutée auparavant, et pour gagner du temps, il n’exécutera que l’application. Si vous ajoutez de nouvelles
dépendances à votre application, vous pouvez vous assurer qu’elles soient installées en passant une option -r lorsque
vous lancez briefcase dev.
Cela devrait ouvrir une fenêtre GUI :
macOS
Linux
Windows
Si vous saisissez un nom dans la zone de texte et que vous appuyez sur le bouton GUI, vous devriez voir apparaître une
sortie dans la console où vous avez démarré l’application.
Nous avons maintenant une application qui fait quelque chose d’un peu plus intéressant. Mais elle ne fonctionne que sur
notre propre ordinateur. Allons empaqueter cette application pour la distribuer. DansTutoriel 3, nous allons empaqueter
notre application sous la forme d’un programme d’installation autonome que nous pourrons envoyer à un ami, un client,
ou télécharger sur un App Store.
Jusqu’à présent, nous avons exécuté notre application en « mode développeur ». Cela nous permet d’exécuter facilement
notre application localement - mais ce que nous voulons vraiment, c’est pouvoir donner notre application à d’autres
personnes.
Cependant, nous ne voulons pas avoir à apprendre à nos utilisateurs comment installer Python, créer un environne-
ment virtuel, cloner un dépôt git, et lancer Briefcase en mode développeur. Nous préférons leur donner un programme
d’installation et faire en sorte que l’application fonctionne tout simplement.
Briefcase peut être utilisé pour empaqueter votre application afin de la distribuer de cette manière.
Puisque c’est la première fois que nous empaquetons notre application, nous devons créer quelques fichiers de configu-
ration et autres échafaudages pour supporter le processus d’empaquetage. Depuis le répertoire helloworld, exécutez :
macOS
Linux
Windows
...
...
...
Vous venez probablement de voir défiler des pages de contenu dans votre terminal. . . que s’est-il passé ? Briefcase a
fait ce qui suit :
1. Il génère un modèle d’application. Il y a beaucoup de fichiers et de configurations nécessaires pour construire
un installateur natif, en plus du code de votre application réelle. Cet échafaudage supplémentaire est presque le
même pour chaque application sur la même plateforme, à l’exception du nom de l’application réelle en cours
de construction - Briefcase fournit donc un modèle d’application pour chaque plateforme qu’il supporte. Cette
étape déploie le modèle, en substituant le nom de votre application, l’ID du bundle, et d’autres propriétés de
votre fichier de configuration comme requis pour supporter la plateforme sur laquelle vous construisez.
Si vous n’êtes pas satisfait du modèle fourni par Briefcase, vous pouvez créer votre propre modèle. Cependant,
vous ne voudrez probablement pas faire cela avant d’avoir un peu plus d’expérience dans l’utilisation du modèle
par défaut de Briefcase.
2. Il télécharge et installe un paquetage de support. L’approche d’empaquetage adoptée par Briefcase est décrite
comme « la chose la plus simple qui puisse fonctionner » - elle fournit un interpréteur Python complet et
isolé dans le cadre de chaque application qu’elle construit. Cette approche est légèrement inefficace en termes
d’espace - si vous avez 5 applications empaquetées avec Briefcase, vous aurez 5 copies de l’interpréteur Python.
Cependant, cette approche garantit que chaque application est complètement indépendante, utilisant une version
spécifique de Python connue pour fonctionner avec l’application.
Encore une fois, Briefcase fournit un paquetage de support par défaut pour chaque plateforme ; si vous le sou-
haitez, vous pouvez fournir votre propre paquetage de support, et faire en sorte que ce paquetage soit inclus
dans le processus de construction. Vous pouvez faire cela si vous avez des options particulières dans l’interpré-
teur Python que vous devez activer, ou si vous voulez retirer de la bibliothèque standard les modules dont vous
n’avez pas besoin au moment de l’exécution.
Briefcase maintient un cache local des paquets de support, de sorte qu’une fois que vous avez téléchargé un
paquet de support spécifique, cette copie en cache sera utilisée dans les futures versions.
As noted above, when Briefcase packages an app as a native Linux system package (the default package format
for Linux), a support package is not included with the app. Instead, the app will use the Python that is provided
by the distribution of Linux being targeted.
3. Il installe les exigences de l’application. Votre application peut spécifier tous les modules tiers qui sont né-
cessaires à l’exécution. Ceux-ci seront installés en utilisant pip dans l’installeur de votre application.
4. Il installe le code de votre application. Votre application aura son propre code et ses propres ressources (par
exemple, les images nécessaires à l’exécution) ; ces fichiers sont copiés dans le programme d’installation.
5. Il installe les ressources nécessaires à votre application. Enfin, il ajoute toutes les ressources supplémentaires
nécessaires à l’installateur lui-même. Cela inclut des choses comme les icônes qui doivent être attachées à
l’application finale et les images de l’écran d’accueil.
Une fois cette opération terminée, si vous regardez dans le répertoire du projet, vous devriez voir un répertoire corres-
pondant à votre plateforme (macOS, linux, ou windows) qui contient des fichiers supplémentaires. C’est la configura-
tion de l’empaquetage spécifique à la plate-forme pour votre application.
Vous pouvez maintenant compiler votre application. Cette étape permet d’effectuer toute compilation binaire nécessaire
pour que votre application soit exécutable sur votre plate-forme cible.
macOS
Linux
Windows
Sous macOS, la commande build n’a pas besoin de compiler quoi que ce soit, mais elle doit signer le contenu du
binaire pour qu’il puisse être exécuté. Cette signature est une signature ad hoc - elle ne fonctionnera que sur votre
machine ; si vous voulez distribuer l’application à d’autres, vous devrez fournir une signature complète.
...
make: Leaving directory '/home/brutus/beeware-tutorial/helloworld/build/linux/ubuntu/
˓→jammy/bootstrap'
Une fois cette étape terminée, le dossier build contiendra un dossier helloworld-0.0.1 qui contient un miroir du sys-
tème de fichiers Linux /usr. Ce miroir du système de fichiers contiendra un dossier bin avec un binaire helloworld,
ainsi que les dossiers lib et share nécessaires pour supporter le binaire.
Sous Windows, la commande build n’a pas besoin de compiler quoi que ce soit, mais elle doit écrire quelques méta-
données pour que l’application connaisse son nom, sa version, et ainsi de suite.
ò Déclenchement de l’antivirus
Puisque ces métadonnées sont écrites directement dans le binaire précompilé déployé à partir du modèle pendant
la commande create, cela peut déclencher un logiciel antivirus fonctionnant sur votre machine et empêcher les
métadonnées d’être écrites. Dans ce cas, demandez à l’antivirus d’autoriser l’outil (nommé rcedit-x64.exe) à
s’exécuter et relancez la commande ci-dessus.
PYTHONPATH:
- /Users/brutus/beeware-tutorial/helloworld/macOS/app/Hello World/Hello World.app/
˓→Contents/Resources/support/python311.zip
Configure argc/argv...
Initializing Python runtime...
Installing Python NSLog handler...
Running app module: helloworld
---------------------------------------------------------------------------
- /home/brutus/beeware-tutorial/helloworld/build/helloworld/linux/ubuntu/jammy/
˓→helloworld-0.0.1/usr/lib/helloworld/app_packages
Configure argc/argv...
Initializing Python runtime...
Running app module: helloworld
---------------------------------------------------------------------------
===========================================================================
Log started: 2023-04-23 04:47:45Z
PreInitializing Python runtime...
PythonHome: C:\Users\brutus\beeware-tutorial\helloworld\windows\app\Hello World\src
PYTHONPATH:
- C:\Users\brutus\beeware-tutorial\helloworld\windows\app\Hello World\src\python39.zip
- C:\Users\brutus\beeware-tutorial\helloworld\windows\app\Hello World\src
- C:\Users\brutus\beeware-tutorial\helloworld\windows\app\Hello World\src\app_packages
- C:\Users\brutus\beeware-tutorial\helloworld\windows\app\Hello World\src\app
Configure argc/argv...
Initializing Python runtime...
Running app module: helloworld
---------------------------------------------------------------------------
Ceci lancera l’exécution de votre application native, en utilisant la sortie de la commande build.
Il se peut que vous remarquiez de petites différences dans l’apparence de votre application lorsqu’elle est en cours
d’exécution. Par exemple, les icônes et le nom affichés par le système d’exploitation peuvent être légèrement différents
de ceux que vous avez vus lors de l’exécution en mode développeur. Cela s’explique également par le fait que vous
utilisez l’application packagée et que vous ne vous contentez pas d’exécuter du code Python. Du point de vue du
système d’exploitation, vous exécutez maintenant « une application » et non « un programme Python », ce qui se
reflète dans l’apparence de l’application.
Vous pouvez maintenant empaqueter votre application pour la distribuer, en utilisant la commande package. La com-
mande package effectue toutes les compilations nécessaires pour convertir le projet d’échafaudage en un produit final
distribuable. Selon la plateforme, cela peut impliquer la compilation d’un installateur, la signature du code, ou d’autres
tâches de pré-distribution.
macOS
Linux
Windows
*************************************************************************
** WARNING: Signing with an ad-hoc identity **
*************************************************************************
*************************************************************************
Le dossier dist contiendra un fichier nommé Hello World-0.0.1.dmg. Si vous localisez ce fichier dans le Finder,
et que vous double-cliquez sur son icône, vous monterez le DMG, ce qui vous donnera une copie de l’application Hello
World, et un lien vers votre dossier Applications pour faciliter l’installation. Faites glisser le fichier de l’application
dans Applications, et vous aurez installé votre application. Envoyez le fichier DMG à un ami, qui devrait pouvoir faire
de même.
Dans cet exemple, nous avons utilisé l’option --adhoc-sign - c’est-à-dire que nous signons notre application avec
des informations d’identification ad hoc - des informations d’identification temporaires qui ne fonctionneront que sur
votre machine. Nous avons fait cela pour que le tutoriel reste simple. La mise en place d’identités de signature de code
est un peu fastidieuse, et elles ne sont nécessaires que si vous avez l’intention de distribuer votre application à d’autres
personnes. Si nous publiions une application réelle pour que d’autres puissent l’utiliser, nous devrions spécifier de
vraies informations d’identification.
Lorsque vous êtes prêt à publier une application réelle, consultez le guide Briefcase How-To sur Setting up a macOS
code signing identity
Le résultat de l’étape du paquetage sera légèrement différent selon votre distribution Linux. Si vous êtes sur une distri-
bution dérivée de Debian, vous verrez :
vous montrera une invite Unix (quelque chose comme root@84444e31cff9:/#) à l’intérieur d’un conteneur Docker
Ubuntu 22.04. Tapez Ctrl-D pour quitter Docker et revenir à votre shell local.
Une fois que vous avez installé Docker, vous pouvez utiliser Briefcase pour construire un paquet pour n’importe quelle
distribution Linux que Briefcase supporte en passant une image Docker comme argument. Par exemple, pour construire
un paquet DEB pour Ubuntu 22.04 (Jammy), quel que soit le système d’exploitation sur lequel vous êtes, vous pouvez
exécuter :
Ceci téléchargera l’image Docker pour le système d’exploitation choisi, créera un conteneur capable d’exécuter les
builds de Briefcase, et construira le paquetage de l’application à l’intérieur de l’image. Une fois terminé, le dossier
dist contiendra le paquet pour la distribution Linux cible.
*************************************************************************
** WARNING: No signing identity provided **
*************************************************************************
*************************************************************************
Dans cet exemple, nous avons utilisé l’option --adhoc-sign - c’est-à-dire que nous signons notre application avec
des informations d’identification ad hoc - des informations d’identification temporaires qui ne fonctionneront que sur
votre machine. Nous avons fait cela pour que le tutoriel reste simple. La mise en place d’identités de signature de code
est un peu fastidieuse, et elles ne sont nécessaires que si vous avez l’intention de distribuer votre application à d’autres
personnes. Si nous publiions une application réelle pour que d’autres puissent l’utiliser, nous devrions spécifier de
vraies informations d’identification.
Lorsque vous êtes prêt à publier une application réelle, consultez le guide Briefcase How-To sur Setting up a macOS
code signing identity
Une fois cette étape terminée, le dossier dist` contiendra un fichier nommé Hello_World-0.0.1.msi`. Si vous double-
cliquez sur ce programme d’installation pour le lancer, vous devriez passer par un processus d’installation Windows
familier. Une fois l’installation terminée, il y aura une entrée « Hello World » dans votre menu de démarrage.
Notre application est désormais prête à être distribuée sur les plates-formes de bureau. Mais que se passe-t-il lorsque
nous devons mettre à jour le code de notre application ? Comment intégrer ces mises à jour dans notre application
packagée ? Consultez Tutoriel 4 pour le découvrir. . .
Dans le dernier tutoriel, nous avons packagé notre application en tant qu’application native. Si vous avez affaire à une
application réelle, l’histoire ne s’arrêtera pas là : vous ferez probablement des tests, découvrirez des problèmes et devrez
apporter des modifications. Même si votre application est parfaite, vous finirez par vouloir publier la version 2 de votre
application avec des améliorations.
Alors, comment mettre à jour l’application installée lorsque vous modifiez le code ?
Notre application imprime actuellement sur la console lorsque vous appuyez sur le bouton. Cependant, les applications
d’interface graphique ne devraient pas vraiment utiliser la console pour la sortie. Elles doivent utiliser des boîtes de
dialogue pour communiquer avec les utilisateurs.
Ajoutons une boîte de dialogue pour dire bonjour, au lieu d’écrire dans la console. Modifiez le callback say_hello
pour qu’il ressemble à ceci : :
Toga ouvre ainsi une boîte de dialogue modale lorsque le bouton est enfoncé.
Si vous lancez briefcase dev, entrez un nom et appuyez sur le bouton, vous verrez la nouvelle boîte de dialogue :
macOS
Linux
Windows
Si Briefcase ne trouve pas le modèle échafaudé, il invoquera automatiquement create pour générer un nouvel écha-
faudage.
Maintenant que nous avons mis à jour le code de l’installateur, nous pouvons lancer briefcase build pour recompiler
l’application, briefcase run pour exécuter l’application mise à jour, et briefcase package pour reconditionner
l’application en vue de sa distribution.
(Utilisateurs de macOS, rappelez-vous que comme indiqué dans Tutoriel 3, pour le tutoriel nous recommandons d’exé-
cuter briefcase package avec le drapeau --adhoc-sign pour éviter la complexité de la mise en place d’une identité
de signature de code et garder le tutoriel aussi simple que possible)
Si vous effectuez rapidement des changements de code, vous voudrez probablement faire un changement de code, mettre
à jour l’application et la réexécuter immédiatement. Dans la plupart des cas, le mode développeur (briefcase dev)
sera le moyen le plus facile de faire ce genre d’itération rapide ; cependant, si vous testez quelque chose sur la façon dont
votre application fonctionne en tant que binaire natif, ou si vous chassez un bogue qui ne se manifeste que lorsque votre
application est sous forme de paquetage, vous pouvez avoir besoin d’utiliser des appels répétés à briefcase run.
Pour simplifier le processus de mise à jour et d’exécution de l’application packagée, Briefcase dispose d’un raccourci
pour supporter ce schéma d’utilisation - l’option -u (ou –update) de la commande run.
Essayons d’apporter une autre modification. Vous avez peut-être remarqué que si vous ne tapez pas de nom dans la
zone de saisie, la boîte de dialogue dira « Hello, « . Modifions à nouveau la fonction say_hello pour gérer ce cas
particulier.
En haut du fichier, entre les imports et la définition de class HelloWorld, ajoutez une méthode utilitaire pour générer
un message d’accueil approprié en fonction de la valeur du nom qui a été fourni : :
def greeting(name):
if name:
return f"Hello, {name}"
else:
return "Hello, stranger"
Ensuite, modifiez le callback say_hello pour utiliser cette nouvelle méthode utilitaire : :
Exécutez votre application en mode développement (avec briefcase dev) pour confirmer que la nouvelle logique
fonctionne ; puis mettez à jour, compilez et exécutez l’application avec une seule commande :
macOS
Linux
Windows
La commande package accepte aussi l’argument -u, donc si vous faites un changement dans le code de votre application
et que vous voulez repackager immédiatement, vous pouvez lancer briefcase package -u.
Notre application est désormais prête à être distribuée sur les plates-formes de bureau et nous avons pu mettre à jour
le code de notre application.
Mais qu’en est-il de l’application mobile ? Dans Tutoriel 5, nous allons convertir notre application en une application
mobile, et la déployer sur un simulateur d’appareil, et sur un téléphone.
Jusqu’à présent, nous avons exécuté et testé notre application sur un ordinateur de bureau. Cependant, BeeWare prend
également en charge les plates-formes mobiles - et l’application que nous avons écrite peut également être déployée
sur votre appareil mobile !
iOS Les applications iOS ne peuvent être compilées que sur macOS.
Tutoriel 5 - Le mobile : iOS Android Les applications Android peuvent être compilées sur macOS, Windows
ou Linux.
Tutoriel 5 - Le mobile : Android
Pour compiler les applications iOS, nous avons besoin de Xcode, qui est disponible gratuitement sur le macOS App
Store <https://apps.apple.com/au/app/xcode/id497799835?mt=12>`__.
Une fois Xcode installé, nous pouvons prendre notre application et la déployer en tant qu’application iOS.
Le processus de déploiement d’une application sur iOS est très similaire au processus de déploiement d’une application
de bureau. Tout d’abord, vous exécutez la commande create - mais cette fois, nous spécifions que nous voulons créer
une application iOS :
...
Une fois cette opération terminée, nous aurons un répertoire build/helloworld/ios/xcode contenant un projet
Xcode, ainsi que les bibliothèques de support et le code nécessaire à l’application.
Vous pouvez ensuite utiliser Briefcase pour compiler votre application en utilisant briefcase build iOS :
Nous sommes maintenant prêts à exécuter notre application, en utilisant briefcase run iOS. Il vous sera demandé
de sélectionner un appareil pour lequel compiler ; si vous avez installé des simulateurs pour plusieurs versions du SDK
iOS, il vous sera peut-être demandé quelle version d’iOS vous voulez cibler. Les options affichées peuvent différer
de celles présentées dans cette sortie - au moins, la liste des appareils sera probablement différente. En ce qui nous
concerne, le simulateur choisi n’a pas d’importance.
> 10
or:
[helloworld] Starting app on an iPhone SE (3rd generation) running iOS 16.2 (device UDID␣
˓→2614A2DD-574F-4C1F-9F1E-478F32DE282E)
Ceci lancera le simulateur iOS, installera votre application et la démarrera. Vous devriez voir le simulateur démarrer,
puis ouvrir votre application iOS :
Si vous savez à l’avance quel simulateur iOS vous voulez cibler, vous pouvez dire à Briefcase d’utiliser ce simulateur
en fournissant une option -d (ou --device). En utilisant le nom de l’appareil que vous avez sélectionné lorsque vous
avez créé votre application, exécutez :
Si vous avez plusieurs versions iOS disponibles, Briefcase choisira la version iOS la plus élevée ; si vous voulez choisir
une version iOS particulière, vous lui direz d’utiliser cette version spécifique :
Étapes suivantes
Nous avons maintenant une application sur notre téléphone ! Y a-t-il un autre endroit où nous pouvons déployer une
application BeeWare ? Consultez Tutoriel 6 pour le savoir. . .
Nous allons maintenant prendre notre application et la déployer en tant qu’application Android.
Le processus de déploiement d’une application sur Android est très similaire au processus de déploiement d’une appli-
cation de bureau. Briefcase prend en charge l’installation des dépendances pour Android, y compris le SDK Android,
l’émulateur Android et un compilateur Java.
Tout d’abord, lancez la commande create. Celle-ci télécharge un modèle d’application Android et y ajoute votre code
Python.
macOS
Linux
Windows
...
...
...
Lorsque vous lancez briefcase create android pour la première fois, Briefcase télécharge un JDK Java et le SDK
Android. La taille des fichiers et le temps de téléchargement peuvent être considérables ; cela peut prendre un certain
temps (10 minutes ou plus, selon la vitesse de votre connexion Internet). Une fois le téléchargement terminé, vous serez
invité à accepter la licence Android SDK de Google.
Une fois cette opération terminée, nous aurons un répertoire buildhelloworld\android\gradle dans notre projet,
qui contiendra un projet Android avec une configuration de construction Gradle. Ce projet contiendra le code de votre
application, ainsi qu’un package de support contenant l’interpréteur Python.
Nous pouvons ensuite utiliser la commande build de Briefcase pour compiler ce fichier dans un fichier d’application
APK Android.
macOS
Linux
Windows
Pendant l’étape briefcase build android, Gradle (l’outil de construction de la plateforme Android) affiche
CONFIGURING : 100%, et semble ne rien faire. Ne vous inquiétez pas, il n’est pas bloqué - il est en train de télé-
charger plus de composants du SDK Android. Selon la vitesse de votre connexion Internet, cela peut prendre encore
10 minutes (ou plus). Ce décalage ne devrait se produire que la première fois que vous lancez build ; les outils
sont mis en cache, et lors de votre prochain build, les versions mises en cache seront utilisées.
Nous sommes maintenant prêts à exécuter notre application. Vous pouvez utiliser la commande run de Briefcase pour
exécuter l’application sur un appareil Android. Commençons par l’exécuter sur un émulateur Android.
Pour lancer votre application, exécutez briefcase run android. Vous obtiendrez alors une liste d’appareils sur
lesquels vous pouvez faire fonctionner l’application. Le dernier élément sera toujours une option pour créer un nouvel
émulateur Android.
macOS
Linux
Windows
Select device:
>
Select device:
>
Select device:
>
Nous pouvons maintenant choisir l’appareil que nous souhaitons. Sélectionnez l’option « Créer un nouvel émulateur
Android », et acceptez le choix par défaut du nom de l’appareil (beePhone).
Briefcase run démarrera automatiquement l’appareil virtuel. Lorsque l’appareil démarre, vous verrez le logo Android :
Une fois que l’appareil a fini de démarrer, Briefcase installera votre application sur l’appareil. Vous verrez brièvement
un écran de lancement :
L’application démarre alors. Vous verrez un écran de démarrage pendant que l’application démarre :
L’émulateur Android est un logiciel complexe qui s’appuie sur un certain nombre de caractéristiques du matériel et
du système d’exploitation - des caractéristiques qui peuvent ne pas être disponibles ou activées sur des machines plus
anciennes. Si vous rencontrez des difficultés au démarrage de l’émulateur Android, consultez la section « Exigences
et recommandations <https://developer.android.com/studio/run/emulator#requirements>`__ » de la documentation
destinée aux développeurs Android.
La première fois que l’application démarre, elle doit se décompresser sur l’appareil. Cela peut prendre quelques se-
condes. Une fois qu’elle est décompressée, vous verrez la version Android de notre application de bureau :
Si vous ne voyez pas votre application se lancer, vous devrez peut-être vérifier le terminal où vous avez lancé briefcase
run et rechercher les messages d’erreur.
A l’avenir, si vous souhaitez utiliser cet appareil sans utiliser le menu, vous pouvez fournir le nom de l’émulateur à
Briefcase, en utilisant briefcase run android -d @beePhone pour utiliser directement l’appareil virtuel.
Si vous avez un téléphone ou une tablette Android physique, vous pouvez le connecter à votre ordinateur à l’aide d’un
câble USB, puis utiliser la mallette pour cibler votre appareil physique.
Android exige que vous prépariez votre appareil avant de pouvoir l’utiliser pour le développement. Vous devrez apporter
deux modifications aux options de votre appareil :
— Activer les options pour les développeurs
— Activer le débogage USB
Les détails sur la manière d’effectuer ces changements peuvent être trouvés dans la documentation du développeur
Android <https://developer.android.com/studio/debug/dev-options#enable>`__.
Une fois ces étapes terminées, votre appareil devrait apparaître dans la liste des appareils disponibles lorsque vous
lancez briefcase run android.
macOS
Linux
Windows
Select device:
1) Pixel 3a (94ZZY0LNE8)
2) @beePhone (emulator)
3) Create a new Android emulator
>
Select device:
1) Pixel 3a (94ZZY0LNE8)
2) @beePhone (emulator)
3) Create a new Android emulator
>
Select device:
1) Pixel 3a (94ZZY0LNE8)
2) @beePhone (emulator)
3) Create a new Android emulator
>
Ici, nous pouvons voir un nouvel appareil physique avec son numéro de série sur la liste de déploiement - dans ce cas, un
Pixel 3a. À l’avenir, si vous souhaitez exécuter sur cet appareil sans utiliser le menu, vous pouvez fournir le numéro de
série du téléphone à Briefcase (dans ce cas, briefcase run android -d 94ZZY0LNE8). Cela lancera l’application
directement sur l’appareil, sans l’inviter à le faire.
Si votre appareil n’apparaît pas du tout dans cette liste, c’est que vous n’avez pas activé le débogage USB (ou que
l’appareil n’est pas branché !).
Si votre appareil apparaît, mais qu’il est listé comme « Unknown device (not authorized for development) », le mode
développeur n’a pas été correctement activé. Réexécutez les étapes pour activer les options de développement, et
réexécutez briefcase run android.
Étapes suivantes
Nous avons maintenant une application sur notre téléphone ! Y a-t-il un autre endroit où nous pouvons déployer une
application BeeWare ? Consultez Tutoriel 6 pour le savoir. . .
En plus de prendre en charge les plateformes mobiles, la boîte à outils Toga widget prend également en charge le web !
En utilisant la même API que celle utilisée pour déployer vos applications de bureau et mobiles, vous pouvez déployer
votre application en tant qu’application web à page unique.
ò Preuve de concept
Le backend de Toga Web est le moins mature de tous les backends de Toga. Il est suffisamment mature pour présenter
quelques fonctionnalités, mais il est probable qu’il soit bogué et qu’il manque de nombreux widgets disponibles sur
d’autres plates-formes. À ce stade, le déploiement sur le Web doit être considéré comme une « preuve de concept »
- suffisante pour démontrer ce qui peut être fait, mais pas assez pour être utilisée pour un développement sérieux.
Si vous avez des problèmes avec cette étape du tutoriel, vous pouvez passer à la page suivante.
Le processus de déploiement en tant qu’application web à page unique suit le même schéma familier - vous créez
l’application, vous la construisez, puis vous l’exécutez. Cependant, Briefcase peut être un peu plus intelligent ; si vous
essayez d’exécuter une application et que Briefcase détermine qu’elle n’a pas été créée ou construite pour la plateforme
ciblée, il effectuera les étapes de création et de construction pour vous. Puisque c’est la première fois que nous lançons
l’application pour le web, nous pouvons exécuter les trois étapes en une seule commande :
macOS
Linux
Windows
...
...
...
Si vous entrez votre nom et cliquez sur le bouton, une boîte de dialogue apparaît.
Cette application web est un site web statique - une seule page source HTML, avec quelques feuilles de style CSS et
d’autres ressources. Briefcase a démarré un serveur web local pour servir cette page afin que votre navigateur puisse la
voir. Si vous voulez mettre cette page web en production, vous pouvez copier le contenu du dossier www sur n’importe
quel serveur web qui peut servir du contenu statique.
Mais lorsque vous appuyez sur le bouton, vous exécutez du code Python. . . Comment cela fonctionne-t-il ? Toga utilise
PyScript pour fournir un interprète Python dans le navigateur. Briefcase présente le code de votre application sous forme
de roues que PyScript peut charger dans le navigateur. Lorsque la page est chargée, le code de l’application s’exécute
dans le navigateur, construisant l’interface utilisateur en utilisant le DOM du navigateur. Lorsque vous cliquez sur un
bouton, ce bouton exécute le code de gestion des événements dans le navigateur.
Bien que nous ayons maintenant déployé cette application sur les ordinateurs de bureau, les téléphones portables et le
web, l’application est assez simple et n’implique pas de bibliothèques tierces. Pouvons-nous inclure des bibliothèques
du Python Package Index (PyPI) dans notre application ? Consultez Tutoriel 7 pour le savoir. . .
Jusqu’à présent, l’application que nous avons construite n’a utilisé que notre propre code, ainsi que le code fourni
par BeeWare. Cependant, dans une application réelle, vous voudrez probablement utiliser une bibliothèque tierce,
téléchargée à partir du Python Package Index (PyPI).
Modifions notre application pour y inclure une bibliothèque tierce.
Une tâche courante qu’une application doit effectuer est de faire une requête sur une API web pour récupérer des
données, et afficher ces données à l’utilisateur. Comme il s’agit d’une application jouet, nous n’avons pas de vraie API
à utiliser. Nous utiliserons donc la {JSON} Placeholder API comme source de données.
L’API {JSON} Placeholder possède un certain nombre de « faux » points de terminaison d’API que vous pouvez utiliser
comme données de test. L’une de ces API est le point de terminaison /posts/, qui renvoie de faux billets de blog.
Si vous ouvrez https://jsonplaceholder.typicode.com/posts/42 dans votre navigateur, vous obtiendrez un
fichier JSON décrivant un seul article - un contenu Lorum ipsum pour un article de blog avec l’ID 42.
La bibliothèque standard de Python contient tous les outils dont vous avez besoin pour accéder à une API. Cependant,
les API intégrées sont de très bas niveau. Ce sont de bonnes implémentations du protocole HTTP, mais elles exigent de
l’utilisateur qu’il gère de nombreux détails de bas niveau, comme la redirection d’URL, les sessions, l’authentification
et l’encodage des données utiles. En tant qu“« utilisateur normal de navigateur », vous avez probablement l’habitude
de considérer ces détails comme allant de soi, car le navigateur les gère pour vous.
En conséquence, des bibliothèques tierces ont été développées pour envelopper les API intégrées et fournir une API plus
simple qui correspond mieux à l’expérience quotidienne du navigateur. Nous allons utiliser l’une de ces bibliothèques
pour accéder à l’API {JSON} Placeholder - une bibliothèque appelée httpx.
Ajoutons un appel API httpx à notre application. Ajoutez un import au début de app.py pour importer httpx : :
import httpx
payload = response.json()
self.main_window.info_dialog(
greeting(self.name_input.value),
payload["body"],
)
Cela modifiera le callback say_hello() de telle sorte que lorsqu’il est invoqué, il le fera :
— effectuer une requête GET sur l’API JSON pour obtenir le poste 42 ;
— décoder la réponse en JSON ;
— extraire le corps du message ; et
— inclure le corps de ce message dans le texte du dialogue.
Exécutons notre application mise à jour dans le mode développeur de Briefcase pour vérifier que notre changement a
fonctionné.
macOS
Linux
Windows
import httpx
ModuleNotFoundError: No module named 'httpx'
import httpx
ModuleNotFoundError: No module named 'httpx'
import httpx
ModuleNotFoundError: No module named 'httpx'
Qu’est-ce qui s’est passé ? Nous avons ajouté httpx à notre code, mais nous ne l’avons pas ajouté à notre environnement
virtuel de développement. Nous pouvons corriger cela en installant httpx avec pip, puis en relançant briefcase
dev :
macOS
Linux
Windows
Lorsque vous entrez un nom et que vous appuyez sur le bouton, une boîte de dialogue doit s’afficher :
Lorsque vous entrez un nom et que vous appuyez sur le bouton, une boîte de dialogue doit s’afficher :
Lorsque vous entrez un nom et que vous appuyez sur le bouton, une boîte de dialogue doit s’afficher :
Nous avons maintenant une application fonctionnelle, utilisant une bibliothèque tierce, fonctionnant en mode dévelop-
pement !
Nous allons faire en sorte que ce code d’application mis à jour soit empaqueté en tant qu’application autonome. Puisque
nous avons modifié le code, nous devons suivre les mêmes étapes que dans Tutoriel 4 :
macOS
Linux
Windows
Mettre à jour le code dans l’application packagée :
Reconstruire l’application :
Cependant, lorsque l’application s’exécute, vous verrez une erreur dans la console, ainsi qu’une boîte de dialogue de
plantage :
Reconstruire l’application :
import httpx
ModuleNotFoundError: No module named 'httpx'
Reconstruire l’application :
Cependant, lorsque l’application s’exécute, vous verrez une erreur dans la console, ainsi qu’une boîte de dialogue de
plantage :
Une fois de plus, l’application n’a pas pu démarrer parce que httpx a été installé - mais pourquoi ? N’avons-nous pas
déjà installé httpx ?
Nous l’avons fait, mais uniquement dans l’environnement de développement. Votre environnement de développement
est entièrement local à votre machine - et n’est activé que lorsque vous l’activez explicitement. Bien que Briefcase
dispose d’un mode de développement, la principale raison pour laquelle vous utilisez Briefcase est d’empaqueter votre
code afin de le donner à quelqu’un d’autre.
La seule façon de garantir que quelqu’un d’autre disposera d’un environnement Python contenant tout ce dont il a
besoin est de construire un environnement Python complètement isolé. Cela signifie qu’il y a une installation Python
complètement isolée, et un ensemble de dépendances complètement isolé. C’est ce que Briefcase construit quand vous
lancez briefcase build - un environnement Python isolé. Cela explique aussi pourquoi httpx n’est pas installé - il
a été installé dans votre environnement de développement, mais pas dans l’application packagée.
Nous devons donc indiquer à Briefcase que notre application a une dépendance externe.
Dans le répertoire racine de votre application, il y a un fichier nommé pyproject.toml. Ce fichier contient tous les
détails de configuration de l’application que vous avez fournis lorsque vous avez lancé briefcase new.
pyproject.toml est divisé en sections ; l’une d’entre elles décrit les paramètres de votre application : :
[tool.briefcase.app.helloworld]
formal_name = "Hello World"
description = "A Tutorial app"
(suite sur la page suivante)
L’option requires décrit les dépendances de notre application. C’est une liste de chaînes de caractères, spécifiant les
bibliothèques (et, optionnellement, les versions) des bibliothèques que vous voulez inclure dans votre application.
Modifiez le paramètre requires de façon à ce qu’il se lise : :
requires = [
"httpx",
]
En ajoutant ce paramètre, nous disons à Briefcase « lorsque vous compilez mon application, lancez pip install
httpx dans le bundle de l’application ». Tout ce qui serait une entrée légale pour pip install` peut être utilisé ici - ainsi,
vous pourriez spécifier :
— Une version spécifique de la bibliothèque (par exemple, "httpx==0.19.0") ;
— Une gamme de versions de la bibliothèque (par exemple, "httpx>=0.19") ;
— Un chemin vers un dépôt git (par exemple, "git+https://github.com/encode/httpx") ; ou
— Un chemin d’accès à un fichier local (Cependant, attention : si vous donnez votre code à quelqu’un d’autre, ce
chemin d’accès n’existera probablement pas sur sa machine !)
Plus loin dans pyproject.toml, vous remarquerez d’autres sections qui dépendent du système d’exploitation,
comme [tool.briefcase.app.helloworld.macOS] et [tool.briefcase.app.helloworld.windows]. Ces
sections ont également un paramètre requires. Ces paramètres vous permettent de définir des dépendances sup-
plémentaires spécifiques à une plate-forme - ainsi, par exemple, si vous avez besoin d’une bibliothèque spécifique
à une plate-forme pour gérer un aspect de votre application, vous pouvez spécifier cette bibliothèque dans la sec-
tion requires'' spécifique à la plate-forme, et ce paramètre ne sera utilisé que pour cette
plate-forme. Vous remarquerez que les bibliothèques ``toga sont toutes spécifiées dans la section
requires spécifique à la plate-forme - c’est parce que les bibliothèques nécessaires pour afficher une interface utili-
sateur sont spécifiques à la plate-forme.
Dans notre cas, nous voulons que httpx soit installé sur toutes les plateformes, donc nous utilisons le paramètre
requires au niveau de l’application. Les dépendances au niveau de l’application seront toujours installées ; les dé-
pendances spécifiques à la plate-forme sont installées en plus de celles au niveau de l’application.
Sur les plateformes de bureau (macOS, Windows, Linux), tout pip-installable peut être ajouté à vos exigences. Sur
les plateformes mobiles et web, vos options sont légèrement limitées.
En bref, tout paquetage pure Python (c’est-à-dire les paquetages qui ne contiennent pas de module binaire) peut
être utilisé sans difficulté. Cependant, si votre dépendance contient un composant binaire, il doit être compilé ; à
l’heure actuelle, la plupart des paquets Python ne fournissent pas de support de compilation pour les plates-formes
autres que les ordinateurs de bureau.
BeeWare peut fournir des binaires pour certains modules binaires populaires (y compris numpy, pandas, et
cryptographie). Il est habituellement possible de compiler des paquets pour les plateformes mobiles, mais ce
n’est pas facile à mettre en place – ce qui sort du cadre d’un tutoriel d’introduction comme celui-ci.
Maintenant que nous avons informé Briefcase de nos exigences supplémentaires, nous pouvons essayer d’empaqueter
à nouveau notre application. Assurez-vous que vous avez sauvegardé vos changements dans pyproject.toml, puis
mettez à jour votre application à nouveau - cette fois-ci, en passant le drapeau -r. Cela indique à Briefcase de mettre
à jour les exigences dans l’application packagée :
macOS
Linux
Windows
˓→extensions-4.11.0 zipp-3.18.1
˓→extensions-4.11.0 zipp-3.18.1
˓→extensions-4.11.0 zipp-3.18.1
Une fois la mise à jour effectuée, vous pouvez lancer briefcase build et briefcase run - et vous devriez voir
votre application packagée, avec le nouveau comportement du dialogue.
ò Note
L’option -r pour la mise à jour des exigences est également honorée par les commandes build et run, donc si vous
voulez mettre à jour, compiler et exécuter en une seule étape, vous pouvez utiliser briefcase run -u -r.
Nous avons maintenant une application qui utilise une bibliothèque tierce ! Cependant, vous avez peut-être remarqué
que lorsque vous appuyez sur le bouton, l’application ne répond plus vraiment. Pouvons-nous faire quelque chose pour
résoudre ce problème ? Consultez Tutoriel 8 pour le savoir. . .
A moins que vous ne disposiez d’une connexion internet très rapide, vous remarquerez peut-être que lorsque vous
appuyez sur le bouton, l’interface graphique de votre application se bloque pendant un petit moment. C’est parce que la
requête web que nous avons faite est synchrone. Lorsque notre application effectue la requête web, elle attend que l’API
renvoie une réponse avant de continuer. Pendant cette attente, l’API ne permet pas à l’application de se redessiner, ce
qui a pour effet de bloquer l’application.
Pour comprendre pourquoi cela se produit, nous devons entrer dans les détails du fonctionnement d’une application
GUI. Les spécificités varient en fonction de la plate-forme, mais les concepts de haut niveau sont les mêmes, quelle
que soit la plate-forme ou l’environnement d’interface graphique que vous utilisez.
Une application GUI est, fondamentalement, une boucle unique qui ressemble à quelque chose comme : :
Cette boucle est appelée boucle d’événements. (Il ne s’agit pas de noms de méthodes réels, mais d’une illustration de
ce qui se passe dans le « pseudo-code »).
Lorsque vous cliquez sur un bouton, faites glisser une barre de défilement ou tapez une touche, vous générez un « évé-
nement ». Cet « événement » est placé dans une file d’attente, et l’application traitera la file d’événements lorsqu’elle
en aura l’occasion. Le code utilisateur déclenché en réponse à l’événement est appelé « gestionnaire d’événement ».
Ces gestionnaires d’événements sont invoqués dans le cadre de l’appel process_events().
Une fois qu’une application a traité tous les événements disponibles, elle va redraw() l’interface graphique. Cela prend
en compte tous les changements que les événements ont causés à l’affichage de l’application, ainsi que tout ce qui se
passe dans le système d’exploitation - par exemple, les fenêtres d’une autre application peuvent masquer ou révéler une
partie de la fenêtre de notre application, et le redessin de notre application devra refléter la partie de la fenêtre qui est
actuellement visible.
Détail important : pendant qu’une application traite un événement, elle ne peut pas redessiner, et elle ne peut pas traiter
d’autres événements.
Cela signifie que toute logique utilisateur contenue dans un gestionnaire d’événements doit être exécutée rapidement.
Tout retard dans l’exécution du gestionnaire d’événements sera observé par l’utilisateur sous la forme d’un ralentisse-
ment (ou d’un arrêt) des mises à jour de l’interface graphique. Si ce délai est suffisamment long, votre système d’ex-
ploitation peut signaler qu’il s’agit d’un problème - les icônes macOS « beachball » et Windows « spinner » indiquent
que votre application prend trop de temps dans un gestionnaire d’événements.
Des opérations simples comme « mettre à jour une étiquette » ou « recalculer le total des entrées » sont faciles à
réaliser rapidement. Cependant, de nombreuses opérations ne peuvent pas être effectuées rapidement. Si vous effectuez
un calcul mathématique complexe, si vous indexez tous les fichiers d’un système de fichiers ou si vous effectuez une
requête réseau importante, vous ne pouvez pas « faire vite » - les opérations sont intrinsèquement lentes.
Alors, comment effectuer des opérations à long terme dans une application GUI ?
Ce dont nous avons besoin, c’est d’un moyen de dire à une application au milieu d’un gestionnaire d’événements de
longue durée qu’il est acceptable de relâcher temporairement le contrôle dans la boucle d’événements, tant que nous
pouvons reprendre là où nous nous sommes arrêtés. C’est à l’application de déterminer quand cette libération peut
avoir lieu ; mais si l’application libère le contrôle dans la boucle d’événements régulièrement, nous pouvons avoir un
gestionnaire d’événements de longue durée et maintenir une interface utilisateur réactive.
Nous pouvons le faire en utilisant la programmation asynchrone. La programmation asynchrone est une façon de décrire
un programme qui permet à l’interpréteur d’exécuter plusieurs fonctions en même temps, en partageant les ressources
entre toutes les fonctions qui s’exécutent simultanément.
Les fonctions asynchrones (appelées co-routines) doivent être explicitement déclarées comme étant asynchrones. Elles
doivent également déclarer en interne lorsqu’il est possible de changer de contexte et de passer à une autre co-routine.
En Python, la programmation asynchrone est implémentée à l’aide des mots-clés async et await, et
du module asyncio <https://docs.python.org/3/library/asyncio.html>`__ dans la bibliothèque
standard. Le mot-clé ``async nous permet de déclarer qu’une fonction est une co-routine asynchrone. Le mot-
clé await permet de déclarer qu’il existe une opportunité de changer de contexte vers une autre co-routine. Le module
asyncio fournit d’autres outils et primitives utiles pour le codage asynchrone.
Pour rendre notre tutoriel asynchrone, modifiez le gestionnaire d’événement say_hello() pour qu’il ressemble à
ceci : :
payload = response.json()
self.main_window.info_dialog(
greeting(self.name_input.value),
payload["body"],
)
This has been a taste for what you can do with the tools provided by the BeeWare project. Over the course of this
tutorial, you have :
— Created a new GUI app project ;
— Run that app in development mode ;
— Built the app as a standalone binary for a desktop operating system ;
— Packaged that project for distribution to others ;
— Run the app on a mobile simulator and/or device ;
— Run the app as a web app ;
— Added a third-party dependency to your app ; and
— Modified the app so that it remains responsive.
So - where to from here ?
— If you’d like to go further, there are some additional topic tutorials that go into detail on specific aspects of
application development.
— If you’d like to know more about how to build complex user interfaces with Toga, you can dive into Toga’s
documentation. Toga also has it’s own tutorial demonstrating how to use various features of the widget toolkit.
— If you’d like to know more about the capabilities of Briefcase, you can dive into Briefcase’s documentation.
Want to go deeper on specific topics ? Here are some additional tutorials that explore common aspects of application
development. Each tutorial is standalone, and can be completed in any order ; but they all assume you’ve completed the
core tutorial.
Customizing icons Customize your application’s appearance by replacing the default « gray bee » icon.
Customizing icons Application Testing How do you ensure that your application works, and stays working ?
By adding a test suite to your project !
Tutoriel 9 - Temps de test Camera access Use the camera on your mobile or desktop device to take and view
a picture from within your application.
Using the camera
Jusqu’à présent, notre application utilise l’icône par défaut « abeille grise ». Comment mettre à jour l’application pour
qu’elle utilise notre propre icône ?
Every platform uses a different format for application icons - and some platforms need multiple icons in different sizes
and shapes. To account for this, Briefcase provides a shorthand way to configure an icon once, and then have that
definition expand in to all the different icons needed for each individual platform.
Edit your pyproject.toml, adding a new icon configuration item in the [tool.briefcase.app.helloworld]
configuration section, just above the sources definition :
icon = "icons/helloworld"
This icon definition doesn’t specify any file extension. The value will be used as a prefix ; each platform will add
additional items to this prefix to build the files needed for each platform. Some platforms require multiple icon files ;
this prefix will be combined with file size and variant modifiers to generate the list of icon files that are used.
We can now run briefcase update again - but this time, we pass in the --update-resources flag, telling Briefcase
that we want to install new application resources (i.e., the icons) :
macOS
Linux
Windows
Android
iOS
This reports the specific icon file (or files) that Briefcase is expecting. However, as we haven’t provided the actual icon
files, the install fails, and Briefcase falls back to a default value (the same « gray bee » icon).
Let’s provide some actual icons. Download this icons.zip bundle, and unpack it into the root of your project
directory. After unpacking, your project directory should look something like :
beeware-tutorial/
beeware-venv/
...
helloworld/
...
pyproject.toml
icons/
helloworld.icns
helloworld.ico
helloworld.png
helloworld-16.png
...
src/
...
There’s a lot of icons in this folder, but most of them should look the same : a green snake on a light blue background :
The only exception will be the icons with -adaptive- in their name ; these will have a transparent background. This
represents all the different icon sizes and shapes you need to support an app on every platform that Briefcase supports.
Now that we have icons, we can update the application again. However, briefcase update will only copy the updated
resources into the build directory ; we also want to rebuild the app to make sure the new icon is included, then start
the app. We can shortcut this process by passing --update-resources to our call to run - this will update the app,
update the app’s resources, and then start the app :
macOS
Linux
Windows
Android
iOS
ò Note
If you’re using a recent version of Android, you may notice that the app icon has been changed to a green snake,
but the background of the icon is white, rather than light blue. We’ll fix this in the next step.
When you run the app on iOS or Android, in addition to the icon change, you should also notice that the splash screen
incorporates the new icon. However, the light blue background of the icon looks a little out of place against the white
background of the splash screen. We can fix this by customizing the background color of the splash screen. Add the
following definition to your pyproject.toml, just after the icon definition :
splash_background_color = "#D3E6F5"
Unfortunately, Briefcase isn’t able to apply this change to an already generated project, as it requires making modifi-
cations to one of the files that was generated during the original call to briefcase create. To apply this change, we
have to re-create the app by re-running briefcase create. When we do this, we’ll be prompted to confirm that we
want to overwrite the existing project :
macOS
Linux
Windows
Android
iOS
You can then re-build and re-run the app using briefcase run. You won’t notice any changes to the desktop app ; but
the Android or iOS apps should now have a light blue splash screen background.
You’ll need to re-create the app like this whenever you make a change to your pyproject.toml that doesn’t relate
to source code or dependencies. Any change to descriptions, version numbers, colors, or permissions will require a
re-create step. Because of this, while you are developing your project, you shouldn’t make any manual changes to the
contents of the build folder, and you shouldn’t add the build folder to your version control system. The build folder
should be considered entirely ephemeral - an output of the build system that can be recreated as needed to reflect the
current configuration of your project.
La plupart des développements de logiciels n’impliquent pas l’écriture d’un nouveau code, mais la modification d’un
code existant. S’assurer que le code existant continue à fonctionner comme nous l’attendons est une partie essentielle
du processus de développement logiciel. Une façon de s’assurer du comportement de notre application est d’utiliser
une suite de tests.
Il s’avère que notre projet possède déjà une suite de tests ! Lorsque nous avons généré notre projet à l’origine, deux
répertoires de premier niveau ont été générés : src et tests. Le dossier src contient le code de notre application ; le
dossier tests contient notre suite de tests. Dans le dossier tests se trouve un fichier nommé test_app.py avec le
contenu suivant : :
def test_first():
"An initial test for the app"
assert 1 + 1 == 2
Ceci est un Pytest test case - un bloc de code qui peut être exécuté pour vérifier un certain comportement de votre
application. Dans ce cas, le test est un placeholder, et ne teste rien de notre application - mais c’est un test que nous
pouvons effectuer.
Nous pouvons lancer cette suite de tests en utilisant l’option --test de briefcase dev. Comme c’est la première
fois que nous lançons des tests, nous devons également passer l’option -r pour nous assurer que les exigences de test
sont également installées :
macOS
Linux
Windows
cachedir: /var/folders/b_/khqk71xd45d049kxc_59ltp80000gn/T/.pytest_cache
rootdir: /Users/brutus
plugins: anyio-3.6.2
collecting ... collected 1 item
Succès ! Nous venons d’exécuter un seul test qui vérifie que les mathématiques Python fonctionnent de la manière
attendue (Quel soulagement !).
Remplaçons ce placeholder test par un test pour vérifier que notre méthode greeting() se comporte comme nous
l’attendons. Remplacez le contenu de test_app.py par ce qui suit : :
def test_name():
"""If a name is provided, the greeting includes the name"""
(suite sur la page suivante)
def test_empty():
"""If a name is not provided, a generic greeting is provided"""
Ceci définit deux nouveaux tests, vérifiant les deux comportements que nous attendons : la sortie lorsqu’un nom est
fourni, et la sortie lorsque le nom est vide.
Nous pouvons maintenant réexécuter la suite de tests. Cette fois, nous n’avons pas besoin de fournir l’option -r, puisque
les pré-requis pour les tests ont déjà été installés ; nous avons seulement besoin d’utiliser l’option --test :
macOS
Linux
Windows
(beeware-venv) $ briefcase dev --test
Maintenant que nous disposons d’une suite de tests, nous pouvons l’utiliser pour développer de nouvelles fonctionna-
lités. Modifions notre application pour avoir un message d’accueil spécial pour un utilisateur particulier. Nous pou-
vons commencer par ajouter un scénario de test pour le nouveau comportement que nous aimerions voir au bas de
test_app.py : :
def test_brutus():
"""If the name is Brutus, a special greeting is provided"""
def test_brutus():
"""If the name is Brutus, a special greeting is provided"""
tests/test_app.py:19: AssertionError
=========================== short test summary info ============================
(suite sur la page suivante)
def test_brutus():
"""If the name is Brutus, provide a special greeting"""
tests/test_app.py:19: AssertionError
=========================== short test summary info ============================
FAILED tests/test_app.py::test_brutus - AssertionError: assert 'Hello, Brutus...
========================= 1 failed, 2 passed in 0.14s ==========================
def test_brutus():
"""If the name is Brutus, provide a special greeting"""
tests/test_app.py:19: AssertionError
=========================== short test summary info ============================
FAILED tests/test_app.py::test_brutus - AssertionError: assert 'Hello, Brutus...
========================= 1 failed, 2 passed in 0.14s ==========================
Cette fois, nous voyons un échec du test - et la sortie explique la source de l’échec : le test attend la sortie « BeeWare the
IDEs of Python ! », mais notre implémentation de greeting() retourne « Hello, Brutus ». Modifions l’implémentation
de greeting() dans src/helloworld/app.py pour avoir le nouveau comportement : :
def greeting(name):
if name:
if name == "Brutus":
return "BeeWare the IDEs of Python!"
else:
return f"Hello, {name}"
else:
return "Hello, stranger"
Si nous exécutons à nouveau les tests, nous constatons qu’ils sont réussis :
macOS
Linux
Windows
(beeware-venv) $ briefcase dev --test
Tests d’exécution
Jusqu’à présent, nous avons exécuté les tests en mode développement. C’est particulièrement utile lorsque vous déve-
loppez de nouvelles fonctionnalités, car vous pouvez rapidement itérer sur l’ajout de tests et l’ajout de code pour faire
passer ces tests. Cependant, à un moment donné, vous voudrez vérifier que votre code s’exécute correctement dans
l’environnement de l’application groupée.
Les options --test et -r peuvent également être passées à la commande run. Si vous utilisez briefcase run
--test -r, la même suite de tests s’exécutera, mais elle s’exécutera dans le paquetage de l’application plutôt que
dans votre environnement de développement :
macOS
Linux
Windows
(beeware-venv) $ briefcase run --test -r
PYTHONPATH:
(suite sur la page suivante)
Configure argc/argv...
Initializing Python runtime...
Installing Python NSLog handler...
Running app module: tests.helloworld
---------------------------------------------------------------------------
============================= test session starts ==============================
...
collecting ... collected 3 items
===========================================================================
Log started: 2022-12-02 10:57:34Z
PreInitializing Python runtime...
PythonHome: C:\Users\brutus\beeware-tutorial\helloworld\windows\app\Hello World\src
PYTHONPATH:
- C:\Users\brutus\beeware-tutorial\helloworld\windows\app\Hello World\src\python311.zip
- C:\Users\brutus\beeware-tutorial\helloworld\windows\app\Hello World\src
- C:\Users\brutus\beeware-tutorial\helloworld\windows\app\Hello World\src\app_packages
- C:\Users\brutus\beeware-tutorial\helloworld\windows\app\Hello World\src\app
Configure argc/argv...
Initializing Python runtime...
Running app module: tests.helloworld
---------------------------------------------------------------------------
============================= test session starts ==============================
...
collecting ... collected 3 items
Comme pour briefcase dev --test, l’option -r n’est nécessaire que la première fois que vous exécutez la suite
de tests pour vous assurer que les dépendances des tests sont présentes. Lors des exécutions suivantes, vous pouvez
omettre cette option.
Vous pouvez également utiliser l’option –test` sur les backends mobiles : - ainsi briefcase run iOS –test` et briefcase
run android --test fonctionneront tous les deux, lançant la suite de tests sur l’appareil mobile que vous avez
sélectionné.
Almost every modern computing device has a camera of some sort. In this tutorial, we’ll write new application that is
able to request access to this camera, take a photograph, and then display that photograph in the app. new application
that uses your device’s camera.
Unfortunately, at present, this tutorial will only work on macOS and Android.
Although iPhones all have cameras, the iOS Simulator doesn’t have a working camera. Windows and Linux devices
also have cameras, but Toga doesn’t currently have the ability to access the camera on these platforms.
The code presented here will run on Windows or Linux ; but it will raise an error when you try to take a photograph.
The code will work if it is run on an actual iOS device, but will fail to take a photograph if deployed to the iOS
simulator.
For this tutorial, we’re not going to build onto the application from the core tutorial - we’re going to start a fresh
project. You can use the same virtual environment you used in the first project ; but we need to re-run the briefcase
new wizard.
Change back to the directory that contains the helloworld project folder, and start a new project named « Hello
Camera » :
(beeware-venv) $ cd ..
(beeware-venv) $ briefcase new
...
[hellocamera] Generated new application 'Hello Camera'
$ cd hellocamera
$ briefcase dev
(beeware-venv) $ cd hellocamera
The wizard has generated a new empty Toga project. We can now add the code to take and display a photograph. Edit
the app.py for the new application so that it has the following content :
import toga
from toga.style import Pack
from toga.style.pack import COLUMN, ROW
class HelloCamera(toga.App):
def startup(self):
main_box = toga.Box()
main_box.add(self.photo)
main_box.add(camera_button)
self.main_window = toga.MainWindow(title=self.formal_name)
self.main_window.content = main_box
self.main_window.show()
def main():
return HelloCamera()
This code has two changes over the default app that is generated by Briefcase. These additions are highlighted in yellow :
1. The first highlighted code block (in the startup() method) adds the two widgets needed to control the camera :
an ImageView to display a photo ; and a Button to trigger the camera.
2. The second highlighted code block (the take_photo() method) defines the event handler when the button
is pressed. This handler first confirms if the application has permission to take a photo ; if permission doesn’t
exist, it is requested. Then, a photo is taken. The request for permission and the request to take a photo are
both asynchronous requests, so they require the use of await ; while the app is waiting for the user to confirm
permissions or take the photo, the app’s event loop can continue in the background.
If the camera successfully takes a photo, it will return an Image object that can be assigned as the content of the
ImageView. If the photo request was canceled by the user, the self.camera.take_photo() call will return None,
and the result can be ignored. If the user doesn’t grant permission to use the camera, or the camera isn’t implemented
on the current platform, an error will be raised, and a dialog will be shown to the user.
Part of this code we’ve just added asks for permission to use the camera. This is a common feature of modern app
platforms - you can’t access hardware features without explicitly asking the user’s permission first.
However, this request comes in two parts. The first is in the code we’ve just seen ; but before the app can ask for
permissions, it needs to declare the permissions it is going to ask for.
The permissions required by each platform are slightly different, but Briefcase has a cross-platform representation for
many common hardware permissions. In the [tool.briefcase.app.helloworld] configuration section of your
app’s pyproject.toml file, add the following (just above the sources declaration) :
This declares that your app needs to access the camera, and provides a short description why the camera is required.
This description is needed on some platforms (most notably macOS and iOS) and will be displayed to the user as a
additional information when the permission dialog is presented.
We can now generate and run the app :
macOS
Android
When the app runs, you’ll be presented with a button. Press the button, and the platform’s default camera dialog will
be displayed. Take a photo ; the camera dialog will disappear, and the photo will be displayed on in the app, just above
the button. You could then take another photo ; this will replace the first photo.
Permissions are declared in the files that are generated during the original call to briefcase create. Unfortunately,
Briefcase can’t update these files once they’ve been initially generated ; so if you want to add a new permission to
your app, or modify existing permissions, you’ll need to re-create the app. You can do this by re-running briefcase
create ; this will warn you that the existing app will be overwritten, and then regenerate the application with the new
permissions.