Blogs officiels sur tous les services et produits de PC SOFT
Publié par
19:22 Jeudi
12 Mar. 2015

[Billet publié dans le blog Le blog du ST]

Un point s'impose sur la place du menu principal dans les applications pour Android. En effet, les applications les plus anciennes initialement développées pour Android 1.X ou 2.X, peuvent ne plus afficher le bouton d'ouverture du menu principal en fonction de options de compilation de la version de WINDEV Mobile utilisée pour générer l'application. 

Avant la version la version 3.0 de Android, les applications offraient généralement un accès au menu principal des fenêtres via un bouton dans la barre de navigation pour les appareils ne disposant pas de boutons physique :
  • si le menu comportait moins de 6 options, il s'affichait sous forme de boutons en bas de l'écran, 
  • si le menu comportait plus de 6 options, les 5 premières options s'affichaient sous forme de gros boutons, et un sixième bouton automatique "Plus" permettait à l'utilisateur de voir la suite du menu sous forme d'un menu déroulant. 
A partir de la version 3.0 de Android, pour une "expérience utilisateur" améliorée et une homogénéisation des application, Google recommande l'utilisation de l'Action Bar pour permettre un accès au menu principal.

Cette différence de gestion du menu principal n'avait pas d'impact sur les application WINDEV Mobile compilées avec une version antérieure à la 20. En effet, WINDEV Mobile 19 par exemple compilait l'application en indiquant dans sa description une compatibilité relativement ancienne (via le "targetSdkVersion" de son "manifeste"). Les périphériques Android utilisaient ainsi un mode de compatibilité permettant dans tous les cas l'affichage du menu.

A partir de la version 20 de WINDEV Mobile, les applications sont générées avec une compatibilité plus élevée (le "targetSdkVersion" de son "manifeste" passe à 14). C'est nécessaire afin que les applications bénéficient des améliorations et de l'apparence des versions les plus récentes du système Android. Mais cela a pour conséquence sur les périphériques de désactiver le mode de compatibilité permettant l'affichage systématique du bouton d'accès au menu principal.

Afin de permettre l'utilisation du menu principal dans tous les cas de figure, les solutions dépendent donc des périphériques utilisés pour le déploiement :

1. Si tous les périphériques des utilisateurs de l'application sont sous Android 3.X, 4.X ou 5.X :

  • La solution vivement recommandée consiste à utiliser un champ Action Bar. Il permettra l'accès au menu via l'Action Bar, tout en donnant à l'application l'aspect "standard" des applications Android ce qui facilite sa prise en mains par les utilisateurs. 
  • L'autre alternative peut consister à ajouter un bouton appelant la fonction OuvreMenuPrincipal
2. Si des périphériques Android 1.X ou 2.X restent utilisés pour cette application :

  • restaurer une compatibilité antérieure pour l'application lors de sa génération :  
    • génération de l'application,
    • étape "Configuration",
    • bouton "Configuration avancée",
    • bouton "Editer le manifeste",
    • dérouler le nœud "uses-sdk",
    • modifier la valeur de "targetSdkVersion" en précisant la même valeur que "minSdkVersion" : 

  • ou ajouter un bouton appelant la fonction OuvreMenuPrincipal

Publié par
21:13 Mardi
03 Mar. 2015

[Billet publié dans le blog Le blog du ST]

Une nouvelle version de WINDEV, WEBDEV et WINDEV Mobile 20 est disponible en téléchargement., il s'agit de la versio 200051m qui a passé tous les niveaux de validation :


Publié par
13:24 Lundi
02 Mar. 2015

[Billet publié dans le blog HFSQL & Performances]

Toutes les applications et sites qui utilisent des données d'une base HFSQL client/serveur, reposent sur une connexion permanente entre l'application, ou le site, et le moteur HFSQL client/serveur. Cette connexion repose sur le protocole TCP/IP, et l'utilisation de sockets.

Pas d'exception pour confirmer la règle, qu'il s'agisse :
  • d'une application WINDEV sous Windows 32 ou 64 bits, 
  • d'un site WEBDEV, 
  • d'une application mobile sous iOS ou Android compilée avec WINDEV Mobile,
  • d'un moteur HFSQL client/serveur installé sur un réseau local, distant, ou dans un CLOUD (PCSCLOUD, ...),
c'est toujours une connexion TCP qui servira à l'envoi des requêtes au moteur HFSQL client/serveur, à la récupération des données...

Le but de ce billet est de détailler comment sont faites les connexions, puis surtout les déconnexions. En effet comme toujours, lorsque l'on connaît le principe de fonctionnement, il devient plus simple de déterminer les solutions à mettre en place, quelque soit le but à atteindre !

