Est-il possible de télécharger des données en tant que processus d'arrière-plan dans j2me?

Question

Même avec une mauvaise connexion réseau?

Spécifiquement, j'ai écrit du code qui lance un thread séparé (à partir de l'interface utilisateur) qui tente de télécharger un fichier via HTTP POST. J'ai trouvé, cependant, que si la connexion est mauvaise, le processeur reste bloqué sur outputstream.close() ou httpconnection.getheaderfield() ou toute lecture/écriture qui force les données sur le réseau. Cela provoque non seulement le thread à rester bloqué, mais vole le processeur entier, de sorte que même l'interface utilisateur ne répond plus.

J'ai essayé d'abaisser la priorité du thread, en vain. Ma théorie est qu'il n'y a pas de moyen facile d'éviter ce comportement, c'est pourquoi tout le tutoriel j2me demande aux développeurs de créer un écran 'envoi de données sur le réseau ...' au lieu de simplement tout envoyer dans un thread d'arrière-plan. Si quelqu'un peut me prouver le contraire, ce serait fantastique.

Merci!

Answer 1

Un aspect important est que vous ayez besoin d'une interface ou d'un écran générique qui peut être affiché lorsque l'appel réseau en arrière-plan échoue. C'est un must sur toute application mobile, J2ME ou autre. Comme Honza l'a dit, cela dépend de la conception, il y a tellement de choses à faire, comme pré-extraire les données au démarrage de l'application, ou pré-extraire les données en fonction de l'écran chargé (chemin de navigation) Un autre élément que vous pouvez essayer est un mécanisme de minuterie intégré qui réessaye le téléchargement de données après un certain laps de temps, et qui avorte après, par exemple, 5 essais ou 1 à 5. 2 minutes et l'affichage de l'écran générique ou un message d'erreur.

Certains combinés de J2ME permettent la détection du mode avion, si possible, vous pouvez le détecter et afficher rapidement un écran approprié.

Aussi un design qui a fonctionné pour moi synchronise l'interface utilisateur et les threads de mise en réseau, de sorte qu'ils ne se verrouillent pas les uns les autres (prendre ce petit conseil avec beaucoup de sel sur certains samsung et sanyo combinés à cause de cela)

Dans l'ensemble, pas de bonne réponse pour vous, mais des stratégies différentes.

Answer 2

Cela dépend beaucoup de la façon dont vous écrivez le code et où vous l'exécutez. Sur CLDC le concept de threading est assez limité et si n'importe quel thread est en train de faire des opérations de longue durée, d'autres threads pourraient être (et sont habituellement) bloqués par lui aussi. Vous devriez en tenir compte lors de la conception de votre application.

Answer 3

Vous pouvez diviser les données de vos fichiers en blocs, puis les télécharger en effectuant plusieurs tentatives en cas d'échec. Cela dépend de votre stratégie d'application. Si votre priorité est de télécharger un volume de données sans échec. Vous devez assembler les morceaux sur le serveur pour reconstituer vos données. Cela peut avoir les frais généraux pour faire des connexions, mais la chance est grande pour vos données seront téléchargées. Si vous ne téléchargez pas de fichiers simultanément, cela fonctionnera facilement.