2009-06-19 13 views
0

Nous chargeons le contenu swf externe dans une application adobe air. Le contenu est fourni par un nombre croissant de tiers.Quelles sont les restrictions/solutions de contournement nécessaires pour les fichiers SWF externes?

En tant que contenu tiers, il sera chargé dans un domaine de sécurité distinct (trustContent = false) et un domaine d'application frère (loadForCompatibility = true). Nous faisons cela en utilisant la classe Loader. Quelles sont les caractéristiques/options/approches qui pourraient causer des problèmes lors de l'utilisation du swf en tant que contenu externe?

Je suis intéressé par tout type de problèmes, car nous avons déjà reproduit des problèmes avec le contenu qui se produisent indépendamment du domaine de l'application/domaine de sécurité où il est chargé (et se produit aussi bien dans Loader et SWFLoader).

Toutes les solutions de contournement pour les problèmes sont très appréciés, en particulier ceux qui peuvent être appliqués à partir de l'application principale.

Répondre

1

Le gros problème (et celui que nous avons beaucoup traité!) Est que les fichiers SWF externes ne peuvent tout simplement pas être directement approuvés. Déjà. Cela rend la communication entre eux et l'application AIR de base difficile au mieux.

Il y a un bidouillage autour de ceci basé sur le chargement des données du SWF via un URLLoader et ensuite en retirant le bytearray et en le pompant dans un Loader. Cependant, je crois que ce hack a été tué avec AIR 1.5.1. Ceci étant dit, il est possible de communiquer entre l'application AIR et le SWF chargé via ce que Adobe appelle le pont sandbox. Cependant, la mise en place du sandbox est une douleur royale et toutes les données complexes (objets, même simples comme Arrays) sont dépouillées vers les objets génériques de l'autre côté du pont et ne peuvent pas être renvoyées à leur forme originale. Pour nos projets récents qui ont nécessité l'utilisation du pont, nous avons créé une classe de spécialité appelée AIRBridge que vous utilisez des deux côtés du pont et qui facilite le réglage correct. Si vous êtes intéressé, vous pouvez retirer la source actuelle de notre projet Google Code Automata-Tools.

+0

Merci beaucoup Branden pour le bon info. Cela confirme ce que j'avais lu récemment sur le modèle de sécurité aérienne dans le lien posté dans cette réponse: http://stackoverflow.com/questions/697155/is-there-an-way-to-load-external-swf-into- a-sandbox-in-flash/698079 # 698079. À l'heure actuelle, nous ne communiquons pas avec les fonds souverains de tierces parties, mais nous allons certainement approfondir ce projet lorsque nous y arriverons. Avez-vous rencontré d'autres types de problèmes avec un contenu externe, c'est-à-dire en utilisant les propriétés stage, root et similaires? (lire récemment ceux qui peuvent présenter des problèmes - mais pas sûr) – eglasius

+0

Oui, vous n'avez pas accès à la scène. Toute tentative d'accès entraînera une exception. Cela signifie également que certains composants ne fonctionneront pas dans le swf enfant. Je sais que le comobox est un délinquant, et je soupçonne que tous ceux qui font un «popup» de n'importe qui causeraient des problèmes. Bonne chance et il était sacrément intelligent de demander ici d'abord - nous avons dû découvrir ces problèmes de manière douloureuse! –

0

Une que nous avons déjà abordé:

  • contenu en dehors des spectacles extérieurs de scène swf dans l'application et le réglage de la taille où il sera affiché les éléments hors scène sont pris en compte. Solution de contournement: Ajoutez un masque sur l'application principale afin que le contenu externe soit masqué. Utilisez .content.width/height (complet avec les éléments hors scène) et .content.loaderInfo.width/height (taille de la scène d'origine) pour calculer la quantité de contenu à mettre à l'échelle afin que la scène d'origine corresponde à la zone visible.
Questions connexes