Почему заглох Eclipse Andmore?
Самим авторам надоело или Google им поставил неразрешимое препятствие?

Я Eclipse Neon скачал, в нем проект для Андроид не создается. Просто Exception при попытке его создания. Вот и думаю - традиционный ли это геморрой для Андроида, в котором в отличие от нормальных сред программирования нельзя просто установить и чтобы заработало, или Google этот плугин специально отрубил.

Кстати, команду anroid create гуголь убрал - и не только в последних версиях SDK.

Приложение можно хоть на коленке собирать без всякой IDE.

Можно, я уже попробовал. Без автодополнения с Явой и громоздкой системой классов работать неудобно, однако. В мире Java же принято давать имена в 12 символов, не меньше, делать хитрозамудренные конструкции со множеством скобочек для выполнения элементарных вещей (назначения обработчика нажатия кнопки, например) а чтобы потом со всем этим бороться, придумывать костыли в IDE.

Зачем мне Eclipse? Хочу уйти от gradle. Дело не только в сложности этого сборщика и ужасно плохой работе. Но и в самой идеологии, когда скачивается и устанавливается помимо желания и ведома разработчика неизвестно что в неизвестный момент. Мало того, что гугл может удалить или объявить устаревшими любые библиотеки и заблокировать ваш проект в любой момент. Есть еще такое понятие, как валидация программного обеспечения. В некоторых областях деятельности валидируют и контролируют каждый чих - от оборудования и производственных процессов до программ. С валидацией любое изменение должно быть контролируемо. Ситуация, когда после простого запуска что то меняется, что то обновляется, что то перестает работать (как чувствую обычно для андроидных систем, раз уж они не могут даже своим собственным инструментам обеспечить стабильную работу) - неприемлема.

Поэтому - поставил, настроил - все, никаких обновлений. Хотите обновление? Можно - только точно знать что именно, запускать вручную и валидировать после этого весь проект заново. С документированием всего процесса.

alex55555,
Там, кстати, действительно полезных фич немного.

Как я понял AndMore сделали не для фич, а чтобы вообще был плугин под Ecslipse, после того, как Гугл удалил свой.

Полезных фич во всех этих вариантах вообще немного - что в новейших, что в старых. Главная - синтаксический анализ и автодополнение. Т. к. система Java классов для Андроида большая, запутанная и с длинными именами - искусственная сложность, с которой борются с помощью костылей в редакторе.

самыми популярными IDE для явы традиционно считаются Jetbrains IDEA

А про NetBeans вы уже "забыли".

имея 18 лет опыта создания IDE

Что уж они там 18 лет создали, эти питерцы, загадка. А создатели Eclipse по вашему не имеют опыта создания IDE? А Netbeans c 1996 года ведет свою историю. В общем то по сравнению с другими IDE - из взрослого, так сказать, мира, что те, что другие выглядят дилетантами. Я это говорю не с целью раздувания флейма, а в ответ на ваше преклонение перед их "опытом". Очевидно, что главным мотивом Гугла было обособление от Java сообщества и от Oracle, который с ними судился, поэтому они и редактор взяли никому не известной компании, и язык в Котлин переименовывают. Любимая тактика Гугла - взять что то чужое, обычно бесплатное и объявить своим, причем эпохальным открытием.

chpasha,
предлагаю вам обращаться ко мне на вы, в противном случае буду просто игнорировать все, что вы пишете. Если вам на каждое слово хочется устроить холивар, то проблема в вас самом, не ищите ее в других. Ваше длинное сообщение с кучей цитат воспринимаю, как попытку все зафлудить, которую я поддерживать не буду, уж простите великодушно.
Нетерпимость к мнению, которое отличается от вашего собственного, неспособность отделить предмет обсуждения от личности (считать, что любое несогласие с тем, что вы отстаиваете это личная нападение именно на вас), неумение отстраненно аргументировать - плохие качества для дискуссии и для установления истины.

можно, в Android Stuido.
Нет, нельзя. Установка этой IDE тот еще геморрой. Даже не скачивается в готовом виде. И не только у меня.

