Простые коммуникации в Java-приложении

Привет, 

Как вы уже, наверное, знаете, Jmix — это такая платформа для разработки корпоративных приложений, построенная на основе фреймворков Spring, Vaadin и других классных технологий с открытым исходным кодом. 

Ее использование позволяет абстрагироваться от многих сложностей фронтенд-разработки. Разработчикам не обязательно учить JavaScript/TS, погружаться в особенности популярных фронтенд-фреймворков, тренироваться в верстке, чтобы иметь возможность создавать полнофункциональные веб-приложения. Достаточно просто писать код на Java и немного компоновать экраны в XML. При разработке интерфейса для Jmix под капот уходят также некоторые механики, связанные с «перекладыванием джейсонов», что открывает дополнительные возможности для написания интерактивных веб-приложений с использованием готовых компонентов и дополнений. 

Сегодня мы попробуем убедиться в этом на примере, создав MVP приложения для взаимодействия пользователей.  

Для начала работы нам потребуется IntelliJ IDEA или GIGA IDE с установленным плагином Jmix (https://plugins.jetbrains.com/plugin/14340-jmix). 

Создадим новый проект, выбрав тип Jmix, Full-Stack Application и назовем его jmix-colab. 

Добавим новый пустой экран DrawBoardView. 

Экран состоит из XML-дескриптора, в котором описывается его общий дизайн (или лейаут) и Java-класса, в котором пишется бизнес-логика, относящаяся к экрану и взаимодействию с его дочерними компонентами. 

Изобретать компонент для работы с Canvas мы сегодня не будем, а вместо этого просто пройдем в реестр дополнений Vaadin, в котором, кажется, есть готовые решения на любой случай, и по слову canvas найдем там вот такой вариант.

Добавим его зависимость в build.gradle. 

implementation 'org.parttio:canvas-java:2.0.0' 

Для начала программно добавим холст на экран. Для генерации метода-обработчика удобно использовать меню Generate Handler. 

onBeforeShow и onInit — стандартный способ навесить свой функционал для экрана: загрузить, сконфигурировать, добавить в отображение и другие инициализационные операции. 

На холсте мы сразу что-нибудь нарисуем, чтобы увидеть, что все заработало. 

  @Subscribe    public void onBeforeShow(final BeforeShowEvent event) {      Canvas canvas = new Canvas(800, 500);      CanvasRenderingContext2D ctx = canvas.getContext();          ctx.setStrokeStyle("red");      ctx.beginPath();      ctx.moveTo(10, 10);      ctx.lineTo(100, 100);      ctx.closePath();      ctx.stroke();    } 

В дескриптор экрана добавим контейнер для холста. 

<div id="canvasContainer" /> 

А в коде программно добавим реализацию холста в контейнер в метод onBeforeShow. 

canvasContainer.add(canvas); 

Так мы «привязали» компонент, созданный в коде, к объявленному в дескрипторе экрана.  

Кстати, при помощи Alt+Enter в пункте меню Inject мы можем быстро и легко добавлять ссылки на элементы из дескриптора в код. 

Должна отобразиться пока что только одна красная линия. 

Теперь уберем все, что касается линии, кроме стиля, и добавим обработчик движения мышью, реализовав метод класса экрана в коде. 

public void onCanvasMouseMove(MouseMoveEvent event) {    ctx.lineTo(event.getOffsetX(), event.getOffsetY());    ctx.stroke();    log.info("event.x: {}, event.y: {}", event.getOffsetX(), event.getOffsetY());  } 

В этот раз мне пришлось написать метод вручную, потому что Generate Handler опознает только компоненты, объявленные в дескрипторе и имеющие id. 

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

private static final Logger log = LoggerFactory.getLogger(DrawBoardView.class); 

Привязывать добавленный ранее обработчик движения мыши надо будет тоже в методе onBeforeShow. 

canvas.addMouseMoveListener(this::onCanvasMouseMove); 

Теперь мы можем вернуться в браузер и порисовать, двигая мышью. 

Но когда на любое движение мыши без остановки происходит отрисовка линии — это не очень удобно, поэтому мы будем рисовать только когда нажата левая кнопка мыши. Для этого классу экрана добавим признак, определяющий, что рисование сейчас происходит. 

protected Boolean drawingEnabled = false; 

А на события mousedown и mouseup добавим обработчики его включения и выключения, а также вызовы методов начала и завершения фигуры у контекста. Его следует поднять на уровень свойства класса экрана, чтобы иметь доступ из других методов класса. 

  canvas.addMouseMoveListener(this::onCanvasMouseMove);    canvas.addMouseDownListener(this::onCanvasMouseDown);    canvas.addMouseUpListener(this::onCanvasMouseUp);    canvasContainer.add(canvas);  }    public void onCanvasMouseMove(MouseMoveEvent event) {    ctx.lineTo(event.getOffsetX(), event.getOffsetY());    ctx.stroke();    log.info("event.x: {}, event.y: {}", event.getOffsetX(), event.getOffsetY());  }  public void onCanvasMouseDown(MouseDownEvent event) {    this.drawingEnabled = true;    ctx.beginPath();  }  public void onCanvasMouseUp(MouseUpEvent event) {    ctx.closePath();    this.drawingEnabled = false;  } 

