ラベル キーボードON/OFFモニタ の投稿を表示しています。 すべての投稿を表示
ラベル キーボードON/OFFモニタ の投稿を表示しています。 すべての投稿を表示

2013年3月29日金曜日

[SwipeStarter]またリリース


■バグ対応
☆くるくるを再調整。
 標準がダメとのことなので、昨日の対応を元に戻して標準用にチューニング

☆フォルダが二重起動しない問題を修正。
 マーカーに2個フォルダを登録しておいて1個起動中にもう一個起動しようとすると起動しないっていうのを起動するようにしました。

■新機能
メジャーバージョンを4.0にしました。
要望系を入れていきます。
今回はバグも込でリリースを急いでいたので1本だけですけど(汗)
なるべく頑張ります。

☆マーカー単位にON/OFFを設定できるように
 以前から要望のあった、マーカーOFFの時には画面下半分だけ無効にしたい(キーボードに干渉するのが問題だからね)というのを出来るようにしました。
 一律下半分っていうのはどうかと思ったので、マーカー詳細設定でOFFの時も消えないチェックボックスをつけました。
 お試しあれ。


でで、これ!
Google日本語入力がオープンソースになりました!!
http://googledevjp.blogspot.jp/2013/03/google-android.html



こいつのキーボードON/OFFのブロードキャスト投げる版を作れば「キーボードON/OFFモニタ」よりも精度の高いやつが作れるぞっっっって事で、早速やってます。
ソースは出来たんだけど、、、、ビルドがとまるw

しばらくしたら「GoogleIME+ON/OFFインテント」をリリースしますね!
お待ちをををををーーーー!!

2012年8月20日月曜日

[キーボードモニタ]スミマセンでしたm(_ _)m


コメント貰っているのぜっんぜん気づいてませんでした(汗)
別に無視してたとかじゃなくて、本当に気づいていなかった。。

まぁ、それはともかく、WI-FI設定画面が閉じちゃう問題ですけど、僕の端末では再現しなかったです。
となると、端末固有のDialog作っているのか。。。。

端末依存になっちゃう。。うぅぅ。
一応、WI-FI設定のダイアログを無効にしてみたけど、直るか分かりません。。
ごめんなさい。

そろそろ、ON/OFF無効設定作ろうかな。
どうしても動かない場合、設定画面からアプリ指定してもらえれば動かないように。

端末固有とか、有料アプリとかで対応できないのが5個になったらやろう。

あ、後やっとGalaxys2をICSにしました。
ICS端末復活。

ICSで履歴呼ぶとホームが落ちると言う奴の調査をします。

2012年8月6日月曜日

[キーボードモニタ]バグとか言わないで


最初から完璧じゃないよって言ってるんだから、バグって言わないで。
気持ちが萎える。

まぁ、それはさておき

アプリ単位で除外設定できるようにしようかと検討中。
そうすれば、そのアプリでは動かなくなるけど、支障は無くなるかな。

うーん。
でも設定画面作りたくないなぁ。

悩みどころ。

2012年7月10日火曜日

[キーボーモニタ]うぇぇぇん。改修多いよぅ。


敢えて言おう、バグでないと。

前にも書いたけど、入力項目へのフォーカスでキーボードのON/OFFを判断しているから、フォーカスをバンバン変更するアプリとかの場合、ちょっとおかしな動きをします。
後、センスの無いカスタムビュー名の場合(ひどい言い方だけど・・)それが入力項目とすら認識できないみたい。
S「ピー」モード(一部自主規制)とかひでーよ。
本文入力ボックスなんて、長押しイベントも飛んでこない。
→あ、コレFlipClipの話。

有料アプリは金払えば対応できるけど(買わないけど、無料の奴から想像して対応する)、プリインアプリはどうやっても出来ない。

あぁぁぁっぁぁぁぁぁ、こんなアフターケアのめんどくさいアプリリリースしなければよかったZ
まぁ、でも少しでもSwipeStarterユーザに喜んでもらえれば。

そして、最近ぱったりだったSwipeStarterの改修要望が急にがんと来た。
会社の仕事もがんと来た。

やっぱり、会社が一番なので、ちょっと更新滞るかも。
へんな動作系は何とか即改修やってみるつもりです。

敢えて言おう、バグでないと。
そういうアプリであると。

と言ってみたい。

2012年7月5日木曜日

[キーボードON/OFFモニタ]どうしようもない問題発覚