вот есть у меня зависимость от библиотеки support-design:27.0.2 - что дальше, каковы действия гугл по объявлению этой библиотеки устаревшей и блокированию моего проекта?

Я должен разжевывать элементарные вещи? Гугл полностью контролирует как сборщик, так и то, что он скачивает. Блокируется либо модификацией источника скачивания, либо сборщика. Обновление этого сборщика происходит на каждый чих. Можно сделать вообще все, что угодно. Вы так верите Гуглу, что он не будет ничего портить? Гугл вам даже ничего не обещал! Гуголь обещает строго противоположное - что будет делать что хочет, не спрашивая вас и не интересуясь вашими нуждами. Вспомните массовое удаление клиентов вацапа из другой системы ловушек для программиста - гитхаба.

В один прекрасный момент Гугл решил всех заставить перейти на gradle и сделал все, чтобы программирование без него стало крайне неудобным. Сейчас пытается все завязать на адроид студии, даже проект без нее создать больше нельзя. Это очень плохая практика, так как ведет к лишним зависимостям - к зависимостям от визуальной среды. Разработчик визуальной среды начинает полагаться на особенности сборщика, а сборщик - на то, что создается через визуальную среду. Результаты помимо всего прочего - рост трудноразрешимых глюков.

Сами эти проекты, в которых настройки компоновщика перемешаны с локальными настройками и раскиданы по куче файлов. Чтобы программист ничего не понимал и действовал только в узком коридоре, который ему дает гугол. Мучаясь на каждом шагу с глюками, которые не знает как исправить и за которые никто не отвечает.

Например, у меня grandlew не работает - не может себя обновить. И поэтому ничего не компилирует. При этом из студии компиляция проходит нормально и по ссылке, на которую он дает ошибку, вручную тоже скачивается. Почему? Хрен его знает. И с этим можно мучатся день, два, а может и месяц. Можно ли обойти это скачав нужное из интернета? Может и можно, только grandle хранит все в кеше с зашифрованными именами - чтобы программист не вздумал скачивать вручную.
Гуголь завязал все на скачивание через интернет при этом не озаботившись работоспособностью своих инструментов для этого. Выглядит это как поделка на коленке, сделанная дилетантом.

Вывод: гугол заставляет пользоваться только своими инструментами, которые при этом даже не работают как должны.

Если посмотреть на гугл-плее на комментарии к популярным программам, обнаруживаем огромное чисто жалоб на глюки, на то, что все перестало работать после выпуска очередной новой версии.

Убогость среды выполнения Андроида (нельзя делать подключаемые библиотеки) и убогость запутанной библиотеки и убогость языка, все вместе создает дикое количество зависимостей. Вместо их уменьшения придумали костыль в виде компоновщика. Который только провоцирует на еще большее количество зависимостей. Впрочем, Гуглу это все очень выгодно - контроль над всеми разработчиками.

alex55555, обсуждение взрослых сред разработки выходит за рамки данной темы. К тому же тут на некоторых тут это действует как американский флаг на шахида.
Возьмите любую известную IDE под Windows - названия основных классов там будут короткие, система классов стройнее, а возможности больше. И программы гораздо сложнее, чем простенькие приложения на Андроиде из 10 форм (вацап, например). Понятное дело, что на Андроиде тонкий клиент, а основная сложность на серверах. Но я говорю как раз о визуальной части. Нет, я понимаю, что есть свои резоны и свои цели. Но все равно создается ощущение искусственного усложнения.

Может, язык Ява так мозг выносит, т. к. в нем отсутствует отделение описания от реализации, плюс конструкции, порождающие многословие. В результате программист видит не класс с его объявлениями, а поток кода, туманящего мозг. Какое мне дело до реализаций методов? Мне нужно видеть только их список и их аргументы и знать, что они должны делать (есть "волшебное слово" инкапсуляция, которое все твердят как минимум 30 лет).

По иронии судьбы виноват в этом любитель чистоты. немногословности и ясности Вирт, который в своем Обероне убрал разделение описания и определения процедур, что потом заимствовали и в Java, и в С#.

