Недоліки в Universal Apps

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

 

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

Тут він говорить про те, про що я говорив деякий час тому. Ані WP8.1, ані W8.1 ще не надають розробникам достатньої цінності для розробки для будь-якого з них, тому що, як я вже сказав, «Windows Є користувачі, але ці користувачі не обов’язково хочуть програми. Користувачі Windows Phone хочуть програми, але їх небагато».

Однак користувачі не єдине, що заважає розробникам переходити на програми WinPRT 8.1. Також є технічні проблеми:

 

Ще більше заплутаних API

Отже, API фонового відтворення аудіо для Windows Phone 8.1 зіпсований, щось ще? звичайно BackgroundDownloader — інший приклад. У Silverlight був BackgroundDownloader, який був досить обмеженим, але він працював. У Universal Apps з’явився новий BackgroundDownloader з деякими новими функціями, а деякі важливі відсутні. Наприклад, у Silverlight кожне завантаження може мати тег, де ви можете зберігати будь-які дані, щоб знати щось про завантаження після його завершення (кому суб’єкту господарювання воно належить тощо). Більше не в Universal Apps. Немає тегів, тому вам потрібно створювати власний індекс для всіх завантажень і керувати ним, щоб ви могли фактично зіставити їх із своїми бізнес-об’єктами. Роздратування, але нічого, з чим ви не можете впоратися, вірно.

Коментатор у блозі також додав, що API Camera не такі хороші, як Silverlight, і мені сказали, що API 8.1 не має інтеграції об’єктива.

API камери на WP8.1 також жахливо зіпсований. Немає способу отримати кадри попереднього перегляду. За допомогою Silverlight API ви можете просто підписатися на подію та проштовхувати кадри з низькою роздільною здатністю через ZXing зі швидкістю кількох кадрів в секунду. У WinRT найкраще, що ви можете зробити, це робити багато знімків за одним, інколи зі спалахом і скануванням приблизно 0.8 кадру в секунду.

Продуктивність також зазнає удару, оскільки обсяг роботи, необхідний для плавного прокручування, збільшився у 8.1 проти 8.0.

продуктивність

У Silverlight я зазвичай використовував LongListSelector для відображення даних, використовуючи його з WrapPanel, коли мені потрібно було створити макет із двох стовпців. LongListSelector зник, в Universal Apps вам потрібно використовувати 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 може змінитися в майбутньому, і це чудово. Проте для багатьох розробників, яких змушують створювати універсальні програми зараз, майбутнє не настане досить скоро.

Більше, ніж уривки, які ви тут отримуєте, прочитайте повну частину тут. Більш детальний твір див тут.