2013-10-28 Каким бы мог быть Андроид

Материал из YourcmcWiki
Перейти к: навигация, поиск
м
(Массовая правка: добавление Category:VitaliPrivate)
Строка 14: Строка 14:
 
Как это натянуть на андроид — ХЗ, явно нужна какая-то дополнительная прослойка, т.к по дефолту активити описываются в манифесте и только в нём.
 
Как это натянуть на андроид — ХЗ, явно нужна какая-то дополнительная прослойка, т.к по дефолту активити описываются в манифесте и только в нём.
 
Но сама идея по-моему хорошая, так как максимально упрощается вообще ВСЁ, появляется вариант генерить страницы на лету бэкендами (или может наоборот он не особо нужен), плюс есть теоретический шанс суметь сделать это кроссплатформенно.
 
Но сама идея по-моему хорошая, так как максимально упрощается вообще ВСЁ, появляется вариант генерить страницы на лету бэкендами (или может наоборот он не особо нужен), плюс есть теоретический шанс суметь сделать это кроссплатформенно.
 +
[[Category:VitaliPrivate]]

Версия 13:49, 16 сентября 2014

Гугл — лицемеры. Говорить что-то о свободном ПО в то время, как делаете такой огороженный и несовместимый с обычным linux’ом андроид — аморально.

  • Модульность и пакетная организация системы, как в любом нормальном linux’е. Возможность обновления по кускам.
  • Встроенные В ЛЮБУЮ СИСТЕМУ ВСЕГДА ДОСТУПНЫЕ root права для пользователя. Любые способы «защиты телефона от пользователя» (например, selinux) должны быть ОТКЛЮЧАЕМЫМИ.
  • Отсутствие DRM. Ну не было бы без DRM фильмов в play — И НЕ НАДО. Каждый, кто делает DRM — проприетарная сволочь, и я бы предпочёл, если бы этих людей не стало (как Столлман сказал про Джобса — я не рад, что он умер, но я рад, что его больше нет).
  • Работа на стандартном ядре Linux, отсутствие костылей типа binder’а и «зиготы». Вместо первого — сокеты, вместо второго — dalvik assembly (которые надо было бы, конечно, сначала запилить, чтобы они работали).
  • Лицензия GPLv3 на всю систему вместо текущей Apache! Причём, вреда бы это не принесло никакого, а наоборот — уменьшило бы фрагментацию, потому что производители вынуждены были бы открывать свои идиотские костыльные доработки типа изменённых интерфейсов и прочего, и их было бы гораздо легче поддерживать и обновлять. И это бы позволило изначально использовать нормальные linux’овые компоненты, например, busybox и нормальный uclibc вместо bionic.

Дальше уже другая фантазия: скрестить какой-нибудь декларативный язык описания UI с JS и загрузкой из веба.

Типа «html5» приложение с JS, но вместо HTML — QML (там JS уже какой-то есть, с другой стороны это не XML), ну или андроидовский язык (XML, но не очень удобный, может и не подойти, ибо не особо заточен на динамическое создание)… Activity («экраном») будет та же страница, открытая по какому-то адресу (URL). В JS предоставить DOM и вообще API, похожие на обычный браузерный JS настолько, чтобы этого было достаточно для запуска всяких стандартных JS фишек. Плюс видимо как-то эти «описания страниц» кэшировать, чтобы всё-таки не каждая активити из инета открывалась, либо чтобы вообще была возможность завернуть её в пакет приложения. То есть очевидная идея: в чём проблема html5 приложений? В самом html5. Ну так заменить его на что-то и чики-пуки. Как это натянуть на андроид — ХЗ, явно нужна какая-то дополнительная прослойка, т.к по дефолту активити описываются в манифесте и только в нём. Но сама идея по-моему хорошая, так как максимально упрощается вообще ВСЁ, появляется вариант генерить страницы на лету бэкендами (или может наоборот он не особо нужен), плюс есть теоретический шанс суметь сделать это кроссплатформенно.