Какие принципы использовать для реализации GUI на андроиде?

В андроиде вроде набор нативных виджетов встроен.

Иди на 4pda или xda-dev.

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

Используйте нативный тулкит, он вполне развит, это вам не J2ME с убогим lcdui (хотя даже туда на последнем издыхании подъехал LWUIT, на некоторых мобилах даже из коробки). Там XML-лэйауты, не надо библиотек никаких. В Android Studio, поговаривают, виджеты на форму вообще мышкой накидываются в два счёта.

У любителей рисовать на канвасе получается ненативное говно

Понял.

Android Studio, поговаривают, виджеты на форму вообще мышкой накидываются в два счёта.

Я несколько часов пытался это сделать. В итоге, все связки прописывал напрямую в XML. Мышой оно все время норовило прицепиться не туда куда нужно и не так как нужно. Хотя как заготовка это вполне неплохо.

В Android Studio я уже на двух глюках споткнулся, хотя повозился с ним всего пару дней. Первый это кривой поиск. И второй при работе в Design свойства толком не хотят добавляться в Favorite attributes.

А что с поиском-то не так?

Не пробовал документацию почитать? А ведь там всё написано.

Неужели даже startandroid.ru или developer.alexanderkerimov.ru не читал? Там хоть устарело, но не настолько

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

Понял, спасибо.

В итоге, все связки прописывал напрямую в XML. Мышой оно все время норовило прицепиться не туда куда нужно и не так как нужно.

Ъ-погромисты пишут весь гуй руками обычно, по крайней мере тут об этом постоянно кричат.

Ъ-погромисты пишут весь гуй руками обычно, по крайней мере тут об этом постоянно кричат.

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

В андроиде всё работает на 70%, это нормально. Визуальный редактор можно юзать только для экранов с десятком элементов, более сложные он слава Бже если отрисовать может.

Android Studio: не работает поиск в скрытых файлах.

ТС бы ещё на ripgrep пожаловались ;)

А что такое ripgrep?

Ну а поиск в самом деле как-то не доработаный. Если бы он искал в скрытых, я бы сразу понял как настраивается связка файлов в проекте. А так кучка времени было выкинуто.

Плюс неудобно отсутствие кнопки Отмена/закрыть. Если хочу закрыть окно поиска без передислокации, нужно искать куда бы ткнуть в основное окно или тянуться до эскейпа. И есть еще многолетняя привычка жать кнопку Отмена/Закрыть.

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

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

В общем мрак какой-то.

А что такое ripgrep?

Вас в поисковиках забанили?

Если бы он искал в скрытых

Скрытые файлы на то и скрытые, что в них лазить не положено ;) IDE же делаются для мышевозных хомячков, привыкших к Корзинам и Проводникам, которым чужды простые и дубовые rm/find/grep/etc., не спрашивающие подтверждений и не водящие за ручку ;)

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

А так кучка времени было выкинуто

И теперь всю жизнь за это дуться будете, да? ;)

или тянуться до эскейпа

Блондинко, что ли — клавиатуру отодвигаете подальше? ;)

это явно глюк какой-то

Глюк оконного менеджера, ага. Штудия тут при чём?

оно существенно заторможенно двигается с подвисаниями

Это нормально, IDE вообще жирные и тормозные. Страдайте, или переходите к нам в стан Ъ-юниксоидов ;)

Очень развернутый ответ для человека, который по его же словам эту систему даже не видел: «В Android Studio, поговаривают, виджеты на форму вообще мышкой накидываются в два счёта.»

IDE же делаются для мышевозных хомячков, привыкших к Корзинам и Проводникам, которым чужды простые и дубовые rm/find/grep/etc

Требование десятилетия. Поживу еще пару десятков лет, и все действия будут выполняться движением мысли. А некоторые так и будут Ъ-«rm/find/grep/etc». И хотя знания таких людей не оспоримо, но нужно двигаться дальше.

izzholtik: В андроиде всё работает на 70%, это нормально

Мне кажется это больше похоже на действительность.

который по его же словам эту систему даже не видел

А толку, IDEA видели, её сборочки все на одно лицо ;)

Требование десятилетия

Ну вообще-то мышевозня является как раз ретроградством, следствием майкрософтовской пропаганды ещё из 90-х (ибо M$ надо было втюхать мышевозную винду вместо текстового M$-DOS, и всячески очернить консоль в массовом сознании). Если Вы не заметили, то даже в мобильниках заменители мышки в виде трекпоинтов отмерли в пользу тачскринов, в то время как клавиатуры местами сохранились. А консольный софт активно развивается и пилится новый, вопреки скепсису промытых майкрософтом хомячков. Параллельно развиваются и консолеобразные интерфейсы для хомячков, типа IVR-ботов или ботов в мессенджерах.

IDE концептуально также являются приветом из однозадачного MS-DOS, где было околонереально использовать сразу много программ, поэтому все инструменты разработки запихивали в одну, в отличие от изначально многозадачных *NIX-систем, где это попросту не нужно. Более того, чуть менее чем все IDE сделаны на ретроградских технологиях из 00-х (Qt, .NET, SWT, Cocoa…); новые среды разработки делаются изначально модульно и с прицелом на Web и Mobile, монолитным IDE там места уже нет.

Мне кажется это больше похоже на действительность.

Да, но об Android речи нет, Вы же не на Android запускаете Android Studio? ;)

Они все сговорились. Сидели в нулевых и делали ретро-нулевые IDE. После сидели в 10 и делали ретро-10. Ну а лет через 20 будут ретро-мозговозные IDE. Они давно изыскивают пути атрофировать левые руки, ну а после и мозги всему человечеству.

После сидели в 10 и делали ретро-10

Не делали, а допиливали существующие. Хоть одну новую назовёте, которая появилась в 10-х и взлетела?

Нет, не назову. Хотя до этого казалось что Intellij была из таких. Я не сильно много лазил по разным IDE. Вы перечислили Qt и сказали что от нее веет нулевыми, так она и есть из нулевых.

Хотя сев за Intellij я был сильно удивлен качеству подсказок от IDE. У Qt Creator & C++ они на порядок хуже.

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

Следующим существенным шагом уже может быть только когда IDE будет угадывать что хочет разработчик и сама дописывать (мозговозность)). Т.е. по сути прогнозировать, пред-опережать действия разработчика.

Сейчас же она предлагает возможные варианты от того что какое действие произвел разработчик - синтаксис-помошники.

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

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

подсказок

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

которое зависит от предрасположенности конкретного человека, как ему удобней воспринимать информацию

Увы — нет, ибо во многих сферах использовать IDE фактически требуют.

некоторым было бы удобней чисто звуковая IDE, но такие по этой причине не идут в программисты

Да вполне себе есть программисты-инвалиды, слепые и безрукие.

Да вполне себе есть программисты-инвалиды, слепые и безрукие.

Что-то вас на крайности тянет. Нельзя все делить на черное и белое. Ну или можно. По желанию.

Предиктивные системы типа этих ваших T9, Swype…

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

Текущие механизмы могут предугадать ~50% действий, и начинают об это радостно возглашать отвлекая от процесса, вставляя палки на каждое второе действие. А вот если оно будет предугадывать 99%, то это будет существенная экономия на движениях пальчиков…

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

Что-то вас на крайности тянет

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

потому что текущие систем крайне плохо могут предугадывать действия

Когда научатся предугадывать идеально — прокладка между стулом и монитором станет не нужна.

А вот если оно будет предугадывать 99%, то это будет существенная экономия на движениях пальчиков…

До тех пор, когда оно незаметно что-то не нафакапит, ага.