На выходных посмотрел видео Алексея Макаренкова с заголовком “Полоса загрузки - не то, чем кажется…”, где он рассказывает как разработчики игр мухлюют с полоской загрузки. Вкратце: полоска загрузки в играх - фейк, могла двигаться как угодно, но движется рывками, человеческое восприятие считает именно такой сценарий загрузки самым правдоподобным, а в плавную загрузку игроки не верят. Лучше один раз увидеть, чем сто раз услышать, вот это видео: Полоса загрузки - не то, чем кажется... (осторожно, присутствует реклама красного банка). Но если смотреть лень, то дальше Алексей говорит о том, что это и так было предсказуемо - секрет Полишинеля, но об этом никто, как правило, не говорит. Когда люди узнают правду, это их “слегка” удивляет. Более того, в статьях и лекциях девелоперов, даже в тех которые посвящены дизайну экранов загрузки, о фейках не пишут. И тут я могу попытаться заполнить пробел, и рассказать про то, как создавал фейковый экран загрузки. Нет, я не разработчик игр, однако играми экраны загрузки не ограничиваются. Лично я писал такой муляж для приложения на Silverlight. Как давно, это было, помнит только мутной реки вода: все сроки давности уже прошли, про это приложение, да и про Silverlight, уже все позабыли, так что можно снять гриф секретности, сдуть пыль со старого кода и вспомнить как это было. В публикации будет некрокод, с учётом того, что Silverlight уже не поддерживается, буду исходить из предположения что никто разбираться в этом не желает, постараюсь давать пояснения, достаточные для формирования представления и понимания. Всё-таки статья не про Silverlight, а про то, “как разработчики обманывают с экранами загрузки”. Нам экран загрузки изначально не особо был нужен, и уж тем более не было цели кого-то обманывать. В проекте присутствует индикатор загрузки по умолчанию, он справлялся со своей обязанностью, даже ничего писать не надо, типичный код, по-моему, генерируется при создании проекта:  Указывается xap-файл, и пока он грузится - идёт индикатор загрузки: вращающееся колесо и число показывающее процент загрузки в зависимости от размера скачиваемого xap-файла: скачалось 2 Мб из 8, покажет 25%. Это поведение по умолчанию - ничего дополнительно писать не надо. Всё было хорошо пока в один прекрасный день, в который никто ничего не трогал, оно само, размер скачиваемого xap-файл ни стал оцениваться в 0 байт. Само собой файл не стал невесомым, просто, почему-то, при скачивании, кто-то, или что-то, зарезал заголовок с размером файла. На экране загрузке гордо крутилось колесо с надписью 0%, висели эти 0% относительно долго, обычно загрузка занимала пару минут, и потом резко 100%... На поиск решения потратили день - решить с наскоку не получилось. С другой стороны жалко тратить на это время: ошибки то вроде нет, ну и что что полоска загрузки висит на нуле долгое время, - на работе приложения это не сказывается никак, да неприятно, поэтому проблему не стали сбрасывать, но решили что приоритет у неё невысокий и будет она решаться в свободное от других задач время. Прошла неделя, периодически к этой задаче возвращались, но решение найдено не было.  Прошло ещё некоторое время. И тут начали возмущаться уже пользователи, мол висит индикатор загрузки, кэш чистили, куки чистили, компьютер перезагружали, браузер меняли, а он на нуле и ничего не грузит, и у всех такое дело. Что с приложением стало? Объясняли что так мол и так, - не надо суеты, ждите и всё будет. Пользователи набирались терпения, убедились что всё работает, но осадочек остался, и чтобы не разводить панику надо было индикатор загрузки чинить. Вернулись к задаче, прошла ещё пара дней, а причину почему оценка размера xap-файла равна нулю, мы не нашли и даже никаких соображений на этот счёт не осталось. В этот то момент мы и встали на скользкую дорожку. Ну самое очевидное - пользователи ведь жалуются не на то, что размер файла не определяется, а на то, что полоска загрузки замерла, на файл то им плевать с высокой колокольни. Да, ключ к решению проблемы лежал в плоскости "вернуть правильный заголовок" и всё станет как было, но здесь мы ничего не добились. Потраченного времени жаль, - тратить его на эту “не ошибку” мы не были готовы изначально, а когда поиски не приводят к результату а приводят к ещё большей трате - так время жаль вдвойне. В итоге решили поискать решение в другой плоскости. Мы примерно знали сколько времени занимает загрузка (замеряли), понятно что эта величина непостоянная, зависит от сети, но при типичном сценарии загрузка колебалась в районе двух минут. Соответственно нам нужно было написать экран загрузки который бы развлекал пользователей это время. На самом деле чуть больше - на всякий случай с запасом. К счастью в Silverlight задача кастомизации экрана загрузки - типичная, нацелена не на фейковые экраны, а на всякое украшательство, но так или иначе гуглится легко, а там уже кто какие цели преследует - кто украшательство, кто подделку полосы прогресса. Нужно добавить два параметра splashscreensource и onsourcedownloadprogresschanged: Первый - это визуальное представление, xaml-файл (LoadScene.xaml): Второй - это скрипт для обработки загрузки. Изначально это была просто полоска. Не знаю как так получилось, но со временем полоска, предназначенная для того чтобы заполняться равномерно в течении двух минут, превратилась в две: одна чтобы показывать общий прогресс, вторая чтобы показывать загрузку "текущего" модуля: Откуда мы знаем какой модуль загружается и сколько времени это займёт? Да ниоткуда - это тоже подделка. Обычный массив со списком строк, которые якобы названия модулей. Названия выводятся вместо слова "загрузка". В итоге пользователь видит что нижняя полоса - прогресс модуля, загружается достаточно быстро, вероятно это и был ожидаемый эффект: система очень быстро грузит отдельные модули, а долго загружается потому что модулей много. Ниже представлена XAML-разметка второго варианта:  Здесь у нас четыре квадрата: два для верхней полосы прогресса (progressBarBackground, progressBar), два для нижней.  По одному квадрату progressBarBackground и progressBarBackground2 - представляют пустую незаполненную полосу прогресса, и ещё по одному progressBar и progressBar2 меняют свою ширину по мере “загрузки” и тем самым иллюстрирует движение полосы прогресса. Также здесь несколько текстовых блоков для отображения числа в процентах и названия исполняемого модуля. Собственно для реализации анимации прогресса нужно сделать изменение ширины у progressBar и progressBar2, ну и надписи периодически менять. Для всего этого необходимо реализовать onSourceDownloadProgressChanged, возвращаемся к aspx файлу: На что тут можно обратить внимание, во-первых: на diff - это фейковый список загружаемых модулей, а i - это индекс текущего загружаемого модуля. И во-вторых: на функцию onSourceDownloadProgressChanged, при нормальном сценарии, - если размер файла приходит корректный, она вызывается с некоторой периодичностью и в её параметрах содержится какая доля файла уже загружена, соответственно мы можем использовать это для честной визуализации. Однако в нашем случае функция вызывается всего два раза: в самом начале, когда загружено 0, и в самом конце, когда загружено 100%. Этот код: Написан на всякий случай, чтобы не было накладок если ошибка с определением размера файла пропадёт так же внезапно, как и возникла. В этом случае код должен попытаться правдоподобно скоординировать фейковый и реальный прогресс. По крайней мере чтобы это не сильно бросалось в глаза и наш обман не вскрылся. Такого не случилось, но ожидаю что при таком стечении обстоятельств полоска будет заполняться плавно, как в фейковом алгоритме, и потом рывками, когда реальный прогресс загрузки начнёт обгонять поддельный. Полоса загрузки модулей тоже начнёт двигаться рывками из-за условия в строках 7 - 10. Суть его в том, что если мы загрузили 25% от общего размера, то мы не должны показывать что грузится первый модуль, а писать уже про второй - с первым заканчивать. Если общий прогресс превысил 50%, то и второй модуль надо перестать грузить, показать что он загружен на 100% и переходить дальше и т.д. из расчёта 25% на модуль, - четыре модуля покажем и хватит. Ну и если общий прогресс приближается к 100%, то и загружаемый сейчас модуль тоже должен сделать вид что полностью загружен. На один листинг выше, в 22 строке есть условие Сделано для тех же целей, - на случай если функция начнёт вызываться корректно. Если проверку условия не сделать - то запустится множество циклов в setInterval и полоска загрузки будет двигаться очень быстро, дойдёт до 100% и замрёт так на пару минут. Думаю это отличает нашу поддельную полосу загрузки от большинства других подделок: мы предусмотрели корректировку относительно реального прогресса. Теперь о самих интервалах. Их два. Первый: Раз в 3.5 секунды изменяет общую полосу прогресса на случайную величину от 2 до 4  процентов. Замирает на 96% и делает вид что осталось совсем чуть-чуть, но он замер на какой-то тяжёлой операции, после которой сразу 100% и приложение запущено. Обычно загрузка завершилась раньше чем он доходил до 96%. Второй: Второй интервал управляет полосой загрузки модуля. Если основная полоса загрузки подвисла на 96%, то делаем вид что текущий модуль загружен на 100%, но к следующую модулю не переходим, даже если в списке ещё что-то есть. Так и остаётся. В остальных ситуациях плавно доходим до 100%, увеличиваем i на единицу - доставая из массива “следующий модуль”, сбрасываем полосу прогресса загрузки модуля на 0, и всё сначала. Загрузка “модуля” идёт в 7 раз быстрее “общей” загрузки, поэтому на всякий случай в массиве необходимо иметь 7 элементов, за границу массива не выйдет т.к. при достижении общего прогресса в 96% - мы перестаём инкрементировать переменную i. Хотя сейчас мне это не кажется надёжным, лучше было бы ещё сделать дополнительную проверку на значение i, ну да ладно. Вот и вся реализация. Таким образом мы дурим пользователя за его же деньги. И обмануть его не трудно! Он сам обманываться рад! И это не фигура речи, дословно не помню, но желание коллективного пользователя было сформулировано как-то так: “Сделайте хоть что-нибудь чтобы мы видели что приложение не зависло, и примерно представляли сколько ещё осталось ждать”. С этой точки зрения мы достигли того чего хотел пользователь, приложение даже грузилось быстрее чем обещала полоса прогресса, как правило уже на 70-80% загрузка завершилась - приятный бонус за Ваше ожидание. Ну и никто больше не перезагружал страницу полагая что она зависла. Даже если бы она зависла на 96%, вряд ли бы кто-то нажал F5, ведь остался последний рывок и загрузка может завершиться в любой момент. Если Вы читаете это как пользователь, не удивляйтесь что иногда полоса загрузки действительно не то чем кажется. Но я полагаю что в глубине души Вы и сами это давным-давно поняли, и даже готовы с этим мириться, и более того готовы простить нас - тех, кто подделывает экран загрузки, потому что почти всегда это ложь во благо. Если Вы читаете это как разработчик - знайте, подделать экран загрузки это нормально, а порой необходимо.  Программист, скептик и оптимист