DroidScript

Предварительный просмотр работы кода (Live Preview) на этапе разработки ПО: сложности и решения

DroidScript
инструменты для мобильной разработки

Предварительный просмотр работы кода (Live Preview) на этапе разработки ПО: сложности и решения

Оглавление 

При взаимодействии пользователя с компьютерной системой, имеющей экран, происходит визуализация действий, данных и работы программного кода - их отображение на нём. Пользователь перемещает мышь или нажимает на клавиши клавиатуры - это действия, которые сразу видны на экране посредством движения курсора мыши, текстового курсора и появления текста. Движение курсора по экрану, щелчок по кнопке, выбор пункта меню - это тоже действия. К данным в широком смысле относится текст и графика - интерфейсы, элементы дизайна, данные в таблице, графики и др. Действия и данные напрямую связаны с работой программного кода и можно сказать, что последний визуализируется посредством первых двух. Например, в графическом редакторе пользователь выбрал фигуру, а затем перемещает курсор мыши с зажатой клавишей в рабочем поле.  Вслед за движением курсора на экране начинает отображаться фигура и данные - её положение, размеры, форма, цвет, контур и т.д. Часть данных отображается при помощи элементов интерфейса, а часть мы видим и анализируем непосредсвенно, что происходит одновременно с действиями. Также происходит при редактировании текста, видео, музыкальных данных и др. При достаточной вычислительной мощности компьютера пользователь сразу видит изменения на экране и не задумывается об этом. Если что-то работает недостаточно быстро, то решить задачу качественно он может путём приобретения более производительного компьютера или комплектующих. Программисты-разработчики также могут воспользоваться более мощной аппаратной конфигурацией, но последнее может не дать ожидаемого эффекта. А нужен ли живой просмотр при разработке ПО? Конечно! Если отображение работы кода происходит практически одновременно с его редактированием, что называется Live Priview или живой просмотр, то эффективность работы увеличится по сравнению со случаем, когда сначала код редактируется, а затем производится его запуск на выполнение. Проверить это легко. Какие эмоции будут у пользователя, если изображение или текст в редакторе будут появляться через несколько секунд после движения мыши и нажатия на клавиши? Но компиляция кода может происходить значительно дольше, а при разработке её приходится делать постоянно, на что тратится немало времени и ресурсов. Значит, нужно каким-то образом ускорить компиляцию кода. А можно ли при использовании компилируемых языков программирования добиться живого просмотра? Теоретически, да, путём увеличения аппаратно-программной вычислительной мощности и использованием менее требовательного к ресурсам ПО (прошлых лет). Например, можно увеличить размер оперативной памяти, создать в ней виртуальный диск и установить на него среду разработки, что вся работа происходила в ней без обращения к твёрдотельному или жесткому диску. Но устроит ли работа с устаревшим ПО заказчика и разработчика? Нет. Значит, компиляция с последующей сборкой (установкой) и запуском приложения в современных средах разработки пока останется затратным по времени процессом. Для её компенсации используют разные подходы:

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

Последний пункт вызывает особый интерес, так как вокруг существует немало интерпретируемых языков программирования. Но многие ли из них позволяют осуществить удобный и столь необходимый на этапе разработки интерактивный живой просмотр? Сходу можно вспомнить Dreamweaver с вкладкой Live, Brackets с функцией Live Preview, браузер Chrome с workspace, несколько Интернет-ресурсов, имеющих on-line редакторы и "песочницы" для быстрого знакомства с возможностями предлагаемых технологий и создания набросков (скетчей), а также пару сред разработки мобильных приложений - App Inventor, Corona SDK, PhoneGap. Кажется, что всё неплохо, но живой просмотр в Dreamweaver более или менее хорошо работает только с простой статичной разметкой. В Brackets он привязан к браузеру Chrome и работает крайне нестабильно, если вообще работает. В Chrome также случаются странности, не позволяющие испытывать удовольствия от работы. Имитация мобильных устройств в настольных средах разработки не отличается наглядностью (в большинстве случаев), а web-редакторы не поражают своей функциональностью. Получается так, что живой просмотр на этапе разработки приложений используется, главным образом, для демонстрации некоторых возможностей интерпретируемых технологий, обучения и создания набросков, тогда как на этапе выполнения приложения он является важнейшей и неотъемлемой частью, которую пользователи воспринимают как нечто необходимое и само сабой разумеющееся. Почему так происходит?

