Комментарии 29
Очень хорошая и нужная штука. Уже вижу потенциальные возможности применения по работе. Я со своей стороны проголосую за улучшенный UI (особенно интересует возможность передачи изображений) и за поддержку специфических функций клиентского устройства.
Заодно интересует и возможность надёжной идентификации/авторизации пользователей.
Заодно интересует и возможность надёжной идентификации/авторизации пользователей.
Изображения и авторизация — две вещи, которые крутятся у меня в голове, но пока я не решил, как лучше их реализовывать в библиотеке с архитектурной точки зрения.
Основное требование, которого я придерживаюсь при написании библиотеки — её легковесность и кросплатформенность. Именно поэтому весь сетевой код вынесен в отдельное пространство имён, которое необязательно для использования. Для авторизации и шифрования скорее всего придётся использовать внешние библиотеки, что может поставить под вопрос кросплатформенность.
С изображениями немного попроще — передать картинки на клиентское устройство можно средствами операционной системы (отправить URL картинки клиенту, который сам её скачает). Это, конечно, урезанный вариант, но, как мне кажется, большую долю use-кейсов он покроет.
Идентификация клиентских устройств в базовом виде есть уже сейчас. Во время инициации соединения первый пакет данных отправляется от клиента к серверу. В этом пакете есть строковый параметр — deviceID, который можно использовать в качестве идентификатора устройства.
В С++ коде эти данные доступны в параметре коллбэка:
Основное требование, которого я придерживаюсь при написании библиотеки — её легковесность и кросплатформенность. Именно поэтому весь сетевой код вынесен в отдельное пространство имён, которое необязательно для использования. Для авторизации и шифрования скорее всего придётся использовать внешние библиотеки, что может поставить под вопрос кросплатформенность.
С изображениями немного попроще — передать картинки на клиентское устройство можно средствами операционной системы (отправить URL картинки клиенту, который сам её скачает). Это, конечно, урезанный вариант, но, как мне кажется, большую долю use-кейсов он покроет.
Идентификация клиентских устройств в базовом виде есть уже сейчас. Во время инициации соединения первый пакет данных отправляется от клиента к серверу. В этом пакете есть строковый параметр — deviceID, который можно использовать в качестве идентификатора устройства.
В С++ коде эти данные доступны в параметре коллбэка:
void packetReceived_clientDeviceInfo(
tau::communications_handling::ClientDeviceInfo const & info)
По поводу изображений — я имел в виду картинки, генерируемые самим приложением-сервером. Например, регулярно обновляемый background с красивыми индикаторами состояния или даже какая-то 3D-визуализация.
А вот для серьёзной авторизации «как у взрослых дядь», видимо, понадобится в светлом, но отдалённом будущем реализовать какой-то протокол с обеих сторон, рассмотреть способы генерации и защиты идентификационных данных и всё такое. Сложная тема.
А вот для серьёзной авторизации «как у взрослых дядь», видимо, понадобится в светлом, но отдалённом будущем реализовать какой-то протокол с обеих сторон, рассмотреть способы генерации и защиты идентификационных данных и всё такое. Сложная тема.
С рисованием на серверной стороне есть несколько вариантов реализации.
Мне пока что из них больше всего нравится третий вариант.
- Рисовать картинку на сервере и отправлять полученный в результате bitmap на клиент. Этот подход проще в реализации, но усложняет пользовательский код. Необходимо на пользовательской стороне иметь возможность генерировать битмапки, что неизбежно потребует дополнительных усилий и/или добавит зависимостей.
- Рисовать напрямую на клиенте. Это можно сделать пересылая все команды рисования по сети и воспроизводя эти команды на клиенте. На клиентской стороне в UI будет элемент типа Canvas, на котором будут воспроизводиться все операции. Проблема тут в том, что такие объекты имеют очень богатый интерфейс рисования, который необходимо будет переносить в С++ библиотеку. Кроме того, Canvas-объекты различаются на разных платформах, поэтому, если будут добавляться клиенты для других платформ, возникнет проблема унификации отображаемого изображения.
- Компромисом между предыдущими двумя вариантами может быть использование svg изображений для таких задач. Поскольку svg открытый текстовый формат, его должно быть довольно легко как генерировать на пользовательской стороне, так и отображать на клиентской. При этом, если пользователю нужно отображать довольно ограниченное множество изображений, то он сможет обойтись без использования внешних библиотек (достаточно иметь базовый шаблон изображения, из которого можно делать конечные svg объекты). Стандартизация svg должна позволить отображать изображения на клиенте одинаково на всех платформах.
Мне пока что из них больше всего нравится третий вариант.
Мне это представлялось как один или несколько элементов управления на стороне клиента, способных отображать переданные сервером битмапы (в общем смысле, необязательно именно BMP): background, image box, button… В конце концов, если серверу так приспичило отображать свои картинки, он и битмап сгенерирует и ничего страшного с ним не случится. А если там 3D, так и совсем просто.
Возможность загружать svg тоже ценная и полезная возможность, но в моём-то случае нужны именно битмапы.
Возможность загружать svg тоже ценная и полезная возможность, но в моём-то случае нужны именно битмапы.
Вообще, наверно вы правы. Функциональность, позволяющая отправлять с сервера на клиент битмапы не усложняет работу с библиотекой тем пользователям, которым это не нужно. А те, кому эта функциональность необходима, сами решат, как генерировать битмапы на их стороне.
Про 3D не совсем понял. Вы имеете ввиду рендеринг 3D сцены в буфер в памяти и отправку этого буфера как картинки на клиент?
Про 3D не совсем понял. Вы имеете ввиду рендеринг 3D сцены в буфер в памяти и отправку этого буфера как картинки на клиент?
На лету менять лейауты можно? При этом интерфейс как себя поведёт? Исходники андроид приложения не нашёл.
- сейчас зависит от TAU. насколько быстро будет оно развиваться?
- заюзать для клиента Qt/QML:
- готовые контролы (шрифты, цвета, стили)
- встроенная сетевая либка: QTcp-/Udp-/Ssl-/WebSocket...
- формы выглядят как QML-скрипты (или в каком-то ином виде скриптов), которые можно распарсить или сгенерировать
- встроенные скрипты и обработчики — валидация/маски инпута на клиенте, а не отправка каждого изменения текстового поля на сервер
- с кодогенерацией будет совсем хорошо: есть "скриптовое" описание UI с логикой работы, на основе него можно сгенерить/cбилдять/присобачить и код для сервера с JITом — C++/CLang/Qt(нет проблем с сериализацией), C#/Roslyn (по мне, он менее монструозный, чем CLang, но будут вопросы с сериализацией из/в Qt-клиент) и код для клиента — QML.
Перенос логики на клиентское устройство — противоположный подход к данной проблеме. Он позволяет гораздо серьёзнее кастомизовать клиентскую часть.
Проблемой с моей точки зрения является то, что при этом на клиенте возникает сложное состояние, которое надо синхронизировать с сервером. Это серьёзно усложнит серверную часть библиотеки (а также добавит зависимостей в клиентском коде), чего мне хотелось избежать. Кроме того, возникает вопрос отладки скриптов клиентской части, что может тоже оказаться проблематичным.
Проблемой с моей точки зрения является то, что при этом на клиенте возникает сложное состояние, которое надо синхронизировать с сервером. Это серьёзно усложнит серверную часть библиотеки (а также добавит зависимостей в клиентском коде), чего мне хотелось избежать. Кроме того, возникает вопрос отладки скриптов клиентской части, что может тоже оказаться проблематичным.
есть еще "конкурент": UbiqMobile
Возможно в 80% случаев будет проще настроить HTML server и сделать билд HTML страниц, а на андроиде/ios/другой комп и т.д.
грузить эти страницы?
грузить эти страницы?
Поднятие web-сервера внутри пользовательского приложения это альтернативный подход, который очень часто используется. Вот хороший пример этого подхода. Однако, зачастую, это серьёзное усложнение с точки зрения пользовательского кода.
Данную систему лучше всего рассматривать как средство пользовательского ввода/вывода: основная её функция — передавать команды и данные от клиента серверу, отображать информацию для клиента.
Данную систему лучше всего рассматривать как средство пользовательского ввода/вывода: основная её функция — передавать команды и данные от клиента серверу, отображать информацию для клиента.
Вы можете написать конвертер, который будет принимать примерно такие же параметры, иметь примерно такой же API, как вы привыкли, но генерировать HTML.
И это будет много лучше, потому что будет работать и на desktop системах, и на Android'е и на iOS и на других ХренаксОС, которые появятся/прибавят в популярности.
И это будет много лучше, потому что будет работать и на desktop системах, и на Android'е и на iOS и на других ХренаксОС, которые появятся/прибавят в популярности.
Добавить поддержку последовательного интерфейса (через USB), поддержку стандартного протокола и получится HMI клиент.
Использовать стандартный протокол WebSocket (или даже WAMP) и стандартную сериализацию json/msgpack/protobuf по вкусу.
Это упростит «добавление серверных библиотек для других языков программирования» и с авторизацией и шифрованием сразу понятно будет что делать.
Про HTML уже написали (можно генерировать HTML код если так хочется писать только на c++)
Это упростит «добавление серверных библиотек для других языков программирования» и с авторизацией и шифрованием сразу понятно будет что делать.
Про HTML уже написали (можно генерировать HTML код если так хочется писать только на c++)
кажется автор picoLisp сейчас доделывает нечто подобное — универсальный UI для Андроида, на серверной стороне лисп (работает на множестве posix-систем)
Господа, я покорно прошу прощения.
Но этот подход уже 13 лет как используется мной в проекте Glan (Известен также как Kalpa.Cloud). ( http://www.slideshare.net/olegshalnev/kalpa-doklad )
Система была (в рабочем виде) показана в 2005 году. В 2010 получила специальный приз за лучший свободный проект.
glan много лет используется для разработки различных приложений, в том числе и зарубежными группами. Мой продукт был изначально кроссплатформенен и поддерживает все коммерчески значимые системы.
Правда автору новой разработки придется столкнуться с известным противодействием. Ох как же убедительно мне доказывали на RSDN мою неправоту, как убедительно бросались в меня различными субстанциями, как доказывали, что web — всему голова.
Сейчас мой проект выведен из Open Source (по требованию партнеров) и используется как технологическая платформа для создания семейства коммерческих продуктов.
В любом случае, я благодарю taco_attaco за его разработки, за смелость искать нетрадиционные пути.
Но этот подход уже 13 лет как используется мной в проекте Glan (Известен также как Kalpa.Cloud). ( http://www.slideshare.net/olegshalnev/kalpa-doklad )
Система была (в рабочем виде) показана в 2005 году. В 2010 получила специальный приз за лучший свободный проект.
glan много лет используется для разработки различных приложений, в том числе и зарубежными группами. Мой продукт был изначально кроссплатформенен и поддерживает все коммерчески значимые системы.
Правда автору новой разработки придется столкнуться с известным противодействием. Ох как же убедительно мне доказывали на RSDN мою неправоту, как убедительно бросались в меня различными субстанциями, как доказывали, что web — всему голова.
Сейчас мой проект выведен из Open Source (по требованию партнеров) и используется как технологическая платформа для создания семейства коммерческих продуктов.
В любом случае, я благодарю taco_attaco за его разработки, за смелость искать нетрадиционные пути.
пардон не проснулся
Спасибо за слова поддержки.
Одной из мотиваций к написанию мной данной статьи была возможность получить информацию об уже существующих системах с аналогичным подходом.
Философия вашего проекта, насколько я могу судить, схожа с моей — позволить пользователю максимально абстрагироваться от сетевой инфраструктуры и писать свою программу так, как будто это обычное десктопное приложение с UI.
Одной из мотиваций к написанию мной данной статьи была возможность получить информацию об уже существующих системах с аналогичным подходом.
Философия вашего проекта, насколько я могу судить, схожа с моей — позволить пользователю максимально абстрагироваться от сетевой инфраструктуры и писать свою программу так, как будто это обычное десктопное приложение с UI.
Да. Именно потому я попытался максимально приблизить API к Qt, чтобы дать возможность разработчику максимально использовать свой опыт разработки standalone приложений в деле создания сетевых без переучивания и освоения новых технологий и новых подходов.
Сторонюсь подхода QML(XUL) основанного на декларативном описании интерфейса. На стороне сервера такой подход возможен, но для генерации интерфейса необходимо использовать атомарные сигналы. Это позволяет крайне динамично и легко управлять сценой на стороне клиента. Интерфейс описанный в «жесткой форме» такой гибкости лишен.
И конечно подход позволил работать не только с пользовательским интерфейсом, но взаимодействовать (например) с аппаратной частью стереотипно, в том числе и асинхронно.
Сторонюсь подхода QML(XUL) основанного на декларативном описании интерфейса. На стороне сервера такой подход возможен, но для генерации интерфейса необходимо использовать атомарные сигналы. Это позволяет крайне динамично и легко управлять сценой на стороне клиента. Интерфейс описанный в «жесткой форме» такой гибкости лишен.
И конечно подход позволил работать не только с пользовательским интерфейсом, но взаимодействовать (например) с аппаратной частью стереотипно, в том числе и асинхронно.
По части генерации интерфейса множеством атомарных сигналов, я опасался, что этот подход приведёт к тому, что будет тяжело на серверной стороне поддерживать актуальное представление состояния на клиенте. Что, в свою очередь, усложняет дальнейшие изменения сцены на клиенте.
Не возникает ли у вас такая проблема?
Не возникает ли у вас такая проблема?
По сути это всё свои реализации xterm'а.
У нас аналогичный подход используется с 2002-2004 года.
Представляя полный объем работы и все сложности, которые встретит автор, могу только пожелать удачи и стойкости.
У нас аналогичный подход используется с 2002-2004 года.
Представляя полный объем работы и все сложности, которые встретит автор, могу только пожелать удачи и стойкости.
Спасибо, в общем подход понравился. Особенно сопряжение с C++ c помощью asio, который я очень часто использую.
Из предложенных направлений дальнейшего развития я бы проголовал в первую очередь за:
- поддержка более специфичных функций клиентского устройства (notifications, sensors, volume buttons, e.t.c)
- более глубокая кастомизация внешнего вида элементов на клиенте (цвета, шрифты, стили)
- добавление новых UI элементов (drop-down boxes, images, e.t.c)
Кроме того, думаю, что необходима аутентификация не сервере. Да и использование TLS соединения не помешало бы (на asio это легко реализуемо).
Что не понравилось, это "ручное" создание layout к коде на сервере. Лично для меня было бы идеальным использование визуального конструктора наподобие Glade. Руками на С++ я бы разве что binding-у с контролами согласился бы помочь только.
По-моему, основная проблема с «ручным» созданием layout — отсутствие документации. Я надеюсь, что после её добавления, будет проще в этом разобраться. Конечно, графический конструктор более интуитивен, но пока что для меня он не в приоритете.
Спасибо, что обратили моё внимание на сенсоры. Возможно, реализация доступа к сенсорам устройства — одна из самых важных фич подобных систем сопряжения телефона с компьютером.
Спасибо, что обратили моё внимание на сенсоры. Возможно, реализация доступа к сенсорам устройства — одна из самых важных фич подобных систем сопряжения телефона с компьютером.
Не могу говорить за всех, но для меня лично "ручное" описание layout — самая скучная и неприятная операция независимо от наличия документации.
И я не предлагаю Вам создавать граф-й редактор с нуля, но, возможно, стоит использовать результаты Glade, разумеется с какими-то ограничениями. Там довольно простой XML на выходе… Возможно, если Ваш проект будет востребован, кто-то другой напишет такой загрузчик layout из внешнего файла.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование Android устройства в качестве тонкого UI для С++ программ