Да, я знаю, что в редакторе Java IDE есть костыли, "решающие" этот вопрос - сворачивание плюсиком и другое. Видимо, это общая проблема всего на Java - вместо исправления самого языка придумывать внешние костыли. Что, вероятно, создает для программиста Java определенный образ мысли и привычку делать так всегда, во всех вопросах.

chpasha,
не старайтесь больше сюда писать, вы в игноре, так как не желаете себя прилично вести и еще ничего не сказали по делу.

alex55555,

Освоение нового - тот ещё геморой, да.
Я говорю не про освоение, а про установку. Которая сама по себе тот еще геморрой.

И да - с этим вам придётся смириться, если вы хотите писать под платформу

Гугол хочет новые правила - полностью контролировать программистов. Такого еще не было. Под Виндовс были сторонние средства разработки и вы могли очень долго не переходить на новые версии, даже если использовали VS. Гугл теперь считает, что сможет насильно заставить пользоваться любым отстоем, т. к. обновление идет без ведома программиста. Пока что это до конца не реализовано - но цель такая.

Можно добавить

Я не об этом. Вы вынуждены включать все используемые ваши библиотеки в apk-файл. Аналога dll для обычного разработчика нет.

даже никто не мешает использовать старые плагины для Eclipse. Я с новой студией не возился, а под эклипсину библиотеки добавляются легко.

Можно сказать лучшее, что пока что массово используется. Но старые привычки мешают это видеть.

Наверное сам язык надо в отдельной теме в другом разделе обсуждать.

То есть просто не знаете те возможности, с которыми пытаетесь сравнивать.

Напоминаю - я говорил про Андроидную библиотеку и андроидную среду разработки.
Ок, покажите мне приложение из 100 окон на Android, делающее что то более сложное, чем отправка и получение сообщений с сервера. Игры не в счет - их, кажется, пишут не на Яве.
Визуальный редактор в Android Studio не может создавать обработчики событий и объявления переменных с их автоматической инициализацией - то, что мог любой редактор форм начиная с середины 90-х годов. Т. е. делали настолько невежественные люди, что не удосужились даже скопировать давно известное. Ааа, они наверное редактор визуальных ресурсов под Windows 3.1 копировали. Дальше не пошли.
Ну я понимаю, что может быть несколько лейаутов, и некоторые контролы могут в одним быть, а в других нет. Поэтому так и сделали - переложили все на программиста, гибкость мол.
Но все равно вышел фактически визуальный просмотрщик, а не редактор. Как от просмотрщика от него польза есть. Как от редактора - почти нулевая.
Вот я думаю, как бы это можно было по человечески сделать.Лейаут то с формой никак не связан, где генерировать обработчики неизвестно. Тоже типа гибкость. Правда на деле эта гибкость вряд ли используется, т. к. все все равно привязывается 1 к 1 на стадии выполнения.
Если засунуть объявления и обработчики в отдельный класс, он не сможет использовать закрытые члены Activity. Засунуть его генерацию в класс наследник Activity мы не можем, т. к. не знаем, к какой Activity будет привязан layout.

Будь в Java friend class-ы, задача бы решалась. Подскажите, как знаток Java, можно ее решить или нет?

Ну да ладно, в Андроиде все равно не может быть много контролов в одном окне - экранчик маленький. Так что невелика беда для понимающего человека.

Так вот там длина ни чем не ограничена

Название должно быть понятным, но настолько коротким насколько это возможно сделать, оставляя его понятным. Можно назвать - Form, в Java - Activity. Длиннее почти в 2 раза, преимуществ по понятности нет.

Можно назначить обработчик.

OnCLick = MyClick;

В Android вы сами знаете как. На несколько строк с кучей скобок. Многословность и запутаннее одновременно.
Можно для процедурного типа объявить только аргументы - то, что действительно имеет значение. Но в Android надо объявлять функцию-член с определенным названием. Ненужное усложнение библиотеки. Потому что в версии Java, используемой Android нет процедурного типа.

