Почему UI программирует таким образом трудоемкий, и что можно сделать для смягчения этого? [закрытый]
Это немного выходит за рамки оригинального дизайна каркаса. Но я бы еще больше усомнился в вашей архитектуре. , , Если вы действительно хотите подписаться на неограниченное количество направлений, мне интересно, почему? Каковы основные бизнес-требования?
Имейте в виду, что даже если бы мы делали это как-то, это потребовало бы динамического создания контейнера слушателя сообщений для каждого нового пункта назначения, что вызвало бы больше вопросов, таких как, как долго этот контейнер должен жить с тех пор в конце концов у вас закончатся ресурсы.
Если, однако, вы просто спрашиваете о возможности отображения нескольких адресатов в один канал, чтобы все сообщения отправлялись в один и тот же обработчик сообщений (например, StreamListener), тогда вы можете просто использовать свойство input destination и определить несколько разделителей, разделенных адресатом. комами.
10 ответов
Разработка пользовательского интерфейса отнимает много времени и подвержена ошибкам, поскольку включает в себя дизайн . Не только визуальный или звуковой дизайн, но, что более важно, интерактивный дизайн. Хороший API всегда нейтрален в отношении модели взаимодействия, то есть он накладывает минимальные ограничения на фактический рабочий процесс, локализацию и представление информации. Основной движущей силой этого является инкапсуляция и повторное использование кода.
В результате невозможно извлечь достаточно информации из одного API, чтобы создать хороший пользовательский интерфейс, адаптированный к конкретному случаю использования API.
Однако существуют генераторы пользовательского интерфейса, которые обычно создают экраны CRUD на основе заданного API. Само собой разумеется, что такие сгенерированные пользовательские интерфейсы не очень подходят для частых пользователей, которым требуется более высокая эффективность пользовательского интерфейса, и при этом они не особенно просты в изучении в случае более крупной системы, поскольку они не очень хорошо передают образ системы или последовательность взаимодействия.
Создание хорошего пользовательского интерфейса требует больших усилий, потому что его нужно разрабатывать в соответствии с конкретными потребностями пользователей, а не из-за какой-то приземленной задачи преобразования API-интерфейса, которая может быть полностью автоматизирована.
Чтобы ускорить процесс создания пользовательского интерфейса и снизить риски, можно предложить либо привлечь специалистов по пользовательскому интерфейсу, либо узнать больше о работе самостоятельно. К сожалению, нет, так сказать, ни ярлыка, ни волшебной палочки, которая создаст качественный интерфейс, полностью основанный и только на API, без большого количества дополнительной информации и анализа.
Пожалуйста, посмотрите также отличный вопрос: « Почему хороший дизайн пользовательского интерфейса так труден для некоторых разработчиков ?» у него есть очень проницательные и ценные ответы, в частности:
Бесстыдная заглушка для моего собственного ответа .
Великолепный ответ Карла Фаста.
Я не верю, что программирование пользовательского интерфейса занимает больше времени, чем любой другой вид программирования, и при этом оно не более подвержено ошибкам , Однако ошибки в пользовательском интерфейсе часто более очевидны. Обнаружение ошибки в компиляторе часто намного сложнее.
Одно четкое различие между программированием пользовательского интерфейса заключается в том, что у вас есть человек на другом конце, а не другая программа, что очень часто бывает, когда вы пишете компиляторы парсеры протоколов, отладчики и другой код, который общается с другими программами и компьютерами. Это означает, что сущность, с которой вы общаетесь, не очень точно определена и может вести себя очень хаотично.
РЕДАКТИРОВАТЬ: «непредсказуемый», вероятно, более подходящий термин. / Jesper
Ваш вопрос о преобразовании API в пользовательский интерфейс просто не имеет смысла для меня.
Похоже, вы ищете архитектурный паттерн «Голые объекты». Доступны различные реализации.
Я не предоставляю решения, но я попытаюсь ответить на вопрос «почему».
Так что я говорю не за всех, но, по крайней мере, за себя, я считаю, что одной из причин является то, что программисты склонны больше концентрироваться на функциональности так что юзабилити и они, как правило, не слишком художественные. Я думаю, что они просто имеют другой тип творчества. Я считаю, что на создание правильной графики у меня уходит много времени, по сравнению с тем, сколько времени у меня уходит на написание кода (хотя, по большей части, я не делал ни одного проекта со слишком большим количеством графических требований).
Автоматическая генерация пользовательских интерфейсов может быть до некоторой степени возможной, поскольку она может генерировать элементы управления для требуемого ввода и вывода данные. Но дизайн пользовательского интерфейса гораздо сложнее, чем просто поместить необходимые элементы управления на экран. Для создания удобного в использовании пользовательского интерфейса необходимо объединить знания из таких дисциплин, как графический дизайн, эргономика, психология и т. Д. Есть причина, по которой взаимодействие человека с компьютером становится самостоятельной дисциплиной: создание достойного пользовательского интерфейса не является тривиальным.
Так что я не думаю, что есть реальное решение вашей проблемы. Дизайн пользовательского интерфейса - сложная задача, для выполнения которой требуется время. Единственная область, где относительно легко выиграть некоторое время, - это инструменты: если у вас есть мощные инструменты для реализации дизайна пользовательского интерфейса, Вам не нужно вручную кодировать каждый пиксель пользовательского интерфейса.
, если вы уже знаете или могли бы научиться использовать Ruby on Rails , ActiveScaffold отлично подходит для этого.
Одна из причин заключается в том, что у нас нет хорошо разработанного шаблона для UTDD - User Test Driven Development. Также я не видел много хороших примеров сопоставления пользовательских историй с юнит-тестами. Почему, например, так мало учебников обсуждают истории пользователей?
You are absolutely correct when you say that UI is time consuming, costly and error prone!
A great compromise I have found is as follows...
I realized that a lot of data (if not most) can be presented using a simple table (such as a JTable), rather than continuously try to create custom panels and fancy GUI's. It doesn't seem obvious at first, but it's quite decent, usable and visually appealing.
Why is it so fast? Because I was able to create a reusable framework which can accept a collection of concrete models and with little to no effort can render all these models within the table. So much code-reuse, its unbelievable.
By adding a toolbar above the window, my framework can add to, remove from or edit entries in the table. Using the full power of JTables, I can hide (by filtering) and sort as needed by extending various classes (but only if/when this is required).
I find myself reusing a heck of a lot of code every time I want to display and manage new models. I make extensive use of icons (per column, rows or cells, etc) to beautify the screens. I use large icons as a window header to make each screen 'appear' different and appealing and it always looks like new and different screens, but its always the same code behind them.
A lot of work and effort was required at first to do the framework, but now its paying off big time.
I can write the GUI for an entirely new application with as many as 30 to 50 different models, consisting of as many screens in a fraction of the time it would take me using the 'custom UI method'.
I would recommend you evaluate and explore this approach!
ASP.NET Dynamic Data is something that you should investigate. It meets most, if not all your requirements
Это сложно, потому что большинство пользователей / клиентов глупы и не могут мыслить прямо! :) Это отнимает много времени, потому что разработчики / дизайнеры пользовательского интерфейса настолько навязчивы! :)