PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV Mobile 23 → Retour au premier plan app Android de manière intempestive
Retour au premier plan app Android de manière intempestive
Débuté par Jérôme, 29 aoû. 2018 09:18 - 13 réponses
Membre enregistré
136 messages
Popularité : +1 (1 vote)
Posté le 29 août 2018 - 09:18
Bonjour à tous,

nous avons chez un client une app Android qui revient au premier plan de manière intempestive (sans que l'utilisateur ne revienne dessus ou relance l'app).

Ma question est la suivante : avez-vous déjà constaté ce phénomène en Android et surtout avez-vous compris la cause et réussi à trouver une solution ?

L'application utilise beaucoup de fonctionnalités différentes (traitement en arrière plan, géosuivi et tâche parallèle à la mise en arrière plan) il est donc difficile de savoir laquelle provoque ce phénomène.

Merci d'avance pour votre aide et vos idées ! ;)
Message modifié, 29 août 2018 - 09:19
Posté le 29 août 2018 - 10:52
Pas d'appel à la fonction FenEtat avec la constante "dessus" ?
Membre enregistré
136 messages
Popularité : +1 (1 vote)
Posté le 29 août 2018 - 12:05
Bonjour wddev,

Oui un appel à la fonction FenEtat mais pas de constante "dessus".

le code est le suivant :
SI FenEtat("FEN_home_pointer") <> Inexistant ALORS


J'ai de plus ajouté une condition qui "normalement" ne doit pas exécuter ce code en mode "arrière-plan".

ça pourrait être la cause de ce retour au premier plan ?
Posté le 30 août 2018 - 09:38
Jérôme a écrit :
Bonjour wddev,

Oui un appel à la fonction FenEtat mais pas de constante "dessus".

le code est le suivant :
SI FenEtat("FEN_home_pointer") <> Inexistant ALORS


J'ai de plus ajouté une condition qui "normalement" ne doit pas exécuter ce code en mode "arrière-plan".

ça pourrait être la cause de ce retour au premier plan ?


non, pas dans ce cas.
Ouvrez-vous une fenêtre dans le code d'init du projet .
Membre enregistré
136 messages
Popularité : +1 (1 vote)
Posté le 30 août 2018 - 17:41
Non pas d'ouverture de fenêtre dans le code d'initialisation du projet, par contre éventuellement les éléments suivants peuvent influencer ?

- un appel à la fonction Nation dans le code d'initialisation du projet ?
- dans le code d'initialisation de la première fenêtre du projet j'ai mis un MaFenêtre..Visible = Faux puis plus tard dans le code un MaFenêtre..Visible = Vrai

Est-ce que le code d’initialisation de la première fenêtre est exécuté lors d'un appel en mode arrière plan ?

Dans le doute j'ai modifié mon code comme ceci :
SI PAS EnModeArrièrePlan() ALORS
MaFenêtre..Visible = Vrai
FIN
Posté le 30 août 2018 - 18:21
non, probablement pas.

La propriété ..Visible est sans effet sur les fenêtres sous Android : "La propriété ..Visible ne s'applique pas aux fenêtres."
https://doc.pcsoft.fr/?2510138

Difficile d'en dire plus sans plus d'information...
Membre enregistré
136 messages
Popularité : +1 (1 vote)
Posté le 31 août 2018 - 09:02
Je vais continuer mes investigations, merci déjà beaucoup pour les idées et les pistes ! :merci:
Membre enregistré
1 223 messages
Popularité : +9 (11 votes)
Posté le 31 août 2018 - 09:55
Bonjour Jérôme,

Difficile de répondre...
Quelques pistes :
comment l'utilisateur "quitte" t'il l'application ? Un bouton avec FinProgramme() ou reste t'elle active ?
une notification push agit t'elle sur l'application ?
Sinon il faudrait étudier comment chaque champ de la fenêtre est actualisé. Dans quelle procédure globale, locale, dans le code de la fenêtre?
C'est ce que j'ai fait hier pour une application avec des threads...

Ou alors des interactions entre fenêtres ou fenêtres mères-filles?

--
Cordialement
François
Membre enregistré
136 messages
Popularité : +1 (1 vote)
Posté le 03 septembre 2018 - 11:04
Bonjour François,

merci pour ces suggestions.

L'utilisateur ne quitte pas l'application, il la mets simplement en arrière plan en utilisant le bouton "home".
Non, il n'y a pas de notifiation push qui agit sur l'application.
Alors il y a plusieurs manière d'actualiser les champs :
- procédure local qui mets à jour l'IHM
- procédure globale qui mets à jour l'IHM uniquement si la fenêtre est différente de "Inexistant"
- code d'initialisation et code de fin d’initialisation de la fenêtre

Il n'y a pas de code d'interaction entre les fenêtres par contre.
Membre enregistré
1 223 messages
Popularité : +9 (11 votes)
Posté le 05 septembre 2018 - 09:34
Bonjour Jérôme,

Désolé, difficile de répondre...
Est-ce que ta procédure globale qui mets à jour l'IHM uniquement si la fenêtre est différente de "Inexistant" est lancé depuis l'IHM des fenêtres ou par exemple par un thread ?