Виноват, friend class тоже статически привязывается к типу родителя. Так что и с ним было бы не очень. Да и список уже существующих обработчиков событий выводить в редакторе было бы неплохо, так что так и так надо знать, к какой Activity идет этот layout. А это значит, что к другой Activity его привязать во время выполнения уже не выйдет нормально. Впрочем, если мы зададим список, а не одну Activity, генерировать можно в них всех, а инициализировать по разному в момент загрузки.

Короче, никому это не надо из-за примитивности задачи расположения контролов на экране, которая решается без всяких визуальных редакторов. Хотя это и замедляет работу. Но самих активностей ведь тоже разных не много в проекте.

alex55555,

похоже вы не читаете то, что я пишу. Вроде и так предельно просто все объясняю. 10 раз повторять и разжевывать что ли?

Подымите свой уровень обсуждения, пожалуйста. И хватит заклинаний про гугол и тому подобного. И фантазий насчет собеседника поменьше.

Ок, объясняю еще раз. Вы меня заставляете это делать. Визуальное редактирование в андроиде сделано крайне неудобно, фактически его нет. Библиотека визуальных контролов слишком раздута, сложна и неудобна в сравнении с любой взрослой средой разработки даже 20 летней давности. Это факт.

Притом, что задачи решаемые библиотекой визуальных контролов - задачи создания интерфейса - на порядки проще. И это тоже факт.

Хотите по фактам спорить - спорьте. Я допускаю, что я не прав. Только у вас свидетельств противоположного пока не увидел.

То есть для решения простой задачи выбраны сложные средства. Это плохо. Это называется искусственное усложнение. Заставляют программиста не задачу решать, а с искусственными препонами возится.

По поводу создания обработчиков событий я просто прикинул, как можно сделать - пока что без связи лейаута с активити до компиляции выхода не вижу. Как часто используют один лейаут в разных активити? Вы это хоть раз делали когда-нибудь? Зато неудобство при создании контролов терпят все и постоянно. Тратя на это раз в пять больше времени и создавая во столько же раз больше кода, чем можно было бы при другом подходе.

В очередной раз повторяю - именно в области интефейса все это не так важно в силу примитивности интерфейса у андроида. Примитивность заключает в малом количестве контролов и разных экранов. Это объективный показатель.
Если бы их было много, то неудобство создания пользовательского интерфейса было бы существенно. А так - не особо. 10 окошек максимум слепить через задницу - и потерпеть можно.

Про блютусы и прочее разговор отдельный. Кстати, что там с блютусом, почему так сложно?

Что же делать? Срочно удалять всю документацию!
Документацию надо писать лаконично и ясно. Если не выходит - то что то не так либо с писателем, либо с архитектурой проекта, либо решаемая задача объективно сложная. Но когда задача сложная, тем более надо стремится к простоте, чтобы не добавлять еще и искусственной сложности.

Для чего там вообще делают закрытые члены.

А вы ознакомьтесь для чего делают friend-классы. Ну в Яве в отдельном файле такое не сделаешь, кажется. Ладно, забудьте.

Вам уже выше показали - вы просто не знакомы с возможностями языка, который принялись так смело критиковать.

А я не спорю, что с явой не знаком. Правда, никто ничего не показал, я это и сам знаю. Так просветите. Неужто в андроидной яве есть процедурный тип и свойства? Видал я мельком что в новой яве что то такое добавили, но не в андроид же?

Кстати, сейчас пробуют Netbean + Ant. Сам редактор мне понравился больше всех прочих явовских, автор его солидный.
Чего там нет, так это визуального дизайнера xml-файлов, но как я уже многословно объяснил, этот визуальный дизайнер почти бесполезен.

Существовал плугин для Netbean для создания проекта под Ant. Но почему видимо ПО ЧИСТОЙ СЛУЧАЙНОСТИ это плугин пропал отовсюду, и даже сайт его разработчика закрыт. Так что этот плугин даже для старых версий Netbean не найти. Вот просто так взяли и вычистили.

Правда, уже сделали новый плугин. Но он работает через grandle. Который мне не подходит по своей идеологии и вообще у меня из командной строке просто не запускается и неизвестно почему оно даже не может себя обновить через интернет.