タレコミから発覚しましたが、初期表示で表示されていない入力ボックスの場合、入力ボックス自体が消えます(汗)

なんでやというと、基本的な動作はこんな感じ。
①あるアプリを表示します。
②キーボーモニタで判断した入力項目にフォーカスがあたります。
③「キーボードが表示されたよー」というブロードキャストで、それを受信したアプリ(この場合SwipeStarterのマーカーOFF)が動きます。
④一回SwipeStarterに行って処理(マーカーOFF)をした後、あるアプリに処理が戻ってきます。
⑤あるアプリが"再"表示されます。

このような動作になっています。

注目すべきは⑤の再表示。
全部バックグラウンドでやってるんですが、そういうものらしい。
再表示される時には、初期状態に戻リマス。

初期状態に戻ります。

初期状態に戻ります。

初期状態に戻ります。

初期状態に戻ります。

初期表示で表示されていない入力ボックスが消えます。

ためしにIME版の奴(以前ボツった奴)で試したけど、同じ挙動。
がっかり。

仕方が無いので、指定画面にある入力ボックスはマーカーON/OFFのブロードキャストを投げないっていう対応にしました。
悔しい。

すいません。

もし、このアプリの入力ボックス出なくなった~とかいう問題があればご連絡ください。
個別対応します。

個別対応ばっかりだなぁ。
こんなアプリマーケットに上げてよかったのか。。。

2012年7月4日水曜日

[キーボードON/OFFモニタ][FlipClip]少しだけ自動判別ロジックを入れてみた。


今のところ個別対応した物(超少ないけど)から、誤動作しない範囲の自動判別ロジックを考えて入れてみた。
今までのに比べれば、だいぶ反応するようになったはず。

ただ、やっぱりフォーカス設定を自前でやってる奴(と勝手に想像)はイベントが複数飛んでしまうことがある。
コレに関しては、前後0.5ミリsecでイベントを纏めて、、云々かんぬん見たいな処理を入れたほうがいい気がしてきた。
→ちょっと、次はコレをやろう。

あと、TYPE_VIEW_FOCUSEDとTYPE_WINDOW_STATE_CHANGEDの飛び方もなんかよくわからん。
順序は決まっていないのかね。
でも、アプリによってだから、K.I.T.T.アプリ側に何らかの設定をした場合に発動するんだろうなぁ。
これ、早く見つけたいなぁ。

そもそも、入力項目が必要なアプリなんてそんなに作ったこと無いから、いろいろ勉強になった。

過去形w

まだまだ、直しますよ!


2012年7月3日火曜日

[キーボードON/OFFモニタ][FlipClip]入力項目の判断更新を自動化できないかなぁ。


入力項目の追加を勝手に学習していくようにして自動化出来ないかなぁと思ってやっているんだけど、いいアルゴリズムが思い浮かばない。
FlipClipのほうはいけるかなぁ。
→でもちょっとこっちは後回し。(イベントいっぱい取得する事になるから電池の持ちが悪くなるのは目に見えてる)

キーボーモニタのほうは、ちょっと複雑なんです。
結局、こっちが想定していない入力項目(と思わしき)が来た場合、内部に保存しておいて、次回からは反応するようにってするんだけど、一筋縄ではいかない。
フォーカスでしか判断できないし、抜けたことの判断(今はViewが変わった)の順番にも寄るんだけど、ただ追加していくだけでは無理。

いい例が、指摘もあったけどGooglePlayの検索窓。
あいつの場合、フォーカスが移った後に検索候補を出すんだけど、それが通知の変更に負けるorz
だから、フォーカスで変えると検索候補が出なくなっちゃう。
なので、テキストチェンジで変えてるんだけど、コレもあまり万能でない。
結構苦肉の策。
だから単純に追加って言うのが難しいのね。


あと、今感じているのは、アクセシビリティサービスのイベントが飛んでくる順番がちょっと微妙。

galaxys2のMMS
通常の場合)
07-03 12:17:16.484: DEBUG: Window state change:com.android.mms.ui.ConversationComposer dispkey:false
07-03 12:17:17.934: DEBUG: Focus change:android.widget.EditText dispkey:false
07-03 12:17:17.934: DEBUG: send キーボードが表示されたよ
07-03 12:17:18.464: DEBUG: Window state change:com.android.mms.ui.ConversationComposer dispkey:true
07-03 12:17:18.464: DEBUG: Focus change:android.widget.EditText dispkey:true

