С рисованием на серверной стороне есть несколько вариантов реализации.
Рисовать картинку на сервере и отправлять полученный в результате bitmap на клиент. Этот подход проще в реализации, но усложняет пользовательский код. Необходимо на пользовательской стороне иметь возможность генерировать битмапки, что неизбежно потребует дополнительных усилий и/или добавит зависимостей.
Рисовать напрямую на клиенте. Это можно сделать пересылая все команды рисования по сети и воспроизводя эти команды на клиенте. На клиентской стороне в UI будет элемент типа Canvas, на котором будут воспроизводиться все операции. Проблема тут в том, что такие объекты имеют очень богатый интерфейс рисования, который необходимо будет переносить в С++ библиотеку. Кроме того, Canvas-объекты различаются на разных платформах, поэтому, если будут добавляться клиенты для других платформ, возникнет проблема унификации отображаемого изображения.
Компромисом между предыдущими двумя вариантами может быть использование svg изображений для таких задач. Поскольку svg открытый текстовый формат, его должно быть довольно легко как генерировать на пользовательской стороне, так и отображать на клиентской. При этом, если пользователю нужно отображать довольно ограниченное множество изображений, то он сможет обойтись без использования внешних библиотек (достаточно иметь базовый шаблон изображения, из которого можно делать конечные svg объекты). Стандартизация svg должна позволить отображать изображения на клиенте одинаково на всех платформах.
Мне пока что из них больше всего нравится третий вариант.
Поднятие web-сервера внутри пользовательского приложения это альтернативный подход, который очень часто используется. Вот хороший пример этого подхода. Однако, зачастую, это серьёзное усложнение с точки зрения пользовательского кода.
Данную систему лучше всего рассматривать как средство пользовательского ввода/вывода: основная её функция — передавать команды и данные от клиента серверу, отображать информацию для клиента.
Перенос логики на клиентское устройство — противоположный подход к данной проблеме. Он позволяет гораздо серьёзнее кастомизовать клиентскую часть.
Проблемой с моей точки зрения является то, что при этом на клиенте возникает сложное состояние, которое надо синхронизировать с сервером. Это серьёзно усложнит серверную часть библиотеки (а также добавит зависимостей в клиентском коде), чего мне хотелось избежать. Кроме того, возникает вопрос отладки скриптов клиентской части, что может тоже оказаться проблематичным.
Да, лэйауты можно менять в любой момент. При этом старый лэйаут просто заменяется на новый. Поскольку у клиента практически нет своего состояния, это можно делать без особых проблем.
Исходники приложения для андроид я пока публиковать не собирался.
Изображения и авторизация — две вещи, которые крутятся у меня в голове, но пока я не решил, как лучше их реализовывать в библиотеке с архитектурной точки зрения.
Основное требование, которого я придерживаюсь при написании библиотеки — её легковесность и кросплатформенность. Именно поэтому весь сетевой код вынесен в отдельное пространство имён, которое необязательно для использования. Для авторизации и шифрования скорее всего придётся использовать внешние библиотеки, что может поставить под вопрос кросплатформенность.
С изображениями немного попроще — передать картинки на клиентское устройство можно средствами операционной системы (отправить URL картинки клиенту, который сам её скачает). Это, конечно, урезанный вариант, но, как мне кажется, большую долю use-кейсов он покроет.
Идентификация клиентских устройств в базовом виде есть уже сейчас. Во время инициации соединения первый пакет данных отправляется от клиента к серверу. В этом пакете есть строковый параметр — deviceID, который можно использовать в качестве идентификатора устройства.
В С++ коде эти данные доступны в параметре коллбэка:
Мне пока что из них больше всего нравится третий вариант.
Данную систему лучше всего рассматривать как средство пользовательского ввода/вывода: основная её функция — передавать команды и данные от клиента серверу, отображать информацию для клиента.
Проблемой с моей точки зрения является то, что при этом на клиенте возникает сложное состояние, которое надо синхронизировать с сервером. Это серьёзно усложнит серверную часть библиотеки (а также добавит зависимостей в клиентском коде), чего мне хотелось избежать. Кроме того, возникает вопрос отладки скриптов клиентской части, что может тоже оказаться проблематичным.
Исходники приложения для андроид я пока публиковать не собирался.
Основное требование, которого я придерживаюсь при написании библиотеки — её легковесность и кросплатформенность. Именно поэтому весь сетевой код вынесен в отдельное пространство имён, которое необязательно для использования. Для авторизации и шифрования скорее всего придётся использовать внешние библиотеки, что может поставить под вопрос кросплатформенность.
С изображениями немного попроще — передать картинки на клиентское устройство можно средствами операционной системы (отправить URL картинки клиенту, который сам её скачает). Это, конечно, урезанный вариант, но, как мне кажется, большую долю use-кейсов он покроет.
Идентификация клиентских устройств в базовом виде есть уже сейчас. Во время инициации соединения первый пакет данных отправляется от клиента к серверу. В этом пакете есть строковый параметр — deviceID, который можно использовать в качестве идентификатора устройства.
В С++ коде эти данные доступны в параметре коллбэка: