Как мы сделали Rich Text Editor с поддержкой совместного редактирования под Android25.12.2015 13:33

«Мобилизация» рабочих процессов в компаниях означает, что на телефон или планшет переносится все больше функций для совместной работы. Для Wrike, как кроссплатформенного сервиса управления проектами, важно, чтобы функционал мобильного приложения был абсолютно полноценным, удобным и не ограничивал пользователей в работе. И когда встала задача создать Rich Text Editor с поддержкой совместного редактирования описания задач, мы, оценив возможности существующих WebView компонентов, решили пойти своим путем и реализовали собственный нативный инструмент.

Для начала немного об истории продукта. Одной из базовых функций Wrike изначально была интеграция с почтой. С самой первой версии задачи можно было создавать и обновлять через e-mail, а затем работать над ними совместно с другими сотрудниками. Тело письма превращалось в описание задачи, а все дальнейшее обсуждение шло в комментариях к ней.

Поскольку в почте можно использовать HTML форматирование, в ранних версиях продукта мы использовали CKEditor для дальнейшей работы с описанием задачи. Но в среде, ориентированной на совместную работу, это очень неудобно — необходимо блокировать весь документ или его часть, чтобы подготовленное описание задачи не затер кто-то другой. В итоге мы решили углубиться в практику Operation Transformation (OT) и сделать инструмент для настоящей совместной работы. В этой статье я не буду подробно рассматривать теорию и реализацию OT для rich text документов, об этом есть уже достаточно материалов. Я рассмотрю лишь сложности, с которыми столкнулась наша команда при разработке мобильного приложения.

Совместное редактирование на смартфоне —, но зачем?

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

1. Реализация OT требует хранить документ в определенном формате, поддерживающим совместное редактирование. В случае простого текста особого формата тут нет — это может быть просто строка. Но в случае с Rich Text (текста с форматированием), формат хранения становится сложнее.
2. Нам нужен способ сохранять изменения, сделанные мобильным клиентом, не сломав документ и не создав конфликт с изменениями, которые могли внести в тот же промежуток времени другие пользователи. Это задачи, которые как раз и решаются алгоритмами OT.
3. Раз нам нужно перенести алгоритм OT на мобильную платформу, чтобы выполнить условия из пункта 2, то сделать полноценное совместное редактирование уже не требует значительных дополнительных усилий.

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

Варианты реализации

С реализацией компонента для совместной работы опыт уже был, а вот с тем, как перенести его на Android, предстояло разобраться. Многое зависело от требований к редактору и их, по большому счету, было два:

1. Поддержка базового форматирования, списков, вставка картинок и таблиц,
2. API, позволяющий вносить и отслеживать изменения как в самом тексте, так и в его форматировании.

Способ 1: использовать существующий компонент из Web продукта
Действительно, мы могли бы использовать компонент, который у нас уже есть, и обернуть его в WebView. Из плюсов — простота интеграции, так как фактически весь код редактора находится в скриптах, и Android/iOS разработчику остается только реализовать WebView wrapper.

Достаточно быстро стало понятно, что существующий компонент из основного приложения, работающий с ContentEditable документом, функционирует весьма нестабильно в зависимости от версии ОС и от вендора. Экзотичность багов местами зашкаливала, но в основном они всплывали вокруг функций выделения и ввода текста, а также пропадающего фокуса и клавиатуры.

Чтобы обойти проблемы ContentEditable, мы пробовали использовать CodeMirror как фронтенд для редактора, при этом он заметно лучше и стабильнее работает на Android, поскольку обрабатывает все события от клавиатуры и отрисовку самостоятельно. Были, конечно, и минусы, но как быстрый workaround он работал очень неплохо до тех пор, пока не появилось небезызвестное изменение в обработке событий нажатия клавиш в IME — довольно подробно эта проблема обсуждается здесь. Если в двух словах — при использовании LatinIME, он не отправляет событие для KEYCODE_DEL.