Остается добавить только проверку режима в обработчике движения мыши, и наша рисовалка станет как у людей. 

Однако, мы хотим сделать многопользовательское приложение, и в этом нам поможет инструмент для работы с шиной событий uiEventPublisher.  

Чтобы им воспользоваться, его надо заинжектить в класс экрана так же, как мы это проделывали с компонентом-контейнером. 

Вместо рисования в текущем контексте будем отправлять событие рисующего передвижения мыши, в нашем упрощенном варианте — всем пользователям. 

Теперь обработчик передвижения будет выглядеть вот так: 

public void onCanvasMouseMove(MouseMoveEvent event) {    if (drawingEnabled) {      uiEventPublisher.publishEventForUsers(new DrawBoardMoveEvent(event), null);    }    log.info("event.x: {}, event.y: {}", event.getOffsetX(), event.getOffsetY());  } 

Он посылает событие мыши, обернутое в событие уровня всего приложения, которое пока что просто оборачивает его. 

package com.company.jmixcolab.event;    import org.springframework.context.ApplicationEvent;  import org.vaadin.pekkam.event.MouseMoveEvent;    public class DrawBoardMoveEvent extends ApplicationEvent {      protected MouseMoveEvent mouseMoveEvent;      public DrawBoardMoveEvent(MouseMoveEvent event) {      super(event);      this.mouseMoveEvent = event;    }      public MouseMoveEvent getMouseMoveEvent() {      return mouseMoveEvent;    }  }

А обработчик этого события будет уже рисовать на холсте. 

@EventListener  public void boardMoveEventHandler(DrawBoardMoveEvent event) {    ctx.lineTo(event.getMouseMoveEvent().getOffsetX(), event.getMouseMoveEvent().getOffsetY());    ctx.stroke();  } 

Теперь мы можем открыть холст в разных окнах браузера и порисовать синхронно. Работать это все может не идеально, у меня иногда «забывала» отключиться функция рисования и наблюдались некоторые задержки, что вероятно связанно с параметрами debounce для события движения мыши и особенностями сетевого обмена. Однако, мы сейчас работаем с упрощенными примерами, рассчитанными на демонстрацию возможностей, а не на оптимальные режимы работы. 

Правда, получается не понятно, кто где нарисовал. Для того, чтобы стало понятно, в класс эвента добавим поле username в событие DrawBoardMoveEvent и будем заполнять его из контекста текущего пользователя в обработчике движения. 

public void onCanvasMouseMove(MouseMoveEvent event) {    if (drawingEnabled) {      uiEventPublisher.publishEventForUsers(new DrawBoardMoveEvent(event, currentAuthentication.getUser().getUsername()), null);    }    log.info("event.x: {}, event.y: {}", event.getOffsetX(), event.getOffsetY());  } 

А при рисовании мы будем сверять значение с текущим пользователем и менять цвет в зависимости от того сам клиент рисует или получает эвенты рисования от другого пользователя. 

@EventListener  public void boardMoveEventHandler(DrawBoardMoveEvent event) {    ctx.setStrokeStyle(currentAuthentication.getUser().getUsername().equals(event.getUsername()) ? "red" : "green");    ctx.lineTo(event.getMouseMoveEvent().getOffsetX(), event.getMouseMoveEvent().getOffsetY());    ctx.stroke();  } 

Посмотрим на результат.

Теперь наши пользователи могут различать вклад друг друга, но неплохо было бы еще добавить индикацию, когда один из них пребывает в процессе рисования. Для этого создадим эффект мигания рисунка. 

Конечно, в реальном случае это, скорее всего, будет лучше сделать исключительно с помощью анимации CSS, однако у нас демонстрационный проект и мы будем мигать, просто изменяя во времени это свойство. Как это сделать?  

