Androidの共同編集をサポートするリッチテキストエディターの作成方法

企業の作業プロセスの「動員」とは、コラボレーションのための機能がますます携帯電話またはタブレットに移されることを意味します。 クロスプラットフォームのプロジェクト管理サービスであるWrikeの場合、モバイルアプリケーションの機能が完全に完全で便利であり、ユーザーの作業を制限しないことが重要です。 そして、タスク記述の共同編集をサポートするリッチテキストエディターを作成するタスクが発生したとき、既存のWebViewコンポーネントの機能を評価して、独自の方法で独自のネイティブツールを実装することにしました。




まず、製品の歴史について少し。 Wrikeのコア機能の1つは、もともとメール統合でした。 タスクの最初のバージョンから、電子メールで作成および更新し、他の従業員と一緒に作業することができました。 手紙の本文は問題の説明に変わり、それ以上の議論はすべてそのコメントにありました。

メールではHTMLフォーマットを使用できるため、製品の初期バージョンではCKEditorを使用してタスクの説明をさらに処理しました。 しかし、コラボレーション指向の環境では、これは非常に不便です。ドキュメントの全体または一部をブロックして、誰かが準備したタスクの説明を上書きしないようにする必要があります。 その結果、オペレーション変換（OT）の実践を掘り下げ、真のコラボレーションのためのツールを作成することにしました。 この記事では、リッチテキストドキュメントのOTの理論と実装については詳しく検討しませんが、これについては既に十分な資料があります。 私たちのチームがモバイルアプリケーションの開発で遭遇した困難のみを考慮します。

スマートフォンでの共同編集-なぜですか？

もちろん、これが製品の重要な機能でない限り、おそらく必要はありません。 すべてのプラットフォームで最大限の基本機能を提供するという一般的な目標に加えて、それについて考えなければならなかったいくつかのより具体的な理由がありました。

1. OTを実装するには、共同編集をサポートする特定の形式でドキュメントを保存する必要があります。 プレーンテキストの場合、ここには特別な形式はありません。単なる文字列です。 ただし、リッチテキスト（書式付きテキスト）の場合、ストレージ形式はより複雑になります。
2. ドキュメントを壊すことなく、また他のユーザーが同じ期間に行うことができる変更と競合することなく、モバイルクライアントによって行われた変更を保存する方法が必要です。 これらは、OTアルゴリズムによって正確に解決されるタスクです。
3. パラグラフ2の条件を満たすためにOTアルゴリズムをモバイルプラットフォームに転送する必要があるため、本格的な共同編集を行うために、これ以上大きな労力は必要ありません。

そのため、基本的な機能としてのタスクのリッチテキスト記述、特定のドキュメント形式と同期プロトコルをサポートする必要性があるので、解決策を見つけましょう。

実装オプション

コラボレーションコンポーネントの実装についてはすでに経験がありましたが、Androidに転送する方法を理解する必要がありました。 編集者の要件に大きく依存しており、一般的には次の2つがありました。

1. 基本的な書式設定、リスト、画像と表の挿入、
2. テキスト自体とそのフォーマットの両方で変更を行い、追跡できるAPI。

方法1：Web製品の既存のコンポーネントを使用する

実際、既に持っているコンポーネントを使用して、WebViewにラップすることができます。 利点の1つは統合の容易さです。これは、実質的にすべてのエディターコードがスクリプトに含まれており、Android / iOS開発者はWebViewラッパーのみを実装できるためです。

すぐに、ContentEditableドキュメントで動作するメインアプリケーションの既存のコンポーネントは、OSとベンダーのバージョンによっては非常に不安定であることが明らかになりました。 場所のエキゾチックなバグが暴走しましたが、大部分はテキストの強調表示と入力の機能、およびフォーカスとキーボードの欠落の機能の周りにポップアップしました。

ContentEditableの問題を回避するため、エディターのフロントエンドとしてCodeMirrorを使用しようとしましたが、キーボードからのすべてのイベントを処理し、独自にレンダリングするため、Androidではるかに安定して動作します。 もちろんマイナスもありましたが、IMEのキー押下イベントの処理に悪名高い変更が現れるまで、簡単な回避策として非常にうまく機能しました。この問題については、 ここで詳しく説明します 。 簡単に言えば-LatinIMEを使用する場合、KEYCODE_DELのイベントは送信されません。

これはユーザーにとって何を意味しますか？ [削除]をクリックしても何も起こりません。つまり、エディターは正常に動作し、テキストを入力し、書式設定を適用できます。どのように聞こえても、テキストは削除できません。 この問題の唯一の解決策は、とりわけ、次のコードが含まれていました。