L'ouverture d'une connexion se fait :
  • lors d'un appel explicite de la fonction HOuvreConnexion
  • ou implicitement dès qu'il sera nécessaire d'interroger le serveur, car toutes les fonctions HFSQL (H*), ouvrent si besoin la connexion associée aux tables. C'est valable pour les connexions décrites dans l'analyse, mais également par programmation, ou paramétrées lors du déploiement de l'application. 

Dans les deux cas le centre de contrôle HFSQL (CCHF) permet de visualiser les connexions ouvertes par les applications, via le volet "Connexions". C'est un autre sujet, mais soulignons qu'un même processus peut instancier plusieurs clients HFSQL et donc ouvrir plusieurs connexions, grâce aux contextes HFSQL indépendants (disponible également pour les classes).

Voici maintenant les différents cas possibles qui vont terminer les connexions :
  1. L'application n'a plus besoin des données du serveur et poursuit son exécution dans une phase n'utilisant pas de donnée. Elle peut terminer ses connexions par un appel de la fonction HFermeConnexion. Elle libère ainsi sur le serveur les ressources nécessaires aux différentes connexions ouvertes.
  2. L'application est terminée par son utilisateur par son option standard de fermeturen sans faire appel à HFermeConnexion. Toutes les connexions ouvertes par le processus sont automatiquement fermées. En effet dans ce cas l'arrêt du processus déclenche le déchargement des modules du framework, dont le client HFSQL fait partie. Le client HFSQL informe le serveur de l'arrêt du processus et, le moteur HFSQL peut donc supprimer les connexions. 
  3. L'application est terminée par un arrêt du processus (fin de tâche sur le processus). Dans ce cas le client HFSQL n'est pas déchargé, il ne peut donc envoyer au moteur HFSQL client/serveur la demande de fermeture des connexions en cours. Dans ce cas, c'est une fonctionnalité du système d'exploitation qui prend le relais. En effet, il gère automatiquement l'envoi d'un paquet réseau spécifique (RST) pour les connexions TCP de l'application. Le moteur HFSQL client/serveur gère la récupération de ces paquets, ainsi il peut mettre fin aux connexions même s'il n'a pas été notifié de façon standard par l'application.

    Dans ces 3 cas, le moteur HFSQL client/serveur est notifié de l'arrêt de l'application et toutes les connexions sont immédiatement supprimées. 
  4. L'application n'est pas terminée, mais la connexion réseau est perdue. Pour le moteur HFSQL client/serveur la connexion est donc toujours présente, puisque ni l'application, ni le système client n'a pu le notifier (cas 1 2 3). Dans ce cas la connexion va persister sur le serveur, jusqu'à : 

    - la reconnexion automatique ou programmée de l'application qui était connectée, si la coupure de connexion n'a été que temporaire, et qu'il n'y avait aucune donnée bloquée (Cf. Limites de la fonction HReconnecte), 

    - un envoi d'information du moteur HFSQL client/serveur à cette connexion, par exemple un message, dans ce cas le serveur pourra détecter la connexion rompu et la supprimer, 

    - la réception d'une notification du système d'exploitation serveur sur le fait que la connexion TCP n'existe plus. En effet, les systèmes serveurs notifient régulièrement les processus qui communiquent via TCP/IP, dont le moteur HFSQL client/serveur, afin de leur signaler les éventuelles connexions qui ne sont plus valides. Dans ce cas le temps nécessaire pour que le moteur HFSQL client/serveur supprime la connexion est très variable, la fréquence de notification par le système étant réglable sur les serveurs (généralement aux alentours de deux heures). 

Découlent de ces mécanismes un ensemble de constats, astuces... 