Что это значит для пользователя? При нажатии на Delete ничего не происходит, то есть редактор работает корректно, можно вводить текст, применять форматирование… вот только текст нельзя удалить, как бы это абсурдно ни звучало. Единственный вариант решения данной проблемы помимо всего прочего включал в себя следующий код:

@Override
public InputConnection onCreateInputConnection(EditorInfo outAttrs) {
  BaseInputConnection baseInputConnection = new BaseInputConnection(this, false) {
     @Override
     public boolean sendKeyEvent(KeyEvent event) {
        if (needsKeyboardFix() && event.getAction() == KeyEvent.ACTION_MULTIPLE && event.getKeyCode() == KeyEvent.KEYCODE_UNKNOWN) {
           passUnicodeCharToEditor(event);
           return true;
        }
        return super.sendKeyEvent(event);
     }

     @Override
     public boolean deleteSurroundingText(int beforeLength, int afterLength) {
        if ((Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) && (Build.VERSION.SDK_INT < Build.VERSION_CODES.KITKAT) &&
              (beforeLength == 1 && afterLength == 0)) {
           // Send Backspace key down and up events
           return super.sendKeyEvent(new KeyEvent(KeyEvent.ACTION_DOWN, KeyEvent.KEYCODE_DEL))
                 && super.sendKeyEvent(new KeyEvent(KeyEvent.ACTION_UP, KeyEvent.KEYCODE_DEL));
        }
        else {
           return super.deleteSurroundingText(beforeLength, afterLength);
        }
     }
  };

  outAttrs.inputType = InputType.TYPE_NULL;

  return baseInputConnection;
}

InputType.TYPE_NULL при этом переводил IME в «упрощенный» вид, сигнализируя, что InputConnection работает в ограниченном режиме, что означает отсутствие copy/paste, autocorrect/autocomplete, а также ввода текста с помощью жестов, но при этом он позволяет обрабатывать все события клавиатуры.

В итоге, в последней реализации редактора, который использовал веб-интерфейс, были следующие недостатки:

• медленная скорость загрузки;
• отсутствие доступа к расширенным возможностям IME (copy/paste, autocomplete/autocorrect, gesture input);
• в некоторых случаях нестабильная работа, в связи с различной реализацией WebView на разных версиях API и модификации этого компонента некоторыми вендорами;
• обычно WebView долго не держится в памяти, особенно на девайсах с небольшим объемом памяти, и, если свернуть приложение и через некоторое время запустить заново, то в большинстве случаев WebView придется снова инициализировать;
• многочисленные костыли в коде, число которых со временем только увеличивалось.

Осознав, что поддерживать подобную имплементацию редактора непросто, и учитывая описанные недостатки и ограничения, было решено разработать нативный компонент, который бы давал возможность работать с форматированным текстом.Способ 2: нативная реализация
Для нативной реализации необходимо решить две задачи:

1. UI редактор, то есть отображение текста с учетом форматирования и его редактирование.
2. Работа с форматом документа, отслеживание изменений, а также обмен данными с сервером.

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

Вторая задача решается переносом алгоритмов OT из JavaScript на Java, и процесс здесь достаточно прозрачен.

Отображение Rich Text в EditText

В Android есть замечательный интерфейс Spannable, который позволяет задать разметку текста. Сам процесс формирования разметки довольно прост — нужно воспользоваться специальным классом SpannableStringBuilder, который позволяет как задавать/изменять текст, так и устанавливать стили для заданных участков текста через метод

setSpan(Object what, int start, int end, int flags). 

Первый параметр как раз задает стиль. Он должен быть экземпляром класса, который реализует один или несколько интерфейсов из пакета android.text.style: CharacterStyle, UpdateAppearance, UpdateLayout, ParagraphStyle и т.д. Набор дефолтных стилей довольно широк — от изменения формата символов (StyleSpan, UnderlineSpan), задания размера текста (RelativeSizeSpan) и изменения его положения (AlignmentSpan) до поддержки изображений (ImageSpan) и кликабельного текста (ClickableSpan).

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

