• Как обрабатывать события мыши и клики по кнопкам на сенсорном экране в программе для информационного киоска?

    lexxpavlov
    @lexxpavlov
    Программист, преподаватель
    Зависит от драйверов тачскрина. Я разрабатывал такой киоск, там был простой антивандальный тач стекло, умел делать только клики (без жестов), вставлялся в киоск вместо обычного стекла впереди обычного нетактильного монитора. Я делал веб-приложение, показывал Оперой (в то время только у оперы был хороший режим киоска, из которого нельзя было выйти только мышью). На Win-приложение тоже всё заработает, это считается работа мышкой.
    Ответ написан
    Комментировать
  • Как обрабатывать события мыши и клики по кнопкам на сенсорном экране в программе для информационного киоска?

    krdpsr
    @krdpsr
    loading...
    в веб-программировании да
    онклик срабатывает с задержкой после онтача
    Ответ написан
    Комментировать
  • Как обрабатывать события мыши и клики по кнопкам на сенсорном экране в программе для информационного киоска?

    firedragon
    @firedragon
    Не джун-мидл-сеньор, а трус-балбес-бывалый.
    сенсорный экран определяется как usb hid возможно будут какие то дрова, но базовый функционал это мышка. Конечно без правого клика
    Ответ написан
    Комментировать
  • Какой конструктор мобильных приложений стоит выбрать?

    iLLuzor
    @iLLuzor
    Java, Kotlin, Android Developer
    Понятия "качественный" и "конструктор приложений" взаимосключающие. Тут вариантов ровно ноль.
    Ответ написан
    2 комментария
  • Объясните, плиз зачем нужен react и vue?

    Ответ на вопрос "почему" заключается в одной емкой фразе: потому что сложно синхронизировать интерфейс и состояние.

    Представьте, что у вас есть простой UI какого-нибудь ToDoApp. Вам всего-то нужно сделать так, чтобы при вводе новой задачи она появлялась в списке, а при нажатии на крестик напротив удалялась бы. Проще простого!

    Но когда начнете решать проблему на нативном JS или на б-гомерзком jQuery, вы столкнетесь с необходимостью писать очень много шаблонного кода. Прежде всего на обслуживание DOM. Найти элемент, вставить элемент, добавить элементу класс, атрибут... в итоге у вас получится портянка на десятки строк для такой элементарной задачи, а ведь мы еще не добавили много кульных штук, без которых ToDoApp совсем не ToDoApp, как-то: возможность создавать разные списки, расписания, галочка, чтобы зачеркивать задачу и т.п. С реализацией всего этого ваша простыня будет расти, вы будете в ней путаться.

    На этом этапе вы можете начать велосипедить. Писать какие-то утилиты для работы с DOM. Разделите index.js на несколько файлов, сообразно DDD или хотя бы единой ответственности. Допустим даже, что вашим приложением внезапно стали пользоваться, у вас куча бизнес-идей. Вы начинаете наваливать фичи, структура становится все запутаннее, кода становится все больше, а еще приложение начинает тормозить. Вы проводите небольшой анализ и понимаете, что проблема в излишне частом обращении к DOM - вы дергаете его на каждый чих, ведь с jquery это так просто! И что делать? Писать еще один велосипед, чтобы обновлять DOM пакетно? А как отслеживать изменения в данных с сервера? Это ж сколько работы!

    К счастью, все вышеописанное, и даже гораздо больше, уже решено в Google, Facebook, а также некоторыми талантливыми энтузиастами. И у нас есть Angular, Vue, React, Svelte, которые предлагают вам возможность создавать быстрые, поддерживаемые приложения с минимумом шаблонного кода и продуманной архитектурой.
    Ответ написан
    Комментировать
  • Объясните, плиз зачем нужен react и vue?

    zoonman
    @zoonman
    ⋆⋆⋆⋆⋆
    Когда-то я писал на PHP. Писал много. Сначала это было месиво из кода на PHP и HTML, потом появились всякие шаблонизаторы, стало чуть чище.
    Проекты росли, кода становилось все больше и хотелось некоторые кусочки переиспользовать. Так я пришел к управлению кодом через Composer.
    На каком-то этапе разработки я столкнулся с тем, что у меня было 2 разных веб-интерфейса делающих одно и то же. Вдобавок нужно было часть данных отдавать в систему логистики. Причем это должно было быть автоматизировано. Тогда я уже знал, что есть такая штука - автоматизированные программные интерфейсы (API).
    Наскоро было что-то написано и оно заработало. По итогу, оба веб-интерфейса и система логистики использовали одни и теже функции. Но поддерживать 2 разных интерфейса было очень геморно. В те времены был jQuery самым главным. Очень сложно было добиться правильного отображения, посколько Javascript код был в перемешку с HTML, часть которого генерировалась из PHP. Возникали ошибки. Данных было много, разных скриптов было много (сотни), части скриптов были копиями друг друга с небольшими отклонениями. По итогу, на решение простых задач вроде редактирования строчки в таблице с обновлением на сервере уходило много времени, дни, иногда даже недели.
    Потом я увидел Mustache.js, это был предок Ангуляра и Реакта. Что-то вроде шаблонизатора, но только на стороне клиента. Работало оно только в одну сторону, отображало данные в HTML, но потом была та же жесть из jQuery.
    Затем я познакомился с Angular1. Идея была простая - пишешь шаблон, подставляешь в него данных. Оно отображается, само! Никаких тебе извращений, найди класс или идентификатор, или еще какая-нибудь ерунда.
    Кодить стало проще. Стало можно создавать библиотеки компонентов и просто редактировать стили. Можно было сделать компонент для ввода и проверки почты, и использовать его сразу во всех проектах и исправлять ошибки в одном месте, а не бегать по сотням скриптов и искать в каждом этот повторяющийся косяк.
    Поначалу я тоже относился к Ангуляру с предубеждением, столько траблов, стоят ли они того. Но как только я стал чаще сталкиваться с задачами, когда мне понадобились разные интерфейсы для отображения одних и тех же данных, это стало сходить на нет.
    Пока вы пилите простые штуки, всякие фреймворки вам не втарахтели. Даже jQuery не нужен. Но иногда начинается жопа, когда одному уже проект не вытащить, ибо охеренеть, как сложно, а еще и делать надо быстро. Поэтому лучше разделиться, кто-то делает бэкенд, кто-то фронт. Так просто удобнее, а общаться через API. Вначале вы вместе просто пишите спецификацию для API, это занимает день или два. А потом вы бомбите месяц в параллель. Причем фишка такого подхода в том, что есть инструменты, которые просто выдают заглушки для кода на фронте. Т.е. если фронт пишется быстрее, то его проще тестить и все такое. Аналогично с бэкендом. Его тоже можно тестить даже если фронт не готов. Причем эти все фишки особенно круты, когда вас не двое, а например 20, да и живете вы по всему миру в разных часовых поясах и т.д.
    Ответ написан
    1 комментарий