Склоняюсь к мысли, что главное зло это grandle.

Пока что воспользовался android create из очень старого SDK. В новых SDK его нет, но он ведь ничего мистического не делает, только создает структуру каталогов и файлы и это можно сделать руками, если знать как.

Правда, может в новых SDK гуголь совсем поддержку ant-а уберет или уже убрал - а использование ant завязано на конфигурационные файлы из каталога SDK. Буду смотреть. нужно разобраться как xml из библиотечных проектов обрабатывается при компиляции и чем. А так ведь можно и свой плугин под НетБин написать при желании.

Siemargl,

Предъявлять к среде претензии в неочевидности - это просто недостаток опыта.

Познается в сравнении. Если человек кроме андроида и явы ничего не видел и не использовал - вряд ли он вообще что то поймет.

Иногда понимание заключается в понимании того, что автор делает глупости. Не читали 12 стульев? Помните как там любители г. Васюки были в шоке от ходов "гроссмейстера" Бендера, который наговорил им с три короба и в первый раз в жизни играл в шахматы?

Чтобы понять Java следует знать две вещи:

1) Этот язык скопирован с Оберона безусловного мэтра профессора Вирта
2) В коммерческих целях при этом был искажен его синтаксис + плюс из-за непонимания и не разделения до конца идей истинного автора.

Так что для начала неплохо почитать Вирта, он то знал, что делает и запутать не пытался. Потом оценить как это было искажено и испорчено теми, кто это заимствовал.

Например, в том, что нет отделения объявления и определения виноват, увы, поборник чистоты и понятности Вирт. Я склонен считать это самой большой ошибкой, которую он когда либо делал. Конечно, в его Обероне это выглядело не так ужасно, но наложившись на искажения и запутывания языка Ява, сделанные с целью привлечь и сишников и адептов Smalltalk и показать свой язык крутым (а потом еще начали из лиспа тянуть, чтобы показать себя крутыми в глазах непосвященных), выросло в ужас-ужас.

в нем многое делается по другому.

Поскольку в Яве нет ничего нового в смысле ООП, да и трудно это было бы сделать, тем более его разработчикам, которые не творцы и не гении, а заимстователи-коммерсанты, "по другому" обычно означает - "через задницу" - то, что было признано плохим и от чего другие отказались.

Было бы неплохо понимать, что сейчас никаких новых идей в языках программирования вообще нет. Все придумано давно - в прошлом веке. Смешно смотреть, как заново открывают сделанное 50 лет назад и набивают те же шишки. Пример - xml и иерархические базы данных, от которых отказались годах в 1970-1980-х. В данный момент идет экстенсивное освоение возможностей, которые дают слишком высокая скорость передачи данных по сетям, а вообще индустрия программирования сворачивается и деградирует.

alex55555, исправьтесь или отправитесь в игнор вслед за предыдущим гражданином. Начните хотя бы читать то, с чем вы спорите.
Если вы говорите, что как то можно - показывайте как можно. Иначе все это пустословие.

Даю вам задачу: обеспечить назначение событий в визуальном редакторе, избавить пользователя от необходимости вручную объявлять и инициализировать переменные-контролы. Сделать это статической связи между лейаутом и формой. Из кода событий должно быть возможно обращаться к любому члену активити, в том числе закрытому. Генерировать для решения файлы классов в текущем проекте разрешается.

Как знатоку Ява даю вам день, чтобы дать свое решение.. Потом сравним с тем, что пришло мне в голову.

Siemargl,

Вирт убрал разделение в REVISED OBERON

РАЗЛИЧИЯ МЕЖДУ OBERON’ом И ПЕРЕСМОТРЕННЫМ OBERON’ом (REVISED OBERON)

Пересмотр языка Oberon был произведен после большого числа экспериментов в использовании и реализации данного языка. И вновь этот процесс был вызван стремлением к упрощению и обобщению. Различия между исходной версией [Wir88b] и пересмотренной версией [Wir90] следующие.

