Добрый вечер, Карты играют важную роль в жизни человека, они приятны глазу и выручают людей в сложных ситуациях (скажу вам как человек с топографическим кретинизмом).

То что, представил Ярослав, приятно глазу, но пока не выручает.

Потому пожелалки такие:

1. Предоставить возможность работы со всеми типами объектов, возможные в ГуглеМапс ( далее ГМ)
2. Возможность отображения контролов, которые возможны в ГМ (как-то масштабирование, мое местоположение, и т.д.)
3. Управление объектами  программно (к примеру отобразить информационное окно, без клика пользователем)
4. Собственные слои, это самая сложная часть имхо, потому что я потратил на нее два года своей постылой жизни, и не добился результатов AndroidBridge возвращает не тот интерфейс, но возможно Ярослав и Ко справятся

Прошу вас, поддержите меня, ибо как говорил Фукс (капитан Врунгель), карты это мой хлеб.

В 03.01.2020 в 18:48, Stas сказал:

Возможность отображения контролов, которые возможны в ГМ (как-то масштабирование, мое местоположение, и т.д.)

Добавлено в 1.0.2.0, демо-проект "TfgMap -> Настройка элементов управления картой".

В 03.01.2020 в 18:48, Stas сказал:

Управление объектами  программно (к примеру отобразить информационное окно, без клика пользователем)

В 03.01.2020 в 18:48, Stas сказал:

Предоставить возможность работы со всеми типами объектов, возможные в ГуглеМапс ( далее ГМ)

Добавлено в 1.1.0.0.

Ярослав, а почему появилось столько событий, которые можно было не постулировать в таком количестве?

О каких именно событиях идет речь? 

OnTap<TfgMapObject>

Де факто их можно было объединить в одно.

В Google Maps листенеры сделаны для каждого объекта в отдельности.

Какой кейс для общего обезличенного ивента?

Внутри все равно будет производится анализ от какого типа объекта пришло это событие.

Я знаю, Виктор, Но в GoogleMaps отсутствует и общий объект, наследниками которого являются полигоны полилинии и иже с ними в Fgx, просто это несколько странно, делать столько событий,  когда можно обойтись одним. (бритва Оккама)

Я не в претензии, мысли вслух.

 

Может мы упускаем какой-то кейс?

Расскажите, для чего может понадобиться общее событие, если внутри не анализируется тип объекта, по которому был тап?

Виктор, это для чистоты и изящества кода,  

Вы же все равно используете TfgAndroidListener, что мешает, передавать в конструктор тип объекта, и вызывать один и тот же метод TfgMap

З.Ы. Повторюсь, я не в претензии.

Несколько моих мыслей на этот счет:

1 час назад, Stas сказал:

Но в GoogleMaps отсутствует и общий объект, наследниками которого являются полигоны полилинии и иже с ними в Fgx

В iOS внутри будет по другому. А если еще добавиться какой-нибудь OpenStreeMaps или YandexMap, то там будет другое API. Поэтому задача библиотеки предоставить универсальное API, которое вы сможете одинаково использовать на любой платформе и любой внутренней реализации. На текущий момент разработанное API - это позволяет сделать и для iOS в том числе.

Для самообучения и сравнения обязательно нужно изучать разные варианта API, чтобы предоставить правильный и удобный функционал, НО не всегда надо зеркально отражать его же в обертках. Обертка должна быть синтезом достоинств разных API, собранных воедино.

1 час назад, Stas сказал:

Но в GoogleMaps отсутствует и общий объект, наследниками которого являются полигоны полилинии

При этом, там как раз на каждый тип объекта предлагается свой набор листенеров. Я полагаю, что именно по причине, что обезличенная работа с объектами карты не такой частый кейс, как может показаться. Именно за счет того, что разные объекты по разному наносятся интерактивно на карты. Полилиния через последовательность точек и их редактирование, а маркеры и круги по другому.