たまにおかしい)
07-03 11:57:36.224: DEBUG: Focus change:android.widget.EditText dispkey:false
07-03 11:57:36.229: DEBUG: send キーボードが表示されたよ
07-03 11:57:36.829: DEBUG: Window state change:com.android.mms.ui.ConversationComposer dispkey:true
07-03 11:57:36.829: DEBUG: send 画面が変わったからキーボード消えたはず。
07-03 11:57:36.829: DEBUG: Focus change:android.widget.EditText dispkey:false
07-03 11:57:36.829: DEBUG: send キーボードが表示されたよ
07-03 11:57:37.029: DEBUG: Window state change:com.android.mms.ui.ConversationComposer dispkey:true
07-03 11:57:37.029: DEBUG: Focus change:android.widget.EditText dispkey:true

画面変更とフォーカスチェンジの順番がちょっとおかしい時がある。
この場合、同一ミリsec(11:57:36.829)に2つブロードキャスト呼ばれているから、どっちかが無視されちゃう。
だから、消えない時もあるし、消える時もある。

でも、コレってココまで来るとどうしようもない。
イベント少し纏めようかなぁ。

あと、Viewが変わった事でマーカーONにしろって投げるんだけど、履歴から戻るような奴(?)に関してはView変更イベントが走らないので、「ホームまで行かないと戻らない」みたいな事になることがあります。
これ、今調査中というか、何も飛んでこないから動きようが無い。
どうしようかなぁ。

例)MMS表示してバックで戻っているところだけど、ホームに戻る前にウィンドウチェンジが来ない。
07-03 12:24:42.519: DEBUG: Window state change:com.android.mms.ui.ConversationComposer dispkey:false
07-03 12:24:44.854: DEBUG: Focus change:android.widget.EditText dispkey:false
07-03 12:24:44.854: DEBUG: send DISP TYPE_VIEW_FOCUSED
07-03 12:24:45.244: DEBUG: Window state change:com.android.mms.ui.ConversationComposer dispkey:true
07-03 12:24:45.244: DEBUG: Focus change:android.widget.EditText dispkey:true
  想定ではココにWindow state changeが来るはず
07-03 12:24:48.999: DEBUG: Window state change:sx4s9xdw.stoichome.StoicHomeActivity dispkey:true

[キーボードIN/OFFモニタ][FlipClip]やっぱちょっと甘かったかなぁ。


動かないアプリ結構あったみたい。
ごめんなさい。
↑
マーケット上で謝れってw

(マーケットの履歴部分とかの最大文字数が少なすぎて書きたいことぜんぜん書けないんだよなぁ。ほんと難儀。)
 →コメントに対して返信が出来る機能が公になったら、いろいろめんどくさいかも知れないけど、こういうところでは役に立つな。

話ずれた。

いやー、本とすいません。
自分があまりアプリ入れてないから、すげーいけんジャン!!とか浮かれてたけど、甘かったみたいね。

っていうか、エディットテキストのカスタムビューなんてあまり使われていないと思っていたけど、意外と多いのね。
ぜひ、皆さんで使いやすいアプリを育てていきましょう(責任転化)!

あ、あと、内容的にはほぼ一緒なので、「キーボードIN/OFFモニタ」で報告受けた物に関しては「FlipClip」に随時反映させていきます。


うん。
あ、あと、いがいと反応が早くてびびった。
やっぱ、作ってよかった。

2012年7月2日月曜日

[キーボードON/OFFモニタ]作った!


公開しました。
キーボードON/OFFモニタ
https://play.google.com/store/apps/details?id=tora.mamma.edittextmonitor

この機能を利用するには、端末の設定画面から「ユーザ補助」→「キーボードON/OFFモニタ」をチェックしてください。
警告メッセジ出るけど、何も悪い事していないのでお気軽にw

どういったアプリかというと、
現在のフォーカスがどこにあるかを判断して「擬似的に」キーボードのON/OFFを判断。
キーボードがONの場合、"open.android.intent.action.DISP_KEYBOARD"ブロードキャストを投げる。
キーボードがOFFになると、"open.android.intent.action.HIDE_KEYBOARD"を投げる。

それだけ。
なので、このアプリだけでは何の役にも立ちませんw

