Stas Posted January 3, 2020 Share Posted January 3, 2020 Добрый вечер, Карты играют важную роль в жизни человека, они приятны глазу и выручают людей в сложных ситуациях (скажу вам как человек с топографическим кретинизмом). То что, представил Ярослав, приятно глазу, но пока не выручает. Потому пожелалки такие: Предоставить возможность работы со всеми типами объектов, возможные в ГуглеМапс ( далее ГМ) Возможность отображения контролов, которые возможны в ГМ (как-то масштабирование, мое местоположение, и т.д.) Управление объектами программно (к примеру отобразить информационное окно, без клика пользователем) Собственные слои, это самая сложная часть имхо, потому что я потратил на нее два года своей постылой жизни, и не добился результатов AndroidBridge возвращает не тот интерфейс, но возможно Ярослав и Ко справятся Прошу вас, поддержите меня, ибо как говорил Фукс (капитан Врунгель), карты это мой хлеб. 4 Quote Link to comment Share on other sites More sharing options...
Administrators Yaroslav Brovin Posted January 5, 2020 Administrators Share Posted January 5, 2020 В 03.01.2020 в 18:48, Stas сказал: Возможность отображения контролов, которые возможны в ГМ (как-то масштабирование, мое местоположение, и т.д.) Добавлено в 1.0.2.0, демо-проект "TfgMap -> Настройка элементов управления картой". Quote Link to comment Share on other sites More sharing options...
Administrators Yaroslav Brovin Posted February 9, 2020 Administrators Share Posted February 9, 2020 В 03.01.2020 в 18:48, Stas сказал: Управление объектами программно (к примеру отобразить информационное окно, без клика пользователем) В 03.01.2020 в 18:48, Stas сказал: Предоставить возможность работы со всеми типами объектов, возможные в ГуглеМапс ( далее ГМ) Добавлено в 1.1.0.0. 1 1 Quote Link to comment Share on other sites More sharing options...
Stas Posted February 10, 2020 Author Share Posted February 10, 2020 Ярослав, а почему появилось столько событий, которые можно было не постулировать в таком количестве? Quote Link to comment Share on other sites More sharing options...
Administrators Viktor Akselrod Posted February 10, 2020 Administrators Share Posted February 10, 2020 О каких именно событиях идет речь? Quote Link to comment Share on other sites More sharing options...
Stas Posted February 10, 2020 Author Share Posted February 10, 2020 OnTap<TfgMapObject> Де факто их можно было объединить в одно. Quote Link to comment Share on other sites More sharing options...
Administrators Viktor Akselrod Posted February 10, 2020 Administrators Share Posted February 10, 2020 В Google Maps листенеры сделаны для каждого объекта в отдельности. Какой кейс для общего обезличенного ивента? Внутри все равно будет производится анализ от какого типа объекта пришло это событие. Quote Link to comment Share on other sites More sharing options...
Stas Posted February 10, 2020 Author Share Posted February 10, 2020 Я знаю, Виктор, Но в GoogleMaps отсутствует и общий объект, наследниками которого являются полигоны полилинии и иже с ними в Fgx, просто это несколько странно, делать столько событий, когда можно обойтись одним. (бритва Оккама) Я не в претензии, мысли вслух. Quote Link to comment Share on other sites More sharing options...
Administrators Viktor Akselrod Posted February 10, 2020 Administrators Share Posted February 10, 2020 Может мы упускаем какой-то кейс? Расскажите, для чего может понадобиться общее событие, если внутри не анализируется тип объекта, по которому был тап? Quote Link to comment Share on other sites More sharing options...
Stas Posted February 10, 2020 Author Share Posted February 10, 2020 Виктор, это для чистоты и изящества кода, Вы же все равно используете TfgAndroidListener, что мешает, передавать в конструктор тип объекта, и вызывать один и тот же метод TfgMap З.Ы. Повторюсь, я не в претензии. Quote Link to comment Share on other sites More sharing options...
Administrators Yaroslav Brovin Posted February 10, 2020 Administrators Share Posted February 10, 2020 Несколько моих мыслей на этот счет: 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 Quote Link to comment Share on other sites More sharing options...
Stas Posted February 10, 2020 Author Share Posted February 10, 2020 1 час назад, Yaroslav Brovin сказал: P. S. Если нужно централизованное событие, то можем добавить его в следующий релиз. Благо все уже готово, чтобы это сделать. Ярослав, спасибо за развернутый ответ, я должен понимать принципы построения библиотеки. Конечно не имеет смысл добавлять общий метод. Quote Link to comment Share on other sites More sharing options...
Administrators Yaroslav Brovin Posted February 10, 2020 Administrators Share Posted February 10, 2020 На самом деле имеет ? Как раз для ситуаций централизованного управления объектами по типу Dispatch, когда точка входа одна, а потом происходит просто выбор нужного обработчика. Quote Link to comment Share on other sites More sharing options...
joko pitoyo Posted July 23, 2020 Share Posted July 23, 2020 Interest... count me 10... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.