|
|
|
|
|
|
|
|
|
|
- Présentation
- Eléments de projets disponibles
- Champs disponibles
- Bases de données
- Menus de l'application
- Menus contextuels
- Fenêtres modales
- Gestion du bouton "Retour" et du bouton "Home"
- Bouton Retour
- Bouton Home/Accueil
- Notification d'inactivité de l'application
- Fonctionnement du focus et de la sélection
- Ascenseurs automatiques dans les fenêtres
- Gestion des répertoires
- Changement d'orientation de l'écran
- Divers
- Gestion des threads
- Opérateurs d'indirection
- Utilisation des polices natives Android
- Gestion des logs ADB
- Débogage d'applications déployées via les logs ADB
- Impression au format PDF
- API level
Particularités des applications pour Android
Le développement d'applications pour Android présente des différences par rapport au développement habituel avec WINDEV Mobile dans les domaines suivants : Eléments de projets disponibles Les éléments de projets suivants sont disponibles pour le développement Android : - Fenêtres.
- Requêtes.
Remarque : dans une requête paramétrée, tous les paramètres sont obligatoires. - Classes.
- Collections de procédures.
- Modèles de fenêtres.
Les éléments suivants ne sont pas disponibles pour le développement Android : - Composants externes.
Remarque : Les composants internes sont disponibles pour le développement Android. Cependant, si le composant interne possède une analyse, cette analyse ne sera pas prise en compte lors de l'exécution. - Etats et modèles d'états.
Champs disponibles Les champs suivants sont disponibles pour le développement Android : Remarques : - Les propriétés de style des champs (onglet "Style" de la fenêtre de description des champs), bien que disponibles en édition, ne sont pas toutes supportées par les applications Android.
- Lors de la définition du la couleur de fond du cadre des champs, il est possible d'utiliser une couleur de fond dégradée.
Pour les applications Android, les bases de données disponibles sont : - HFSQL (Classic et Client/Serveur),
- SQLite.
WINDEV Mobile inclut en standard un Connecteur Natif pour SQLite pour Android. Les principaux ordres Hxxx sont disponibles.
Remarques : - Gestion des mémos avec HFSQL : Le mode UNICODE ou ANSI d'utilisation des chaînes en exécution défini dans la configuration du projet détermine l'alphabet utilisé pour le stockage. En ANSI, par défaut les chaînes affectées aux rubriques mémos HFSQL sont encodées en UTF8. La fonction ChangeAlphabet peut être appelée afin de changer l'encodage.
- Base de données SQLite : Si votre projet Android partage son analyse avec un autre projet (non Android), vous pouvez utiliser la fonction HChangeConnexion pour associer les fichiers de données de l'application à une connexion de type SQLite. Pour plus de détails, consultez Application Android : Utilisation et partage de données.
- Gestion des mémos avec SQLite : Le stockage d'informations sous forme de mémos est conseillé uniquement pour des données de taille peu volumineuse (inférieures à 1 Mo). Il est recommandé d'enregistrer directement les données sous forme de fichier externe sur la mémoire du téléphone (interne ou externe) et de mémoriser dans la base uniquement le chemin d'accès à ces données.
- Il est également possible d'accéder à une base de données tierce (Oracle, SQL Server, ...) via un Webservice. Pour plus de détails, consultez Accès à une base de données via un Webservice.
Dans une application Android, les options de l'application peuvent être proposées : - via le champ Action Bar. Cette solution est actuellement recommandée.
- sous forme de menus (déconseillé).
Remarques sur les menus : - En édition, les menus des fenêtres Android sont présentés comme de simples menus déroulants.
- A l'exécution, ces menus s'afficheront de façon différente en fonction du nombre d'options :
- Si le menu comporte moins de 6 options, il s'affiche sous forme de gros boutons en bas de l'écran.
- Si le menu comporte plus de 6 options, les 5 premières options s'affichent sous forme de gros boutons et un sixième bouton automatique "Plus" permet à l'utilisateur de voir la suite du menu sous forme d'un menu déroulant.
- Les menus des applications Android ne supportent pas d'avoir plus d'un niveau de sous-menus. Au-delà , une erreur fatale se produit lors de l'exécution de l'application.
Menus contextuels Les menus contextuels sont supportés par WINDEV Mobile pour les applications Android. - En édition, ils sont présentés comme les menus déroulants Windows mais ils adoptent l'apparence des menus Android à l'exécution.
- Ils sont également limités à un seul niveau de sous-menu.
- Sur les appareils ne disposant pas de "clic-droit" (les téléphones par exemple), les menus contextuels sont affichés après un "appui long" sur le champ auquel ils sont associés.
Les fenêtres modales ne sont pas supportées par le système d'exploitation Android. La fonction Ouvre n'est pas autorisée. Les fenêtres peuvent être ouvertes : Pour passer une valeur de retour : - Lors de sa fermeture, une fenêtre (fille ou soeur) peut appeler une procédure locale de la fenêtre qui l'a ouverte afin de lui passer une valeur de retour. Il est également possible de renvoyer une valeur de retour via une variable globale.
- Il est possible de spécifier la valeur de retour grâce à la propriété ValeurRenvoyée de la fenêtre fille et de récupérer cette valeur via l'événement "Fermeture d'une fenêtre fille de la fenêtre" de la fenêtre mère.
Gestion du bouton "Retour" et du bouton "Home" Bouton Retour Tous les appareils sous Android disposent d'une touche spéciale "Retour" (symbolisée généralement par une petite flèche vers la gauche). Dans une application WINDEV Mobile, cette touche provoque la fermeture de la fenêtre en cours et l'exécution de l'événement "Fermeture" de la fenêtre. S'il s'agit de la première fenêtre de l'application cela provoquera l'exécution du code de fermeture de l'application et donc la fermeture de l'application. Une application doit être conçue de façon à se comporter convenablement si n'importe laquelle de ses fenêtres est fermée en utilisant la touche "Retour". En général, il suffit que chaque champ de la fenêtre soit initialisé avec une valeur par défaut ou que le bouton "Retour" soit considéré comme un bouton "Annuler". Remarque : Il est possible de changer ce comportement et d'exécuter un traitement personnalisé (par exemple pour demander une confirmation à l'utilisateur et éventuellement ne pas fermer la fenêtre notamment s'il s'agit de la première fenêtre de l'application). Pour cela, la fenêtre doit posséder un bouton ayant pour raccourci clavier "Bouton 'Back' " (onglet "UI" de la fenêtre de description du champ). Bouton Home/Accueil L'appui sur le bouton "Accueil" (ou bouton "Home") ne ferme pas l'application en cours : l'application est mise en arrière-plan. L'événement "Fermeture" de la fenêtre n'est donc pas exécuté. Remarque : Même si la fenêtre possède un champ Bouton ayant pour raccourci clavier le "Bouton 'Home' " (défini dans l'onglet "UI"), le code de ce bouton ne sera pas exécuté. Contrairement au bouton Retour, il n'est pas possible de changer le comportement par défaut. Un appui prolongé sur la touche "Home" permet de faire réapparaître la liste des applications lancées. L'utilisateur peut ainsi sélectionner son application lorsqu'il souhaite la remettre au premier-plan.
Remarque : Le système Android ne permet pas de proposer cette option par programmation. Notification d'inactivité de l'application Le système d'exploitation Android n'autorise pas une application à rester dans un traitement (sans rendre la main au système d'exploitation) pendant plus de quelques secondes. Si une application se trouve dans ce cas, Android affiche une boîte de dialogue proposant à l'utilisateur de fermer l'application ou d'attendre la fin du traitement : Pour éviter le déclenchement de ce mécanisme, les phases de calcul ne doivent pas être placées dans le thread principal de l'application. Utilisez des procédures lancées dans des threads secondaires (consultez la fonction ThreadExécute pour plus de détails). Remarque : Il est très fortement déconseillé de manipuler les éléments de l'interface d'une application depuis un thread secondaire. Les concepteurs d'Android recommandent qu'une action de l'utilisateur provoque une réaction perceptible de l'application en moins de 200 millisecondes pour donner une bonne impression de réactivité. Fonctionnement du focus et de la sélection Afin de gérer à la fois les interfaces (UI) pilotées au doigt (ou à l'aide d'un stylet) et les interfaces (UI) utilisables avec un clavier et un trackball, Android offre un système de gestion du focus et de la sélection différent des autres systèmes d'exploitation : - Le focus peut être déplacé uniquement avec une souris, un trackball ou un périphérique équivalent.
- Lorsque le focus est déplacé, les événements d'entrée et de sortie des champs sont exécutés.
- Les champs cliquables mais non éditables (boutons, listes, etc.) se comportent comme des champs en interruption. Lorsqu'ils reçoivent un clic, ils ne prennent pas le focus.
- L'événement "Sélection d'une ligne" dans les champs Liste et les champs Zone répétée est exécuté uniquement lorsque la ligne est sélectionnée par un clic.
- L'événement "Sélection d'une ligne" dans les champs Liste et les champs Zones répétée n'est pas exécuté lorsque la ligne ayant le focus change.
Attention : Dans un champ Liste ou un champ Zone répétée, le bandeau affiché ne représente pas la sélection mais seulement le focus. Ascenseurs automatiques dans les fenêtres Si la hauteur d'une fenêtre est supérieure à la hauteur de l'écran et si l'option "Ascenseurs automatiques" est cochée dans la description d'une fenêtre, un ascenseur est automatiquement ajouté à droite de la fenêtre. Il est nécessaire de tenir compte de sa présence lors de la conception de la fenêtre afin que cet ascenseur ne recouvre pas les champs. La gestion des répertoires sous Android présente les particularités suivantes : - Par défaut, le répertoire courant d'une application correspond au sous-répertoire "files" qui est automatiquement créé à la racine du répertoire d'installation de l'application.
- Les chemins relatifs manipulés par l'application sont relatifs à ce répertoire.
- Le chemin complet du répertoire en cours peut être connu avec la fonction fRepEnCours. Par défaut, il est possible de lire et écrire dans ce répertoire.
- Le répertoire en cours peut être modifié par la fonction fRepEnCours.
- Le répertoire d'exécution (retourné par la fonction fRepExe) correspond au répertoire d'installation de l'application. Par défaut les applications sont toujours installées dans le répertoire /data/data/<nom du package>.<nom de l'application>.
- Sous Android, sur l'appareil comme sur l'émulateur, le système de fichiers est en lecture seule. Une application a uniquement le droit d'écrire dans son répertoire d'installation ou dans un de ses sous-répertoires, ainsi que sur la mémoire externe (SDCard).
- Le répertoire "databases" est également automatiquement créé à la racine du répertoire d'installation de l'application pour stocker les bases de données SQLite manipulées par l'application (à moins qu'un chemin spécifique n'ait été spécifié au moment de la connexion). Le chemin du répertoire "databases" peut être connu grâce à la fonction fRepDonnées.
- Pour avoir un emplacement de stockage commun à plusieurs applications, utilisez la mémoire externe (SDCard par exemple). Le chemin d'un répertoire pour le stockage de fichiers dans l'espace de stockage externe peut être connu grâce à la fonction SysRepStockageExterne.
- Si l'utilisateur connecte son appareil au PC en mode "stockage de masse" (ou "lecteur de disque"), la SD Card est automatiquement démontée de l'appareil et n'est plus accessible depuis celui-ci. Toutes les applications installées sur la SD Card et en cours de fonctionnement sont alors tuées. Tant que la SD Card sera démontée, il ne sera pas possible de :
- lancer les applications installées sur la SD Card.
- accéder à la SDCard depuis les applications exécutées sur le téléphone.
Pour plus de détails sur la gestion des répertoires de l'application, consultez : Changement d'orientation de l'écran Pour détecter le changement d'orientation de l'écran, utilisez l'événement "Changement d'orientation" des fenêtres. Il est également possible d'utiliser les fonctions CapteurXXXX pour détecter les mouvements du téléphone. Remarque : La famille de fonctions GPS permet de gérer la géolocalisation du téléphone. - Sous Android, pour des raisons de sécurité, les touches "Home" et "Fin d'appel" ne peuvent pas être utilisées comme lettres d'appel.
- Pour utiliser le thème "Material Design", dans l'onglet "Général" de la description de la configuration Android, cochez l'option "Appliquer le thème Material design aux champs natifs et aux fenêtres Info/Erreur/Dialogue".
- Gestion des images selon le DPI : Selon le DPI de l'appareil, les images peuvent être pixelisées ou floues. Il est possible d'utiliser la gestion automatique des DPI. Pour plus de détails, consultez Android/iOS : Fournir une image par DPI.
- Les styles CSS dans les images au format SVG ne sont pas supportés sous Android.
La fonction ThreadArrête n'est pas disponible sous Android. Seul le thread lui-même peut s'arrêter en sortant de la procédure WLangage appelée par la fonction ThreadExécute. Exemple :
ThreadExécute("th", threadNormal, ProcThread) PROCEDURE ProcThread
bThreadEnVie est un booléen = Vrai
TANTQUE bThreadEnVie
// ... Traitement
// Teste de la condition de fin du thread
SI <CONDITION FIN THREAD> ALORS
bThreadEnVie = Faux
FIN
FIN Opérateurs d'indirection Les indirections sont gérées uniquement sur les variables globales. Une indirection sur une variable locale d'un traitement provoquera l'erreur "élément inconnu". Utilisation des polices natives Android Les polices suivantes peuvent être utilisées :- Droid Sans,
- Droid Sans Mono,
- Droid Serif,
- Roboto,
- Roboto Condensed,
- Roboto Light,
- Roboto Thin.
Si la police spécifiée n'est pas supportée en exécution sur l'appareil, une police de substitution sera utilisée (Roboto). Débogage d'applications déployées via les logs ADB Lorsqu'une application est déployée, les éventuelles erreurs de l'application qui se produisent chez les utilisateurs finaux sont mises à disposition du concepteur de l'application dans le "log ADB". Il est ainsi possible de récupérer les erreurs, mais également les Asserts et les traces de tous les matériels qui exécutent l'application. Les messages suivants sont écrits dans le log ADB : - Messages de la fonction Trace(niveau "Info").
- Messages de la fonction dbgSortieStandard (niveau "Debug").
- Messages des asserts (fonctions dbgAssertion, dbgVérifiexxx, dbgErreur(niveau "Assert").
- Messages des erreurs fatales et non fatales (niveau "Error").
Le "log ADB" est accessible : - dans le Centre de Contrôle Android (onglet "Logcat") : sous le volet "Outils", dans le groupe "Outils Mobile", cliquez sur "CCAndroid").
- sur chaque téléphone. Des logiciels spécifiques permettent de traiter et de visualiser le contenu de ce fichier.
- via l'outil "Monitor" disponible dans le SDK Android. Dans ce cas, il est possible de visualiser dans l'onglet "Log cat" les logs ADB de toutes les applications situées sur le périphérique connecté au PC (le périphérique doit avoir le mode "Débuggage USB" activé. Pour plus de détails, consultez Préparation du téléphone pour tester une application Android).
Sous Android, les impressions PDF supportent uniquement les polices standards Adobe (non Unicode) : Courrier, Helvetica, Times, Symbol et ZapFDingbats. Lorsqu'une application est générée pour Android, l'APK ou l'AAB obtenu contient un niveau d'API cible (ou API Level ou TargetSdkVersion) du SDK Android. Ce niveau d'API cible est déterminant pour le déploiement et l'exécution de l'application : - Google autorise ou non le déploiement d'une application dans le Play Store en fonction de son niveau d'API,
- le système Android installé sur les appareils, détermine les fonctionnalités dont peut disposer l'application et les règles de sécurité qui doivent lui être appliquées en fonction de son niveau d'API.
En fonction de la version de Android des appareils sur lesquels l'application doit être utilisée et de son mode de déploiement, il faut donc générer l'application avec une version de WINDEV Mobile adaptée. Synthèse du niveau/level d'API (TargetSdkVersion) indiqué dans le manifeste des applications Android en fonction de la version de WINDEV Mobile : | | | Versions de WINDEV Mobile | Niveau d'API (TargetSdkVersion) / Version de Android supportée | | WINDEV Mobile 22 -> WINDEV Mobile 23 "Update 2" | 24 / Android 7 | | WINDEV Mobile 23 "Update 3" -> WINDEV Mobile 24 "Update 3" | 26 / Android 8 | | WINDEV Mobile 24 "Update 4" -> WINDEV Mobile 25 "Update 3" | 28 / Android 9 | | WINDEV Mobile 25 "Update 4" -> WINDEV Mobile 26 "Update 2" | 29 / Android 10 | | A partir de WINDEV Mobile 26 "Update 3 -> WINDEV Mobile 27 "Update 3" | 30 / Android 11 | | WINDEV Mobile 27 "Update 4" | 31 / Android 12 | | A partir de WINDEV Mobile 28 -> WINDEV Mobile 28 "Update 1" | 31 / Android 13 | | A partir de WINDEV Mobile 28 "Update 2" | 33 / Android 13 | | A partir de WINDEV Mobile 2024 "Update 2" | 34 / Android 14 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|