SpannableStringBuilder ssb = new SpannableStringBuilder(text);
ssb.setSpan(new ForegroundColorSpan(Color.BLUE), 0, text.length(), Spannable.SPAN_EXCLUSIVE_EXCLUSIVE);
textView.setText(ssb, TextView.BufferType.SPANNABLE);

Итак, на входе есть текст в неком формате, а на выходе нужно получить его представление в виде Spannable объекта и передать его в EditText. В нашем случае с сервера документ приходит в особом формате в виде атрибутированной строки — необходимо распарсить эту строку, используя нашу библиотеку для OT, и применить атрибуты к заданным участкам текста. В зависимости от стиля, нужно выставить корректный флаг, чтобы маркировка текста соответствовала ожиданиям пользователя.

Если пометить стиль флагом SPAN_EXCLUSIVE_INCLUSIVE, то он будет применен к введенному в конце интервала тексту, но не будет применяться в начале. Например, есть интервал [10, 20], для которого выставлен стиль UnderlineSpan + SPAN_EXCLUSIVE_INCLUSIVE. В этом случае при вводе текста в позицию 9, к нему стиль UnderlineSpan применяться не будет, но если начать вводить текст в позиции 20, то интервал, который покрывает стиль, расширится и станет [10, 21]. Естественно, это полезно для inline форматирования (bold / italic / underline и т.п.).

При использовании флага SPAN_EXCLUSIVE_EXCLUSIVE, интервал стиля ограничивается с обоих концов. Это подходит, например, для ссылок — если начать вставлять текст сразу после ссылки, то стиль ссылки к нему применяться не должен.

Используя флаги SPAN_EXLUSIVE_INCLUSIVE и SPAN_EXCLUSIVE_EXCLUSIVE можно управлять поведением форматирования при вводе текста в зависимости от ожиданий пользователя. Например, если вы включили режим форматирования Bold, то вводимый текст должен оставаться жирным. А если вы сделали ссылку, то дописывание текста в конце не должно расширять границы ссылки.

Для отображения элементов списка можно воспользоваться BulletSpan, но он подойдет только для ненумерованных списков. Если же необходима нумерация, то можно написать свой класс, реализующий интерфейсы LeadingMarginSpan и UpdateAppearance, отрисовывая индикатор списка на свое усмотрение в методе drawLeadingMargin.

Обработка пользовательских стилей

Понятно, что редактор должен давать пользователю возможность применять форматирование, это включает:

1. Добавление нового стиля к выбранному тексту,
2. Вставку нового стиля в позиции курсора,
3. Применение текущего стиля при редактировании.

В первую очередь нужно где-то разместить кнопки для поддерживаемых редактором стилей. Помещать их в тулбаре Activity было не практично до выхода Android Marshmallow. По умолчанию этот же тулбар используется для контекстного меню при выделении текста, и таким образом выбрать стиль для выбранного текста невозможно. Поэтому можно поместить их на тулбар внизу экрана. При нажатии на кнопку стиля необходимо определиться с текущим состоянием редактора и либо применить стиль к выбранному тексту, либо запомнить этот стиль как временный в позиции курсора.

private void onApplyInlineAttributeToSelection(int selectionStart, int selectionEnd, TextAttribute attribute) {
  int selectionStart = mEditText.getSelectionStart();
  int selectionEnd = mEditText.getSelectionEnd();

  if (!mEditText.hasSelection()) {
     // if there's no selection, insert/delete empty span for the appropriate attribute,
     // but only in case the cursor is present
     if (selectionStart == selectionEnd && selectionStart != -1) {
        if (mTempAttributes == null || mTempAttributes.getPos() != selectionStart) {
           mTempAttributes = new TempAttributes(selectionStart);
        }

        Set