Wady uniwersalnych aplikacji

Microsoft zaczął zachęcać programistów do migracji swoich aplikacji do aplikacji Universal, ale niektórzy programiści nadal nie są przekonani. Jakiś czas temu napisałem artykuł wstępny cytujący deweloperów o możliwości zastosowania uniwersalnych aplikacji i dlaczego jeszcze nie podpalają świata. Dziś inny programista opublikował artykuł o swoich doświadczeniach z uniwersalnymi aplikacjami (które powiemy tutaj za zgodą)

 

Windows Phone 8.1 XAML i Universal Apps zawierały interfejsy WinRT API, które mają wiele problemów, w tym niektóre, dla których nie ma rozwiązania. Ale najpierw porozmawiajmy tylko o nazwie „Aplikacje uniwersalne”. Myślę, że jest to dość aroganckie, nazywanie uniwersalnym czymś, co jest skierowane do dwóch platform, z których, szczerze mówiąc, nie tak wielu użytkowników korzysta lub na czym zależy. Również jeśli myślisz tylko o platformach Windows, te aplikacje również nie są uniwersalne, ponieważ nie mogą być kierowane na najczęściej używane wersje Windows (7 i XP). Ale robię dygresję.

Mówi o tym tutaj, co zrobiłem jakiś czas temu. Ani WP8.1, ani W8.1 nie zapewniają programistom wystarczającej wartości do opracowania dla żadnego z nich, ponieważ, jak powiedziałem, „Windows MA użytkowników, ale ci użytkownicy niekoniecznie chcą aplikacji. Użytkownicy Windows Phone chcą aplikacji, ale nie ma ich zbyt wiele”.

Użytkownicy nie są jednak jedyną rzeczą, która uniemożliwia twórcom przejście do aplikacji WinPRT 8.1. Są też problemy techniczne:

 

Więcej pomieszanych interfejsów API

Więc interfejs API odtwarzania dźwięku w tle dla Windows Phone 8.1 jest zepsuty, czy coś jeszcze? Pewny. Innym przykładem jest BackgroundDownloader. W Silverlight był dość ograniczony BackgroundDownloader, ale działał. W Universal Apps jest nowy BackgroundDownloader z kilkoma nowymi funkcjami, ale brakuje niektórych istotnych. Na przykład w Silverlight każde pobieranie może mieć tag, w którym można przechowywać dowolne dane, dzięki czemu po zakończeniu pobierania będziesz wiedzieć coś o pobieraniu (do jakiego podmiotu biznesowego należy itp.). Już nie w Universal Apps. Nie ma tagu, więc musisz zbudować i zarządzać własnym rodzajem indeksu dla wszystkich pobrań, aby móc dopasować je do swoich podmiotów biznesowych. Irytacja, ale nic, z czym nie możesz sobie poradzić, prawda.

Komentator na blogu dodał również, że interfejsy Camera nie były tak dobre jak Silverlight i powiedziano mi, że interfejs API 8.1 nie ma integracji z obiektywem.

Interfejs API aparatu w WP8.1 również jest strasznie popieprzony. Nie ma możliwości uzyskania ramek podglądu. Dzięki interfejsowi API Silverlight możesz po prostu subskrybować wydarzenie i przesyłać klatki o niskiej rozdzielczości przez ZXing przy wielu klatkach na sekundę. W WinRT najlepsze, co możesz zrobić, to robić wiele zdjęć po kolei, czasami z lampą błyskową i skanować około 0.8 klatki na sekundę.

Wydajność również została uderzona ilością pracy potrzebnej do uzyskania płynnego przewijania, która wzrosła w porównaniu do 8.1 w porównaniu z 8.0.

Wydajność

W Silverlight często używałem LongListSelector do wyświetlania danych, używając go z WrapPanel, gdy potrzebowałem utworzyć układ dwukolumnowy. LongListSelector zniknął, w Universal Apps musisz używać GridView również na Windows Phone. Możesz też użyć ListView z niestandardowym panelem zawijania, który sam piszesz lub pobierasz gdzieś, ale wymaga to trochę wysiłku, aby poprawnie wykonał wirtualizację.

Dlatego używasz GridView zarówno w systemie Windows Phone 8.1, jak i Windows 8.1, aby zapewnić spójność. Dodaj do tego dziesiątki przedmiotów z obrazami, a wydajność zacznie naprawdę ucierpieć. Pojawią się szare symbole zastępcze, a co ważniejsze, nigdy nie znika. Nie potrzebujesz obrazów, wystarczy dodać około 300 elementów tekstowych do GridView, a szare symbole zastępcze zaczną się wyświetlać podczas przewijania

Celem tego postu nie jest zmiażdżenie Microsoftu, ale wyjaśnienie, dlaczego programiści mogą jeszcze nie chcieć tworzyć uniwersalnych aplikacji. Nie są to absolutnie lepsza metoda, w niektórych obszarach są uaktualnieniem, a w innych obniżeniem (użytkownicy Windows Phone dobrze znają to uczucie). Jeśli Microsoft ma przyciągnąć programistów, muszą działać szybciej niż teraz, „wkrótce” i „w nadchodzących miesiącach” nie są atrakcyjne dla ludzi, których źródła utrzymania zależą od tego, że „wkrótce” będzie „wczoraj”. Na szczęście są oznaki, że może się to zmienić. WP 8.1.1 przyniósł nowe API (choć ograniczone) i mówi się, że 8.1.2 (w ukrytym poście) pozwala programistom tworzyć nowe niesamowite aplikacje. Microsoft może się zmieniać w przyszłości i to jest świetne. Jednak dla wielu deweloperów, którzy są teraz pod presją tworzenia uniwersalnych aplikacji, przyszłość nie może nadejść wystarczająco szybko.

Więcej niż fragmenty, które tu dostajesz, przeczytaj cały artykuł tutaj. Aby uzyskać bardziej szczegółowy artykuł, zobacz tutaj.