1. Интерфейсная и исполнительная части модуля слиты воедино. Это вызвано желанием иметь спецификацию модуля с точки зрения программиста и с точки зрения компилятора в виде одного документа. Спецификация интерфейса для клиентов модуля (интерфейсная часть) может быть получена автоматически.

Объекты, ранее описываемые в интерфейсной части (и еще раз встречающиеся в исполнительной части), помечаются специальным значком экспорта.


Никлаус Вирт "От Модулы к Оберону"

Andy_OLAP,
я не юноша и вы выбрали неверный стиль общения, пытаясь взять криком. Я и юношей так с собой разговаривать не позволял, теперь тем более.

Да, заставляет, но они работают как должны. Как должны офицерам из подразделения,

1. В Гугле нет и не может быть никаких офицеров (даже если вы переводите английское слово чиновник неправильно - чиновников там тоже нет и быть не может). Это не армия и не государственная организация, а частная компания. Равноправная с любым юридическим лицом и не имеющая преференций перед частными лицами.
2. Что его работники должны Гуглу нужно слушать от самого Гугла, а не от вас.
3. Гугл пока еще вроде не заявлял, что его Студия не должна работать сразу после установки, не запускаться, выдавать ошибки в созданных ею же проектах, что grandlew может не запускаться и т. п.

Так что вы не правы - именно что не работает как должно. Не работает как заявлено, если вам от этого легче. Заявлено - используйте нашу песочницу и все будет работать без проблем. Даже это не выполняется.

Причем это закономерно - если разработчики считают, что могут всем выкрутить руки, удалить конкурентов и принудить работать на том, что они подсовывают, они стараться сделать что то вообще работающее не будут, мол и так сожрут - а всем недовольным мол заткнут роль с помощью нанятых агитаторов. Низкая квалификация видна невооруженным взглядом.

Я думаю, что несмотря на лживые победные реляции Гугл уже давно столкнулся с МАССОВЫМ нежеланием разработчиков использовать свою Студию. Поэтому руки и выкручивают, даже SDK manadger удалили из SDK. Чтобы отчитываться перед руководством компании о росте числа установок своей бракованной продукции. Ну а на ресурсах с порочной системы репутации сидят специально нанятые люди и минусуют любое недовольство этим продуктом.

Это напоминает анекдот о том, как цыган учил лошадь не есть.

В принципе, интересам Гугла бракоделие создателей студии противоречит, так как мешает заманивать разработчиков в капкан полной зависимости от себя. Куда проще им бы было, если бы сыр в мышеловке был сыром, а не куском грязи.

лиспа - оттуда взят код по сборке мусора

Нет, я имел в виду другое. Сборщик мусора тиснули из Оберона. Я имел в виду т. н. лямбда-функции, которые вносят еще больше хаоса в код на Яве.

Java - многопоточность там часть языка

В Java многопоточность не является частью языка. Считаете я неправ - тогда покажите, как вы будете создавать поток в Java, какие зарезервированные слова языка для этого используете.

интерпретируемый диалект языка Си++ изначально

В Java от C++ только скобочки и некоторые ключевые слова.

Я Вам более того скажу, принцип Java - классы вместо структур, а у Оберона с точностью до наоборот.

Это внешняя мишура. Класс - структура с данными, метод - процедура, которой передается указатель на экземпляр класса. Виртуальный метод - поле с указателем на процедуру. В Обероне есть расширение структур (наследование).

Надо обладать хотя бы минимальными способностями к абстрактному мышлению и некоторыми знаниями о реализации, чтобы это увидеть. Хотя все достаточно очевидно.

Просто я уже и не знаю, чего ожидать от современных т. н. "андроид-ява-программистов". Когда вместо статей ролики в ютубе (просмотр ролика занимает в 5-10 раз больше времени, чем чтение текста и информация на слух воспринимается куда хуже, чем с из текста), вместо изучения внутренней структуры - инструкции по магическим манипуляциям в IDE и за ее пределами.

Вирт книжный червь, а не инженер-прагматик

Вирт сам писал компиляторы и операционные системы всю свою жизнь. Внимание вопрос - что создал Джеймс Гослинг, какие программы написал?