■利用想定
僕が作成しているSwipeStarterなんですが、ディスプレイの最前面にマーカーと呼んでいるタッチポイントが配置されます。
最前面にある事により、現在どんな画面を操作していようが好きなアプリを呼び出せるっていうアプリなんですが、鬱陶しい問題として、「常に」最前面にマーカーが配置されちゃう。
いわゆる「誤爆」ってやつ。

で、要望として多いのが、せめてキーボード表示時にはマーカーを消してくれっていうもの。
今まで、コレがどうしても出来なかった。
※Androidからコレを判断する情報が何も提供されていないから。

で、IME(キーボード)に仕組みを実装してみたりしてたんですけど、結果ボツ。
→自分が普段使っているIMEを替えることにはものすごく抵抗がある為。

なんか使えるのないかなぁと資料あさっていたところ、このアプリに行き着きました。
SwipeStarterユーザなら使ってみる価値はあると思います(自画自賛)。
ぜひ。

■注意点
このアプリを利用する上で、注意点が一個あります。
動かない奴があります。
その時は、マーケットのコメ欄かメールで反応しないアプリ名を教えてください。
個別対応します。

~何で動かない物があるか~
入力項目にフォーカスが当たっているかを判断する為に、フォーカスが当たっている「クラス名」というのを見て判断しています。
「クラス名」って言うのは項目の名前みたいな物で、入力項目だよーとかボタンだよーっていうのが分かる。
基本的にはAndroid標準の物を使えるんですが、開発者はその標準の奴を改造出来ます。
改造した際には、そいつに名前をつけます(つけなきゃいけない)。
たとえば「hoge.hoge.MyCustomView」。
それがクラス名になります。
こうなると、入力項目かどうかを判断できません。
入力項目で無いと判断されると、動きません。
コレが理由です。

その場合は、「hoge.hoge.MyCustomView」は入力項目だよって覚えさせる必要があります。
→「マーケットのコメ欄かメールで・・・」

■開発者向け
こんなインテント欲しい人はそうそういないと思いますが、もし利用したければまにふぇすとに以下追記とレシーバを作成してください。
もちろん、「キーボードON/OFFモニタ」が有効でないと飛んでこないのでお忘れなく。



    
        
        
     
        
    

public class YourReceiver extends BroadcastReceiver {

 @Override
 public void onReceive(Context context, Intent intent) {

  if ("open.android.intent.action.DISP_KEYBOARD".equals(intent.getAction())) {
   //キーボードが表示された時の処理
  }
  if ("open.android.intent.action.HIDE_KEYBOARD".equals(intent.getAction())) {
   //キーボードが隠れた時の処理
  }
 }
}

2012年6月29日金曜日

[キーボードON/OFFモニタ]試用運転中


これ、意外といい感じになってきた。
電池もそんなに喰わない。
DeepSleepもちゃんと入るし。

ただ、ネックなのは下の2点
①「擬似的に」キーボードのON/OFFを判断している
②Viewのクラス名しか取れない

あくまで「擬似的に」なので、バックボタン等でキーボードを消した場合の判断が出来ない。
ただコレに関しては今のところそんなに不都合とは思わないかなぁ。
OpenWnnに実装した奴のほうが精度がいい(もちろんだけど)から、気持ち比較してしまう。
でも、まぁ許せる範囲。

問題は、こっち。
「クラス名」しか取得できない。
まぁ、人様のアプリの中の独自クラスのオブジェクトなんて取れるわけないから仕方ないんだけど、このアプリは今のフォーカスが入力項目にあるかどうかを判断=キーボード表示中としているから、現フォーカスが入力項目かどうかの判断が必須になってくる。
android標準の入力項目(以下)で作成されているアプリは問題ないんだけど、カスタムビュー作っちゃってると判断できない。
・android.widget.EditText
・android.widget.MultiAutoCompleteTextView
・android.widget.AutoCompleteTextView
・android.webkit.WebTextView

今、自分の端末でカスタムビューが確認できているのは以下
・SPモードメール
・instagram
・facebook
・G+

自分があんまりアプリ入れてないから参考にならないかもだけど、よく使いそうな奴らは試してみた。
絵文字出したり、ユーザ名を補完したりとかやっているのはカスタムビュー率高い。

コレをどうするかだよなぁ。
もう割り切って、動かないのがあったらコメ欄にアプリ名書いてもらうっていう状態で公開しちゃおうかなぁ。

まぁ、自分が使っている分にはぜんぜん問題ないので、来週頭にでも公開してみる。