|
|
|
|
|
- Présentation
- Créer un projet pour Catalyst avec WINDEV Mobile
- Développer une application pour Catalyst avec WINDEV Mobile
- Des fonctions spécifiques pour le mode asynchrone
- Exemple simple d'adaptation de code en mode asynchrone
- Cas complexe d'adaptation de code en mode asynchrone
MacOS - Développer une application en mode Catalyst
Apple a récemment publié un SDK permettant de compiler nativement des applications iOS pour MacOS. Naturellement WINDEV Mobile a évolué afin de vous faire bénéficier de ces nouvelles fonctionnalités. Le développement d'une application Catalyst est réalisé en plusieurs étapes : Cette page d'aide présente uniquement la création d'un projet MacOS et son développement. Sa génération et sa compilation sont identiques à celles pour une application iOS classique. Créer un projet pour Catalyst avec WINDEV Mobile Pour créer un projet pouvant être compilé pour MacOS avec WINDEV Mobile : - Créez un projet pour iOS (pour plus de détails, consultez Développer une application pour iPhone/iPad).
- Affichez la fenêtre de description de la configuration courante : sous le volet "Projet", dans le groupe "Configuration de projet", cliquez sur "Configuration courante".
- Dans l'onglet "Général", cochez l'option Permettre l'exécution de l'application sur macOS Catalina ou supérieur (Mac Catalyst).
- Validez.
Développer une application pour Catalyst avec WINDEV Mobile Le développement d'une application pouvant être compilée pour MacOs est similaire au développement pour une application classique. Cependant, de nouvelles contraintes apparaissent. La principale contrainte ajoutée est la disparition du mode synchrone. En effet, l'application n'a pas le droit de bloquer l'interface utilisateur : - pas de traitements longs dans le thread principal,
- pas de boîtes d'information ou d'erreur,
- ...
Des fonctions spécifiques pour le mode asynchrone Pour afficher des informations à l'utilisateur, le WLangage propose des fonctions spécifiques :
| | AvertissementAsynchrone | Affiche un message personnalisé dans une fenêtre d'avertissement système non bloquante. | ConfirmerAsynchrone | Affiche un message non bloquant dans une boîte de dialogue standard proposant les réponses "Oui", "Non", "Annuler" et appelle une procédure WLangage avec la réponse de l'utilisateur. | DialogueAsynchrone | Affiche une boîte de message non bloquante et appelle une procédure WLangage avec la valeur du bouton cliqué par l'utilisateur. | ErreurAsynchrone | Affiche un message d'erreur personnalisé dans une fenêtre d'erreur système non bloquante. | ErreurAvecDélaiAsynchrone | Affiche un message d'erreur personnalisé dans une fenêtre d'erreur système non bloquante pendant un délai défini. | InfoAsynchrone | Affiche un message personnalisé et non bloquant dans une fenêtre d'information système. | InfoAvecDélaiAsynchrone | Affiche un message personnalisé dans une fenêtre d'information système non bloquante pendant un délai défini. | OKAnnulerAsynchrone | Affiche un message dans une boîte de dialogue standard non bloquante proposant les réponses "OK" et "Annuler" et appelle une procédure WLangage avec la réponse de l'utilisateur. | OuiNonAsynchrone | Affiche un message dans une boîte de dialogue standard non bloquante proposant les réponses "Oui" et "Non" et appelle une procédure WLangage avec la réponse de l'utilisateur. |
Comme leur nom l'indique, ces fonctions sont asynchrones : elles ne bloquent pas le code. Le code situé après ces fonctions est donc exécuté directement, même si l'utilisateur n'a pas validé la boîte d'information. Il est donc nécessaire d'adapter le code afin d'avoir un comportement cohérent. - le texte à afficher (contrairement aux fonctions Erreur et Info, ce texte doit être composé d'une seule chaîne),
- une procédure qui sera appelée lorsque l'utilisateur valide le message.
Exemple simple d'adaptation de code en mode asynchrone Pour comprendre comment adapter le code en asynchrone, voici un cas simple de vérification de saisie : // Vérifie le nom SI SAI_Nom ~= "" ALORS // Affiche un message à l'utilisateur Erreur("Vous devez saisir un nom") // Force la saisie dans le champ DonneFocus(SAI_Nom) // Stoppe la suite du code RETOUR FIN En asynchrone, ce code devra être adapté de la façon suivante : // Vérifie le nom SI SAI_Nom ~= "" ALORS // Affiche un message à l'utilisateur // La procédure cbErreurNom sera exécutée à la validation de l'erreur ErreurAsynchrone("Vous devez saisir un nom", cbErreurNom) // Stoppe la suite du code RETOUR FIN  PROCÉDURE INTERNE cbErreurNom() // Rend le focus au champ DonneFocus(sNomChamp) FIN Remarque : pour un code plus concis, il est tout à fait possible d'utiliser les procédures lambdas en remplacement des procédures internes. // Vérifie le nom SI SAI_Nom ~= "" ALORS // Affiche un message à l'utilisateur // La fonction DonneFocus sera exécutée à la validation de l'erreur ErreurAsynchrone("Vous devez saisir un nom.", () => { DonneFocus(SAI_Nom) } ) // Stoppe la suite du code RETOUR FIN Cas complexe d'adaptation de code en mode asynchrone Dans un champ Zone répétée, il est possible de demander à gérer automatiquement la gesture de suppression : - Affichez l'onglet "Détail" de la fenêtre de description du champ.
- Pour l'option "Balayage d'une ligne", sélectionnez "Suppression automatique".
- Validez. Les événements suivants sont automatiquement associés au champ : "Avant suppression automatique", "Après suppression automatique", "Balayage d'une ligne".
Dans l'événement "Avant suppression automatique", il est possible d'annuler la suppression de la ligne, par exemple après avoir demandé confirmation. Il suffit d'utiliser l'instruction "RENVOYER Faux" pour annuler l'événement. Voici un exemple de code présent dans l'événement "Avant suppression automatique" : // Demande confirmation à l'utilisateur SI OuiNon("Supprimer le contact ?") = Oui ALORS // Supprime la ligne RENVOYER Vrai FIN  // Annule la suppression RENVOYER Faux En mode asynchrone, ce code devra bien entendu être adapté, en utilisant la fonction WLangage asynchrone correspondante. Comme la confirmation n'est pas bloquante, l'astuce consiste ici à annuler la suppression par défaut. La suppression est réellement effectuée lorsque l'utilisateur répond au dialogue qui lui est proposé.
// Demande confirmation à l'utilisateur OuiNonAsynchrone("Supprimer le contact ?", _cbSuppression) // Annule la suppression : la suppression ne sera faite que si l'utilisateur clique sur "Oui" RENVOYER Faux  PROCÉDURE INTERNE _cbSuppression(nRéponse) // Si l'utilisateur répond "Oui" SI nRéponse = Oui ALORS // Supprime la ligne demandée ZoneRépétéeSupprime(ZR_Contacts)  FIN FIN Lorsque l'application pour MacOS est développée, il suffit de générer l'application pour iOS et, comme pour les applications iOS, de passer sur un Mac pour compiler le projet Xcode : - Cliquez sur parmi les boutons d'accès rapide.
- Choisissez si nécessaire la première fenêtre affichée sur les différentes plateformes (iPhone, iPad et Apple Watch).
- L'assistant de génération se lance. Pour plus de détails sur la génération du projet Xcode, consultez Génération de l'application.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|