Вот Ричи (один из создателей С), например, сделал ОС Unix, которая получила широкое распространение. Его можно назвать программистом-практиком.

Уж про гугловских вообще можно не говорить. Стырили свободную ОС, свободную виртуальную машину, объявили все своим и начали портить. При этом сначала создавая у программистов иллюзия открытости и противопоставления "плохим корпорациям", а потом решили намертво все закрыть, объявить своим и показать всем, кто им помогал, что плевать они на них хотят. Взяв чужую среду разработки.

Тут остается только удивляться распространенности Android-устройств и тому, что там есть работающие и использующиеся программы.

Поэтому я утвердился во мнении, что пишется это на чем то старом и/или стороннем, вопреки стараниям гугла и уж точно не на последней версии Студии.

Отсюда вывод - использовать Студию = быть лохом. Даже если программируешь под Андроид.

Siemargl,
Похоже в статье по вашей ссылке вы спутали объявление процедурного типа с объявлением функции. Советую почитать другие документы с того же сайта. В первоначальной редакции Оберона было разделение на открытую и закрытую части модуля, а в исправленной версии в 1990 году профессор Вирт это разделение убрал и больше к нему не возвращался (forward декларация это не то, она не является обязательной и служит другим целям).
Описание v90 https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon.Report.pdf . На всякий случай поясняю: в Обероне начиная с 1990 года доступность процедуры извне модуля обозначается * возле ее имени.

Зачем гадать об отношении профессора, когда он сам о нем прямо сказал?

Что до моего мнения о таком решении, то я считаю что решение мягко говоря спорное, спровоцировавшее явистов (а вслед за ними и других) на безобразия. А оправдание этого решения тем, что мол можно интерфейс модуля автоматически сгенерировать спровоцировало на затыкание любых дыр в языке костылями из IDE.

alex55555,
а я то думал вы мне тут покажете класс понимания ООП и знания языка Java, утрете нос, и что мы пообсуждаем минусы и плюсы разных решений.

По решению задачи скажу кратко.

Генерируемый в отдельном визуальным редактором класс:


В xml описаны объекты с такими же именами.

В окне активите пишутся вручную две строчки



MyCoolLib.InitLayoutImp заполняет button1 и edit1 используя RTTI (Class). Реализацию прикиньте сами. Если не сможете - просите, напишу.
Дальше везде можно использовать L1.button1 и т. п. Гибкость сохраняется. Вполне удобно.

С методами все гораздо хуже. Кстати, почему то магистры андроида не вспомнили атрибут android:onClick . Пользоваться им неудобно, так как приходится редактировать в двух местах. Если бы можно было бы из редактора создать тело метода и сразу туда перейти - было бы удобно. А так нет. К тому же необходимость объявления обработчика public нарушает лелеемую инкапсуляцию.

Можно так же генерировать обработчик события в теле InitLayoutImp, но он тогда не сможет обращаться к Activity. Можно добавить в InitLayoutImp поле parent: Activity, но тогда придется приводить тип к Activity1 принудительно для обращения к специфическим методам, да и как быть, если вызывается из другой Activity - цепочку if-в устраивать? Уродливо. Тут больше всего мешает архитектурное решение не связывать layout с activity жестко. Так что это решение с обработчиками событий не дает почти ничего полезного по сравнению с их обычной инициализацией вручную.

Я не знаю, что вы понимаете под процедурным типом и свойствами.

"Указатель на функцию, указатель на метод класса" - так понятнее? Только в отличие от указателя процедурному типу нельзя ни численные значения адресов присваивать, ни нетипизированные указатели. Решили от хакерства таким путем защитится. Вдруг бы программист как то умудрился обойти ограничения и записал бы ссылку на вредоносный код и таким образом выполнил бы его?
Мотив понятен, а все равно неудобно писать эти монстроузные конструкции вместо простого присваивания обработчика.

Свойство это когда вы пишете что то вроде

property Width: integer read GetWidth write SetWidth

и потом используете Width везде как будто это просто поле (за исключением передачи параметра по ссылке).

androidannotations

