| |
Posté le 05 juin 2023 - 15:42 |
Bonjour,
J'ai une application Windev Mobile (Android) qui doit récupérer des données toute les 100ms en BLE et les afficher.
Le problème est que la fonction appelé pas BTLECaractéristiqueChangementValeur ne semble pas réagir aussi rapidement, j'ai des décalages dans le temps entre l'envoi et l'affichage.
Est-il possible de prioriser cet fonction ou de l'application ?
Merci d'avance |
| |
| |
| | | |
|
| | |
| |
Posté le 05 juin 2023 - 17:11 |
Bonjour,
Utilisateur des fonctions Bluetooth depuis quelques années, je rencontre les mêmes soucis de performances et ceci est valable sur la plupart des fonctions sous Android en comparaison avec d'autres outils de développement.
Les procédures Java qui se cachent derrière les fonctions du WLanguage ne sont pas optimisées pour la plupart.
La seule solution pour faire fonctionner correctement le Bluetooth est d'y aller à taton en fonction du matériel et d'ajouter des multitache dans le code pour faire respirer le système.
L'utilisation d'un Thread qui gère uniquement le bluetooth permet également un fonctionnement plus stable.
Sur nos applications Android Multitâche doit être la fonction la plus utilisée.
Nous travaillons encore en WM27 en attendant que WM28 soit optimisé. |
| |
| |
| | | |
|
| | |
| |
Posté le 05 juin 2023 - 18:50 |
Selon moi l'utilisation de la fonction Multitache devrait pourtant être réservée à des cas très particulier.
Sur mobile il FAUT programmer en asynchrone.
Multitache peut bien souvent conduire à des bugs aléatoires car il rend la main à l'utilisateur au milieu d'un traitement. Cela peut potentiellement provoquer des effets inattendus et souvent difficile à reproduire. |
| |
| |
| | | |
|
| | |
| |
Posté le 06 juin 2023 - 12:58 |
zouka a écrit :
Selon moi l'utilisation de la fonction Multitache devrait pourtant être réservée à des cas très particulier.
Sur mobile il FAUT programmer en asynchrone.
Multitache peut bien souvent conduire à des bugs aléatoires car il rend la main à l'utilisateur au milieu d'un traitement. Cela peut potentiellement provoquer des effets inattendus et souvent difficile à reproduire.
Problème sans les multitache partout , les applications développées en Windev Mobile sous Android entrainent des ralentissement des appareils.
Comment procédez vous quand par exemple un thread collecte en permanence des infos sur un webservice ou un thread collecte des données par Bluetooth?
Sans intégrer des multitache partout le système est très lent! |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
328 messages |
|
Posté le 06 juin 2023 - 14:34 |
Cezame a écrit :
Problème sans les multitache partout , les applications développées en Windev Mobile sous Android entrainent des ralentissement des appareils.
Comment procédez vous quand par exemple un thread collecte en permanence des infos sur un webservice ou un thread collecte des données par Bluetooth?
Sans intégrer des multitache partout le système est très lent!
Est-ce que les automatismes de procédure pourraient convenir ? |
| |
| |
| | | |
|
| | |
| |
Posté le 06 juin 2023 - 14:41 |
Je ne vois pas le rapport avec Windev Mobile ici. Si vous récupérer par exemple des données d'un webservices et que c'est lent c'est probablement plutôt du côté de la qualité de la connexion qu'il faut regarder ou alors de la quantité de la données échangées qui n'est peut-être pas optimisée pour un mobile. J'ai développé plusieurs application WM qui accède à des WS, je n'ai jamais eu de problème de lenteur particulier et en tout cas pas plus qu'en développant directement dans Android Studio.
Bien souvent des applications mobiles qui paraissent lentes sont des applications mal conçues (sans remettre en cause vos compétences) car elles font trop de choses dans le thread principal en bloquant la navigation dans l'application et en dégradant l'expérience utilisateur.
Vous parlez de Multitâche et de threads, ce sont deux choses qui n'ont rien à voir. Multitâche n'a de sens que si elle est appelée dans le thread principal (je le répète dans des cas très particulier). Appelée dans un thread, la fonction Multitâche n'est rien de plus qu'une pause (équivalent à un ThreadPause) et n'apporte donc aucun gain.
La programmation asynchrone consiste à faire les traitements les plus chronophages dans des threads et de revenir dans le thread principal uniquement pour mettre à jour l'interface. Nul besoin d'appel à Multitâche pour cela. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
328 messages |
|
Posté le 06 juin 2023 - 15:12 |
Je fais un petit détour pour vous faire part de mon expérience, mais je reviens bien au sujet à la fin 
Sur le fait que l'emploi du Multitâche est à éviter le plus possible, je rejoins zouka.
J'admets par contre que je l'emploie encore dans les cas où je pressens que mes problèmes viennent du fait "que je vais trop vite pour l'OS". Mais ça reste un contournement et pas une solution pérenne.
Je prendrai comme exemple quelque chose qui est mal voire pas documenté, que j'utilisais mal et que j'ai résolu récemment : comment mettre à jour une fenêtre mère au retour d'une fenêtre fille ? J'avais des plantages parce que je rafraîchissais immédiatement la mère dans l'événement de fermeture d'une fille. Or c'était trop tôt. Lorsque je l'ai "deviné", j'ai fait usage du multitâche pour "attendre" que la fille se ferme vraiment, mais quelle durée ? Et ça créait des latences. Bref c'était moche et pas 100% efficace.
Puis on m'a parlé sur ce forum de DemandeDeMiseAJourUI. Ca a résolu le problème. Il fallait comprendre que DemandeDeMiseAJourUI allait plus loin que ce qui était documenté.
J'en reviens au sujet. Je ne serais pas surpris que PC Soft propose un mécanisme adapté au cas de Philippe, soit avec de l'asynchrone soit avec des automatismes de procédure ou encore je ne sais quoi d'autre. Ce qui fait défaut, c'est plutôt la littérature dans la doc.
Tout simplement, une requête au support peut donner de très bonnes pistes, ainsi que les projets exemples. |
| |
| |
| | | |
|
| | |
| |
Posté le 06 juin 2023 - 15:45 |
Pucpood a écrit :
Je fais un petit détour pour vous faire part de mon expérience, mais je reviens bien au sujet à la fin Sur le fait que l'emploi du Multitâche est à éviter le plus possible, je rejoins zouka. J'admets par contre que je l'emploie encore dans les cas où je pressens que mes problèmes viennent du fait "que je vais trop vite pour l'OS". Mais ça reste un contournement et pas une solution pérenne. Je prendrai comme exemple quelque chose qui est mal voire pas documenté, que j'utilisais mal et que j'ai résolu récemment : comment mettre à jour une fenêtre mère au retour d'une fenêtre fille ? J'avais des plantages parce que je rafraîchissais immédiatement la mère dans l'événement de fermeture d'une fille. Or c'était trop tôt. Lorsque je l'ai "deviné", j'ai fait usage du multitâche pour "attendre" que la fille se ferme vraiment, mais quelle durée ? Et ça créait des latences. Bref c'était moche et pas 100% efficace. Puis on m'a parlé sur ce forum de DemandeDeMiseAJourUI. Ca a résolu le problème. Il fallait comprendre que DemandeDeMiseAJourUI allait plus loin que ce qui était documenté. J'en reviens au sujet. Je ne serais pas surpris que PC Soft propose un mécanisme adapté au cas de Philippe, soit avec de l'asynchrone soit avec des automatismes de procédure ou encore je ne sais quoi d'autre. Ce qui fait défaut, c'est plutôt la littérature dans la doc. Tout simplement, une requête au support peut donner de très bonnes pistes, ainsi que les projets exemples.
Pour toute les ouvertures de fenêtre qui ont besoin de mettre à jour la fenêtre parente, j'utilise la fonction OuvreAsynchrone et je fais mon traitement de mise à jour de la fenêtre dans la callback que je passe à la fonction. |
| |
| |
| | | |
|
| | |
| |
Posté le 06 juin 2023 - 15:51 |
zouka a écrit :
Je ne vois pas le rapport avec Windev Mobile ici. Si vous récupérer par exemple des données d'un webservices et que c'est lent c'est probablement plutôt du côté de la qualité de la connexion qu'il faut regarder ou alors de la quantité de la données échangées qui n'est peut-être pas optimisée pour un mobile. J'ai développé plusieurs application WM qui accède à des WS, je n'ai jamais eu de problème de lenteur particulier et en tout cas pas plus qu'en développant directement dans Android Studio.
Bien souvent des applications mobiles qui paraissent lentes sont des applications mal conçues (sans remettre en cause vos compétences) car elles font trop de choses dans le thread principal en bloquant la navigation dans l'application et en dégradant l'expérience utilisateur.
Vous parlez de Multitâche et de threads, ce sont deux choses qui n'ont rien à voir. Multitâche n'a de sens que si elle est appelée dans le thread principal (je le répète dans des cas très particulier). Appelée dans un thread, la fonction Multitâche n'est rien de plus qu'une pause (équivalent à un ThreadPause) et n'apporte donc aucun gain.
La programmation asynchrone consiste à faire les traitements les plus chronophages dans des threads et de revenir dans le thread principal uniquement pour mettre à jour l'interface. Nul besoin d'appel à Multitâche pour cela.
Le problème souligné n'est pas le temps de réponse du webservice mais les performances globales du système.
J'utilise des thread pour toutes les taches hors interface graphique, le thread principal ne gère que les affichages.
Pour en revenir au Bluetooth , sans utiliser des multitache que les divers équipements que j'utilise il est impossible de faire fonctionner.
Par exemple j'ai un équipement qui demande un acquittement pour chaque donnée reçue, si je mets pas un multitâche entre la réception et l'envoi de la commande ça ne fonctionne pas!
En Java sans temps d'attente ça fonctionne ! |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
328 messages |
|
Posté le 06 juin 2023 - 16:22 |
Ce qui pourrait vouloir dire "j'envoie alors que la réception n'a pas été soldée". N'y a-t-il pas quelque-chose qui annonce officiellement que la réception est terminée (flag, événement, statut, ...) ou bien manquerait-il un tout petit élément au niveau du protocole de réception (un acquittement, la fermeture d'un truc, ...) ? Peut-être que l'UI peut être impliquée.
Attendre débloque sûrement, jusqu'à tomber sur un appareil où le temps d'attente n'est pas assez long.
Je n'affirme pas que la bonne solution existe, mais les 2 bonnes questions à mon avis quand on pense "Multitâche" sont :
- attendre QUOI ?
- comment intercepter ce QUOI ?
Si on n'a pas de réponse alors OK pour un Multitâche en attendant mieux. |
| |
| |
| | | |
|
| | |
| |
Posté le 06 juin 2023 - 16:31 |
Pucpood a écrit :
Ce qui pourrait vouloir dire "j'envoie alors que la réception n'a pas été soldée". N'y a-t-il pas quelque-chose qui annonce officiellement que la réception est terminée (flag, événement, statut, ...) ou bien manquerait-il un tout petit élément au niveau du protocole de réception (un acquittement, la fermeture d'un truc, ...) ? Peut-être que l'UI peut être impliquée.
Attendre débloque sûrement, jusqu'à tomber sur un appareil où le temps d'attente n'est pas assez long.
Je n'affirme pas que la bonne solution existe, mais les 2 bonnes questions à mon avis quand on pense "Multitâche" sont :
- attendre QUOI ?
- comment intercepter ce QUOI ?
Si on n'a pas de réponse alors OK pour un Multitâche en attendant mieux.
Pour beaucoup de choses il n'y a aucune autre solution que le multitache.
J'ai constaté en général que les fonctions du WLanguage sous Android ne sont pas optimisées et qu'elle prennent plus de temps que la même fonction code en Java. |
| |
| |
| | | |
|
| | |
| |
Posté le 06 juin 2023 - 16:37 |
Cezame a écrit :
zouka a écrit : Je ne vois pas le rapport avec Windev Mobile ici. Si vous récupérer par exemple des données d'un webservices et que c'est lent c'est probablement plutôt du côté de la qualité de la connexion qu'il faut regarder ou alors de la quantité de la données échangées qui n'est peut-être pas optimisée pour un mobile. J'ai développé plusieurs application WM qui accède à des WS, je n'ai jamais eu de problème de lenteur particulier et en tout cas pas plus qu'en développant directement dans Android Studio.
Bien souvent des applications mobiles qui paraissent lentes sont des applications mal conçues (sans remettre en cause vos compétences) car elles font trop de choses dans le thread principal en bloquant la navigation dans l'application et en dégradant l'expérience utilisateur.
Vous parlez de Multitâche et de threads, ce sont deux choses qui n'ont rien à voir. Multitâche n'a de sens que si elle est appelée dans le thread principal (je le répète dans des cas très particulier). Appelée dans un thread, la fonction Multitâche n'est rien de plus qu'une pause (équivalent à un ThreadPause) et n'apporte donc aucun gain.
La programmation asynchrone consiste à faire les traitements les plus chronophages dans des threads et de revenir dans le thread principal uniquement pour mettre à jour l'interface. Nul besoin d'appel à Multitâche pour cela.
Le problème souligné n'est pas le temps de réponse du webservice mais les performances globales du système. J'utilise des thread pour toutes les taches hors interface graphique, le thread principal ne gère que les affichages. Pour en revenir au Bluetooth , sans utiliser des multitache que les divers équipements que j'utilise il est impossible de faire fonctionner. Par exemple j'ai un équipement qui demande un acquittement pour chaque donnée reçue, si je mets pas un multitâche entre la réception et l'envoi de la commande ça ne fonctionne pas! En Java sans temps d'attente ça fonctionne !
Donc de ce que je comprends vous utilisez Multitache dans des threads pour faire des temporisations.
Je ne connais pas votre code mais si c'est nécessaire au bon fonctionnement, ca ressemble quand même fortement à des problèmes de synchros de threads (accès concurrent à une même ressource, ici un périphérique BT). Je pense que l'utilisation de signaux devrait remplacer avantageusement l'usage de Multitache qui par définition ralentissent vos traitements. |
| |
| |
| | | |
|
| | |
| |
Posté le 06 juin 2023 - 18:11 |
Cezame a écrit :
Pucpood a écrit : Ce qui pourrait vouloir dire "j'envoie alors que la réception n'a pas été soldée". N'y a-t-il pas quelque-chose qui annonce officiellement que la réception est terminée (flag, événement, statut, ...) ou bien manquerait-il un tout petit élément au niveau du protocole de réception (un acquittement, la fermeture d'un truc, ...) ? Peut-être que l'UI peut être impliquée.
Attendre débloque sûrement, jusqu'à tomber sur un appareil où le temps d'attente n'est pas assez long.
Je n'affirme pas que la bonne solution existe, mais les 2 bonnes questions à mon avis quand on pense "Multitâche" sont :
- attendre QUOI ?
- comment intercepter ce QUOI ?
Si on n'a pas de réponse alors OK pour un Multitâche en attendant mieux.
Pour beaucoup de choses il n'y a aucune autre solution que le multitache. J'ai constaté en général que les fonctions du WLanguage sous Android ne sont pas optimisées et qu'elle prennent plus de temps que la même fonction code en Java.
Je ne vois vraiment pas comment l'utilisation d'un Multitâche pourrait accélérer l'exécution d'un traitement puisque justement son but est de faire une temporisation. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 messages |
|
Posté le 18 août 2023 - 10:21 |
Bonjour,
La lenteur du Bluetooth était du a la version 27 de windev.
Après avoir constaté le service assistance direct (599€) et envoyé du matériel pour test, il m'ont envoyé un patch correctif.
Le problème ne doit pas existé en version 28.
Salutations |
| |
| |
| | | |
|
| | |
| |
Posté le 18 août 2023 - 10:54 |
Philippe a écrit :
Bonjour,
La lenteur du Bluetooth était du a la version 27 de windev.
Après avoir constaté le service assistance direct (599€) et envoyé du matériel pour test, il m'ont envoyé un patch correctif.
Le problème ne doit pas existé en version 28.
Salutations
En WM27 comme en WM28 il y a des bugs sur les fonctions BLE, j'ai ouvert un incident voila bientôt 2 mois et j'attends toujours le correctif!
Par exemple la fonction BTLEConnecte avec syntaxe 2 non bloquante ne fonctionne pas ni en WM27 ni en WM28!
Ce bug traine donc depuis au moins un an et demi et toujours pas de correctif!
Je suis intéressé par le patch pour WM27 pour faire des essais en revanche. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
328 messages |
|
Posté le 23 août 2023 - 08:22 |
Cezame a écrit :
> Je suis intéressé par le patch pour WM27 pour faire des essais en revanche.
Demande un peu délicate vu les dépenses engagées par Philippe pour l'obtenir ... |
| |
| |
| | | |
|
| | |
| |
Posté le 23 août 2023 - 09:10 |
Pucpood a écrit :
Cezame a écrit : Je suis intéressé par le patch pour WM27 pour faire des essais en revanche.
Demande un peu délicate vu les dépenses engagées par Philippe pour l'obtenir ...
Pour information j'ai reçu un patch de pcsoft pour WM28 car en WM28 ça ne fonctionne pas non plus.
Si cela fonctionne il me délivreront un patcour WM27.
En revanche payer pour corriger un bug de l'outil je trouve cela plus que limite! |
| |
| |
| | | |
|
| | |
| |
Posté le 24 août 2023 - 09:38 |
Cezame a écrit :
Pucpood a écrit : Cezame a écrit : Je suis intéressé par le patch pour WM27 pour faire des essais en revanche.
Demande un peu délicate vu les dépenses engagées par Philippe pour l'obtenir ... Pour information j'ai reçu un patch de pcsoft pour WM28 car en WM28 ça ne fonctionne pas non plus. Si cela fonctionne il me délivreront un patcour WM27. En revanche payer pour corriger un bug de l'outil je trouve cela plus que limite!
Après 2 mois d'attente d'un correctif celui ci arrive enfin mais ne fonctionne pas mieux !
J'ai maintenant des gros doutes sur le fait d'obtenir une communication BLE efficace avec Windev Mobile sous Android !
Est ce que quelqu'un utilise BLE et arrive a gérer la connexion automatique ou la reconnexion automatique des périphériques?
Par avance merci
Cordialement |
| |
| |
| | | |
|
| | |
| |
Posté le 24 août 2023 - 11:08 |
Bonjour
Oui j'utilise les fonctions BLE avec des capteurs Texas Instrument. Je ne rencontre pas de problème particulier. |
| |
| |
| | | |
|
| | |
| |
Posté le 25 août 2023 - 00:11 |
wddev a écrit :
Bonjour
Oui j'utilise les fonctions BLE avec des capteurs Texas Instrument. Je ne rencontre pas de problème particulier.
Est ce que vous utilisez la connexion à la volée?
Comment gérez vous les déconnexions et reconnexions?
Moi lorsque j'utilise la syntaxe 2 non bloquante , la procédure callback est appelée la première fois mais jamais ensuite.
Le ST a reproduit le problème et ouvert un incident mais la solution proposée dans un patch ne fonctionne pas.
Même problème en WM27 et WM28 avec différents périphériques BLE
Par avance merci pour votre retour |
| |
| |
| | | |
|
| | |
| |
Posté le 25 août 2023 - 10:01 |
Je lance un premier scan pour trouver mon périphérique et je m'y connecte avec BTLEConnecte. J'écoute l'état de la connexion avec BTLEEtatConnexion. Si je reçois une déconnexion je retente la connexion ou un scan si elle échoue.
après le bt low energy est un protocole assez capricieux et selon le matériel utilisé on n'obtient pas tjs le comportement attendu. |
| |
| |
| | | |
|
| | |
| |
Posté le 25 août 2023 - 11:42 |
wddev a écrit :
Bonjour
Oui j'utilise les fonctions BLE avec des capteurs Texas Instrument. Je ne rencontre pas de problème particulier.
Je viens de m'apercevoir que vous êtes en fait une personne du ST.
Pouvez vous nous mettre un morceau de code qui fonctionne?
Cette syntaxe là ne fonctionne pas du tout et le problème a été bien reproduit par le ST :
BTLEConnecte(LIB_IDRécepteur,BTLEConnecte_Callback)
Procedure BTLEConnecte_Callback(Périphérique btlePériphérique, Résultat booléen)
SI PAS Résultat ALORS
ToastAffiche(Périphérique.Nom+" Échec Connexion")
SINON
ToastAffiche(Périphérique.Nom+" Connexion établie")
FIN
ce code simplissime passe par la callback lors de la première connexion mais plus jamais ensuite lors de la reconnexion en cas de perte de connexion par éloignement ou arrêt et remise en route du périphérique Bluetooth.
Test réalisé avec différents périphériques Bluetooth aboutissant au même résultat
Nous constatons également des déconnexions intempestives avec cette syntaxe.
Un correctif a été apporté après plus de 2 mois mais il ne fonctionne pas non plus. |
| |
| |
| | | |
|
| | |
| |
Posté le 25 août 2023 - 11:44 |
wddev a écrit :
Je lance un premier scan pour trouver mon périphérique et je m'y connecte avec BTLEConnecte. J'écoute l'état de la connexion avec BTLEEtatConnexion. Si je reçois une déconnexion je retente la connexion ou un scan si elle échoue.
après le bt low energy est un protocole assez capricieux et selon le matériel utilisé on n'obtient pas tjs le comportement attendu.
La Syntaxe suivante est censée faire tout cela automatiquement non?
Se connecter à un périphérique Bluetooth Low Energy (connexion non bloquante) Masquer les détails
BTLEConnecte(<Périphérique> , <Procédure WLangage>)
<Périphérique> : Variable de type btlePériphérique ou chaîne de caractères
Nom de la variable de type btlePériphérique représentant le périphérique Bluetooth Low Energy avec lequel la connexion doit être établie.
Identifiant du périphérique Bluetooth Low Energy avec lequel la connexion doit être établie (propriété Identifiant du type btlePériphérique).
iPhone/iPad Attention : Le périphérique doit avoir été identifié par la fonction BTLEListePériphérique depuis le lancement de l'application.
Il n'est pas nécessaire que le périphérique soit accessible au moment de l'appel : la connexion s'effectuera dès que le périphérique sera accessible. La procédure sera appelée chaque fois que le périphérique s'allume et/ou entre dans la zone de détection de l'appareil.
<Procédure WLangage> : Nom de procédure
Nom de la procédure WLangage (également nommée "callback") appelée lors de la connexion au périphérique Bluetooth Low Energy.
Cette procédure est de la forme :
PROCEDURE <Nom de la procédure>(<Périphérique>, <Résultat>)
où :
<Périphérique> est une variable de type btlePériphérique correspondant au périphérique Bluetooth connecté.
<Résultat> est une variable de type booléen :
Vrai si la connexion a réussi,
Faux dans le cas contraire. La fonction ErreurInfo permet d'obtenir plus de renseignements sur le problème rencontré.
Source Aide en Ligne PCSoft |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 messages |
|
Posté le 28 août 2023 - 11:21 |
Bonjour,
Pas de problème pour le partage, si cela peut aidé...
Voici le lien pour le patch BLE windev mobile 27 : https://transfert.free.fr/w1Cspxh
Le procédure fourni par PCSOFT pour l'install :
Elle doit être décompressée en conservant l'arborescence dans le dossier \Programmes\ de WINDEV MOBILE 27.
Vous devez lors de la décompression confirmer le remplacement des fichiers de mêmes noms déjà présents.
Lorsque le Framework Android est mis à jour, effectuez les actions suivantes au niveau du projet :
- supprimer dans le dossier du projet le sous-dossier \Android\,
- ouvrir à nouveau le projet dans l'éditeur de WINDEV ou WINDEV Mobile,
- exécuter l'assistant de génération de l'application Android avec les options habituelles afin de recréer l'APK pour une diffusion interne, ou l'AAB pour une publication via le Play Store de Google. |
| |
| |
| | | |
|
| | |
| |
Posté le 28 août 2023 - 11:56 |
Bonjour,
Merci pour le patch, je vais faire un essai sur un pc isolé
Petite question concernant les patchs,
Ayant reçu après la dernière version de WM27 différents patchs pour différents bugs et régressions de l'outil même après la sortie e WM28
Est ce que le patch écrase les patchs précédents?
Car si c'est le cas on supprime un problème pour en créer un autre et on ne peut jamais avoir un projet complet |
| |
| |
| | | |
|
| | |
| |
Posté le 28 août 2023 - 12:52 |
Philippe a écrit :
Bonjour, Pas de problème pour le partage, si cela peut aidé... Voici le lien pour le patch BLE windev mobile 27 : https://transfert.free.fr/w1CspxhLe procédure fourni par PCSOFT pour l'install : Elle doit être décompressée en conservant l'arborescence dans le dossier \Programmes\ de WINDEV MOBILE 27. Vous devez lors de la décompression confirmer le remplacement des fichiers de mêmes noms déjà présents. Lorsque le Framework Android est mis à jour, effectuez les actions suivantes au niveau du projet : - supprimer dans le dossier du projet le sous-dossier \Android\, - ouvrir à nouveau le projet dans l'éditeur de WINDEV ou WINDEV Mobile, - exécuter l'assistant de génération de l'application Android avec les options habituelles afin de recréer l'APK pour une diffusion interne, ou l'AAB pour une publication via le Play Store de Google.
Bonjour,
Merci pour ce patch.
Après vérification le ST n'a fait que vous envoyer le patch correctif qu'il m'avaient envoyé suite à ma demande au ST Gratuit.
J'ai dons déjà ce pacth en place il ne solutionne en rien le bug de la syntaxe 2 de la fonction BTLEConnecte.
Désolé de vous le dire mais vous avez payé un support pour rien car ce correctif existait déjà et de plus il ne corrige pas l'ensemble des problèmes des fonctions BLE. |
| |
| |
| | | |
|
| | |
| |
Posté le 04 septembre 2023 - 12:20 |
wddev a écrit :
Je lance un premier scan pour trouver mon périphérique et je m'y connecte avec BTLEConnecte. J'écoute l'état de la connexion avec BTLEEtatConnexion. Si je reçois une déconnexion je retente la connexion ou un scan si elle échoue.
après le bt low energy est un protocole assez capricieux et selon le matériel utilisé on n'obtient pas tjs le comportement attendu.
Rectification...
Avec Windev Mobile "selon le matériel utilisé on n'obtient pas tjs le comportement attendu!"
Gestion calamiteuse du BLE.
Pouvez vous me fournir un code qui fonctionne et qui remplace la fonction BTLEConnecte avec syntaxe 2 non bloquante?
Par avance merci |
| |
| |
| | | |
|
| | |