25 septembre 2019
publié par 

Sous iOS 13, Apple a décidé un changement de comportement des fenêtres modales sans Action Bar.

 

En effet, pour donner plus de volumes aux applications, Apple affiche maintenant les fenêtres modales en léger décalé vers le bas pour donner l'effet que la fenêtre modale s'ouvre au-dessus de la fenêtre principale.

 

On peut toujours fermer cette fenêtre en la faisant glisser vers le bas. Mais pour tenir compte des nouveaux écrans plus grands, une nouvelle gesture a été pensée par Apple : il faut partir du bord de l'appareil, balayer de la gauche vers la droite (ou de la droite vers la gauche) jusqu'au milieu de l'écran, puis glisser le doigt vers le bas.


La bonne nouvelle est que vous n'avez rien à faire pour bénéficier de ces nouveaux comportements. Il suffit de recompiler votre application avec XCode 11 et la déployer sous iOS 13.

 

Bien entendu si vous ne souhaitez pas que votre application ait ce nouveau comportement, il suffit d'ajouter une ActionBar dans la fenêtre modale à ouvrir. Elle sera considérée comme une fenêtre principale.
Attention, la fenêtre appelante doit également avoir un ActionBar.

< Retour

8 commentaires

Chadli Younes
25/09/2019 - 16:44 - Répondre
Bonjour, C'est plutôt l'inverse =) nous sommes "obligés" d'utiliser les action bar (qui ne marchent pas correctement) pour palier à un problème de fenêtres qui ne s'ouvrent pas correctement. Il faut une option "autre" que l'utilisation d'une action bar pour spécifier si une fenêtre s'ouvre de telle ou telle manière. On ne va pas changer l'apparence de nos applis à cause de cela... La beta de l'iOS 13 ne date pas d'hier. C'est dommage de ne pas avoir anticiper ce problème avant la sortie de la version publique.

Loic HAMEL
25/09/2019 - 16:53 - Répondre
Bonjour, C'est un changement voulu et imposée par Apple. Les fenêtres modales sans Action-Bar sont considérées comme des fenêtres modales. Cela ne change pas. Ce qui change c'est la façon dont elles sont affichées. Ce n'est pas une anomalie, c'est la prise en compte d'une nouvelles régle du système. Si la régle n'est pas respectée, Apple peut décider de ne pas publier voter application.

Chadli Younes
26/09/2019 - 13:21 - Répondre
M Hamel, ce n'est pas mon habitude de critiquer Windev. Mais en testant vos dires, même en rajoutant une action bar cela ne change rien au fonctionnement =) Les fenêtres sont toutes ouvertes avec l'effet volume ) Le timing de publication ne laisse personne dupe. Si le problème avait été anticipé vous auriez publié ce billet bien avant la sortie de l'iOS 13. Cordialement. Testé avec iOS 13 / Xcode 11 / Windev Mobile 01F240077c / iPhone Xs

Loïc HAMEL
26/09/2019 - 15:54 - Répondre
J'ai modifié le billet. Il faut effectivement que la fenêtre principale ait également un ActionBar.

Matthieu JOBERT
02/10/2019 - 16:44 - Répondre
"La bonne nouvelle est que vous n'avez rien à faire pour bénéficier de ces nouveaux comportements. Il suffit de recompiler votre application avec XCode 11 et la déployer sous iOS 13." Ce n'est pas une bonne nouvelle car le look et le comportement de nos appli va changer "il suffit d'ajouter une ActionBar" Cela change radicalement le look de l'appli donc pour moi ce n'est pas une solution D'après les forums, (par exemple https://stackoverflow.com/questions/56435510/presenting-modal-in-ios-13-fullscreen), il suffirait de donner le style UIModalPresentationFullScreen au ViewController ([vc setModalPresentationStyle: UIModalPresentationFullScreen];) J'espère que la prochaine update de WM nous permettra de choisir l'ancien look ou le nouveau

Marco Pagani
03/10/2019 - 15:44 - Répondre
Bonjour, j'ai ajouté unActionBar à la fenêtre principale et à ces appels, mais le problème n'est pas résolu. Oui, même pour mon application, ce comportement différent pose un problème.

Loic HAMEL
03/10/2019 - 16:13 - Répondre
Bonjour, Il y aura dans la prochaine mise à joru de WINDEV Mobile une solution pour obtenir l'ancien comportement d'iOS

Julien B
09/10/2019 - 11:01 - Répondre
Bonjour, Je suis dans la même situation que Marco Pagani. Après quelques tests, je constate que le problème vient du fait que l'action barre doit disposer de l'option Retour à la fenêtre précédente ou Home pour que votre solution fonctionne. Hors, dans la plupart de mes fenêtres, j'effectue des traitements avant de fermer et pour cela j'utilise l'action "Code : Exécuter le traitement de clic du champ". Si cette option est utilisée votre solution ne s'applique plus, même si l'action barre existe dans la fenêtre appelante et celle en cours. Cette nouvelle option me pose de gros problèmes, car je dois effectuer un dialogue avec l'utilisateur avant la fermeture. Ceci crée une faille dans mon application car je ne peux plus empêcher l'utilisateur de revenir à la fenêtre précédente. Soit la nouvelle option est mise en place et permet d'effectuer une fermeture automatique par un tiré lâché depuis le haut de l'écran, soit je rajoute l'action Retour qui effectue également une fermeture automatique de la fenêtre sans laisser la possibilité de ne pas fermer la fenêtre si on le souhaite. Pensez-vous que ce problème pourra être contourné lors de la prochaine mise à jour "Update 4 Niveau 2" de WinDev Mobile 24 ou alors via un patch spécifique dédié ?

Publier un commentaire : 
Votre adresse email ne sera pas publiée


© 2019 PC SOFT. Tous droits réservés. Réalisé  avec WEBDEV