Вообще не о том. Голимые макросы препроцессора. Недостатки макросов известны всем (кто не ява программист) 20 лет. В С они активно использовались, и были написаны тома критики.

butterknife

Еще один набор макросов. Со всеми их недостатками.

DataBinding

Это не то, о чем я говорил. Другая задача. Городят связь между визуальными компонентами и объектами данных. И весь код пишется вручную (плюс макросы). Вроде я четко условия задачи сформулировал. Можете их перечитать.

@BindingAdapter

И в нем голимые макросы препроцессора.

Но вы для меня новое открыли, действительно. И я не знал, что в Android-е макросы препроцессора так широко используются. Кстати, как они там называются, наверняка ведь придумали какой то свой термин?

Вот уж действительно все в этом андроиде изобретается заново из-за невежества, причем наступают на все грабли.

Можете сказать, что предложенный мной подход тоже генерирует код, хотя и из редактора. В чем принципиальное отличие от макроса, скажете вы. Но в моем случае код генерируется сразу в виде готового файла, его можно видеть и прочитать. А дальше все обрабатывается встроенными средствами языка.

Я понимаю, что тут читатели не догоняют. Сложно им понимать, когда у них умения делать магические настройки в IDE, а не умение абстрактно мыслить.

Не придирайтесь к неаккуратной работе с исключениями.

вызов



Предполагается, что это генерируется визуальным редактором и сохраняется в отдельный файл:



Придется обязательно указывать у верхнего layout id, т. к. у activity нет findViewWithTag и я не нашел за 10 минут способа получения текущего layout из activity. Может статься его и нет, чтобы не меняли состав контролов в произвольное время - запрет из соображений "оптимизации".

Аннотациями макросы обозвали. И используют на каждом шагу. Без @override ни шагу ступить.

@override - тоже макрос. Интересно, как он реализован.

Еще и расширили их применение в 8-й версии.

Скажите после этого, что Ява самодостаточный язык..

Без руля и ветрил несет Java неведомо куда, т. к. скопировав в начале работу мэтра (попоротив ее при этом), дальше его создатели уже не понимают, что делают и зачем.
Что уж там говорить об андроидных "программистах".

Как привлекательно использовать макросы - это же можно свой метаязык создать. Потом это приводит к хаосу. Но дилетанты об этом не знают, читать и понимать прочитанное не умеют, чужой опыт усвоить не в состоянии.

alex55555,

Просто взглянув на его первый "шедевр" в виде кода, можно набрать сразу с десяток косяков

Ну так давай, косяки в студию. Конкретно, что не так. Пока что от тебя только общие шаблонные фразы без доказательств.

Я бы даже рекомендовал его бред для начинающих - найди десять ошибок,

Ну так давай, найди. Перечисли. Именно десять. Жду.
Что ты ни своего ничего предложить не можешь, ни на ошибки указать.

chpasha
я тебе пытался объяснить, почему использование визуального редактора бесполезно, но ты либо не захотел, либо не смог понять. Еще раз - layout не принадлежит Activity эксклюзивно. Куча других сущностей может быть "связана" с layout, потому просто не существует одного такого места, где можно сгенерить что-либо. задача бессмысленна изначально.


Это ты теперь мои же слова, которые я давно сказал, мне же и повторяешь и преподносишь это как свое откровение о котором я не знаю. Похоже тебе действительно нужна помощь специалиста.

Давай, еще почитай, может до тебя дойдет, что в моем подходе как раз обеспечивается возможность гибкой связи разных Activity с одним layout.

Но похоже, тебе говорить что то бесполезно, т. к. ты вообще не программист и не понимаешь НИЧЕГО.

Я бы на месте Java программистов серьезно обеспокоился, что их всех начнут считать такими как chpasha . Который все, что ни говорит, все мимо, а в конце вообще начал мне мои же рассуждения пересказывать (о хамстве уж я и не говорю) и меня в них же и убеждать. Т. е. гражданин в принципе не способен воспринимать информацию.

Я бы на месте Java-программистов сказал бы такому - к ноге мол, кыш, не позорь нас, мы не такие. Извините, мол, не принимайте этого гражданина за нашего представителя.