En premier, pas d'inquiétude en cas d'une simple micro-coupure sur la connexion. En effet, puisque le moteur HFSQL client/serveur garde les connexions, les applications vont poursuivre leur exécution dès que la connexion sera restaurée (tant que le processus n'est pas arrêté). Voici les liens utiles en complément sur ce thème :

Ensuite dans le cas général la gestion des connexions ne nécessite aucune programmation spécifique, puisque même si la déconnexion n'est pas explicitement faite par l'application, le système permettra au moteur HFSQL de terminer une connexion inutile à plus ou moins court terme.

Enfin, on peut noter l'importance du fait que le moteur HFSQL client/serveur peut de lui-même supprimer une connexion perdue, si la communication vers l'application client liée à la connexion n'est plus joignable. En effet, si l'application qui a perdu la connexion vers le serveur a bloqué des enregistrements de la base de données, par défaut les données restent bloquées tant que le système serveur n'a pas notifié le moteur HFSQL client/serveur. Si une transaction était en cours, elle reste également active. Suivant le domaine d'activité, un déblocage plus rapide peut être souhaité. On peut donc l'obtenir en jouant sur le fait que le moteur HFSQL client/serveur supprime les connexions inexistantes, s'il tente l'envoi d'un message vers l'une de ces connexions. Pour forcer une communication du moteur HFSQL client/serveur vers les processus clients, dans le cas général toutes les communications sont à l'initiative des applications clientes, on peut utiliser la fonction HEnvoieMessageVersClient

L'utilisation de cette solution avec HEnvoieMessageVersClient doit être prévue dans l'application, sous peine d'afficher des messages sur les postes de tous les utilisateurs de l'application, y compris ceux qui n'ont jamais été déconnectés ! La fonction HSurAppelServeur doit être appelée par les applications afin de personnaliser la gestion de l'affichage des messages, justement pour ne rien afficher ! Exemple de procédure (bien pratique) de réponse à HSurAppelServeur :

Procedure MessageClient(Type, sMessageAAfficher, DuréeMsg)

SI Type = hMessage ALORS
 
 SELON sMessageAAfficher[[1 A 5]]
 
  CAS "##RAS"
   // On ne fait strictement rien
   // message destiné à forcer le moteur HFSQL
   // à solliciter ses connexions pour les vérifier
   
  CAS "##AZE"
   // Au passage on peut inventer toutes sortes de commandes
   // pour faire faire des actions aux applications à la demande
   // sans solliciter ni déranger l'utilisateur !
   ExécuteTraitement(...)
   ThreadExecute(...)
 
  AUTRES CAS :
   // Véritable message à afficher !
   ToastAffiche(sMessageAAfficher,toastLong, cvMilieu, toastLong,VertPastel)
   
 FIN
 
FIN

On note au passage que cette méthode peut permettre de commander à distance des actions aux applications ! Dans certains cas et du moment que toutes les applications partagent leur données via un même serveur HFSQL client/serveur, cela remplace avantageusement une solution du dialogue par socket ou messages Windows. D'autant plus que la structure HClient permet de gérer finement l'envoi des messages. Un exemple d'utilisation de HEnvoieMessageVersClient a été proposé dans la LST 90 p30 : WD Notification.
Publié par
08:50 Mercredi
25 Fév. 2015

[Billet publié dans le blog Le blog du ST]

Un site WEBDEV dynamique déployé sur un serveur a fréquemment besoin d'effectuer des traitements en "back-office", afin de pouvoir effectuer des traitements longs sans attente de l'utilisateur du site :
  • importation, exportation, consolidation de données,
  • traitement de supervision,
  • push de notification,
  • emailing...

Notre support a régulièrement la demande : comment faire tous ces traitements si faciles avec un programme WINDEV lancé en service ou par une tâche planifiée, lorsque le site est déployé sur un serveur mutualisé, qui ne permet pas l'exécution d'un programme compilé (seul le serveur d'application de WEBDEV s'exécute) ?

C'est en fait très simple, mais souvent méconnu, WEBDEV apporte une solution depuis la version 18 grâce aux tâches planifiées et tâches différées. Là où un programme WINDEV sans interface aurait fait l'exécution du traitement "back-office" lancé à intervalles réguliers par une tâche planifiée, une procédure globale du site sera créée dans le site avec l'automatisme adéquate :


 
Cette solution s'applique bien sûr aux plateformes de déploiement hébergées sur PCSCLOUD, du moment que le rôle "serveur d'application" est actif.

Publié par
11:48 Mardi
24 Fév. 2015

[Billet publié dans le blog Le blog du ST]

Les sites dynamiques conservent une session active sur le serveur qui les héberge, pour tous les internautes connectés. Ce mécanisme est déjà détaillé dans le billet suivant :  

Un complément d'information sur ce thème est nécessaire. En effet une nouveauté de WEBDEV incluse à partir de la version 19, reposant sur une possibilité de HTML 5, apporte une nouvelle solution pour les sites qui doivent conserver une session constamment active sur le serveur. Si précédemment l'utilisation d'un timer pouvait s'imposer, il est maintenant possible de l'éviter. 

Dans la description d'un projet une option "maintenir automatiquement les sessions ouvertes (uniquement HTML 5)" est proposée :


Avec l'option "maintenir automatiquement les sessions ouvertes (uniquement HTML 5)" au niveau du projet, les sessions sont maintenues actives tant que la communication avec le navigateur fonctionne, donc tant qu'une page du site est affichée dans le navigateur de l'internaute : cela éviter un timeout des sessions.

D'autre part les pages disposent d'une option "Rafraîchir les données de la page depuis le serveur" dans le volet "Détail" de la description :


L'option "Rafraîchir les données de la page depuis le serveur" permet d'envoyer depuis le code serveur des données vers le navigateur sans timer dans le navigateur. Un code Ajax serveur et un code navigateur sont automatiquement ajoutés dans la page : 


Le code serveur est appelé automatiquement en boucle, en utilisant comme fréquence la "période de rafraîchissement" indiquée dans la description de la page. Il n'est plus nécessaire d'avoir d'une procédure navigateur appelée par Timer, pour faire appel à la fonction AjaxExécute). Par exemple le code serveur "Rafraîchissement des données" consulte une information de la base de données, et met à jour si besoin des champs de la page. Si une mise à jour est faite, le code navigateur "Après rafraîchissement" est appelé. Cela permet "côté navigateur", de pouvoir notifier l'utilisateur du site qu'une modification a été faite, par exemple avec un "toast" de notification (cf. ToastAffiche).  Le code serveur "Rafraîchissement des données" peut également effectuer une action sans provoquer l'appel du code navigateur "Après rafraîchissement", il suffit pour cela de "RENVOYER Faux" à la fin du traitement.

A noter que l'administrateur de WEBDEV permet de voir l'activité provoquée par l'appel du code "Rafraîchissement des données : le délai "Inactif depuis" montré dans la liste des connexions au site (volet "Connexions" de l'administrateur), est remis à zéro à chaque appel automatique du code.
___________________________________