@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が制限モードで動作していることを示します。つまり、コピー/貼り付け、自動修正/自動補完、ジェスチャーを使用したテキスト入力がないことを意味しますが、同時にすべてのキーボードイベントを処理できます。

その結果、Webインターフェイスを使用したエディターの最新の実装には、次の欠点がありました。

• ダウンロード速度が遅い
• 高度なIME機能へのアクセスの欠如（コピー/貼り付け、オートコンプリート/オートコレクト、ジェスチャー入力）;
• 場合によっては、APIのさまざまなバージョンでのWebViewのさまざまな実装および一部のベンダーによるこのコンポーネントの変更のために、動作が不安定になります。
• 通常、WebViewは、特にメモリが少ないデバイスでは長時間メモリにとどまりません。また、アプリケーションを最小化し、しばらくしてから再起動すると、ほとんどの場合、WebViewを再度初期化する必要があります。
• コードには多数の松葉杖があり、その数は時間とともに増加しました。

このようなエディターの実装を維持することは容易ではないことを認識し、記載されている欠点と制限を考慮して、フォーマットされたテキストを使用できるネイティブコンポーネントを開発することにしました。

方法2：ネイティブ実装

ネイティブ実装の場合、次の2つの問題を解決する必要があります。

1. UIエディター。つまり、フォーマットと編集に基づいてテキストを表示します。
2. ドキュメント形式、変更追跡、およびサーバーとのデータ交換を処理します。

最初の問題を解決するために、車輪を再発明する必要はありません-Androidは必要なツール、つまりEditTextコンポーネントとテキストのラベル付けを記述するSpannableインターフェースを提供します。

2番目のタスクは、OTアルゴリズムをJavaScriptからJavaに転送することで解決され、ここでのプロセスは非常に透過的です。

EditTextでリッチテキストを表示する

Androidには、テキストマークアップを設定できるすばらしいSpannableインターフェイスがあります。 マークアッププロセス自体は非常に簡単です。特別なSpannableStringBuilderクラスを使用する必要があります。このクラスを使用すると、テキストを設定/変更し、メソッドを介してテキストの指定セクションのスタイルを設定できます。

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

最初のパラメーターはスタイルを設定するだけです。 android.text.styleパッケージの1つ以上のインターフェース（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でスタイルをマークすると、間隔の最後に入力されたテキストに適用されますが、最初には適用されません。 たとえば、UnderlineSpan + SPAN_EXCLUSIVE_INCLUSIVEスタイルが設定されている間隔[10、20]があります。 この場合、位置9にテキストを入力すると、UnderlineSpanスタイルは適用されませんが、位置20にテキストを入力し始めると、スタイルをカバーする間隔が拡大して[10、21]になります。 当然、これはインライン書式設定（太字/斜体/下線など）に役立ちます。

SPAN_EXCLUSIVE_EXCLUSIVEフラグを使用する場合、スタイル間隔は両端で制限されます。 これは、たとえばリンクに適しています-リンクの直後にテキストの挿入を開始する場合、リンクスタイルを適用しないでください。

フラグSPAN_EXLUSIVE_INCLUSIVEおよびSPAN_EXCLUSIVE_EXCLUSIVEを使用すると、ユーザーの期待に応じてテキストを入力するときの書式設定動作を制御できます。 たとえば、太字書式設定モードをオンにした場合、入力テキストは太字のままになります。 また、リンクを作成した場合、最後にテキストを追加してもリンクの境界は拡大されません。

BulletSpanを使用してリストアイテムを表示できますが、順序のないリストにのみ適しています。 番号付けが必要な場合は、LeadingMarginSpanおよびUpdateAppearanceインターフェイスを実装する独自のクラスを記述して、drawLeadingMarginメソッドでリストインジケーターを希望どおりにレンダリングできます。

カスタムスタイル処理

エディターは、ユーザーがフォーマットを適用できるようにする必要があることは明らかです。これには以下が含まれます。

1. 選択したテキストに新しいスタイルを追加し、
2. カーソル位置に新しいスタイルを挿入し、
3. 編集中に現在のスタイルを適用します。

まず、エディターでサポートされているスタイルのどこかにボタンを配置する必要があります。 これらをアクティビティツールバーに配置することは、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<Object> attributeSpans = getAttributeSpans(selectionStart, selectionEnd, attribute); if (attributeSpans.size() > 0) { attribute.nullify(); } mTempAttributes.addAttribute(attribute); } return; } if (attribute == null) { return; } boolean changed = applyInlineAttributeToSelection(selectionStart, selectionEnd, attribute); // if nothing changed, then there's no need to build any changesets and send updates to server if (!changed) { return; } // ... } 

