A Universal Apps hibái

A Microsoft elkezdte arra ösztönözni a fejlesztőket, hogy telepítsék alkalmazásaikat univerzális alkalmazásokra, de néhány fejlesztő még mindig nincs meggyőzve. Nemrég írtam egy szerkesztőséget, amelyben fejlesztőket idéztem az univerzális alkalmazások megvalósíthatóságáról, és arról, hogy miért nem gyújtják még fel a világot. Ma egy másik fejlesztő közzétett egy darabot az univerzális alkalmazásokkal kapcsolatos tapasztalatairól (amelyeket engedéllyel reprodukálunk itt)

 

A Windows Phone 8.1 XAML és az Universal Apps olyan WinRT API-kat tartalmazott, amelyek sok problémát okoznak, köztük olyanokat is, amelyekre nincs megoldás. De először beszéljünk az „Univerzális alkalmazások” nevéről. Szerintem elég arrogáns dolog univerzálisnak nevezni valamit, ami két platformot céloz meg, amit őszintén szólva kevesen használnak vagy törődnek vele. Ha csak a Windows platformokra gondolunk, ezek az alkalmazások sem univerzálisak, mert nem tudják megcélozni a leggyakrabban használt Windows verziókat (7 és XP). De elkalandozom.

Itt kifejti a lényeget, amit egy ideje megfogalmaztam. Sem a WP8.1, sem a W8.1 nem nyújt még elegendő értéket a fejlesztőknek, hogy egyikükre sem fejleszthessenek, mert, mint mondtam, „A Windows-felhasználók ugyan rendelkeznek, de ezek a felhasználók nem feltétlenül akarnak alkalmazásokat. A Windows Phone-felhasználók alkalmazásokat szeretnének, de nincs belőlük túl sok” .

A felhasználók azonban nem az egyetlenek, amelyek megakadályozzák a fejlesztőket abban, hogy áttérjenek a 8.1-es WinPRT alkalmazásokra. Technikai problémák is vannak:

 

További elrontott API-k

Tehát a Windows Phone 8.1 háttérben készült hanglejátszási API-ja elromlott, bármi más? Biztos. A BackgroundDownloader egy másik példa. A Silverlightban volt egy BackgroundDownloader, ami meglehetősen korlátozott volt, de működött. Az Univerzális alkalmazásokban új BackgroundDownloader található, néhány új funkcióval, és néhány alapvető funkció hiányzik. Például a Silverlightban minden letöltésnek lehet egy címkéje, ahol bármilyen adatot tárolhat, hogy tudjon valamit a letöltésről, amikor befejeződik (mely vállalkozáshoz tartozik stb.). Az Universal Appsban már nem. Nincs címke, ezért létre kell hoznia és kezelnie kell a saját típusú indexet az összes letöltéshez, hogy ténylegesen hozzárendelhesse azokat az üzleti entitásokhoz. Bosszúság, de semmi, amit ne tudnál kezelni, igaz.

A blog egyik hozzászólója azt is hozzátette, hogy a Camera apis nem volt olyan jó, mint a Silverlight, és azt mondták nekem, hogy a 8.1 apis-ben nincs objektív integráció.

A Camera API a WP8.1-en is borzasztóan felpörög. Nincs lehetőség előnézeti képkockák beszerzésére. A Silverlight API-val egyszerűen előfizethet egy eseményre, és az alacsony felbontású képkockákat több képkocka/másodperc sebességgel továbbíthatja a ZXingen keresztül. A WinRT-ben a legjobb, ha sok képet készít egymás után, néha vakuval, és körülbelül 0.8 képkocka/másodperc sebességgel szkennel.

A teljesítményt a sima görgetéshez szükséges munkamennyiség is megüti, mivel a 8.1-hez képest megnőtt a 8.0-hoz képest.

teljesítmény

A Silverlightban általában a LongListSelector-t használtam az adatok megjelenítésére, és egy WrapPanel-lel használtam, amikor kétoszlopos elrendezést kellett létrehoznom. A LongListSelector eltűnt, a Universal Apps-ben Windows Phone-on is GridView-t kell használni. Vagy használhatja a ListView-t egy egyéni burkolópanellel, amelyet saját maga ír, vagy letölt valahonnan, de némi erőfeszítést igényel a virtualizáció megfelelő végrehajtása.

Tehát a GridView-t Windows Phone 8.1-en és Windows 8.1-en is használja, hogy konzisztens legyen. Adjon hozzá több tíz elemet képekkel, és a teljesítmény kezd igazán szenvedni. Megjelennek a szürke helyőrzők, és ami még fontosabb, soha nem tűnik el. Az eseményekhez nincs szükség képekre, csak adjon hozzá körülbelül 300 szöveges elemet a GridView-hoz, és a szürke helyőrzők megjelennek görgetéskor

Ennek a posztnak nem az a célja, hogy megalázzuk a Microsoftot, hanem az, hogy megmagyarázzuk, miért nem hajlandóak a fejlesztők még univerzális alkalmazásokat létrehozni. Nem abszolút jobb módszer, bizonyos területeken frissítés, máshol pedig leminősítés (a Windows Phone felhasználók jól ismerik ezt az érzést). Ha a Microsoft vonzza a fejlesztőket, gyorsabban kell dolgozniuk, mint jelenleg, a „hamarosan” és a „következő hónapokban” nem vonzóak azok számára, akiknek a megélhetése attól függ, hogy „hamarosan” „tegnap” lesz-e. Szerencsére vannak jelek arra, hogy ez megváltozhat. A WP 8.1.1 hozott néhány új API-t (bár korlátozott), a 8.1.2 pedig állítólag (egy immár rejtett bejegyzésben) lehetővé teszi a fejlesztők számára, hogy új fantasztikus alkalmazásokat hozzanak létre. A Microsoft a jövőben változhat, és ez nagyszerű. Sok olyan fejlesztő számára, akikre most nyomás nehezedik, hogy univerzális alkalmazásokat készítsenek, a jövő nem érhet el elég hamar.

Ha többet szeretne megtudni, mint az itt található részletek, olvassa el a teljes részt itt. Részletesebb darabomat lásd itt.