Ces options utilisent la technologie "Server-sent events" (SSE), qui permet à la session (côté serveur) d'initier la transmission de données vers le navigateur une fois que la connexion initiale a été mise en place. 

Cette technologie permet de ne pas consommer de bande passante inutile avec un timer qui ferait des demandes "pour rien" au serveur. De plus sans timer "côté du navigateur" il n'y a pas d'activité de ce dernier, donc son utilisation du CPU est réduite. C'est donc particulièrement intéressant pour les sites visités depuis des smartphones ou tablettes : réduction de la consommation du forfait data, et de la batterie. 

Attention, reposant sur HTML 5, l'utilisation de cette solution nécessite de vérifier au préalable que tous les utilisateurs du sites pourront en bénéficier. Certains navigateurs peuvent ne pas supporter ce mécanisme, certaines stratégies de sécurité et antivirus peuvent bloquer des protocoles.




Publié par
08:27 Mardi
24 Fév. 2015

[Billet publié dans le blog Le blog du ST]

Une nouvelle version de WINDEV, WEBDEV et WINDEV Mobile 20 est disponible en téléchargement. Il s'agit de la version 200051j proposée en niveau 1 de validation :




S'agissant d'une version en niveau 1 de validation, elle n'est pas proposée par WDAutomaticupdate. La mise à jour automatique s'activera lorsque la version sera en niveau 2 de validation.
Publié par
09:27 Vendredi
06 Fév. 2015

[Billet publié dans le blog Le blog du ST]

Le traditionnel champ onglet a été complété en version 20 afin de permettre l'ajout dynamique de volets. On parle alors d'un onglet MDI, qui permet par exemple d'avoir le même principe de manipulation des volets que dans un navigateur :


Voici les liens se rapportant à la fonctionnalité : 

Les volets dynamiques se manipulent non pas par un indice comme les volets décrits dans l'éditeur, mais par un alias. Exemple lors de l'ajout d'un volet :  

soit sAlias = OngletOuvre(ONG_TEST,"Libellé volet",FI_POUR_ONGLET)

L'alias obtenu permet ensuite :
  • de rendre ce volet actif :
    ONG_TEST = sAlias
  • d'affecter un champ de ce volet :
    {sAlias+".SAI_TEST"} = "Texte"

L'onglet MDI permet également à l'utilisateur final d'ajouter un volet par un clic sur le volet "+". Dans le cas général aucune programmation n'est nécessaire pour permettre cette possibilité, il suffit que l'option "avec bouton nouveau" soit coché dans le volet "Détail" de la description du champ :


Par contre, si l'on souhaite pouvoir manipuler par programmation le volet ajouté par le bouton "+", il faut utiliser la méthode suivante :
  • éditer le code du volet MDI,
  • dans le code "Création d'un volet", ajouter un appel de la fonction OngletOuvre tel que décrit précédemment, en récupérant l'alias renvoyé par la fonction. 


En effet le bouton "+" de l'onglet MDI fait automatiquement l'appel de ce code, et s'il utilise la fonction OngletOuvre c'est ce dernier qui sera pris en compte.


Publié par
15:30 Jeudi
29 Jan. 2015