--
Cordialement
François
Membre enregistré
136 messages
Popularité : +1 (1 vote)
Posté le 05 septembre 2018 - 11:22
Oui je comprends que ça soit difficile de répondre, merci en tout cas pour la tentative ! :merci:

Elle est lancée depuis l'IHM des fenêtres ET depuis une tâche parallèle (donc un thread).

Dans le cas concerné ici il semble que ça soit plutôt le thread car il n'y a plus d'interaction de l'utilisateur depuis plusieurs minutes.

J'ai partiellement "résolu" le soucis en le contournant : après un longue séance débogage à distance et sur le terminal du client qui posait problème, je me suis rendu compte que c'était le traitement de mise en arrière plan du projet qui provoquait ceci (le fait de commenter le code à cet endroit résolvait le problème).

Du coup j'ai ajouté une fonctionnalité qui exécute ou non ce code là et le client peut désactiver les actions de mise en arrière plan et ça fonctionne.

Le traitement de mise en arrière plan appel une procédure du webservice, envoi les informations en attente et supprime les anciennes données. C'est un processus qui ne prend pas plus de 2-3 secondes si il y a beaucoup à faire.

Il reste toujours le mystère de savoir pourquoi ça fonctionne dans 98% des cas et pas sur ce téléphone en particulier.
Membre enregistré
1 223 messages
Popularité : +9 (11 votes)
Posté le 05 septembre 2018 - 11:31
Rebonjour,

Cela rejoint peut-être le problème que j'ai rencontré ici:
https://forum.pcsoft.fr/fr-FR/pcsoft.fr.windevmobile/31707-champs-fenetre-actualiser-depuis-procedure-automatique/read.awp

Il ne faut jamais actualiser les données d'une fenêtre depuis les threads mais toujours passer par ExecuteThreadPrincipal.
C'est peut être aussi valable pour exécuter "SI FenEtat("FEN_home_pointer") <> Inexistant ALORS"
je ne sais pas...

--
Cordialement
François
Membre enregistré
14 messages
Posté le 05 septembre 2018 - 20:11
Salut Jérome!

j'ai peut être une piste pour toi :

J'ai eu beaucoup de problème avec windows 10 dans le développement de mon appli, et ce que j'ai remarqué c'est que la fonction FenEtat sert à rien, quand le code est exécuter depuis une fenêtre fille de ton application, et non ta fenetre principale.

Valides à la place avec FenEnCours() = "FEN_home_pointer" c'est plus fiable.
FenEnCours va valider qu'elle fenêtre à la "main" et est en train d'exécuter du code.

Ce qu'on a découvert c'est que le "stack" d'exécution semble contre intuitif :


1- Tu fermes ta fenêtre fille qu'on appelle "B2". l'appli exécute alors le code de fermeture de la fenêtre.

2- l'appli ferme B2 et ouvre et draw le visuel de ta fenêtre parent ( "HOME" )

3- il exécute le code de l'évenement "fermeture de la fenêtre fille de HOME".

4- Même si visuellement, la fenêtre HOME est ouverte, que "B2" est fermée et que c'est le code de HOME qui est en train d'être exécuter ... il ne libèrere pas "B2". Si je valide avec FenEtat, ça me disait que B2 n'éxistait plus, mais on regardait avec FenEnCours à ce moment là, c'est "B2" qui est toujours en train d'exécuter le code.

5- Dans mon cas, à partir de HOME, je validais des donnée et j'ouvrais une nouvelle fenêtre "B2" dans un cas et ça crashait mon application, sans warning, sans erreur. il fesait juste fermé, silencieusement.

6- Quand l'event "fermeture de la fenêtre fille de HOME" est terminé, il repasse à la fonction de fermeture de B2, et comme il n'y a plus de code à exécuter, c'est uniquement a ce moment là que "B2" est libéré et fermé pour vrai.

(pour contourné mon problème, j'ai du lancé un timer et valider FenEnCours() jusqu'à ce que ce soit "HOME" qui reprenne la main, et juste à ce moment là je peux ré-ouvrir une nouvelle fenêtre "B2" )


Donc je dirais d'essaye de valider que ton appli ne lancer une ouverture d'une fenêtre dans un thread alors que tu crois que le code exécute des choses ailleurs. ou encore, que ta fenêtre est bel et bien inexistante si elle est simplement caché et non pas fermée.

( bon, c'est un peu ténu comme fil ... mais bonne chance ! )

EDIT ...

BTW, tiens nous au courant si tu trouves la cause !
Message modifié, 05 septembre 2018 - 20:20
Membre enregistré
136 messages
Popularité : +1 (1 vote)
Posté le 06 septembre 2018 - 16:41
Merci beaucoup tsavard pour ce partage d'expérience et ces explications ! :merci:

Reste à déterminer si le comportement est identique en Android qu'en Windows 10 (ce dont je doute fortement) mais par contre cela montre qu'il faut faire très attention avec les événements de fenêtre et les utilisations du FenEtat.

Je vais essayer de voir si je trouve un comportement identique et je vais voir pour ne plus utiliser FenEtat.

Merci encore ! ;)