Meilleure/méthode standard pour ralentir le chargement des modules Silverlight Prism (pour les tests)

Question

Lors du test localhost des applications Silverlight modulaires basées sur Prism, les modules XAP se téléchargent trop rapidement pour avoir une idée du résultat final. Cela rend difficile la visualisation des progrès, des splash-screens ou d'autres états visuels. Quelle est la meilleure (ou la plus standard) méthode pour ralentir intentionnellement le chargement des modules XAP et d'autres contenus dans une configuration de développement locale?

J'avons ajouté le délai de temporisation de temps en temps (via un story-board à base de code), mais je préférerais quelque chose que je peux placer sous le capot (en dire le chargeur de l'unité?) Pour ajouter un retard important à tous les modules chargent et dans les versions de débogage seulement.

Suggestions accueilli *

* Note: Je l'ai étudié l'option « grand fichier » et il est impraticable pour les grands projets (et ne parvient pas à créer XAP avec des fichiers très grands avec erreur de dépassement de mémoire). La solution doit être basée sur un code et, de préférence, s'intégrer dans les coulisses pour ralentir le chargement du module dans un environnement hôte local.

**** Remarque:. Pour clarifier, nous cherchons spécifiquement une réponse compatible avec le modèle PRISM Microsoft & PRISM/CAL Bibliothèques **

Answer 1

N'ajoutez aucun fichier à vos projets de module. Cela ajoute des tests de régression inutiles à votre module puisque vous modifiez la disposition du module en étendant la partie non exécutable. Les chances sont que vous ne ferez pas ce test de régression, et qui sait si cela va causer un problème. Mieux vaut être paranoïaque. Au lieu de cela, venez avec une procédure Delay (int millisecondes) que vous passez dans un rappel qui matérialise le rappel que vous utilisez pour récupérer l'assembly distant. En d'autres termes, découpler l'acquisition des ressources d'assemblage de l'utilisation des ressources d'assemblage. Entre ces deux phases, insérez arbitrairement des quantités aléatoires de temps d'attente. Je vous recommande également de consigner le temps réel nécessaire aux utilisateurs distants pour obtenir l'assemblage, et de l'utiliser pour les points de test futurs afin que votre équipe d'assurance qualité UI Designers ait des informations précieuses sur la durée d'attente des utilisateurs. Cela vous permettra de simuler à moindres frais l'expérience de l'utilisateur final dans votre environnement d'assurance qualité. Assurez-vous simplement que votre journal contient des informations pertinentes, telles que la taille de l'assemblage demandé.

J'ai posé une question sur StackOverflow il y a quelques semaines à propos de something related to this, et j'ai dû traiter la question que vous avez posée, donc je suis confiant que c'est la bonne réponse, née de l'expérience, pas de l'intelligence.

Answer 2

Vous pouvez simplement ajouter des fichiers énormes (tels que des vidéos) à votre projets de modules. Cela prendra plus de temps pour construire de tels projets, mais ils seront aussi plus gros et donc plus longs à télécharger localement. Lorsque vous passez en production, supprimez simplement les fichiers volumineux.