mTempAttributesは、TempAttributesクラスのインスタンスです。 ユーザーが選択したこの位置の属性のセットを定義します。 この変数は、使用後またはカーソル位置の変更時にゼロにリセットされます。

 static class TempAttributes { private final int mPos; private final Map<AttributeName, TextAttribute> mAttributeMap = new HashMap<>(); public TempAttributes(int pos) { mPos = pos; } public int getPos() { return mPos; } public Collection<TextAttribute> getAttributes() { return mAttributeMap.values(); } public void addAttribute(TextAttribute attribute) { AttributeName name = attribute.getAttributeName(); TextAttribute oldAttribute = mAttributeMap.get(name); if (oldAttribute != null && !oldAttribute.isNull()) { attribute.nullify(); } mAttributeMap.put(name, attribute); } } 

ユーザーがツールバーの特定のスタイルに対応するボタンをクリックしたが、テキストが選択されていない場合、この場合、このスタイルを現在のカーソル位置に「一時」として保存し、この位置にテキストを入力するときに適用する必要があります。 詳細については、以下をご覧ください。

テキストが選択されたら、このスタイルが選択した間隔に既に存在するかどうかを判断する必要があります。 そうでない場合、または部分的に、すべての既存のスパンを結合し、このスタイルで間隔を完全にカバーする必要があります。 ある場合は、間隔から対応するスパンを削除し、必要に応じて分割します。

例1
テキストがあります： Quick brown fox 。
太字[0.4]と太字[12.14]の2つのスパンがあります。 ユーザーがすべてのテキストを選択して太字スタイルを適用した場合、最終的には間隔全体をカバーする必要があります。 これを行うには、両方のスパンを削除して新しい太字[0、14]を追加するか、2番目のスパンを削除して最初のインターバルを間隔の終わりまで延長します。

例2
テキストがあります： Quick brown fox 。
太字[0、14]の1つのスパンがあります。 ユーザーがテキスト[4、12]を選択し、ツールバーで太字スタイルを選択した場合、スタイルは選択範囲に完全に存在するため、間隔からスタイルを削除する必要があります。 これを行うには、間隔を2つの部分に分割します。選択が始まる前に間隔全体[0、14]を短くし（[0、4]）、選択範囲の最後からテキストの終わりまで新しい間隔を追加します（[4、12]）。

ドキュメントの変更を追跡する

ユーザーの変更を正しく追跡してOTアルゴリズムに「フィード」するには、エディターがそれらを追跡できる必要があります。 これを行うには、TextWatcherインターフェイスが使用されます。EditTextで変更が発生するたびに、このインターフェイスのbeforeTextChanged、onTextChanged、afterTextChangedメソッドが順番に呼び出され、何がどこで変更されたかを判断できます。

 private boolean mIgnoreNextTextChange = false; private int mCurrentPos; private String mOldStr = null; private String mNewStr = null; // ... public void ignoreNextTextChange(boolean ignore) { mIgnoreNextTextChange = ignore; } public void beforeTextChanged(CharSequence s, int start, int count, int after){ if (mIgnoreNextTextChange) { return; } mOldStr = null; mCurrentPos = start; if (s.length() > 0 && count > 0) { mOldStr = s.subSequence(start, start + count).toString(); } } public void onTextChanged(CharSequence s, int start, int before, int count) { if (mIgnoreNextTextChange) { return; } mNewStr = null; if (s.length() > 0 && count > 0) { mNewStr = s.subSequence(start, start + count).toString(); } } public void afterTextChanged(Editable s) { // ... } 

setText（CharSequence）を介してエディターに最初にテキストをインストールすると、TextWatcherもこれに関する通知を受け取るため、プログラムによるテキストのインストールは次のようになります。

 mEditTextWatcher.ignoreNextTextChange(true); mEditText.setText(builder); mEditTextWatcher.ignoreNextTextChange(false); 

mOldStr変数とmNewStr変数は、それぞれ古い行と新しい行を格納します。mCurrentPosは、変更が発生した位置を示します。 たとえば、ユーザーが10桁目に「a」という文字を追加した場合、

 mOldStr = null; mNewStr = "a"; mCurrentPos = 10; 

ただし、わずかなニュアンスがあります-自動修正によりテキストを挿入する場合、これらの値には単語の先頭が含まれる場合があります。 たとえば、テキストが「テキスト」という単語で始まり、ユーザーが3番目の文字を「s」に置き換えた場合、IMEはこの変更を次のように報告できます。

 mOldStr = "Tex"; mNewStr = "Tes"; mCurrentPos = 0; 

