Средният потребител на Android вероятно отдавна е спрял да се интересува от „проблема с фрагментирането“ на Android. Но проблемът все още преследва разработчиците.
Фрагментирането е спорен проблем в Android буквално откакто беше обявена мобилната операционна система.
Освен като тояга, която троловете да използват в онлайн пламъчни войни, разнообразието, което идва с фрагментацията, сега до голяма степен се възприема като нетно положително за потребителите на устройства с Android. В края на краищата ни е дадена толкова голяма свобода при избора на типа устройство с вида софтуер, който искаме, че за средния потребител е трудно да се интересува от фрагментацията. Визуализирането на невероятното разнообразие от устройства с Android създава красива мозайка от разнообразното представяне на Android.
Но фрагментирането на хардуера и софтуера не прави щастлив софтуерен разработчик. Всъщност точно обратното. Разработването на приложение в толкова много различни хардуерни и софтуерни конфигурации може да се окаже голямо неудобство при отстраняване на грешки. OEM производителите могат да направят големи или фини промени, които трябва да бъдат отчетени при разработването на приложение, но наистина няма лесен начин за отделния разработчик да гарантира, че приложението му ще работи универсално. Въпреки че средният потребител отдавна е забравил за дебата за фрагментацията, проблемът все още преследва Android разработчици на приложения и привидно няма какво да се направи по въпроса, освен да го изсмучат и да се справят с грешките, докато се появи.
Жалкото състояние на фрагментация
Един OEM по-специално получава голяма порция омраза за главоболията, които причиняват при разработването на приложение – Samsung. Разработчиците говорят за Samsung от години, някои дори пишат такива остри статии като "Има специално място за Samsung в Android Hell“, който описва особено разочароващ бъг, произтичащ от Устройства на Samsung и библиотеката за поддръжка на appcompat. Бих искал да обърна внимание по-специално на един параграф от изказването на г-н Амбри, който отлично очертава защо разработчиците все още се интересуват от фрагментацията:
Ако сте разработчик на Android, вашата омраза към устройствата на Samsung вероятно е безгранична. Повече от обикновен потребител, за когото Samsung е синоним глупав Touchwiz и прекомерен bloatware, вие презирате Samsung, защото нямате избор. Заради Samsung огромен пазарен дял, просто не можете да изберете да не поддържате устройства на Samsung. И това е, което боли най-много; фактът, че този избор е отнет от вас!
Това също не е приказка от старите години на съществуване на Android - тази публикация беше публикувана в средата на декември миналата година. Ще бъда откровен и ще заявя, че не съм сигурен дали този проблем все още е официално коригиран, г-н. Амбри е предоставил поправка в публикацията си за всеки, който се натъкне на неговата тирада чрез търсене в Google за буболечка. Всичко, което трябва да направите, е да използвате ProGuard със следния един ред код:
# 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.** {*;}Това не е толкова лошо, нали? Проблемът обаче е, че тази корекция е изтеглена от Stack Overflow. Не ме разбирайте погрешно, Stack Overflow е страхотен уебсайт. Но всъщност не е идеален източник за откриване на корекции за вашите приложения. Намирането на нещо в Stack Overflow често включва гмуркане в дълбочина през връзки след много търсения в Google на принципа проба-грешка. Понякога дори ще намерите друг потребител да споменава същата грешка, която сте имали, но без видима корекция. Или още по-разочароващи са моментите, когато откриете тема, където оригиналният плакат е претендирал намериха решение, но отдавна са изоставили темата си, без да инструктират другите как да го поправят проблем.
Пример за проблем с фина фрагментация
Аз самият не съм разработчик, но съм достатъчно запознат с възможностите на Android след години бърникане в Tasker, така че започнах да псевдопрограмирам свои собствени решения на проблеми, пред които съм се сблъсквал. И когато не мога да разбера нещо, го правя в Google, точно както всеки друг прави. Докато бях в процес на писане на предишната си статия за ровене в приложението Настройки на телефона ви за скрити дейности, попаднах на доста странен бъг, който не можах да обясня. Грешка, уникална за устройствата на Huawei.
Всеки път, когато се опитвах да стартирам определени дейности (като менюто „Тестване“, което съдържа статистически данни за използването на приложението) в приложението Настройки, винаги се срещах с грешка в разрешението. По-специално, приложението, което използвах, за да започна дейността, нямаше разрешение huawei.android.permission. HW_SIGNATURE_OR_SYSTEM. Никое друго устройство, което тествах, не изисква уникални разрешения за стартиране на тези дейности в настройките, само телефони, работещи с версията на Android на Huawei (EMUI). Анализ на com.android.settings разкри, че определени дейности в приложението Настройки наистина са под ниво на защита, което изисква или подпис или системно разрешение.
За съжаление за мен това означава, че само приложения, инсталирани под /system, или приложения, подписани със същото подпис, тъй като приложението Настройки ще може да отвори тези дейности, използвайки метода, който бях аз опитвайки се. Когато потърсих в Google тази грешка за отговор, аз (познахте) попаднах на Нишка за препълване на стека. Разработчикът, който публикува своя проблем, се натъкна на същия проблем, както и аз (въпреки че неговият беше в процес на действително разработване на приложение). Проблемът му възникна, когато се опита да изпълни следния код:
<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>Съдейки по низовете в намерението и уеб страницата на разработчика, той вероятно се е опитвал да позволи на потребителя да избере приложение на трета страна, в което да пусне някои медии. Корекцията, предоставена от ветеран разработчик CommonsWare, беше съвсем проста: използвайте Намерение. CreateChooser вместо ACTION_PICK_ACTIVITY. Въпреки това, защо трябва ли да внедрим тази корекция? Защо Huawei изисква ли това разрешение на първо място? Защо трябваше ли да намерим отговор в StackOverflow с помощта на много конкретно търсене в Google?
Парадоксът на избора
За да намеря отговор, CommonsWare подаде доклад за грешка в инструмента за проследяване на грешки на Android с искане Google да разгледа проблема. По-конкретно, разработчикът поиска Google да забрани недокументираните изисквания за разрешение да ограничават достъпа на приложения на трети страни до ACTION_PICK_ACTIVITY. Като напишете тези изисквания в CTS, Huawei ще бъде принудена да се съобрази с тези промени.
Честно казано обаче, този бъг сам по себе си не е голяма работа. Въпреки че никое друго приложение, което съм пробвал (като Tasker), не успя да заобиколи това разрешение изискване и стартиране на определени дейности в приложението Настройки, не бях точно разочарован резултатът. Но когато си спомних изказванията на г-н Амбри, разбрах, че малките промени като тези трябва да са много разочароващи за справяне, особено тъй като колкото и малки да са, те несъмненодобавите, понякога достатъчно, за да причини главоболие. Една малка промяна в приложението Настройки може да доведе до незаслужена отрицателна рецензия срещу разработчик. Една малка промяна, която е доста зле документирана и ме наложи да преровя в Интернет за нишка за Stack Overflow. Колко други малки грешки има на други устройства?
Повишената конкуренция в мобилното пространство се оказа чудесна за потребителя, но след като видя как тези фини промени в толкова много различни продуктови линии могат да повлияят на разработчиците, започнах да оценявам гледната точка на разработчиците към фрагментация. Не че самият избор е проблемът, а по-скоро че общността не прави достатъчно, за да каталогизира тези проблеми. Както г-н Ambri предложи в статията си, може би разработчиците на Android се нуждаят от собствена версия на caniuse.com или sdkcritic.com за събиране на всички неясни бъгове в една база данни. Единствената друга алтернатива е да накарате производителите на оригинално оборудване или правилно да документират тези промени, или да спрат да ги правят на първо място, но късмет с това.
Кредити за представяне на изображения: OpenSignal