Изменения

Скрестить какойЭтот пост я начал писать ещё 28 октября 2013 года :-нибудь декларативный язык описания UI с JS и загрузкой из веба.)

Типа "html5" приложение А возвращаюсь я к нему каждый раз, когда думаю об обновлении прошивки на телефоне, задумываюсь об устройстве Андроида и испытываю по этому поводу сильный рвотный рефлекс. Ну почему там внутри такое уродство? Зачем лицемерный гугл, болтающий что-то об опенсорсе, делает его таким монолитным, неудобным для ковыряния и по факту закрытым? Короче, вот каким бы, по-моему, мог быть ПРАВИЛЬНЫЙ андроид:* Первое, что должно быть — модульность и пакетная организация системы, как в любом нормальном linux’е. Возможность обновления '''системной части''' по кускам или установки различных версий интерфейса: захотел — воткнул TouchWiz, захотел — воткнул гугловскую оболочку, захотел — MIUI, захотел — от Sony… без извращений со скачиванием идиотских «Zver Edition» сборок с JSбестолковых файлообменников. Без сбросов, без бэкапов. Опять-таки, как в любом нормальном linux’е!!!* Вот эту фичу, кстати, в последнем андроиде почти реализовали: возможность выбора конкретных разрешений, предоставляемых приложениям, при установке, но вместо HTML безальтернативного «согласиться». «Почти» реализовали потому, что вроде- QML как возможности отрубить приложению доступ в интернет всё равно нет.* Работать оно должно на стандартном ядре Linux, без костылей типа binder’а, «зиготы», эмуляции регистронезависимой ФС через fuse… Вместо первого — нужна тоненькая обёртка над банальными unix сокетами, вместо второго (там JS уже какой-с целью экономии памяти) — assembly, то есть«разделяемые библиотеки» на dalvik’е — насколько я понимаю, с другой стороны это есть в .NET, нужно было бы запилить аналогично.* С учётом выпиленной зиготы запуск приложений тоже надо делать нормально — не XML)через intent и вызов activity, ну или андроидовский язык (XMLа запуском обычного процесса. Тут конечно будут нюансы с обеспечением запуска под нужным юзером, но не очень удобныйвсё равно всё решаемо.* GUI фреймворк делать надо так, может и чтобы его можно было использовать из любых языков, а не подойтитолько из управляемого кода на яве! Самый очевидный способ сделать это — написать его на C/C++, ибо а не особо заточен на динамическое создание)управляемой яве/далвике.Менее очевидный способ — как-то умудриться предоставить API с помощью Assembly, см.предыдущий пункт (тем более что AOT компиляция в андроиде уже есть). Activity Также очень полезна была бы возможность замены UI фреймворка на другой ("экраном"хоть Qt, хоть GTK, если захочется) будет та же страница, открытая по какомубез создания дополнительной прослойки.* Естественно, обязательна поддержка usb mass storage (выпиленного в 4-ом андроиде каким-то адресу (URLидиотом). В JS предоставить DOM и вообще API, похожие на обычный браузерный JS настолькохоть даже напрямую в ext4, чтобы этого было достаточно для запуска всяких стандартных JS фишекмелкософт своим убогим патентом на FAT32 LFN не потрясывал.Плюс видимо как-то эти "описания страниц" кэшировать* Коли уж APK приложения не имеют зависимостей, вполне нормально было бы поддержать установку приложений '''вместе с данными''' в собственный каталог или раздел, чтобы всё-таки не каждая активити из инета открываласьзатрагиваемый при обновлении системы, либо чтобы вообще была возможность завернуть её а также поддержать произвольное разбиение диска. Чтобы на флешке при этом не копилась дикая свалка разнородного мусора, оставляемого приложениями — запись в пакет другие директории разрешать только после подтверждения пользователем. При сносе приложений данные '''не удалять'''! Ибо они — собственность пользователя, а не приложения, и, соответственно, пользователь должен иметь к ним доступ. Бывает, конечно, всякий мусор типа кэша webview, но его просто нужно складывать отдельно, да и всё.Т* Root права для пользователя должны быть доступны ВСЕГДА! Телефон и вообще софт должен защищать пользователя, а не ЗАЩИЩАТЬСЯ ОТ пользователя.еТо есть все selinux’ы и прочее фуфло должно быть либо отключаемым, либо реализовано так, чтобы пользователь всегда имел доступ ко ВСЕЙ системе. очевидная идея: * DRM, разумеется, быть не должно, в чём проблема html5 приложений? В самом html5. Ну так заменить его на частности потому, чтопри наличии рута (который в итоге-то всё равно всем доступен) он всё равно БЕСПОЛЕЗЕН. На половые проблемы проприерастов, занимающихся продажей приложений (и чикифильмов, и прочего), мне в целом положить, но если уж им очень хочется, пусть делают свою защиту через привязку к серверу — способ вполне адекватный для смартфонов: уже сейчас нехилая часть приложений — тупо UI для чего-пукинибудь. Ну, калькуляторы продавать, конечно, уже не получится — НУ ТАК И НЕ ХРЕН. Ну не будет фильмов в маркете — тоже мне потеря. Всегда мечтал смотреть фильмы за деньги на 5" экране мобилы. Через мобильный интернет, ага. Всегда мечтал.Как это натянуть * Маркет должен быть более ориентирован на андроид - ХЗинтеграцию с процессом разработки приложения: пусть там будет багтрекер, явно нужна какая-то дополнительная прослойкаисходники в git, тwiki, история версий, информация о лицензии, документация… Ну или просто интеграция с github’ом.к по дефолту активити описываются * НОРМАЛЬНАЯ опенсорсность самой системы. Сейчас андроид под лицензией Apache, в манифесте официальном репозитории поддерживается только для nexus’ов, и это создаёт огромные неудобства — каждый производитель городит свою закрытую оболочку со своими патчами, своим закрытым загрузчиком, своей системой обновления прошивки, да что там системой обновления… зачастую вообще без обновлений! Чтобы такого не было, нужно либо поменять лицензию на GPLv3 и вынудить производителей открывать все доработки, либо просто административным ресурсом загнать всех в ОДИН общий репозиторий, в котором и поддерживать. По сути, всё должно разрабатываться как CyanogenMod — система общая, а для разных девайсов различаются только специфичные части. Ещё лучше, если сделать и лицензию нормальную (GPLv3), и загнать всех в нёмобщий репозиторий. И поддерживать было бы проще, и обновлялись бы все охотно, и «фрагментации» бы пресловутой не было, и можно было бы изначально использовать нормальные компоненты, например, busybox и нормальный uclibc вместо bionic.Но сама P.S: Ещё есть идея по-моему хорошаяповоду кроссплатформенных HTML/JS приложений — так как их очевидная проблема это непосредственно сам HTML, тс его reflow’ами и отсутствием нативных контролов — нужно просто придумать другой нормальный скриптуемый язык описания интерфейсов (причём без особой специфики, чтобы можно было его сделать кроссплатформенным).Типа как стандартный андроидовский язык описания интерфейсов, только более приведённый к. максимально упрощается вообще ВСЁ«вебовому» виду, появляется вариант генерить страницы на лету бэкендами со скриптами и даже, наверное, с возможностью грузить описания Activity с сервера аналогично HTML страницам сайтов (или может наоборот он не особо нуженс кэшированием, конечно). Было бы, плюс есть теоретический шанс суметь сделать это кроссплатформеннопо-моему, очень круто — многие мобильные приложения сейчас представляют из себя просто нативные интерфейсы к сайтам, а так их даже не нужно было бы оборачивать в приложения — нативный интерфейс появлялся бы прямо в процессе просмотра интернетов.{{wl-publish: 2015-06-02 23:35:51 +0300 | VitaliyFilippov }}