Defectele aplicațiilor universale

Microsoft a început să încurajeze dezvoltatorii să-și migreze aplicațiile către aplicațiile universale, dar unii dezvoltatori încă nu sunt convinși. Am scris un editorial care citează dezvoltatorii cu ceva timp în urmă despre fezabilitatea aplicațiilor universale și de ce nu dau încă foc lumii. Astăzi, un alt dezvoltator a publicat un articol despre experiențele sale cu aplicațiile universale (pe care le vom reproduce aici cu permisiunea)

 

Windows Phone 8.1 XAML și aplicațiile universale au inclus API-uri WinRT care au multe probleme, inclusiv unele pentru care nu există o soluție. Dar mai întâi, să vorbim doar despre numele „Aplicații universale”. Cred că este destul de arogant, numind ceva universal care vizează două platforme, de care, sincer, nu atât de mulți utilizatori îl folosesc sau de care le pasă. De asemenea, dacă te gândești doar la platformele Windows, aceste aplicații nu sunt, de asemenea, universale, deoarece nu pot viza versiunile Windows cel mai frecvent utilizate (7 și XP). Dar mă digresez.

El face ideea aici, pe care am spus-o cu ceva timp în urmă. Nici WP8.1, nici W8.1 nu oferă încă suficientă valoare pentru ca dezvoltatorii să dezvolte pentru niciunul dintre ei, deoarece, așa cum am spus, „Utilizatori Windows HAS, dar acești utilizatori nu doresc neapărat aplicații. Utilizatorii Windows Phone vor aplicații, dar nu sunt foarte multe” .

Cu toate acestea, utilizatorii nu sunt singurul lucru care îi împiedică pe dezvoltatori să treacă la aplicațiile WinPRT 8.1. Există și probleme tehnice:

 

Mai multe API-uri încurcate

Deci, API-ul de redare audio de fundal pentru Windows Phone 8.1 este stricat, altceva? Sigur. BackgroundDownloader este un alt exemplu. În Silverlight, a existat un BackgroundDownloader care a fost destul de limitat, dar a funcționat. În aplicațiile universale, există un nou BackgroundDownloader cu câteva funcții noi și unele esențiale lipsesc. De exemplu, în Silverlight, fiecare descărcare ar putea avea o etichetă, unde puteți stoca orice date, astfel încât să știți ceva despre descărcare când se termină (cărei entități comerciale îi aparține etc.). Nu mai este în aplicațiile universale. Nu există nicio etichetă, așa că trebuie să creați și să gestionați propriul tip de index pentru toate descărcările, astfel încât să le puteți potrivi efectiv cu entitățile dvs. de afaceri. O enervare, dar nimic ce nu poți gestiona, corect.

Un comentator de pe blog a mai adăugat că apis-urile camerei nu erau la fel de bune ca cele Silverlight și mi s-a spus că apis-urile 8.1 nu au integrarea obiectivului.

Camera API-ul de pe WP8.1 este, de asemenea, îngrozitor de înnoit. Nu există nicio modalitate de a obține cadre de previzualizare. Cu API-ul Silverlight, puteți pur și simplu să vă abonați la un eveniment și să împingeți cadrele de joasă rezoluție prin ZXing la mai multe fps. În WinRT, cel mai bun lucru pe care îl poți face este să faci multe poze după alta, cu blitz uneori și să scanezi aproximativ 0.8 cadre pe secundă.

Performanța este, de asemenea, afectată, deoarece cantitatea de muncă necesară pentru a obține o defilare lină a crescut în 8.1 față de 8.0.

Performanţă

În Silverlight, am folosit în mod obișnuit LongListSelector pentru a afișa date, folosindu-l cu un WrapPanel atunci când aveam nevoie să creez un aspect cu două coloane. LongListSelector a dispărut, în aplicațiile universale trebuie să utilizați GridView și pe Windows Phone. Sau puteți utiliza ListView cu un panou de wrap personalizat pe care îl scrieți singur sau îl descărcați de undeva, dar este nevoie de ceva efort pentru a-l face să facă virtualizarea corect.

Așadar, utilizați GridView atât pe Windows Phone 8.1, cât și pe Windows 8.1 pentru a-l face consistent. Adăugați zeci de articole cu imagini și performanța începe să sufere cu adevărat. Vor apărea substituenți gri și, mai important, nu dispare niciodată. Nu aveți nevoie de imagini, doar adăugați aproximativ 300 de elemente doar text în GridView și substituenții gri vor începe să se afișeze la derulare

Scopul acestei postări nu este să-l lovească pe Microsoft, ci să explice de ce dezvoltatorii ar putea să nu fie dispuși să creeze aplicații universale încă. Nu sunt o metodă absolut mai bună, sunt un upgrade în unele zone și un downgrade în altele (utilizatorii de Windows Phone cunosc bine acest sentiment). Dacă Microsoft dorește să atragă dezvoltatori, aceștia trebuie să lucreze mai repede decât fac acum, „în curând” și „în următoarele luni” nu sunt atractive pentru oamenii ale căror mijloace de existență depind de faptul că „în curând” este „ieri”. Din fericire, există semne că acest lucru s-ar putea schimba. WP 8.1.1 a adus niște api-uri noi (deși restricționate) și se spune că 8.1.2 (într-o postare acum ascunsă) permite dezvoltatorilor să creeze noi aplicații minunate. Microsoft se poate schimba în viitor și asta este grozav. Pentru mulți dezvoltatori care sunt presați să creeze aplicații universale acum, viitorul nu poate ajunge aici suficient de curând.

Pentru mai mult decât fragmentele pe care le primiți aici, citiți articolul complet aici. Pentru piesa mea mai detaliată, vezi aici.