Utilizatorul mediu de Android probabil că de mult a încetat să-i pese de „problema de fragmentare” a Androidului. Dar problema îi bântuie în continuare pe dezvoltatori.
Fragmentarea a fost o problemă controversată în Android, la propriu, de când a fost anunțat sistemul de operare mobil.
Pe lângă faptul că este un mâna pe care trolii îl pot folosi în războaiele online, diversitatea care vine odată cu fragmentarea este acum văzută în mare măsură ca un net pozitiv pentru consumatori a dispozitivelor Android. La urma urmei, ni se oferă atât de multă libertate în alegerea tipului de dispozitiv cu tipul de software pe care îl dorim, încât este greu pentru consumatorul mediu să-i pese de fragmentare. Vizualizarea incredibilei varietati de dispozitive Android produce un mozaic frumos al reprezentării diverse a Android.
Dar fragmentarea hardware și software nu face pentru un dezvoltator de software fericit. De fapt, chiar invers. Dezvoltarea unei aplicații în atât de multe configurații hardware și software diferite se poate dovedi a fi o pacoste majoră la depanare. OEM-urile pot face modificări majore sau subtile care trebuie luate în considerare atunci când dezvoltă o aplicație, dar nu există într-adevăr o modalitate ușoară pentru dezvoltatorul individual de a se asigura că aplicația lor va funcționa universal. În timp ce consumatorul mediu a uitat de mult de dezbaterea fragmentării, problema încă bântuie Android dezvoltatorii de aplicații și se pare că nu există nimic de făcut în privința asta, decât să o absorbiți și să faceți față erorilor pe măsură ce acestea apărea.
Starea regretabilă de fragmentare
Un OEM în special primește o mare parte de ură pentru durerile de cap pe care le provoacă atunci când dezvoltă o aplicație -- Samsung. Dezvoltatorii au dezvăluit despre Samsung de ani de zile, unii scriind chiar articole atât de usturatoare precum „Există un loc special pentru Samsung în Android Hell" care descrie o eroare deosebit de frustrantă care decurge din Dispozitivele Samsung și biblioteca de suport pentru aplicații. Aș dori să atrag atenția asupra unui paragraf în special din dezlegarea domnului Ambri, care subliniază excelent de ce dezvoltatorilor le pasă încă de fragmentare:
Dacă ești un dezvoltator Android, ura ta față de dispozitivele Samsung este probabil nemărginită. Mai mult decât un utilizator obișnuit, pentru care Samsung este sinonim prostul Touchwiz și bloatware excesiv, disprețuiești Samsung pentru că nu ai de ales. Din cauza Samsung cota de piata masiva, pur și simplu nu puteți alege să nu acceptați dispozitivele Samsung. Și asta doare cel mai mult; faptul ca aceasta alegere iti este luata!
Nici acesta nu este o dezgustă din vechii ani ai existenței lui Android - această postare a fost publicată la jumătatea lunii decembrie a anului trecut. Voi fi direct și voi spune că nu sunt sigur dacă această problemă a fost încă remediată oficial, totuși, dl. Ambri a oferit o remediere în postarea sa pentru oricine găsește dezbaterea lui printr-o căutare pe Google gândac. Tot ce trebuie să faci este să folosești ProGuard cu următoarea singură linie de cod:
# Samsung ruining all nice things-keep class !android.support.v7.view.menu.**, !android.support.design.internal.NavigationMenu, !android.support.design.internal.NavigationMenuPresenter, !android.support.design.internal.NavigationSubMenu, android.support.** {*;}Nu e chiar atât de rău, nu-i așa? Problema, totuși, este că această remediere a fost retrasă din Stack Overflow. Nu mă înțelege greșit, Stack Overflow este un site grozav. Dar nu este cu adevărat o sursă ideală pentru a descoperi remedieri pentru aplicațiile tale. Găsirea a ceva pe Stack Overflow implică deseori să vă aruncați în adâncime prin linkuri după multe căutări Google de încercare și eroare. Uneori, veți găsi chiar și un alt utilizator menționând același bug pe care l-ați avut, dar fără o remediere la vedere. Sau și mai frustrante sunt momentele în care găsești un fir în care afișul original a pretins au găsit o soluție, dar și-au abandonat de mult thread-ul fără a instrui pe alții cum să remedieze emisiune.
Un exemplu de problemă de fragmentare subtilă
Eu nu sunt un dezvoltator, dar sunt suficient de familiarizat cu capacitățile Android după ani de lucru în Tasker, încât am început să-mi pseudo-programați propriile soluții la problemele cu care m-am confruntat. Și când nu îmi pot da seama de ceva, îl caut pe Google, la fel ca toți ceilalți. În timp ce eram în proces de a scrie articolul meu anterior despre cautând în aplicația Setări a telefonului pentru activități ascunse, am dat peste un bug destul de ciudat pe care nu l-am putut explica. Un bug unic pentru dispozitivele Huawei.
Ori de câte ori încercam să încep anumite activități (cum ar fi meniul „Testare” care conține statistici de utilizare a aplicației) în cadrul aplicației Setări, îmi întâmpina întotdeauna o eroare de permisiune. În special, aplicația pe care o foloseam pentru a începe activitatea nu avea permisiunea permisiunea huawei.android. HW_SIGNATURE_OR_SYSTEM. Niciun alt dispozitiv pe care l-am testat nu a necesitat permisiuni unice pentru a lansa aceste activități de Setări, doar telefoanele care rulează versiunea Android a Huawei (EMUI). O analiză a setări com.android a dezvăluit că anumite activități din aplicația Setări erau într-adevăr sub un nivel de protecție care necesita fie semnătură sau permisiunea de sistem.
Din păcate pentru mine, asta înseamnă că numai aplicațiile instalate sub /system sau aplicațiile semnate cu același semnătură, deoarece aplicația Setări ar putea deschide aceste activități folosind metoda pe care am fost încercând. Când am căutat pe Google această eroare pentru un răspuns, am (ați ghicit) am dat peste un Stiva Depășire fir. Dezvoltatorul care a postat problema sa a întâlnit aceeași problemă pe care am întâlnit-o și eu (deși, a lui era în curs de dezvoltare a unei aplicații). Problema lui a apărut când a încercat să ruleze următorul cod:
<span >Intentspan><span > mainIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_MAINspan><span >,span><span >nullspan><span >);span><span >mainIntentspan><span >.span><span >addCategoryspan><span >(span><span >Intentspan><span >.span><span >CATEGORY_LAUNCHERspan><span >);span><span >Intentspan><span > pickIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_PICK_ACTIVITYspan><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_TITLEspan><span >,span><span >"Pick App to Play in"span><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_INTENTspan><span >,span><span > mainIntentspan><span >);span><span >thisspan><span >.span><span >startActivityForResultspan><span >(span><span >pickIntentspan><span >,span><span > REQUEST_PICK_APPLICATIONspan><span >);span>Judecând după șirurile din intenție și pe pagina web a dezvoltatorului, probabil că a încercat să permită utilizatorului să aleagă o aplicație terță parte pentru a reda unele conținuturi media. Remedierea, furnizată de un dezvoltator veteran CommonsWare, a fost destul de simplu: folosește Intenție. CreateChooser în loc de ACTION_PICK_ACTIVITY. In orice caz, De ce ar trebui să implementăm această remediere? De ce Huawei are nevoie de această permisiune în primul rând? De ce a trebuit să găsim un răspuns pe StackOverflow utilizând o căutare Google foarte specifică?
Paradoxul alegerii
Pentru a găsi un răspuns, CommonsWare a depus un raport de eroare pe dispozitivul de urmărire a erorilor Android, solicitând ca Google să analizeze problema. În special, dezvoltatorul a solicitat ca Google să interzică cerințele de permisiuni nedocumentate să împiedice accesarea aplicațiilor terță parte la ACTION_PICK_ACTIVITY. Scriind aceste cerințe în CTS, Huawei ar fi obligat să respecte aceste modificări.
Pentru a fi sincer, totuși, acest bug în sine nu este mare lucru. Chiar dacă nicio altă aplicație pe care am încercat-o (cum ar fi Tasker) nu a reușit să ocolească această permisiune cerință și lansați anumite activități în aplicația Setări, nu am fost tocmai dezamăgit de rezultatul. Dar când mi-am adus aminte de dezordinea domnului Ambri, mi-am dat seama că micile schimbări ca acestea trebuie să fie foarte frustrante, mai ales pentru că oricât de mici ar fi, fără îndoialăaduna, uneori suficient pentru a provoca o durere de cap. O mică modificare a aplicației Setări ar putea duce la o recenzie negativă nemeritate împotriva unui dezvoltator. O mică schimbare care este destul de prost documentată și mi-a cerut să caut pe internet un fir Stack Overflow. Câte alte erori mici există pe alte dispozitive?
Concurența crescută în spațiul mobil s-a dovedit a fi grozavă pentru consumator, dar după ce am văzut cum aceste schimbări subtile atât de multe linii de produse diferite pot afecta dezvoltatorii, am ajuns să apreciez punctul de vedere al dezvoltatorului fragmentare. Nu este că alegerea în sine este problema, ci mai degrabă că comunitatea nu face suficient pentru a cataloga aceste probleme. După cum a sugerat domnul Ambri în articolul său, poate dezvoltatorii de Android au nevoie de propria lor versiune caniuse.com sau sdkcritic.com pentru a colecta toate erorile obscure într-o singură bază de date. Singura altă alternativă este ca OEM să documenteze în mod corespunzător aceste modificări sau să înceteze să le facă în primul rând, dar mult noroc cu asta.
Credite de imagine caracteristică: OpenSignal