[Billet publié dans le blog Le blog du ST]

Un précédent billet abord le thème de la mise au point d'échange de données avec des requêtes HTTP. L'utilitaire Wireshark est proposé en illustration afin par exemple de consulter un échange complet entre une application et un serveur :  

Le nouveau type httpRequete proposé depuis la version 20 de WINDEV, WEBDEV et WINDEV Mobile peut faciliter la mise au point de requêtes, il remplace au passage très avantageusement la fonction HTTPRequete : 

Ainsi un simple point d'arrêt dans le débogueur peut permettre de voir la réponse d'une requête, sans passer par un utilitaire parallèle :


Publié par
08:40 Mardi
27 Jan. 2015

[Billet publié dans le blog Le blog du ST]

Le sommaire de la LST 99 est en ligne. Les envois vont débuter :  
  • à partir du 29 janvier en courrier "Fréquence" pour la France Métropolitaine (livraisons prévues semaines 6 et 7).  
  • à partir du 3 février en Courrier Postal Prioritaire pour les DOM-TOM et Etranger (livraisons prévues semaines 7 et 8 selon les destinations). 


Parmi les exemples :
  • CHAMPS CARTE, TABLE, ETC. ACTIVER AUTOMATIQUEMENT LA ROULETTE DE LA SOURIS AU SURVOL (WINDEV) 
  • BEST PRACTICE : ENRICHISSEZ UNE FONCTION DU WLANGAGE (WINDEV, WEBDEV, WINDEV Mobile) 
  • WINDEV 20 : LES DONNÉES D'UN CHAMP TCD (CUBE ROLAP) DANS 1 GRAPHE (WINDEV) 
  • EXPLICATIONS JQUERY : SCROLL AUTOMATIQUE & ANIMATIONS (WEBDEV) 
  • 4 ASTUCES POUR ANDROID (WINDEV Mobile) 
  • PILOTEZ UN SITE PRESTASHOP DEPUIS UNE APPLICATION WINDEV ! (WINDEV) 
  • AMÉLIORER SIMPLEMENT L'ASPECT DES GRAPHIQUES (WINDEV) 
  • PERSONNALISER LE MENU CONTEXTUEL D'UNE COLONNE DE TABLE (WINDEV) 
  • ASTUCE : DÉROULER UN MENU PAR PROGRAMMATION (WINDEV) 
  •  QUESTIONS & RÉPONSES (WINDEV, WEBDEV, WINDEV Mobile) 
  • UN NOUVEAU GABARIT DE PRÉSENTATION D'ACTUALITÉS (WINDEV Mobile) 
  • UN SITE DE PRÉSENTATION PRÊT À L'EMPLOI (WEBDEV) 
  • MOBILE & SÉCURITÉ : DES MODÈLES DE CHAMPS POUR DÉVERROUILLER UNE APPLICATION OU SÉCURISER UNE ACTION (WINDEV Mobile) 
  • WEBDEV : DES CHAMPS DE SAISIE ET DES COMBOS QUI ONT DU STYLE !!! (WEBDEV) 
  • UTILITAIRE POUR IPHONE/IPAD GÉNÉRER UN SPLASH SCREEN POUR TOUTES LES RÉSOLUTIONS (WINDEV, WINDEV Mobile) 
  • N'OUBLIEZ PLUS D'EFFACER LES FICHIERS TEMPORAIRES ! (WINDEV) 
  • UN COMPOSANT INTERNE POUR DÉVELOPPER UN WEBSERVICE REST “STANDARD”, ET COMMENT LE CONSOMMER (WEBDEV) 
  • TRANSFORMER UN TEXTE RTF AVEC IMAGES EN DOCUMENT HTML (WINDEV) 
  • UN CHAMP DE RECHERCHE AU GOÛT DU JOUR ! (WINDEV) 
  • CHAMP RTF : AFFICHER UNE BULLE D'AIDE AU SURVOL D'UN MOT (WINDEV) 


Publié par
09:45 Lundi
26 Jan. 2015

[Billet publié dans le blog Le blog du ST]

Référencement des sites web, l'importance de la balise Meta-Description !
WEBDEV propose un assistant pour le référencement des sites, il est accessible par le choix "Optimiser le référencement" du bouton "Référencement" du volet "Projet" du ruban :

Sur ce thème voici un article intéressant qui détaille notamment l'importance du titre et de la balise meta-description dans le référencement / "web-ranking" :


Le contenu de la meta-description ne va pas améliorer directement le référencement de la page, mais favoriser sa sélection par l'internaute à choix égal, et donc par effet indirect, augmenter le "web-ranking" ....