1 час назад, Stas сказал:

просто это несколько странно, делать столько событий,  когда можно обойтись одним. (бритва Оккама)

Если бы библиотека была бы решением одной конкретной задачи одного клиента, то тогда в либе было бы на порядок всего меньше, чем есть на текущий момент. Отличие универсального решения от индивидуального/частного, как раз и заключается в повторном использовании кода. Когда сегодня вы делаете на базе платформы информационную систему для банка, а завтра на ней же делаете расчет параметров полета ракеты и визуализации. Конечно у нас тут не полет ракеты и возможности уже, однако, правило "полезности" разработанного API всегда используется.

Да, можно четко следовать принципу Оккама и делать минимальное самодостаточное АПИ. Есть множество примеров таких библиотек. Достаточно взять Open GLES, в основу которого и положен этот принцип. Этот принцип идеально подходит для решения задач поддержания совместимость. Именно по этому стандарт Open GLES, как раз предлагает минимум, чтобы разработчики мобильных ОС и производителей GPU карт, поддерживали только минимальный набор методов. То же касается в какой-то степени и набора инструкций процессора. Это область, где изменение типа инструкций стоит очень дорого для разработчиков ПО. Как вы могли проследить в этих примерах, с одной стороны вы получаете минималистическое АПИ для решения любой задачи, но с другой - теряете удобство использования за счет минимизации разнообразия API. Что в конечном итоге рано или поздно приведет к появлению высокоуровневой обертке - хелперы. Я уверен, что и у вас в том числе если свои хелпер классы и модули для решения часто встречаемых задач для VCL, FMX, БД и других областей. Самый простой пример - это уровень языка программирования. Есть минималистический ассемблер, есть С++, а есть Делфи. И вы пользуетесь последним инструментов, потому что он позволяет решить ваши задачи проще, чем на предыдущих двух. 

Прежде, чем добавить событие, настройку или метод, мы всегда оперируем возможными ситуациям клиентов. В конкретном случае, объединение объектов под один базовый класс в дальнейшем поможет с легкостью предоставить методы для универсальной работы с обезличенной природой объекта. Например, для операций очистки объектов в одной категории и для работы сгруппированных объектов по смыслу в так называемые слои (не исключая появления в будущем отдельной сущности слоя).

Если же мы говорим про наличие такого количества событий, то с одной стороны, можно предоставить одно агрегированное событие с обезличенными объектами. Этот подход поможет всю логику обработки всех объектов сосредоточить в одном месте и реализовать централизованный диспатчер. Особенно это удобно, если логика обработки объектов вынесена за пределы формы. И я считаю, что мы обязательно добавим такое событие в дополнение к текущим, так как это реальный кейс.

Но с другой стороны, нельзя делать только одно такое универсальное событие, так как это побудит разработчиков с большой долей вероятности в конечном итоге приводить объекты к нужным классам, что снизит порог вхождения для работы с классами и увеличит количество "лишнего" кода. А я хочу напомнить, что в библиотеки я стараюсь сокращать клиентский код по работе с UI, чтобы пользователь концентрировался на бизнес процессах и правильной архитектуре приложения, а не писал монструозные формы на 100500 строк кода. Поэтому у карты в заключении должны быть, как общие события, так и частные.

P. S. Если нужно централизованное событие, то можем добавить его в следующий релиз. Благо все уже готово, чтобы это сделать.

1 час назад, Yaroslav Brovin сказал:

P. S. Если нужно централизованное событие, то можем добавить его в следующий релиз. Благо все уже готово, чтобы это сделать.

Ярослав, спасибо за развернутый ответ, я должен понимать принципы построения библиотеки.

Конечно не имеет смысл добавлять общий метод. 

На самом деле имеет ? Как раз для ситуаций централизованного управления объектами по типу Dispatch, когда точка входа одна, а потом происходит просто выбор нужного обработчика. 

Interest... count me 10...