Posted January 3, 20205 yr Добрый вечер, Карты играют важную роль в жизни человека, они приятны глазу и выручают людей в сложных ситуациях (скажу вам как человек с топографическим кретинизмом). То что, представил Ярослав, приятно глазу, но пока не выручает. Потому пожелалки такие: Предоставить возможность работы со всеми типами объектов, возможные в ГуглеМапс ( далее ГМ) Возможность отображения контролов, которые возможны в ГМ (как-то масштабирование, мое местоположение, и т.д.) Управление объектами программно (к примеру отобразить информационное окно, без клика пользователем) Собственные слои, это самая сложная часть имхо, потому что я потратил на нее два года своей постылой жизни, и не добился результатов AndroidBridge возвращает не тот интерфейс, но возможно Ярослав и Ко справятся Прошу вас, поддержите меня, ибо как говорил Фукс (капитан Врунгель), карты это мой хлеб.
January 5, 20205 yr Administrators В 03.01.2020 в 18:48, Stas сказал: Возможность отображения контролов, которые возможны в ГМ (как-то масштабирование, мое местоположение, и т.д.) Добавлено в 1.0.2.0, демо-проект "TfgMap -> Настройка элементов управления картой".
February 9, 20205 yr Administrators В 03.01.2020 в 18:48, Stas сказал: Управление объектами программно (к примеру отобразить информационное окно, без клика пользователем) В 03.01.2020 в 18:48, Stas сказал: Предоставить возможность работы со всеми типами объектов, возможные в ГуглеМапс ( далее ГМ) Добавлено в 1.1.0.0.
February 10, 20205 yr Author Ярослав, а почему появилось столько событий, которые можно было не постулировать в таком количестве?
February 10, 20205 yr Administrators В Google Maps листенеры сделаны для каждого объекта в отдельности. Какой кейс для общего обезличенного ивента? Внутри все равно будет производится анализ от какого типа объекта пришло это событие.
February 10, 20205 yr Author Я знаю, Виктор, Но в GoogleMaps отсутствует и общий объект, наследниками которого являются полигоны полилинии и иже с ними в Fgx, просто это несколько странно, делать столько событий, когда можно обойтись одним. (бритва Оккама) Я не в претензии, мысли вслух.
February 10, 20205 yr Administrators Может мы упускаем какой-то кейс? Расскажите, для чего может понадобиться общее событие, если внутри не анализируется тип объекта, по которому был тап?
February 10, 20205 yr Author Виктор, это для чистоты и изящества кода, Вы же все равно используете TfgAndroidListener, что мешает, передавать в конструктор тип объекта, и вызывать один и тот же метод TfgMap З.Ы. Повторюсь, я не в претензии.
February 10, 20205 yr Administrators Несколько моих мыслей на этот счет: 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. Если нужно централизованное событие, то можем добавить его в следующий релиз. Благо все уже готово, чтобы это сделать.
February 10, 20205 yr Author 1 час назад, Yaroslav Brovin сказал: P. S. Если нужно централизованное событие, то можем добавить его в следующий релиз. Благо все уже готово, чтобы это сделать. Ярослав, спасибо за развернутый ответ, я должен понимать принципы построения библиотеки. Конечно не имеет смысл добавлять общий метод.
February 10, 20205 yr Administrators На самом деле имеет ? Как раз для ситуаций централизованного управления объектами по типу Dispatch, когда точка входа одна, а потом происходит просто выбор нужного обработчика.
Create an account or sign in to comment