Комментарии 20
У вас же на Qt все, перестал устраивать?
Приветствую.
Написали кодогенератор, который позволяет вызывать C++ код напрямую из Dart с помощью FFI. Благодаря этому кодогенерируемое API полностью аналогично iOS и Android Mobile SDK
Такой вопрос. А проще путь если: клиент-сервер, клиент на Dart, сервер C++, обмен данными не обязательно через сокет, если быстрее надо можно пайпы использовать или шару. Чем такой вариант хуже?
Привет. Я так понимаю, что идея заключается в локальном развертывании клиент-серверного приложения. Теперь по порядку.
При клиент-серверном взаимодействии данные передаются в виде, например, JSON. Сериализовать/десериализовать данные в JSON и обратно - явно будет медленнее, чем через FFI. Да, можно использовать protobuf, но тоже не уверен, что будет сильно производительнее JSON и точно хуже FFI.
Поддержка и использование API пользователями нашего SDK будет сложнее. Сейчас пользователь может подписаться на CancelableOperation и получить в callback готовый для использования тип. Или передать класс в наш API. А так придется еще и через JSON/protobuf все это прогонять.
И ты имеешь ввиду, что проще - это не нужен кодогенератор? Ну при подходе в клиент-серверном взаимодействии нужно реализовать сериализаторы/десериализаторы. Плюс, кодогенератор один раз написали и все, он на CI работает и генерирует сборки.
Генератор бывает надо докручивать, и мало кто туда лезет это делать. В общем, сложно выглядит в поддержке с обоих сторон получается, и у вас и у юзера.
Генератор - это наш внутренний продукт, недоступный для внешнего пользователя. Генерируемый файл мы поставляем вместе с FlutterSDk.
Да, из за того, что политика flutter требует предоставление всех dart исходников, получается, что сгенерированный файл мы выставляем наружу. Но пользователь сам себе выстрелит в ногу, если что-то там сломает))
JSON только если для команд и метаданных, а обновленную карту из 3D движка прямо так и передавать в бинарном виде. Сериализация нужна будет, да, protobuf подойдет, но можно и самим написать не хитрый протокол, типа: в начале метаинфо в json, затем бинарные данные, если есть.
Мне вот кажется наоборот у вас сейчас АПИ для юзера довольно сложное получилось, вы его в свои классы загоняете, которые создавать надо с помощью генератора.
Если клиент-сервер не хочется делать, то можно и либу оставить как сейчас, только интерфейс ей проще сделать - как выше написал, JSON для метаданных, и бинарник для карты.
Так у нас же не просто отображение карты. Наш продукт позволяет задавать перелеты и сложные алгоритмы для изменения параметров камеры во время слежения. Отслеживание разных параметров камеры.
У нас есть справочник со большим объемом данных и вложенными структурами.
Навигатор позволяет в реальном времени получать данные об оставшемся маршруте, о текущей скорости, потери GPS и прочим.
Для всех выше указанных и множества других сценариев постоянно гонять protobuf - накладно.
>его в свои классы загоняете, которые создавать надо с помощью генератора.
Самому пользователю ничего создавать не нужно) Готовые Dart классы и методы уже доступны из коробки вместе с дефолтными UI виджетами.
Для пользователя protobuf мбыть не всем удобен, да. (но протобуф быстре парсить есст-но, чем json, но это мелочь все).
Вот что имею ввиду, если json-ом пусть пользоваться (на самом деле любым можно текст протоколом, без разницы):
имеем в "С" апи такую ф-ю:
BOOL setParam(int ptype, char* jsonVal);
и для валидации json пусть ф-ю, пригодится чтобы проверить апи на изменение в будущем
BOOL checkParamValid(int ptype, char* jsonVal);
< задавать перелеты и сложные алгоритмы для изменения параметров камеры во время слежения:
setParam(CAM_TANG, "{"deg": 2, "posA": 1234, "posB" : 567...}");
Пользователю давать эти ф-ии в руки, а не сгенерирован классы, и он будет доволен.
Еще BSON как вариант использовать, если у вас там прямо большие стр-ры данных передваться будут.
Плюс такого интр-са С-го простого, что можно его в любых языках использовать один и тот же, не надо ничего городить для каждого языка. Пусть юзер сам себе городит сверху что-то, если надо ему.
Ты сейчас рассматриваешь простой кейс - задать позицию камеры.
У нас есть метод Camera.move, который возвращает CancelableOperation с сигналом о том, что перелет камеры завершен. Или у нас есть канал positionChannel, который Stream и возвращает данные об изменении позиции камеры.
С этим как быть? Слушать конкретные сокеты?
Также у нас еще есть функционал с передачей платформенной реализации какого-то абстрактного класса - то же сложное задание слежения за позицией или углом наклона.
>Пусть юзер сам себе городит сверху что-то, если надо ему.
Цель то наша как раз и создать максимально удобный API, чтобы пользователю не нужно ничего "городить", а у него было бы максимально доступный и удобный набор ручек.
В поддержку нашего подхода скажу, что наши конкуренты также используют платформенное API над C++ кодом.
По твоему подходу следует, что ты предлагаешь заменишь наши типизированные классы на JSON/protobuf и тд. Но это лишь малая часть наших "проблем", которые решает кодогенератор.
Самая "мясная" часть кодогенератора связана с передачей CancelableOperation и Stream, с заданием реализации конкретного абстрактного класса.
И у нас кодогенератор еще позволяет генерировать именно платформенные сущности конкретного языка. Dart разработчикам удобно работать с CancelableOperation и Stream, потому что это все часть Dart.
В Swift и Kotlin у нас такой же подход - использовать по максимуму возможности платформенного языка.
Нативная мощь: Flutter SDK на C++ ядре. Часть 2