Чтобы получился эффект мигания, мы будем изменять свойство opacity у холста, уменьшая и увеличивая его значение. Для этого нам потребуется последовательность значений в интервале от 0.6 до 1.0, изменяющаяся с шагом 0.2, при этом сначала убывая от единицы, а затем возрастая.  

Чтобы это свойство изменялось у элемента последовательно во времени, нам потребуется использовать планировщик задач. 

Для нашего случая подойдет однопоточный экзекьютор с возможностью выполнять отложенные и повторяющиеся задачи.  

static ScheduledExecutorService executorService = Executors.newSingleThreadScheduledExecutor(); 

Интерфейс ScheduledExecutorService позволяет создавать отложенные и повторяющиеся с заданным интервалом задачи.

Также надо добавить код, сабмитящий в него задачи по выбрасыванию событий с новым значением opacity.

@EventListener  public void boardMoveEventHandler(DrawBoardMoveEvent event) {    boolean isCurrentUserDrawing = currentAuthentication.getUser().getUsername().equals(event.getUsername());    ctx.setStrokeStyle(isCurrentUserDrawing? "red" : "green");    ctx.lineTo(event.getMouseMoveEvent().getOffsetX(), event.getMouseMoveEvent().getOffsetY());    ctx.stroke();    List<String> users = new ArrayList<>() {{ add(currentAuthentication.getUser().getUsername() );}};    if (!isCurrentUserDrawing) {      Iterator<Integer> it = IntStream.range(0, 5).boxed().iterator();      Stream.of(1.0, 0.8, 0.6, 0.8, 1.0).forEach((i) -> {        long nextTime = Double.valueOf(it.next() * 500.0).longValue();        executorService.schedule(() -> {          uiEventPublisher.publishEventForUsers(new DrawBoardOpacityChangeEvent(i), users);        }, nextTime, TimeUnit.MILLISECONDS);      });    } else {      uiEventPublisher.publishEventForUsers(new DrawBoardOpacityChangeEvent(1.0), users);    }  } 

А слушатель события изменения прозрачности будет, собственно, устанавливать значение. 

@EventListener  public void opacityChangeEventHandler(DrawBoardOpacityChangeEvent event) {    canvasContainer.getElement().setAttribute("style", "opacity: " + String.valueOf(event.getOpacity()));  } 

Почему не сделать это прямо в задаче для ExecutorService? Дело в том, что задачи экзекьютора несмотря на то, что могут выполняться в одном реальном потоке, ведут себя как настоящие потоки. В нашем случае это значит, что они не имеют доступа к контексту выполнения пользовательского интерфейса, и тут нас снова выручает publishEventForUsers, позволяя потокам осуществлять взаимодействие с интерфейсом. 

В Java начиная с версии 21 появилась возможность использовать экзекьюторы виртуальных потоков в дополнение к обычным. Cо стороны кода экзекьютор задач в виртуальных потоках имеет тот же интерфейс, что и для реальных, и отличается только реализацией. 

Преимущество изоляции виртуальных потоков заключается в том, что, выполняя в них «тяжелые» задачи, мы не будем порождать блокировки интерфейса пользователей. Это особенно важно для операций ввода-вывода, таких, как запросы на сторонние сервисы, чтение и запись данных в файлы и базы. Веб-интерфейс в браузере, так же как в играх, оконных системах, десктопных тулкитах, работает в однопоточном режиме и лучшее, что мы можем сделать для обеспечения его отзывчивости — это выполнять «тяжелые» задачи в отдельных потоках, обрабатывая в UI-потоке только результаты их выполнения. Некоторые виды операций, такие как скачивание ресурсов, браузер сам выполнит в фоновых потоках, другие, например выполнение большого цикла или ресурсоемкого вычисления из JavaScript-контекста завесят интерфейс пользователя. 

Говорят, виртуальные потоки как будто предназначены для эффективной работы с блокирующими операциями при высокой их интенсивности. Их создание происходит «с нулевой стоимостью». Заблокировавшись, виртуальный поток освободит контекст реального потока, в котором выполнялся для других задач, не вызвав его блокировки. Единственное исключение — когда вы имеете дело с кодом, в котором присутствует большое количество synchronized-блоков, и это не для всех случаев. В отличие от реальных потоков вы можете предполагать использование сотен и тысяч виртуальных без значительного влияния на общие системные требования приложения. Используя их, можно также перестать беспокоиться о блокировке потоков и лимитах на количество потоков в пулах. Выполнение виртуальных потоков также не привязано только к одному реальному потоку и, как следствие, процессорному ядру, как это происходит со многими имитациями асинхронного кода. Они могут стать настоящим спасением для работы в контексте синхронного кода приложений, позволив вам использовать асинхронность только там, где от нее будет практическая польза, без превращения всего приложения в спагетти обработчиков реактора. Продемонстрируем это все на примере. Добавим в нашу рисовалку возможность делать штампы картинкой с удаленного сервиса. Срабатывать оно будет по двойному клику. Повесить его на сам холст у меня не вышло, но на контейнер вполне получилось при помощи кнопки GenerateHandler. Сначала сделаем простой обработчик, добавляющий картинку урлом в src. 

