Началось все с того, что одно из моих веб-приложение перестало корректно работать, после того как я закрепил его на главном экране своего iPad. Точнее при первом запуске все было отлично. Но потом – многие функции просто не работали. Сначала я подумал, что причина в какой-то ошибке в коде веб-приложения. Но после детального изучения кода и разбора полетов, оказалось, что все дело в браузере.
Вернее в его полноэкранном режиме. Ваше веб-приложение будет замечательно выглядеть на iPad, пока вы не решите сохранить его на главном экране.
В чем же был проблема и как ее решить — вы узнаете дальше.
Хабараюзер MarcusAurelius в своей статье "Отличия в адаптации сайта и AJAX веб-приложения для iOS" уже писал об основных нюансах и неожиданностях при работе с Safari. Однако, это еще не все сюрпризы которые могут поджидать веб-разработчика при работе с этим браузером. Как оказалось – Safari в iOS не всегда корректно поддерживает модель postback событий ASP.NET.
Если вы решите добавить ваше веб-приложение на главный экран iOS то на первый взгляд все будет выглядеть прекрасно…. до тех пор пока по какой либо причине приложение не будет перезагружено. После этого сценарий postback событий будет полностью не работоспособен в этом браузере.
Единственным решением проблемы может стать удаление приложения с главного экрана, и после добавление его туда по новой. Конечно же плохо, и такой сценарий работы никуда не годится.
Немногого побродив по просторам интернета, я обнаружил что это уже достаточно известная проблема и нашел замечательное решение на этом сайте.
Причина
Суть проблемы состоит в том, что iPad, iPhone и iPod Touch используют разные строки UserAgent, в обычном режиме и когда веб-сайт запускается с главного экрана:
- Safari в обычном режиме: Mozilla/5.0 (iPad; U; CPU OS 4_3_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2
- Safari в режиме полноэкранного приложения: Mozilla/5.0 (iPad; U; CPU OS 4_3_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Mobile/8J2
Решение
Из за своей нестандартной UserAgent строки Safari для iOS определяется как старый браузер, который поддерживает клиентские скрипты. Что бы решить эту проблему необходимо вручную указать, что этот браузер относится к новому поколению.
Для этого нужно задать свойство страницы ClientTarget. По умолчанию это свойство может иметь два значения:
- uplevel — определяет возможности браузера, эквивалентно Internet Explorer 6.0.
- downlevel — определяет возможности браузера эквивалентными старым браузерам, не поддерживающим клиентские скрипты. Используя этот псевдоним, можно определить, как веб-страницы будут работать в обозревателе, в котором отключен клиентский скрипт.
Лучше всего добавить следующий код к базовой странице, переопределив метод OnPreInit:
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
if (Request.UserAgent != null && Request.UserAgent.IndexOf("AppleWebKit", StringComparison.CurrentCultureIgnoreCase) > -1)
{
this.ClientTarget = "uplevel";
}
}
Таким образом все браузеры основанные на AppleWebKit будут определятся как те, что поддерживают клиетские скрипты.
И еще немного о UserAgent
Если ваш проект достаточно старый, и начинал разрабатываться еще во времена .NET Framework 1.1, то после обновления до 4 версии вы можете столкнуться с такой ошибкой:
The page is performing an async postback but the ScriptManager.SupportsPartialRendering property is set to false. Ensure that the property is set to true during an async postback.
Это связано с тем, что в web.config файле может быть явно задан ожидаемый размер UserAgent — до 64 символов:
<browserCaps userAgentCacheKeyLength="64" />
Для решения проблемы нужно увеличить это значение, например до в 256 символов.
Более подробно эта проблема рассматривается тут.
После проделанных манипуляций веб-приложение будет отлично работать как в обычном, так и в полноэкранном режиме Safari.
Литература и источники
- Gotcha: iPad versus ASP.NET
- Отличия в адаптации сайта и AJAX веб-приложения для iOS
- MSDN: Page.ClientTarget — свойство
- ASP.NET 4 BrowserCaps
Автор: Ernado
