Я выше писал - у нас кодогенератор один раз написан, а дальше при изменении C++ кода генерирует весь платформенный код. Так что в этом плане поддержка достаточно удобная идет.
По твоему подходу следует, что ты предлагаешь заменишь наши типизированные классы на JSON/protobuf и тд. Но это лишь малая часть наших "проблем", которые решает кодогенератор. Самая "мясная" часть кодогенератора связана с передачей CancelableOperation и Stream, с заданием реализации конкретного абстрактного класса.
И у нас кодогенератор еще позволяет генерировать именно платформенные сущности конкретного языка. Dart разработчикам удобно работать с CancelableOperation и Stream, потому что это все часть Dart. В Swift и Kotlin у нас такой же подход - использовать по максимуму возможности платформенного языка.
>Пусть юзер сам себе городит сверху что-то, если надо ему.
Цель то наша как раз и создать максимально удобный API, чтобы пользователю не нужно ничего "городить", а у него было бы максимально доступный и удобный набор ручек.
В поддержку нашего подхода скажу, что наши конкуренты также используют платформенное API над C++ кодом.
Ты сейчас рассматриваешь простой кейс - задать позицию камеры. У нас есть метод Camera.move, который возвращает CancelableOperation с сигналом о том, что перелет камеры завершен. Или у нас есть канал positionChannel, который Stream и возвращает данные об изменении позиции камеры. С этим как быть? Слушать конкретные сокеты? Также у нас еще есть функционал с передачей платформенной реализации какого-то абстрактного класса - то же сложное задание слежения за позицией или углом наклона.
Так у нас же не просто отображение карты. Наш продукт позволяет задавать перелеты и сложные алгоритмы для изменения параметров камеры во время слежения. Отслеживание разных параметров камеры. У нас есть справочник со большим объемом данных и вложенными структурами. Навигатор позволяет в реальном времени получать данные об оставшемся маршруте, о текущей скорости, потери GPS и прочим.
Для всех выше указанных и множества других сценариев постоянно гонять protobuf - накладно.
Генератор - это наш внутренний продукт, недоступный для внешнего пользователя. Генерируемый файл мы поставляем вместе с FlutterSDk. Да, из за того, что политика flutter требует предоставление всех dart исходников, получается, что сгенерированный файл мы выставляем наружу. Но пользователь сам себе выстрелит в ногу, если что-то там сломает))
И ты имеешь ввиду, что проще - это не нужен кодогенератор? Ну при подходе в клиент-серверном взаимодействии нужно реализовать сериализаторы/десериализаторы. Плюс, кодогенератор один раз написали и все, он на CI работает и генерирует сборки.
Привет. Я так понимаю, что идея заключается в локальном развертывании клиент-серверного приложения. Теперь по порядку.
При клиент-серверном взаимодействии данные передаются в виде, например, JSON. Сериализовать/десериализовать данные в JSON и обратно - явно будет медленнее, чем через FFI. Да, можно использовать protobuf, но тоже не уверен, что будет сильно производительнее JSON и точно хуже FFI.
Поддержка и использование API пользователями нашего SDK будет сложнее. Сейчас пользователь может подписаться на CancelableOperation и получить в callback готовый для использования тип. Или передать класс в наш API. А так придется еще и через JSON/protobuf все это прогонять.
Это остается нашим тех долгом, да. Отпишусь сюда, когда реализуем, плюс в статье update сделаем.
Я выше писал - у нас кодогенератор один раз написан, а дальше при изменении C++ кода генерирует весь платформенный код. Так что в этом плане поддержка достаточно удобная идет.
А что в этом плохого?) По опыту внедрения SDK - разрабам не особо нужна свобода, а нужно удобство использования, набор инструментов и функционала.
По твоему подходу следует, что ты предлагаешь заменишь наши типизированные классы на JSON/protobuf и тд. Но это лишь малая часть наших "проблем", которые решает кодогенератор.
Самая "мясная" часть кодогенератора связана с передачей CancelableOperation и Stream, с заданием реализации конкретного абстрактного класса.
И у нас кодогенератор еще позволяет генерировать именно платформенные сущности конкретного языка. Dart разработчикам удобно работать с CancelableOperation и Stream, потому что это все часть Dart.
В Swift и Kotlin у нас такой же подход - использовать по максимуму возможности платформенного языка.
>Пусть юзер сам себе городит сверху что-то, если надо ему.
Цель то наша как раз и создать максимально удобный API, чтобы пользователю не нужно ничего "городить", а у него было бы максимально доступный и удобный набор ручек.
В поддержку нашего подхода скажу, что наши конкуренты также используют платформенное API над C++ кодом.
Ты сейчас рассматриваешь простой кейс - задать позицию камеры.
У нас есть метод Camera.move, который возвращает CancelableOperation с сигналом о том, что перелет камеры завершен. Или у нас есть канал positionChannel, который Stream и возвращает данные об изменении позиции камеры.
С этим как быть? Слушать конкретные сокеты?
Также у нас еще есть функционал с передачей платформенной реализации какого-то абстрактного класса - то же сложное задание слежения за позицией или углом наклона.
>его в свои классы загоняете, которые создавать надо с помощью генератора.
Самому пользователю ничего создавать не нужно) Готовые Dart классы и методы уже доступны из коробки вместе с дефолтными UI виджетами.
Так у нас же не просто отображение карты. Наш продукт позволяет задавать перелеты и сложные алгоритмы для изменения параметров камеры во время слежения. Отслеживание разных параметров камеры.
У нас есть справочник со большим объемом данных и вложенными структурами.
Навигатор позволяет в реальном времени получать данные об оставшемся маршруте, о текущей скорости, потери GPS и прочим.
Для всех выше указанных и множества других сценариев постоянно гонять protobuf - накладно.
Генератор - это наш внутренний продукт, недоступный для внешнего пользователя. Генерируемый файл мы поставляем вместе с FlutterSDk.
Да, из за того, что политика flutter требует предоставление всех dart исходников, получается, что сгенерированный файл мы выставляем наружу. Но пользователь сам себе выстрелит в ногу, если что-то там сломает))
И ты имеешь ввиду, что проще - это не нужен кодогенератор? Ну при подходе в клиент-серверном взаимодействии нужно реализовать сериализаторы/десериализаторы. Плюс, кодогенератор один раз написали и все, он на CI работает и генерирует сборки.
Привет. Я так понимаю, что идея заключается в локальном развертывании клиент-серверного приложения. Теперь по порядку.
При клиент-серверном взаимодействии данные передаются в виде, например, JSON. Сериализовать/десериализовать данные в JSON и обратно - явно будет медленнее, чем через FFI. Да, можно использовать protobuf, но тоже не уверен, что будет сильно производительнее JSON и точно хуже FFI.
Поддержка и использование API пользователями нашего SDK будет сложнее. Сейчас пользователь может подписаться на CancelableOperation и получить в callback готовый для использования тип. Или передать класс в наш API. А так придется еще и через JSON/protobuf все это прогонять.
На Qt написано приложение 2ГИС. API часть SDK не использует Qt.