@Subscribe(id = "canvasContainer", subject = "doubleClickListener")  public void onCanvasContainerClick(final ClickEvent<Div> event) {    PendingJavaScriptResult res = canvasContainer.getElement().callJsFunction("getBoundingClientRect");    res.then((rect) -> {      canvasLeft = ((JsonObject) rect).getNumber("left");      canvasTop = ((JsonObject) rect).getNumber("top");      ctx.drawImage("https://upload.wikimedia.org/wikipedia/commons/5/50/Smile_Image.png", event.getClientX() - canvasLeft, event.getClientY() - canvasTop, 100, 100);    });  } 

Тут не обошлось без лайфхака: для точного вычисления положения клика мыши относительно границ холоста нам надо знать его собственную позицию. Поэтому я запрашиваю у элемента значения при помощи вызова JavaScript метода getBoundingClientRect, который возвращает эти данные в актуальном виде. 

Но, допустим, нам требуется скачивать картинку с удаленного сервера перед добавлением на холст. Для этого объявим для экрана HTTP-клиента. 

protected HttpClient client; 

И проинициализируем его в методе onBeforeShow. 

client = HttpClient.newBuilder()      .executor(httpExecutorService)      .build(); 

Наш клиент будет использовать экзекьютор виртуальных потоков, который мы проинициализируем аналогичным образом.  

static ExecutorService httpExecutorService = Executors.newVirtualThreadPerTaskExecutor(); 

Все его блокирующие запросы будут происходить как будто в отдельном потоке, не мешая при этом работе интерфейсной логики. 

Чтобы убедиться в этом, добавим логирование в колбэк скачивания картинки. 

client.sendAsync(request, HttpResponse.BodyHandlers.ofByteArray()).thenApply((response) -> {    log.info("Image received for event.x: {}, event.y: {}", event.getClientX(), event.getClientY());    ...  }); 

И мы увидим, что в логах маркировка текущего потока у контекста колбэка будет другой. 

Тогда наш обработчик двойного нажатия вместо непосредственного рисования на холсте будет запрашивать картинку при помощи асинхронного HTTP-запроса и при ее успешном скачивании выбрасывать эвент, содержащий в себе вычисленные координаты изображения и его данные, закодированные в base64. 

@Subscribe(id = "canvasContainer", subject = "doubleClickListener")  public void onCanvasContainerClick(final ClickEvent<Div> event) {    PendingJavaScriptResult res = canvasContainer.getElement().callJsFunction("getBoundingClientRect");    res.then((rect) -> {      canvasLeft = ((JsonObject) rect).getNumber("left");      canvasTop = ((JsonObject) rect).getNumber("top");      try {        HttpRequest request = HttpRequest.newBuilder(new URI("https://upload.wikimedia.org/wikipedia/commons/5/50/Smile_Image.png"))            .version(HttpClient.Version.HTTP_1_1)            .header("Content-type", "image/png")            .build();        client.sendAsync(request, HttpResponse.BodyHandlers.ofByteArray()).thenApply((response) -> {          uiEventPublisher.publishEventForUsers(new DrawBoardImageAddedEvent(response,              event.getClientX() - canvasLeft, event.getClientY() - canvasTop,              "data:image/png;base64," + Base64.getEncoder().encodeToString(response.body())), null);            return null;        });      } catch (URISyntaxException e) {        throw new RuntimeException(e);      }    });  } 

Обработчику этого события останется только отрисовать полученные данные на холсте. 

@EventListener  public void boardImageAddedHandler(DrawBoardImageAddedEvent event) {    ctx.beginPath();    ctx.drawImage(event.getSrc(), event.getX(), event.getY(), 100, 100);    ctx.closePath();  } 

Теперь при двойном нажатии на холсте в точке курсора будут появляться штампы из скачанных картинок. 

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

Готовый код проекта можно скачать из вот этого репозитория.