Одна из причин - различие конфигураций среды разработки и выполнения, например, разработка ведётся в оконной среде, а выполняется в браузерной, или прототипирование происходит в одной операционной системе для другой и т.п. В Dreamweaver для отображения результатов используется эмулятор браузера, работа которого, надо сказать, весьма существенно отличается от работы популярных браузеров. Разработчики Brackets и Chrome выбрали другой подход - живой просмотр в рабочей среде (в браузере), но, к сожалению, пока их решения работаю нестабильно. Браузерные on-line редакторы позволяют вести разработку в среде выполнения, но тут есть нюансы со спецификой работы разных браузеров, да и по функциональности они отстают от оконных сред разработки.

Из сказанного можно сделать вывод о том, что существует два основных способа организации живого просмотра:

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

Для этого можно:

  • использовать существующую (официальную или стороннюю) среду разработки
  • воспользоваться существующим редактором или модулем редактора и дополнить его нужной функциональностью
  • разработать свой редактор

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

Использование модуля редактора является неплохой идеей, но и здесь потребуется немало времени на его адаптацию и дополнение необходимой функциональностью. Для интереса можно посмотреть браузерный редактор DroidScript. Его можно доработать, но не получится выйти на уровень эффективности работы в полнофункциональных средах разработки. Также можно, например, в редакторе NotePad++ добавить подсветку qml-кода и создать сценарий для его запуска на выполнение, но от этого он не превратится в Qt Creator, Visual Studio или Android Studio.

Остаётся первый вариант - использовать готовую среду разработки и дополнить её возможностью интерактивного живого просмотра. Вот здесь, пожалуй, и начинается самое интересное. Рассмотрим подход, который позволит осуществить живой просмотр при использовании практически любого редактора или среды разработки для интерпретируемых языков программирования, что даст:

  • Работу в удобной среде разработки
  • Независимость среды разработки от среды выполнения
  • Интерактивный живой просмотр в среде выполнения

Для осуществления этого нам потребуются:

  • Редактор кода
  • Детектор изменений целевой директории
  • Сервер
  • Клиенты

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

При выборе периода сканирования целевой директории меньше секунды, использования достаточно скоростной сети и производительных устройств - телефонов, планшетов, ноутбуков, настольных компьютеров и др., возможно реализовать одновременный просмотр выполнения кода на разных устройствах в реальном времени.

Код такого проекта, скорее всего, будет дан в разделе Qt Quick применительно к среде разработки Qt Creator, но некоторые общие моменты поясню здесь.

Детектор проверяет время изменения файлов и может отправлять серверу либо полный путь к изменённому файлу, либо пересылать его содержимое. Если проект состоит из главного файла и нескольких подключаемых к нему файлов-модулей, то при изменении модулей клиенты должны обновить главный файл. В первом случае им передаётся имя файла для загрузки, а во втором - текстовая строка, которую нужно интерпретировать в код, что умеют делать, например, движки на JavaScript и QML. После интерпретации кода он отображается в рабочей среде устройства или в браузере. Для обмена данными стоит обратить внимание на веб-сокеты, работа с которыми, к слову, происходит просто в QML.

Думается, что наибольшую пользу показанный подход может принести при кроссплатформенной разработке и тестировании, когда можно сразу после сохранения кода увидеть его работу на телефоне, планшете, эмуляторе, большом мониторе. За это глаза не скажут спасибо, но необязательно одного разработчика загружать десятком устройств. При одноплатформенной разработке эффект также будет виден, так как не придётся долго думать над тем, какой выбрать редактор, есть ли в нём Live Preview и куда выводятся результаты. Разработчик это выбирает сам, что делает его менее зависимым от среды разработки и визуализации работы кода.

Оглавление 
© 2016 droidscript.ru admin@droidscript.ru