PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV Mobile 23 → Nouveauté 715 de la version 23 - Exécuter un traitement en arrière plan sous iOS
Nouveauté 715 de la version 23 - Exécuter un traitement en arrière plan sous iOS
Débuté par Jérôme, 11 juil. 2018 11:56 - 11 réponses
Membre enregistré
123 messages
Popularité : +1 (1 vote)
Posté le 11 juillet 2018 - 11:56
Bonjour à tous,

Est-ce que quelqu'un a réussi à faire fonctionner le traitement en arrière plan sous iOS correctement ?

J'ai lu attentivement la doc de cette page : https://doc.pcsoft.fr/fr-FR/?1000023473&name=taches_arriereplan
Et plus particulièrement les points sur les spécificités iOS :

Durée d'exécution :
Les tâches en arrière-plan ont un total de 30 secondes pour s'exécuter. Si ce délai est dépassé, l'application est arrêtée directement (ce délai peut être réduit selon la disponibilité du système). L'exécution de la tâche doit donc être le plus rapide possible. => Mon traitement fait moins de 30 sec.

Pour que le système considère que l'application peut exécuter des tâches en arrière-plan, l'application doit réaliser des requêtes réseau (appels de Webservices, requêtes HTTP, accès à une base HFSQL, GPS, Email, ...). En effet, iOS vérifie que l'application exploite des données provenant du réseau. => je fais un appel avec httpRequête

L'application doit être capable d'exécuter des tâches en arrière-plan. Sur le périphérique, dans les "Paramètres de l'appareil .. Nom de l'application", l'option "Actualiser en arrière-plan" doit être cochée. => c'est coché

Lorsque l'application est terminée spécifiquement par un double appui sur le bouton Home et un swipe, la procédure en arrière-plan a moins de chance de s'exécuter. => je ne fais pas cette manipulation
La procédure ne sera plus appelée si l'appareil passe en mode "économie d'énergie". => l’appareil n'est pas en économie d'énergie

De manière générale, plus le temps d'exécution de la procédure est long, plus les appels seront espacés dans le temps. Le système a tendance à prioriser les procédures les moins consommatrices en CPU. => j'ai patienté plus d'une heure sans résultat :(

Voici mon code :
Procedure ProcArrierePlan()

fLOG.mess = "Exécution de la proc en arrière plan"
HAjoute(fLOG)

HTTPRequête("https://www.google.ch")


Cette procédure est une procédure globale et j'ai coché "Exécution périodique lorsque l'application est en arrière-plan" avec un intervalle de 15 minutes.

Qui a réussi à faire ça et comment ?

Merci pour vos avis, pistes ou expériences!
Posté le 11 juillet 2018 - 23:00
Jérôme, comment fait tu pour vérifier si ta procédure est exécuté ou pas?
tu fais un httprequette mais pas de httprésultat?
Membre enregistré
123 messages
Popularité : +1 (1 vote)
Posté le 12 juillet 2018 - 11:04
Bonjour popoy et merci de l'intérêt à mon problème.

Je fais un Hajoute avec un message. Mon fichier fLOG est horodaté automatiquement par une rubrique de ce type donc je peux voir à quel moment l'ajout est fait.

Et comme il n'y a aucun enregistrement dans ce fichier je suis sûr que la procédure n'est pas exécutée.

Le HTTPRequête est là pour répondre à l'une des "spécifités iOS" présente dans la doc ( https://doc.pcsoft.fr/fr-FR/?1000023473&name=taches_arriereplan) :
Pour que le système considère que l'application peut exécuter 
des tâches en arrière-plan, l'application doit réaliser des requêtes 
réseau (appels de Webservices, requêtes HTTP, 
accès à une base HFSQL, GPS, Email, ...). 
En effet, iOS vérifie que l'application exploite des données provenant du réseau.


C'est le seul intérêt de cet appel donc c'est pour ça que je ne fais pas de httprésultat après.
Message modifié, 12 juillet 2018 - 11:06
Posté le 12 juillet 2018 - 21:24
il semble qu'il y a en effet un problème.
je te conseil de demander un exemple au support.
personnellement, c'est ce j'ai finis par faire concernant le champ natif.
et ils ont finit par fournir cet exemple dans la Lst et modifier l'aide en conséquence.
Membre enregistré
123 messages
Popularité : +1 (1 vote)
Posté le 13 juillet 2018 - 17:35
Merci popoy pour ces conseils.

