Недостатки универсальных приложений

Microsoft начала поощрять разработчиков к переносу своих приложений на универсальные приложения, но некоторые разработчики все еще не убеждены. Некоторое время назад я написал редакционную статью, в которой цитировал разработчиков о возможности создания универсальных приложений и о том, почему они еще не взорвали мир. Сегодня другой разработчик опубликовал статью о своем опыте работы с универсальными приложениями (мы воспроизведем ее здесь с разрешения).

 

Windows Phone 8.1 XAML и универсальные приложения включали API-интерфейсы WinRT, которые имеют много проблем, в том числе те, для которых нет решения. Но сначала давайте просто поговорим о названии «Универсальные приложения». Я думаю, что это довольно высокомерно называть универсальным то, что предназначено для двух платформ, что, откровенно говоря, не так много пользователей используют или заботятся о нем. Кроме того, если вы думаете только о платформах Windows, эти приложения также не являются универсальными, поскольку они не могут быть ориентированы на наиболее часто используемые версии Windows (7 и XP). Но я отвлекаюсь.

Он делает здесь точку, которую я сделал некоторое время назад. Ни WP8.1, ни W8.1 не представляют достаточной ценности для разработчиков, чтобы разрабатывать их для любого из них, потому что, как я уже сказал, «пользователи Windows ЕСТЬ, но эти пользователи не обязательно хотят приложений. Пользователи Windows Phone хотят приложений, но их не очень много».

Однако пользователи — не единственное, что мешает разработчикам перейти на приложения 8.1 WinPRT. Есть и технические проблемы:

 

Больше запутанных API

Итак, API фонового воспроизведения звука для Windows Phone 8.1 запутался, что-нибудь еще? Конечно. BackgroundDownloader — еще один пример. В Silverlight был довольно ограниченный BackgroundDownloader, но он работал. В Universal Apps появился новый BackgroundDownloader с некоторыми новыми функциями и отсутствием некоторых важных. Например, в Silverlight у каждой загрузки может быть тег, в котором вы можете хранить любые данные, чтобы вы знали что-то о загрузке, когда она завершится (к какому бизнес-объекту она принадлежит и т. д.). Больше не в универсальных приложениях. Тега нет, поэтому вам нужно создать собственный индекс для всех загрузок и управлять им, чтобы вы могли фактически сопоставить их с вашими бизнес-объектами. Раздражение, но ничего, с чем вы не можете справиться, верно.

Комментатор в блоге также добавил, что API-интерфейс камеры не так хорош, как в Silverlight, и мне сказали, что в API-интерфейсе 8.1 отсутствует интеграция с объективом.

API камеры на WP8.1 тоже ужасно испорчен. Нет возможности получить кадры предварительного просмотра. С помощью Silverlight API вы можете просто подписаться на событие и отправлять кадры с низким разрешением через ZXing со скоростью несколько кадров в секунду. В WinRT лучшее, что вы можете сделать, это делать много снимков за другим, иногда со вспышкой и сканировать со скоростью около 0.8 кадра в секунду.

Производительность также страдает из-за того, что объем работы, необходимой для плавной прокрутки, увеличился в 8.1 по сравнению с 8.0.

Перфоманс

В Silverlight я обычно использовал LongListSelector для отображения данных, используя его с WrapPanel, когда мне нужно было создать макет из двух столбцов. LongListSelector больше нет, в универсальных приложениях вы должны использовать GridView также на Windows Phone. Или вы можете использовать ListView с настраиваемой панелью переноса, которую вы написали сами или где-то скачали, но это требует некоторых усилий, чтобы заставить его правильно выполнять виртуализацию.

Таким образом, вы используете GridView как в Windows Phone 8.1, так и в Windows 8.1, чтобы сделать его согласованным. Добавьте к нему десятки элементов с изображениями, и производительность начнет сильно страдать. Появятся серые заполнители и, что более важно, никогда не исчезает. Вам не нужны изображения, просто добавьте около 300 текстовых элементов в GridView, и при прокрутке начнут отображаться серые заполнители.

Цель этого поста не в том, чтобы очернить Microsoft, а в том, чтобы объяснить, почему разработчики могут пока не захотеть создавать универсальные приложения. Это не лучший метод, это улучшение в некоторых областях и понижение в других (пользователи Windows Phone хорошо знают это чувство). Если Microsoft хочет привлечь разработчиков, им нужно работать быстрее, чем сейчас, «скоро» и «в ближайшие месяцы» не привлекательны для людей, чьи средства к существованию зависят от того, что «скоро» означает «вчера». К счастью, есть признаки того, что это может измениться. WP 8.1.1 принес несколько новых API (хотя и с ограничениями), а 8.1.2, как говорят (в теперь скрытом посте), позволяет разработчикам создавать новые потрясающие приложения. Microsoft может измениться в будущем, и это здорово. Тем не менее, для многих разработчиков, на которых сейчас оказывается давление с целью создания универсальных приложений, будущее не может наступить достаточно скоро.

Чтобы получить больше, чем фрагменты, которые вы получаете здесь, прочитайте полную часть здесь. Для моего более подробного материала см. здесь.