2010-03-17 Пожалуюсь на Андроид ещё чуть-чуть

Текущая версия на 16:33, 17 марта 2010

В смысле организации системы Андроид — по сути, к сожалению, шаг назад (куда-то в сторону Windows, возможно, Mobile). Нормальной системы управления пакетами с зависимостями и репозиториями там нет. К чему это приводит на практике? А к тому, что когда на каком-нибудь форуме 4PDA или XDA-Developers куча невнятного народа выкладывает кучу невнятных прошивок («официальная плюс две софтины убрано, а три добавлено») под Windows Mobile, это я понять могу. Ясное дело, винда закрытая, как в неё залезешь. Но когда точно такая же ситуация с Андроидом, который вроде-как Linux, вроде-как открытый, вроде-как инновационный — этого я понять не могу. :-(

Ну что мешало взять, к примеру, ipkg? Был бы ipkg — до Андроида 2.1, к примеру, можно было бы обновляться постепенно, частями. А одна из помех, по-видимому — выбор Java-подобного языка для платформы. В Java, с моей точки зрения, не очень красиво сделано управления библиотеками — куча JAR’ов, которые могут лежать где попало, иметь разные версии и т. д. и т. п. И пусть обычно в нормальных системах под это выделяются отдельные пути, всё равно способ, ИМХО, «defective by design». В Андроиде тоже лежит несколько таких «блобов» (framework.jar) и всё, частями ничего уже не обновишь; а нативная часть системы представляет собой обычную помойку.

Управление библиотеками и модулями языка, с моей точки зрения, очень хорошо сделано в Perl'е, потому что они все физически расположены в директориях, равных названиям пакетов, в фиксированном наборе системных путей. Аналогично расположены XS'ки и AutoSplit’ченные библиотеки. Таким образом, пути не зависят от версий самих библиотек, набор библиотек легко виден невооружённым глазом, и сложно установить две версии одной библиотеки так, что они будут конфликтовать. Плюс к этому есть CPAN — репозиторий библиотек, из которого все они легко ставятся. Похожий подход применяется и в Питоне. В PHP ситуация тоже чем-то похожа, но там, во-первых, большинство функций встроено в сам PHP и используется в виде глобальных функций, а не расширений, имеющих пакет/класс, а во-вторых, нет собственно пакетов.

И ещё один минус управляемого кода: это же ограничение свободы использования интерпретаторов и виртуальных машин разных языков! Ведь если подключить к Java нативную библиотеку ещё можно, то подключить Java-библиотеку к нативной уже сложнее… Короче говоря, мне кажется, что идеальная система должна быть написана на родном коде, а её библиотеки должны быть … ну хотя бы открытыми, чтобы можно было создать биндинги к любым языкам программирования и писать под своё мобилко хоть на сях, хоть на далвике с жабой, хоть на перле.