この場合、行の先頭から同じ文字列をカットする必要があります。

最終的に、TextWatcherを使用して、正確に何が起こったのかを明確に判断できます。テキストが置換、削除、または追加されました。 ユーザーがテキストをその位置に追加するか、既存のテキストの一部をバッファーのテキストで置き換える場合、カーソル位置にある属性を追加されたテキストに適用する必要があります。 これを行うには、空になったオブジェクト（s.getSpanStart（span）== s.getSpanEnd（span））を除外することを忘れずに、カーソル位置にあるすべてのSpannableオブジェクトを検索し、Spannableオブジェクト自体を削除してインライン属性のみでフィルタリングします（太字、斜体など）。 さらに、ツールバーでユーザーが選択したスタイル（mTempAttributes）に対応する属性が追加されます。

 public void afterTextChanged(Editable s) { // ... Object[] spans = s.getSpans(mCurrentPos, mCurrentPos, Object.class); Map<Object, TextAttribute> spanAttrMap = new LinkedHashMap<>(); for (Object span : spans) { TextAttribute attr = AttributeManager.attributeForSpan(span); if (attr != null) { spanAttrMap.put(span, attr); } } if (!TextUtils.isEmpty(mOldStr)) { Iterator<Map.Entry<Object, TextAttribute>> iterator = spanAttrMap.entrySet().iterator(); while (iterator.hasNext()) { Map.Entry<Object, TextAttribute> entry = iterator.next(); Object span = entry.getKey(); TextAttribute attr = entry.getValue(); // ... if (s.getSpanStart(span) == s.getSpanEnd(span)) { s.removeSpan(span); iterator.remove(); } } } // ... Set<TextAttribute> attributes = new HashSet<>(); if (!TextUtils.isEmpty(mNewStr)) { // determine all inline attributes at current position for (Map.Entry<Object, TextAttribute> entry : spanAttrMap.entrySet()) { TextAttribute attr = entry.getValue(); if (AttributeManager.isInlineAttribute(attr)) { attributes.add(attr); } } } if (mCallbacks != null) { mCallbacks.onTextChanged(mCurrentPos, mOldStr, mNewStr, attributes); } } 

その結果、変更が発生した位置があり、この位置の古いテキストと新しいテキスト、および新しいテキストに適用する必要があるインライン属性が認識されます。 その後、追加の処理を追加できます。 たとえば、ユーザーがリストの最後の項目の最後に改行を挿入した場合、リストの現在のカーソル位置に新しい項目を挿入してリストを継続できます。 最終的に、変更のリストがこれらのデータからコンパイルされ、サーバーに送信されます。

エディターで変更を追跡する場合、すべてのデフォルトスタイルにラッパーを使用することをお勧めします。 たとえば、UnderlineSpanの代わりに、UnderlineSpanを継承するCustomUnderlineSpanクラスを使用しますが、メソッドはオーバーライドされません。 このアプローチにより、クラスはEditTextによって使用されるスタイルから「それらの」スタイルを一意に分離できます。 たとえば、オートコレクトが有効になっている場合、単語の編集時にEditTextはUnderlineSpanスタイルを追加し、視覚的に編集時に単語に下線が引かれます。

APIの異なるバージョンとの互換性について

Android KitKatより前のAPIバージョンでは、編集時にスパナブルテキストのオーバーレイに問題があります。 TextViewのハードウェアアクセラレーションを無効にすることで解決します（おそらく、これを修正する他の方法があります-コメントの提案は大歓迎です）。

 mEditText.setLayerType(View.LAYER_TYPE_SOFTWARE, null); 

ただし、このフォームでは、View全体がメモリにレンダリングされるため（「描画キャッシュに収まらないほど大きいビュー」）、TextView自体をスクロールできるようにする必要があるため、TextViewをScrollViewに配置できません。

 mEditText.setVerticalScrollBarEnabled(true); mEditText.setScrollBarStyle(View.SCROLLBARS_OUTSIDE_OVERLAY); 

おわりに

WebViewでのエディターの実装に苦しみ、このアプローチの行き詰まりに気付いた私たちは、共同テキスト編集の困難ではあるがかなり興味深いタスクを解決するネイティブコンポーネントを開発することに成功しました。 これにより、アプリケーションの使いやすさが向上し、ユーザーの生産性が向上しました。 結果は、Google Playからアプリケーションをダウンロードすることで推定できます。