Лучший / стандартный метод замедления загрузки модуля Silverlight Prism (для тестирования)

Question

Во время локального тестирования модульных приложений Silverlight на основе Prism модули XAP загружаются слишком быстро, чтобы почувствовать конечный результат.Из-за этого сложно понять, где нужно отображать прогресс, заставки или другие визуальные состояния.

Какой метод (или самый стандартный) является лучшим (или самым стандартным) для намеренного замедления загрузки модулей XAP и другихсодержание в локальной среде разработки?

Я добавлял случайную задержку таймера (через раскадровку на основе кода), но я бы предпочел что-то, что я могу поместить под капот (скажем, загрузчик Unity?), чтобы добавить существенную задержку к всем загрузкам модуля и только в отладочных сборках .

Предложения приветствуются *

* Примечание: я исследовал параметр «большой файл», и он не работает для больших проектов (и не удается создать XAP с действительно большими файлами с ошибкой нехватки памяти ).Решение должно быть основано на коде и предпочтительно должно быть встроено за кулисы, чтобы замедлить загрузку модуля в среде локального хоста.

**** Примечание. Чтобы уточнить, мы специально ищем ответ, совместимый с Microsoft.PRISM pattern & PRISM / CAL Библиотеки. **

Answer 1

Не добавляйте никаких файлов в проекты вашего модуля. Это добавляет ненужное регрессионное тестирование в ваш модуль, так как вы изменяете макет модуля, расширяя неисполняемую часть. Скорее всего, вы не будете проводить это регрессионное тестирование, и, кто знает, вызовет ли это проблему. Лучше быть параноиком.

Вместо этого придумайте процедуру Delay (int milliseconds), которую вы передаете в обратный вызов, который материализует обратный вызов, который вы используете для извлечения удаленной сборки.

Другими словами, отделить получение ресурса сборки от использования ресурса сборки. Между этими двумя фазами вводят произвольно случайные количества времени ожидания. Я также рекомендовал бы регистрировать фактическое время, которое потребовалось удаленным пользователям для получения сборки, и использовать его для будущих контрольных точек, чтобы ваша UI Designers & QA Team получила ценную информацию о том, как долго пользователи ждут. Это позволит вам дешево смоделировать работу конечного пользователя в вашей среде обеспечения качества. Просто убедитесь, что ваш журнал содержит соответствующие данные, такие как размер запрашиваемой сборки.

Я задал вопрос о StackOverflow несколько недель назад о чем-то, связанном с этим , и мне пришлось иметь дело с заданным вами вопросом, поэтому я уверен, что это правильный ответ, рожденный из опыта, а не сообразительности.

Answer 2

Вы можете просто добавить огромные файлы (например, видео) в проекты вашего модуля. Создание таких проектов займет больше времени, но они также будут больше и, следовательно, будут загружаться локально. Когда вы перейдете к производству, просто удалите огромные файлы.