DOCUMENTATION EN LIGNE
DE WINDEVWEBDEV ET WINDEV MOBILE

Aide / Développer pour iOS (iPhone / iPad)
  • 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
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaEtats et RequêtesCode Utilisateur (MCU)
WEBDEV
WindowsLinuxPHPWEBDEV - Code Navigateur
WINDEV Mobile
AndroidWidget AndroidiPhone/iPadWidget IOSApple WatchMac CatalystUniversal Windows 10 App
Autres
Procédures stockées
Présentation
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 :
  1. Créez un projet pour iOS (pour plus de détails, consultez Développer une application pour iPhone/iPad).
  2. Affichez la fenêtre de description de la configuration courante : sous le volet "Projet", dans le groupe "Configuration de projet", cliquez sur "Configuration courante".
  3. Dans l'onglet "Général", cochez l'option Permettre l'exécution de l'application sur macOS Catalina ou supérieur (Mac Catalyst).
  4. 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 :
AvertissementAsynchroneAffiche un message personnalisé dans une fenêtre d'avertissement système non bloquante.
ConfirmerAsynchroneAffiche 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.
DialogueAsynchroneAffiche une boîte de message non bloquante et appelle une procédure WLangage avec la valeur du bouton cliqué par l'utilisateur.
ErreurAsynchroneAffiche un message d'erreur personnalisé dans une fenêtre d'erreur système non bloquante.
ErreurAvecDélaiAsynchroneAffiche un message d'erreur personnalisé dans une fenêtre d'erreur système non bloquante pendant un délai défini.
InfoAsynchroneAffiche un message personnalisé et non bloquant dans une fenêtre d'information système.
InfoAvecDélaiAsynchroneAffiche un message personnalisé dans une fenêtre d'information système non bloquante pendant un délai défini.
OKAnnulerAsynchroneAffiche 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.
OuiNonAsynchroneAffiche 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.
Par exemple, les fonctions ErreurAsynchrone et InfoAsynchrone attendent deux paramètres :
  • 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 :
  1. Affichez l'onglet "Détail" de la fenêtre de description du champ.
  2. Pour l'option "Balayage d'une ligne", sélectionnez "Suppression automatique".
  3. 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 :
  1. Cliquez sur parmi les boutons d'accès rapide.
  2. Choisissez si nécessaire la première fenêtre affichée sur les différentes plateformes (iPhone, iPad et Apple Watch).
  3. 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.
Version minimum requise
  • Version 25
Commentaires
Cliquez sur [Ajouter] pour publier un commentaire

Dernière modification : 08/06/2023

Signaler une erreur ou faire une suggestion | Aide en ligne locale