Restrictions sur l'utilisation de fonction synchrones (un peu lente) ?

Bonjour

je travaille sur un jeu d'API pour Android.
Parmi les différentes fonctions, on doit en développer une qui renvoie une liste d'éléments.
La construction de la liste est un peu lente (quelques secondes) (recherche sur le réseau)
Est-il possible de faire ça de façon synchrone ?

J'ai bien compris que dans le cas de fonctions un peu lente, il est recommandé de passer par un thread, mais fonctionnellement, cela n'a pas de sens car on est obligé d'attendre l'affichage des éléments de la liste pour continuer et fournir une fonction synchrone permet de réduire grandement le nombre de lignes que le développeur utilisant l'API aura à écrire

Merci pour vos idées / conseils

Pour toute requête réseau tu es obligé (par le SDK) de passer par un thread autre que le thread UI.
Tu ne devrais donc même pas pouvoir faire ta recherche sans passer par un thread indépendant (ou un asynctask)

Quelle genre d'API développe tu ? C'est une API java qu'il faudra inclure comme une librairie ou plutôt une API dispo sur un serveur à requeter en http(s) ?
Tu parle d'affichages d'éléments , du coup je comprend pas vraiment puisque une API devrait plutôt retourner une données brute et c'est ensuite à l'utilisateur de se débrouiller si la requête est trop longue.

Bonjour Grunk

OK, je comprends que le SDK impose une requête réseau en asynchrone.

Toutefois, l'API qu'il faut développer va encapsuler cette requête réseau (c'est pas une requête au sens Web du terme, c'est du protocole interne) et va ensuite renvoyer une liste d'éléments trouvés sur réseau.
C'est une API java qui est inclue dans une librairie qui va scanner un réseau à la recherche d'éléments spécifiques et les retournés dans une liste. L'utilisateur finale de l'application devra ensuite choisir un des éléments de la liste avec lequel il veut travailler (d'où le fait que le développeur doit utiliser l'API pour lister les éléments puis afficher les éléments trouvés)

Ma question est de savoir si je peux faire une API synchrone (avec gestion d'un timeout) qui va s'exécuter dans un thread séparé car on a besoin des résultats de l'API avant de pouvoir aller plus loin.

Citation:

---

L'utilisateur finale de l'application devra ensuite choisir un des éléments de la liste

---

On est d'accord que tu parles bien d'une liste au sens de la collection et pas de l'élément graphique listview ?

Pour te répondre je vois 2 possibilités à ton problème :

1- Ton API est synchrone : un appel à l'API sera bloquant coté utilisateur. Dans ce cas à lui de gérer ce blocage avec par exemple une asynctask et une progressview coté UI
2- Ton API est asynchrone : l'utilisateur doit fournir une fonction de callback qui sera appelée quand l'API aura fini sont travail.

Personnellement je préfère le premier cas (synchrone).
Le second est beaucoup plus complexe à gérer. Par exemple que se passe t'il si je change d'activité et que le callback n'as toujours pas été appelé ?

Après si la recherche prend 5 min , ca n'a pas de sens de faire quelque chose de synchrone et on préfèrera surement quelque chose d'asynchrone avec la possibilité de récupérer une progression de la recherche.

Oui, tu as tout à fait compris, je parle de liste au sens de collection.
Le retour de l'API est de l'ordre de quelques secondes... donc un temps tout à fait acceptable pour attendre et je suis aussi d'accord avec toi, une API synchrone est préférable

Donc tu me confirmes bien que c'est possible avec le SDK d'Android ? Une personne de l'équipe avait l'air de dire que ce n'était pas possible car le retour de la fonction était un peu lent

Ce qu'il ne faut pas c'est qu'un appel bloque le thread UI et déclenche un ANR : https://developer.android.com/traini.../perf-anr.html

Tes requêtes réseaux devront être threadé c'est obligatoire , mais le retour à l'utilisateur peut se faire une fois que le thread de recherche est terminé. A l'utilisateur ensuite d'éviter de bloquer son thread UI quand il utilise ton API.

Tu peux même de ton coté forcer l'utilisateur à threader les appels à l'API en levant une exception si l'appel se fait sur le thread UI :

Code:

---

1 2 3

if (Looper.myLooper() == Looper.getMainLooper()) { throw new IllegalStateException("Must not be invoked from the main thread."); }

---

Super, merci pour les liens et pour toutes tes réponses c'est plus clair.
Comme on n'a le dialogue ANR qu'au bout de 5 secondes (et que l'expérience sur d'autre OS montrent que les réponses réseau arrivent avant les 5 secondes), je peux même me contenter d'avoir une API purement synchrone (pour celui qui va l'utiliser)

A voir comment on va implémenter ça maintenant ...