KyoroText で使用されている技術 その1

 数十回に渡って、KyoroText で使用されている技術について、紹介していきたいと思います。
※ androidとj2seで、自作Editorを作成する方法を紹介します。
    以下ような内容を含んでいます。
      - androidにて、InputConnectionより確定文字、未確定文字、キーイベントを取得する方法
      - j2seにて、未確定文字、確定文字を取得する方法。
  


[はじめに]
  私は今「Kyoro Text」というアプリを作成しています。その際に、「試行錯誤したこと」や、「得たノウハウ」をまとめていきたいと考えています。
  当初、Text Editorという、文字の表示と編集するだけのアプリに、悪戦苦闘するとは、考えていませんでした。
  皆さんも、たかだかEditor程度と思いでしょう。 たかだかEditorと言う認識で正しいのかも知れません。 間違いなのかもしれません。この判断をくだすための材料を提供したいと思います。


[進め方] 
  この文章を読んで頂いている皆様は、多分、androidやJ2SEでEditorを作るのに必要なAPIだとか、その使い方だとかを知りたくてこの文章を読んでいるのではないでしょうか？
残念ながら, あなたのご期待に沿う事は出来ないかも知れません。
  モチロン、apiの使い方にもついて、触れる事は多々あると思います。しかし、apiの使い方をメインに説明しようとは考えてません。
  Editorを作成するにあたり、どのような課題があって、それをどのように克服したのかを説明します。
  残念ながら、優れた対処方法はほとんどありませんが、試行錯誤の結果を物語として楽しんでいただけたらと思います。


[課題一覧]
  - Androidで、PC等で編集したテキストを表示するには、ヒープが足りない。
  - ..
  - ..
  - ..



[課題] Androidで、PC等で編集したテキストを表示するには、ヒープが足りない。

  KyoroTextが対象としていた端末はLowSepcなものが有り。 使用可能なJavaヒープが少ないため、Javaヒープ上にデータをすべて読み込んでから表示する事が困難でした。

  また、Fileから、データを読み込む速度も重要な要素です。 Fileからデータを読み込む速度は高機能を歌っている端末だからといって早いわけではなく。古い型のものの方が早かったりしました。
このため、 最新の端末なのにタカダカ数千キロバイト程度のテキストを読み込むのにカナリ待たされたりする事があるわけです。

  これらの状況をふまえて、ユーザーにストレスを与えないように、即座に画面に表示して上げるようにする必要がありました


[androidのメモリ]

  本当に使えるメモリはそんなに少ないのか?という疑問から解決していきましょう。
 端末には、数メガのヒープを確保してもありあまる程のようりょうがあります。
  これを特別な方法で取得できないのでしょうか?
  結論から言うとデキます。なので、この特殊な方法を使用するという手もあります。

簡単に紹介しましょう。
  - malloc
  - MemoryFile
  - ByteBuffer.alllocateDirect

続く..　中途半端なところで、ごめんなさい!!


[PS]

来年初頭に、KyoroTextの安定版をだす予定です。
そこで、「KyoroTextを紹介するページをつらないとなぁ～」と考えました。
機能の紹介だけだと、平凡な感じがしました。
そこで、KyoroTextを作成するにあたり悪戦苦闘した事を、記事にすることにしまた。

この記事が第一回目となります。
たぶん何度も書き直します。

ショート問題解決 IMEなんかに処理を渡したくない。CTLが押されたら自前で処理したい

KyoroText (自作 Android Editor)ネタです。
来年まとめる予定ですが、こまめに、Android IMEについて情報だししていきます。

* IMEなんかに処理を渡したくない。CTLが押されたら自前で処理したい
 ※ EmacsライクなEditorにしたい場合、IMEがジャマですよね!!

そんな時は、dispatchKeyEventPreIme() で trueを 返すとよい。

ショート問題解決 eclipseでndkアプリをデバック

たぷん、うまくいっていない。メモだけ
※ android-ndk-r8c windows7 
 *  Breakしたところでとまらない
 * ヘッダーとか、いったんEclipseを終了しないと反映されない？

「ショート問題解決　eclipseでndkアプリをデバック」時は、以下をする。

1. Preferences > Android > NDK でパスを設定
2. Android Tools -> Add Native Support
3. AndroidManifest.xmlのDebuggable をtrue
3. 「ndk-build NDK_DEBUG=1」でビルド
4. Debug As--> Native Android Application


[PS]
 そんなにガンバンなくても、Eclipse上で作業が簡潔できるようになった？のかな..。
 良い感じだ。

ショート問題解決 Androidアプリをビルドしている時、「Conversion to Dalvik format failed with error」

ショート問題解決　Androidアプリをビルドしている時、「Conversion to Dalvik format failed with error」と出力されてビルドに失敗する。

そんな時は、
*  「ライブラリとアプリ」のターゲットバージョンをあわせる。
*  eclise -clean とかしてみる。

ショート問題解決 Androidで「node.js」を使ってみたいな

ショート問題解決　Androidで「node.js」を使ってみたいな
と思ったら。

以下のサイトをのぞいてみよう!!

https://github.com/paddybyers/anode/wiki