J'ai fait quelque chose de semblable à savoir envoyer un petit projet de test que j'ai soumis au ST comme étant un bug.

Pour le moment je suis en attente d'une réponse.

Cependant, et c'est vraiment incroyable, mon app est installée depuis maintenant environ 30 heures et la procédure a été exécutée une seule fois, hier (12.7.2018 à 21h05).

Je comprends bien que ce ne soit pas garanti que la procédure soit exécutée chaque 30 minutes (ce que j'ai paramétré) mais qu'une fois en 30 heures c'est vraiment (trop) peu.
Membre enregistré
4 messages
Posté le 16 juillet 2018 - 11:38
Bonjour Jérôme.

c'est en cherchant une solution au problème que vous avez posé que je suis aussi tombé sur votre sujet.

Sur mon iPhone de test (iPhone 5 sur iOS 9), j'ai eu droit à ... 0 déclenchements.
Pourtant, quand je lance l'application en mode debug arrière plan sur mon téléphone via XCode, le code complet se déclenche bien.
Toutefois, si j'active la géolocalisation sur le téléphone avec le paramètre "Toujours", j'ai aussi droit à une exécution du code d'initialisation du projet, mais cette fois, pas de la tâche d'arrière plan, et cette exécution ne se produit qu'une fois.

C'est comme s'il manquait une p'tit kekchose côté XCode pour que ce soit bien activé.

En tous cas je suis preneur d'informations concernant le retour PCSoft à votre égard ;)

--
Cordialement,
François EVSTRATEV
Message modifié, 16 juillet 2018 - 11:44
Membre enregistré
123 messages
Popularité : +1 (1 vote)
Posté le 16 juillet 2018 - 12:07
Bonjour François,

merci pour ces éléments, nous sommes déjà deux à ne pas pouvoir faire fonctionner correctement ce mécanisme.

Il y a eu du nouveau pour ce "test" sur un plus long terme :

la procédure s'est déclenchée :
11 juillet : jamais
12 juillet : 21h05
13 juillet : jamais
14 juillet : 7h15, 14h22, 15h52, 17h23
15 juillet : 7h21, 12h43, 14h26, 15h52, 17h14
16 juillet : 7h27, 8h14, 9h39

C'est donc extrêmement aléatoire et surtout c'est beaucoup moins fréquent que les 30 minutes demandées...
Membre enregistré
4 messages
Posté le 16 juillet 2018 - 16:38
Jérôme,

j'ai réussi à activer la tache d'arrière plan sur iOS.
Pour ce faire, j'ai été voir du côté des forum XCode et il semble qu'une ligne de code est manquante dans le projet porté côté XCode.

XCode:
In order to implement background fetch there are three things you must do:
1 - Check the box Background fetch in the Background Modes of your app’s Capabilities.
2 - Use setMinimumBackgroundFetchInterval(_:) to set a time interval appropriate for your app.
3 - Implement application(_:performFetchWithCompletionHandler:) in your app delegate to handle the background fetch.

Les points n° 1 et n° 3 sont bien gérés, mais le point n° 2 est absent dans le projet.
en effet, dans la fonction didFinishLaunchingWithOptions() du fichier WDAppDelegate.mm, il manque la définition d'intervalle minimum entre deux exécutions d'arrière plan.
Voici comment se présente le code modifié dans le projet XCode:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWtihOptions:(NSDictionary *)launchOptions
{
bBackground = NO;
[[UIApplication sharedApplication] setMinimumBackgroundFetchInterval:900];
[self RunApplication :launchOptions];
return YES;
}


La ligne ajoutée dans la fonction est:
[[UIApplication sharedApplication] setMinimumBackgroundFetchInterval:900];


Cette ligne règle à 900 secondes l'intervalle minimum entre deux exécutions, mais on peut aisément modifier cette valeur.

A tester de votre côté pour confirmer que cette ligne est réellement d'importance.

--
Cordialement,
François EVSTRATEV
Membre enregistré
123 messages
Popularité : +1 (1 vote)
Posté le 16 juillet 2018 - 18:01
Merci François pour ce retour !

J'ai modifié mon code en ajoutant cette ligne (je l'ai paramétrée à 1800 secondes, on verra ce que ça donne d'ici demain.

De mon côté le ST m'a répondu, voici leur réponse :
Il peut se passer plusieurs heures (maximum 24 heures) avant 
que la procédure ne soit exécutée. C’est le système iOS qui décident 
du temps entre deux exécutions. Si l’application n’est pas dans le store 
ou est dans le store mais avec très peu de téléchargement, 
elle ne sera pas prioritaire. 

L'équipe du Support Technique Gratuit reste à votre disposition.


Donc il y a également ce facteur qui entre en ligne de compte. Je fais un feedback demain avec cette nouvelle ligne voir si ça a amélioré le délai entre deux exécutions.
Membre enregistré
123 messages
Popularité : +1 (1 vote)
Posté le 18 juillet 2018 - 09:29
Est-ce que ce nouveau paramètre a amélioré quelque chose ?

Pour ma part non, l'exécution se passe de manière très similaire :

Pour rappel, avant d'avoir mis la ligne ajoutée dans la fonction
[[UIApplication sharedApplication] setMinimumBackgroundFetchInterval:1800];

la procédure s'est déclenchée :
11 juillet : jamais
12 juillet : 21h05
13 juillet : jamais
14 juillet : 7h15, 14h22, 15h52, 17h23
15 juillet : 7h21, 12h43, 14h26, 15h52, 17h14
16 juillet : 7h27, 8h14, 9h39, 14h25, 16h11

Après l'ajout de cette ligne :
17 juillet : 7h31, 8h06, 14h24, 16h01
18 juillet : 7h58

On constate que c'est quasi identique aux exécutions précédentes.

Avez-vous constaté un autre comportement ?
Membre enregistré
4 messages
Posté le 18 juillet 2018 - 11:22
Au départ j'ai cru avoir une amélioration du fait qu'avant, la tâche ne s'exécutait jamais, mais après plusieurs jours, j'ai un comportement similaire au votre.
Comme Apple propose une constante pour demander l'exécution ASAP, je l'ai utilisé:
[[UIApplication sharedApplication] setMinimumBackgroundFetchInterval:UIApplicationBackgroundFetchIntervalMinimum];

Page Apple traitant de l'implémentation du Background App refresh:
https://developer.apple.com/documentation/uikit/core_app/managing_your_app_s_life_cycle/preparing_your_app_to_run_in_the_background/updating_your_app_with_background_app_refresh

Conclusion: pas de réelle amélioration, et en retournant lire les documentations, il semblerait que la politique d'Apple concernant les flux pseudo temps réel est basée sur le traitement des push. Ainsi, c'est au site serveur de produire le push pour que le périphérique en réception exécute la procédure qui effectuera la mise à jour. D'ailleurs Apple a prévu le "silent" push, sans notification.
Lien Apple sur l'approche Push:
https://developer.apple.com/documentation/pushkit
Extrait:
"Although you can also use silent user notifications to update your app in the background, your app isn't guaranteed to launch when a notification arrives. For more information, see Local and Remote Notification Programming Guide."

Le Background fetch s'appuie sur un nombre de paramètres variables important et contrôlé par l'iOS.
De plus, il parait que le nombre de téléchargements de l'application depuis le store est un des paramètres de modification de la fréquence de déclenchement, ce qui tendrait à considérer une logique de "grands acteurs" comme éligibles à l'utilisation de la batterie. En gros, Facebook a le "droit" de dépenser la batterie, mais pas toi ! (Je plaisante mais ça m'étonnerais finalement qu'à moitié).

--
Cordialement,
François EVSTRATEV
Message modifié, 18 juillet 2018 - 11:25
Membre enregistré
123 messages
Popularité : +1 (1 vote)
Posté le 19 juillet 2018 - 10:06
Super merci pour ce retour précis, documenté et sourcé. :merci:

On comprends au moins pourquoi l'on avait quelques soucis de mise en place, il faudra maintenant faire avec ou utiliser ces notifications silencieuses.