Surveiller les onglets du navigateur avec localConnection et détecter lorsqu'un utilisateur ferme un onglet

Question

Dans mon application, la fenêtre du navigateur se connecte avec une interrogation longue (comète) avec le serveur. Si l'utilisateur ouvre plusieurs onglets du navigateur, un seul d'entre eux (appelé le maître) communique avec le serveur et sert de proxy pour les autres onglets. Je veux utiliser flash localConnection pour échanger des données entre les onglets. Que se passe-t-il lorsqu'un utilisateur ferme l'onglet maître qui contient la session de la comète? Je peux utiliser javascript avec l'événement unload pour informer les autres onglets que l'onglet master est en cours de fermeture, puis fermer localConnection mais l'événement unload n'est pas fiable. Je peux utiliser l'interrogation pour surveiller l'objet de connexion de l'onglet maître, mais il semble sale.

Lorsque le maître est fermé, l'un des autres onglets doit devenir le maître. Comment puis-je m'assurer qu'un seul d'entre eux essaie de devenir le maître?

Si un utilisateur ferme l'onglet sans que Flash puisse fermer la connexion locale, provoquera-t-il une fuite de mémoire?

Merci

Answer 1

Ceci est un problème très intéressant. Je suis à moitié tenté de coder quelque chose pour voir comment cela fonctionnerait! Tout d'abord, comme localConnection cause une fuite, je pense que vous devrez vraiment tester cela, mais je pense que c'est possible, mais j'ai fait pas mal avec LocalConnection dans des situations similaires. et n'ont jamais vu une fuite de mémoire significative (qui est aussi de dire, ce qui est une fuite de mémoire et qu'est-ce que le GC est lent est toujours difficile à figurer dans le code non-trivial dans Flash)

question sur la façon de construire cette chose, je ne peux pas donner une réponse définitive, mais voici quelques idées.

Il me semble que le flux de la logique pour chaque SWF doit aller quelque chose comme ceci:

• Vérifiez si je suis le premier (se connecter au canal de commande)
• Si oui Sinon, connectez-vous au canal de commande et demandez une connexion bidirectionnelle (à ce stade, chaque SWF esclave génère un ID aléatoire et l'envoie au maître - cet ID serait utilisé comme nom LC pour les données provenant du maître vers l'esclave)

Pour gérer l'aspect d'auto-guérison, je suppose que vous pourriez faire quelque chose qui s'apparente à une lettre de chaîne. C'est-à-dire que chaque SWF se connectant au maître, il pourrait recevoir une liste des esclaves. Si la connexion venait à disparaître, chaque client chercherait à voir où il se trouvait sur la liste. S'il s'agissait du premier esclave de la liste, il prendrait le relais en tant que maître - redémarrez le canal de contrôle et dites à JS de démarrer une nouvelle connexion de comète. Ensuite, chaque autre esclave verrait que le serveur était de retour et retirerait le maître maintenant de sa chaîne.

Pour gérer les trous dans la chaîne provenant de divers clients qui tombent, le maître coordonne cela. Comme il enverrait des données aux esclaves, il verrait immédiatement si un client a déposé. Si un client tombait, il dirait simplement au reste des clients de retirer ce client de leur chaîne.

Espérons que cela aide!

Answer 2

J'ai également pensé à une stratégie similaire.

La première fenêtre deviendra le maître. Des fenêtres supplémentaires deviendront des esclaves et informeront le maître de leur existence. Chaque esclave interrogera le maître toutes les 100ms pour vérifier qu'il est actif. Si le maître n'est pas actif, l'esclave suivant dans la liste devient le maître. Les esclaves qui suivent dans la liste restent esclaves mais attendent que le premier esclave soit le maître. dans les prochains 100ms le reste des esclaves vont essayer de sonder le prochain maître et s'il est pas là le prochain deviendra le maître ...

Il se sent tellement sale que je crois que je vais prendre une douche maintenant. Va faire du codage.

Merci

Answer 3

Voyant que LocalConnection utilise des chaînes d'identification pour gérer la découverte, la solution devrait fonctionner:

Lorsque l'onglet maître ferme, il informe l'un des esclaves qu'il fait ainsi. Ensuite, il ferme sa LocalConnection. L'esclave peut maintenant enregistrer une nouvelle LocalConnection avec le même nom que celui utilisé par le maître. Le résultat est que la prochaine fois que les autres esclaves essaieront de contacter le vieux maître (en utilisant l'ancienne chaîne), ils se trouveront automatiquement en train de parler au «nouveau» maître.

Un effet similaire pourrait être obtenu sans recourir à l'événement de déchargement (si cela n'est pas souhaitable). Lorsque l'utilisateur ferme l'onglet principal, toute application essayant de se connecter au LocalConnection qu'il utilisait obtiendra une exception. Au lieu de lancer une erreur, l'application esclave pourrait déduire que cette exception signifie que le maître s'est fermé. Il prend alors le rôle de maître et enregistre une nouvelle LocalConnection avec le même nom que le maître. Le reste suit comme ci-dessus.