※ ROOT化不要です!!
※ ちょっと説明不測ですね..。 KyoroPocketNodeJSとして、単体アプリとして、パッケージしたものをGithubにアップする予定です。注意点だとかは、その機会に説明する予定です。

ショート問題解決 「Cannot load library」が表示される

Androidアプリをビルド中に、「Cannot load library」が表示された。
以下のようなエラーがでました。

java.lang.UnsatisfiedLinkError: Cannot load library: reloc_library[1306]:    37 cannot locate '__gnu_thumb1_case_uqi'...

そんな時は、Application.mkに以下を追加する。

APP_ABI          := armeabi armeabi-v7a

KyoroTextViewerでのISO 2022の扱いについて

KyoroTextViewerが下記機能に対応するにあたり、解決すべき問題を記録しておく。
- ISO 2022への対応
- アラビア語へり対応
※ todo アラビア語は、ここでは書かない。別に書く

[はじめに]

ISO 2022は、文字集合(バイトコードに応じて表示する文字)を入れ替えて表示するため、先頭から順に読み込んでいかなくてはなりません。
※具体的には、以下のような感じで、文字集合を変更するESCが挿入されます。

「こんにちはISO_2022_JP」の場合
<ESC 日本語> こんにちは <ESC ASCII> ISO_2022_JP

 KyoroTextViewerでは、ギガバイトのデータも軽快に表示できることを、目標としているため、
 毎回先頭からテキストを読み込むといったことはなるたけ避けたいと考えています。


[問題/解決]
例えば「改行無しに、数万文字が続くような場合」、毎回先頭から読み込むのと、
画面に表示するまでに時間がかかってしまいます。

そこで、毎回先頭から読み込むのではなく、前もって記録していた文字集合を渡すように
してあげることにしました。

[詳細]

具体的には、(designate) と(invoke) を記録しておく必要があります。
以降、ISO 2022について説明します。

文字集合を切り替えるのに、2つの方法を使用します。
* 文字集合を符号表(C0 GL C1 GR)に指定する(designate) 
*  文字集合をバッフア(G0,G1,G2,G3)にi指定する(invoke) する。その後符号表(C0 GL C1 GR)にわたす。
例)

1. <G0に文字集合を設定する>
2. <GLに対応する文字を変える>

[実現方法]

○ シングルシフトは記録しない。

 - ロッキングシフト

   命令で上書きされるまで、

 - シングルシフト

   1文字だけ

○*->UTF8への変換はJavaのAPIをそのまま利用する。なので、指定されている文字集合の変更だけを記録しておけばよい。

○指定されている文字集合の記録について、汎用的に作るのは断念する。

サポートしたいCharsetのdesignate/invokeを記録するようにする。

※ ISO2022ベースかどうかの判定は、自前でする必要があるため、

    もともと、自分が対応しようとしたものしか対応できない。

[サポート]

  ISO-2022-JP

    #designate:

   G0 

       <ESC ( B>, <ESC ( J>, <ESC $ @>, <ESC $ B>

     <ESC $ ( D>, <ESC $ A>, <ESC $ ( C>

     <ESC $ ( O>, <ESC $ ( P>

     <ESC $ ( Q>, 

   G2

    <ESC . A><ESC . F>

  #invoke

   G2

   <ESC N>;single

 ISO-2022-KR

    #designate:

      G1 

     <ESC $ ) C>

  #invoke

   G0

     <SI>

   G1

     <SO>

ISO-2022-CN

    #designate:

      G1

     <ESC $ ) A>,<ESC $ ) G>,<ESC $ ) E>

   G2

     <ESC $ * H>

   G3

     <ESC $ + I>,<ESC $ + J>,<ESC $ + K>,<ESC $ + L>,<ESC $ + M>

  #invoke

   G0

     <SI>

   G1

     <SO>

   G2

     <ESC N>; single

   G3

     <ESC O>; single

[参照]

http://ja.wikipedia.org/wiki/ISO/IEC_2022

[資料]

符号表
  制御文字(C0)
  印字文字(GL)
  制御文字(C1)

  印字文字(GR)


仮想バッフア
  G0 G1 G2 G3

命令
#designate
 CZD   : C0
 C1D   : C1

 GZD4 : G0
 G1D4 : G1

 G2D4 : G2
 G3D4 : G3

 G1D6 : G1

 G2D6 : G2
 G3D6 : G3
 GZDM4  : G0
 G1DM4  : G1

 G2DM4  : G2
 G3DM4  : G3
 G1DM6  : G1

 G2DM6  : G2
 G3DM6  : G3

 DOCS   : 

 IRR       : 

#invoke
 SI      : GOをGLへ 7bit符号
 LS0   : G0をGLへ  8bit符号
 SO    : G1をGLへ 7bit符号
 LS1   : G1をGLへ  8bit符号
 LS2   : G2をGLへ
 LS3   : G3をGLへ

 LS1R : G1をGRへ  8bit符号
 LS2R : G2をGRへ  8bit符号
 LS3R : G3をGRへ  8bit符号
 SS2   : G2をGL/GRへ 1文字限り
 SS3   : G3をGL/GRへ 1文字限り
 ACS   : アナウンス機能