Android3.0メモ：レンダリングのハードウェアアクセラレーション [スマートフォン]
「Google I/O 2011: Accelerated Android Rendering 」より
自分メモ：Android 3.0から通常のViewでもレンダリングにハードウェアアクセラレーションが可能になります。
ハードウェアアクセラレーションを有効にするためにはAndroidManifest.xmlのapplicationでandroid:hardwareAcceleratedをtrueにすればよい。
この指定はactivityにもできるそうで、特定のActivityだけアクセラレーションをOnにするとか、逆に特定のActivityだけOffにするとかの設定も可能。あとはプログラミングレベルでViewでもOn/Offが制御可能なようです。
＃ このことを知っていたら借用したXOOMやOptimus Padでアプリの動作検証を行ったときに
＃ Onにしてやってみればよかった・・・。エミュレータではGPUでの処理まではエミュレート
＃ してくれないだろうし・・・（そもそもAndroid3.0のエミュレータの動作は・・・・かなり厳しい）
アクセラレーションの仕組みはViewをOpen GL ESを使って描画するかどうかの違いのようです。OpenGL ESはCPUではなくGPUで処理されるので高速化が期待できるというわけです。また、さらにアクセラレーションが有効に機能するようにinvalidate()の仕組みも若干いじった模様。
とはいえ、どんなものでも高速化できるということではない。もちろん適切な構成でアプリケーションを作っておくことが重要。
以下はそのポイント（ビデオの35分過ぎから解説されています）
3,4はOpenGL ESのプログラミングを理解していれば当然のものですね。（といって私も理解しているわけではない。ただいま勉強中）
1. Don't user too many views
Keyp your hierarchy flat
2.Be careful of setAlpha()
Without hardware layers, it costs 2x the fill-rate
3.Reuse rendering objects
Don't create new Paints, Bitmaps, etc in drar()
4.Don't modify Bitmaps often
Every change cause a texture upload
5.Don't mofify Paths often
Every changes causes a new rasterization
6.Avoid overdraw
GPUs are fill-rate limited
7.Profile
DDMS and traceview are your friends
タブレットなどの登場で画面は大きくなり、レンダリングも高速化が必須となってきている今だからこそOpenGLってどんなものかを理解しておくのは非常に有用ですね。Google I/O 2011のセッションを見ていてそう感じました。今から基礎をおさえておこうということで以下の書籍で勉強中です。
ちなみに・・・Android3.0 （Honyomb) の主要な特徴は以下のセッションでご覧になれます。
System BarとかAction Barとかは実際の実装でも使うようになるのかな。もちろんFragmentもね・・・。
そのほか実際、どんな動きをするのか非常に参考になりますね。そうそうAndroid3.1からのUSBサポートもちょっと解説されています。
（GPUも強化され、どんどんネットブックに近づいているように思うのは私だけ？？）
自分メモ：Android 3.0から通常のViewでもレンダリングにハードウェアアクセラレーションが可能になります。
ハードウェアアクセラレーションを有効にするためにはAndroidManifest.xmlのapplicationでandroid:hardwareAcceleratedをtrueにすればよい。
この指定はactivityにもできるそうで、特定のActivityだけアクセラレーションをOnにするとか、逆に特定のActivityだけOffにするとかの設定も可能。あとはプログラミングレベルでViewでもOn/Offが制御可能なようです。
＃ このことを知っていたら借用したXOOMやOptimus Padでアプリの動作検証を行ったときに
＃ Onにしてやってみればよかった・・・。エミュレータではGPUでの処理まではエミュレート
＃ してくれないだろうし・・・（そもそもAndroid3.0のエミュレータの動作は・・・・かなり厳しい）
アクセラレーションの仕組みはViewをOpen GL ESを使って描画するかどうかの違いのようです。OpenGL ESはCPUではなくGPUで処理されるので高速化が期待できるというわけです。また、さらにアクセラレーションが有効に機能するようにinvalidate()の仕組みも若干いじった模様。
とはいえ、どんなものでも高速化できるということではない。もちろん適切な構成でアプリケーションを作っておくことが重要。
以下はそのポイント（ビデオの35分過ぎから解説されています）
3,4はOpenGL ESのプログラミングを理解していれば当然のものですね。（といって私も理解しているわけではない。ただいま勉強中）
1. Don't user too many views
Keyp your hierarchy flat
2.Be careful of setAlpha()
Without hardware layers, it costs 2x the fill-rate
3.Reuse rendering objects
Don't create new Paints, Bitmaps, etc in drar()
4.Don't modify Bitmaps often
Every change cause a texture upload
5.Don't mofify Paths often
Every changes causes a new rasterization
6.Avoid overdraw
GPUs are fill-rate limited
7.Profile
DDMS and traceview are your friends
タブレットなどの登場で画面は大きくなり、レンダリングも高速化が必須となってきている今だからこそOpenGLってどんなものかを理解しておくのは非常に有用ですね。Google I/O 2011のセッションを見ていてそう感じました。今から基礎をおさえておこうということで以下の書籍で勉強中です。
OpenGLで作る Android SDKゲームプログラミング
- 作者: 中島 安彦
- 出版社/メーカー: インプレスジャパン
- 発売日: 2011/04/07
- メディア: 単行本（ソフトカバー）
ちなみに・・・Android3.0 （Honyomb) の主要な特徴は以下のセッションでご覧になれます。
System BarとかAction Barとかは実際の実装でも使うようになるのかな。もちろんFragmentもね・・・。
そのほか実際、どんな動きをするのか非常に参考になりますね。そうそうAndroid3.1からのUSBサポートもちょっと解説されています。
（GPUも強化され、どんどんネットブックに近づいているように思うのは私だけ？？）
ついにガラケーがAndroid化：ソフトバンク 007SH [スマートフォン]
操作性がほぼ従来のフィーチャーフォン（ガラケー）のAndroid端末が登場、ソフトバンク 007SH
Androidが登場したときから、この流れはぜったいに来ると信じていました。
つい先日auがかなり近づいたかなと思わせるIS11SHを発表しましたが、同じシャープAQUOS PHONEでもソフトバンクのほうがさらにフィーチャーフォンに近いようです。
どんな操作性になるんだろう？？アプリを作る側にとってはそれが一番の関心事。
フィーチャーフォンに近いとなるとディスプレイにタッチすることは少なくなるんじゃないかなー、キー操作が大半を占めるんじゃないかなーと想像しています。
今までiPhoneとAndroidと同じような操作性で、と考えてデザインしてきましたがAndroidではキー操作をより意識した設計にする必要があるんだろうなー。
この映像を見るとやっぱりほとんどキー操作ですね。なかなか面白い！！
これに加えてタブレットの操作性も考慮していくと・・・、うーんどう実装すれば一番いいのか難しい。
Androidが登場したときから、この流れはぜったいに来ると信じていました。
つい先日auがかなり近づいたかなと思わせるIS11SHを発表しましたが、同じシャープAQUOS PHONEでもソフトバンクのほうがさらにフィーチャーフォンに近いようです。
どんな操作性になるんだろう？？アプリを作る側にとってはそれが一番の関心事。
フィーチャーフォンに近いとなるとディスプレイにタッチすることは少なくなるんじゃないかなー、キー操作が大半を占めるんじゃないかなーと想像しています。
今までiPhoneとAndroidと同じような操作性で、と考えてデザインしてきましたがAndroidではキー操作をより意識した設計にする必要があるんだろうなー。
この映像を見るとやっぱりほとんどキー操作ですね。なかなか面白い！！
これに加えてタブレットの操作性も考慮していくと・・・、うーんどう実装すれば一番いいのか難しい。
Android：フリック／スワイプジェスチャーの実装での注意事項 [スマートフォン]
Androidのフリック／スワイプジェスチャーの実装はあちこちで紹介されているのでご存じの方も多いはず。
Googleで『Android swipe』で検索すればごろごろしています。例えば
http://www.codeshogun.com/blog/2009/04/16/how-to-implement-swipe-action-in-android/
なんかは結構そのまま使えます。
問題は実装、生成したGestureDetectorをどのView/ViewGroupに適用するかということ（最終的にはActivityに適用することもありますね）。
AndroidOSのバージョンによってうまく動いたり動かなかったりするんです。
私が経験した例で言えば、ScrollViewの内側にあるLinearLayoutにGestureDetectorを適用した場合。（ScrollViewには適用していない）
Android2.1までは期待通りの動きをしていたんです。でもAndroid2.2で突如まったく動かなくなった・・・。
最初は原因がわからず困っていたのですが、LinearLayoutでの適用を止めScrollViewに適用するように変更したところAndroid1.6～Android2.2までは期待通りの動きをしました（たぶんAndroid2.3以降でも大丈夫）。
View自体でフリック／スワイプジェスチャーを補足しているScrollViewなどの内側にGestureDetectorを適用するのはいろいろ問題になりそうだ、と今ならば理解できるのですが以前実装したときはそこまで考えなかった。
しかもLayoutはxmlで規定し、ソースコードではレイアウト変更に対応しやすいようにしようとソースコード側はViewGroupで変数を定義するという意識が働いていたの、ScrollViewとかあまり意識しないようにした。
あまり考えなかった結果がOSによって動いたり動かなかったりという結果になり、数時間デバッグを繰り返しjavadocとにらめっこしてやっと理解する羽目に・・・。
タブレットなどを使うとフリック／スワイプジェスチャーを独自実装することも増えてくるでしょう。皆さんもジェスチャーそのものでなく、どこにそれを適用すべきかをよーく考えて実装しましょう。
Googleで『Android swipe』で検索すればごろごろしています。例えば
http://www.codeshogun.com/blog/2009/04/16/how-to-implement-swipe-action-in-android/
なんかは結構そのまま使えます。
問題は実装、生成したGestureDetectorをどのView/ViewGroupに適用するかということ（最終的にはActivityに適用することもありますね）。
AndroidOSのバージョンによってうまく動いたり動かなかったりするんです。
私が経験した例で言えば、ScrollViewの内側にあるLinearLayoutにGestureDetectorを適用した場合。（ScrollViewには適用していない）
Android2.1までは期待通りの動きをしていたんです。でもAndroid2.2で突如まったく動かなくなった・・・。
最初は原因がわからず困っていたのですが、LinearLayoutでの適用を止めScrollViewに適用するように変更したところAndroid1.6～Android2.2までは期待通りの動きをしました（たぶんAndroid2.3以降でも大丈夫）。
View自体でフリック／スワイプジェスチャーを補足しているScrollViewなどの内側にGestureDetectorを適用するのはいろいろ問題になりそうだ、と今ならば理解できるのですが以前実装したときはそこまで考えなかった。
しかもLayoutはxmlで規定し、ソースコードではレイアウト変更に対応しやすいようにしようとソースコード側はViewGroupで変数を定義するという意識が働いていたの、ScrollViewとかあまり意識しないようにした。
あまり考えなかった結果がOSによって動いたり動かなかったりという結果になり、数時間デバッグを繰り返しjavadocとにらめっこしてやっと理解する羽目に・・・。
タブレットなどを使うとフリック／スワイプジェスチャーを独自実装することも増えてくるでしょう。皆さんもジェスチャーそのものでなく、どこにそれを適用すべきかをよーく考えて実装しましょう。
Android3.0とAndroid1/2の違い（ステータスバー） [スマートフォン]
Android1/2のステータスバーって画面上部にありますよね。
この上部ステータスバーの高さを取得するための方法として結構有名な手段がこれ。
Rect rect= new Rect();
Window window= activity.getWindow();
window.getDecorView().getWindowVisibleDisplayFrame(rect);
int statusBarHeight= rect.top;
ところがですね～、Android3（タブレット）ではこれが通用しないんです。なぜならば・・・ステータスバーが画面下部に移ってしまったから。（XOOMなどの画面サンプルをよくご覧になっていただければわかると思います）
上記のコードではrect.topは0となります。
Android3の場合、（画面全体のサイズ- Rect.height）でステータスバーの高さが計算できるのかな。（未確認です）
Android3.1以降では通常のスマートフォンでも利用できるように最適化していくと先日のGoogle I/O 2011で発表されていました。その時ステータスバーが上部に表示されるのか、下部に表示されるのかわかりませんが、どちらに表示されてもいいように実装するのがよさそうです。
（今のところ両方ということはなさそうですのでRect.topが0なら画面下部にステータスバーがあると想定してよさそう）
この上部ステータスバーの高さを取得するための方法として結構有名な手段がこれ。
Rect rect= new Rect();
Window window= activity.getWindow();
window.getDecorView().getWindowVisibleDisplayFrame(rect);
int statusBarHeight= rect.top;
ところがですね～、Android3（タブレット）ではこれが通用しないんです。なぜならば・・・ステータスバーが画面下部に移ってしまったから。（XOOMなどの画面サンプルをよくご覧になっていただければわかると思います）
上記のコードではrect.topは0となります。
Android3の場合、（画面全体のサイズ- Rect.height）でステータスバーの高さが計算できるのかな。（未確認です）
Android3.1以降では通常のスマートフォンでも利用できるように最適化していくと先日のGoogle I/O 2011で発表されていました。その時ステータスバーが上部に表示されるのか、下部に表示されるのかわかりませんが、どちらに表示されてもいいように実装するのがよさそうです。
（今のところ両方ということはなさそうですのでRect.topが0なら画面下部にステータスバーがあると想定してよさそう）
auのMOTOROLA XOOMを触ってみました [スマートフォン]
仕事柄さまざまな端末に触れる機会があります。
今回はauのMOTOROLA XOOMに触れてきました。
実は同時にdocomoのOptimus padにも。Android3.0=Honycombだからって壁紙をHonycombにするとは・・・安易だ。
XOOMはOptimus Padよりもほんのひとまわり大きいサイズ。表示される画面はXOOMもOptimus Padも見た目はほとんどか（まったくと言っていいほど）わらない。Optimus Padは画面内に「設定」ボタンが配置されていたけど、XOOMにはなかった（メニューからたどる）。自分で画面上に配置することもできるとは思いますけど、「設定」を表に出すか、それとも出さないかは結構キャリアさんの方針で決まっているのかなーという感じがします。docomoさんはわりとわかりやすいところに配置するけど、auさんはそれをしないパターンが多い。
さて、本当ならファーストインプレッションといきたいところですが、私が行ったのは自分たちのアプリが動くかどうかというテストなのであまり参考にならない。ファーストインプレッションはこちらの記事を参考にするといいでしょう。
ちなみに１つだけ技術情報。
（本当はもう１つ getResources()問題があったのですが、それはOptimus Padを使ったときに解決したのでそちらを参照くださいませ）
アプリではTelephonyManager.getDeviceId()を使っているのですがXOOMではこれはNULLで返ってきてしまう。電話機能がないし当然ですよね・・・。
では代わりになにを使おうかと悩んだ末、ANDROID_IDを使って解決。
ANDROID_IDは一部端末でユニークではないとか、ある特定の条件の場合書き換えられてしまうという問題はあるのですが、docomoのかんたんログインのようなことをやるわけではないので、なんとかなるのかと判断。プライマリはgetDeviceId()だし。
Skypeの脆弱性の問題以降、「Androidはセキュリティに問題がある」と勘違いした人がいろいろな質問をしてくる。
セキュリティには気を使いつつ、どこまでが問題になってどこからが問題にならないかをしっかり考えて対処しないとあとで大変なことになりますね。
というか、666で権限設定していたのって、さすがにSkype甘すぎない？？？
で、なぜか「禁断のアプリ」と言われた「Skype au」にはこの脆弱性は存在しないんだそうです。
ということはSkype側は問題に気づいて修正していたってことか？（しかも2010年11月以前に！！）
（IS03でroot化して確認しようかと考えちゃいましたけど、運用機をroot化するのは気が引けるので断念）
だんだんXOOMからそれていくのでこの辺で終わりにします。
今回はauのMOTOROLA XOOMに触れてきました。
実は同時にdocomoのOptimus padにも。Android3.0=Honycombだからって壁紙をHonycombにするとは・・・安易だ。
XOOMはOptimus Padよりもほんのひとまわり大きいサイズ。表示される画面はXOOMもOptimus Padも見た目はほとんどか（まったくと言っていいほど）わらない。Optimus Padは画面内に「設定」ボタンが配置されていたけど、XOOMにはなかった（メニューからたどる）。自分で画面上に配置することもできるとは思いますけど、「設定」を表に出すか、それとも出さないかは結構キャリアさんの方針で決まっているのかなーという感じがします。docomoさんはわりとわかりやすいところに配置するけど、auさんはそれをしないパターンが多い。
さて、本当ならファーストインプレッションといきたいところですが、私が行ったのは自分たちのアプリが動くかどうかというテストなのであまり参考にならない。ファーストインプレッションはこちらの記事を参考にするといいでしょう。
Android3.0搭載のタブレット端末「MOTOROLA XOOM Wi-Fi」を試す (1/2) - 電子書籍情報が満載! eBook USER
ちなみに１つだけ技術情報。
（本当はもう１つ getResources()問題があったのですが、それはOptimus Padを使ったときに解決したのでそちらを参照くださいませ）
アプリではTelephonyManager.getDeviceId()を使っているのですがXOOMではこれはNULLで返ってきてしまう。電話機能がないし当然ですよね・・・。
では代わりになにを使おうかと悩んだ末、ANDROID_IDを使って解決。
ANDROID_IDは一部端末でユニークではないとか、ある特定の条件の場合書き換えられてしまうという問題はあるのですが、docomoのかんたんログインのようなことをやるわけではないので、なんとかなるのかと判断。プライマリはgetDeviceId()だし。
Skypeの脆弱性の問題以降、「Androidはセキュリティに問題がある」と勘違いした人がいろいろな質問をしてくる。
セキュリティには気を使いつつ、どこまでが問題になってどこからが問題にならないかをしっかり考えて対処しないとあとで大変なことになりますね。
というか、666で権限設定していたのって、さすがにSkype甘すぎない？？？
で、なぜか「禁断のアプリ」と言われた「Skype au」にはこの脆弱性は存在しないんだそうです。
ということはSkype側は問題に気づいて修正していたってことか？（しかも2010年11月以前に！！）
（IS03でroot化して確認しようかと考えちゃいましたけど、運用機をroot化するのは気が引けるので断念）
だんだんXOOMからそれていくのでこの辺で終わりにします。
Android搭載のWALKMAN発表 [スマートフォン]
ソニーエリクソンがAndroid搭載のWalkman W8を発表。
こちらが公式発表ページ(英語）。
iPod touch対抗のAndroid Walkmanはぜひ欲しいと思っていたんですよね～。音楽クラウドもいっしょに考えてくれるなら結構欲しいですね。
つい先日WALKMANを購入したのですが、iPod touchではなくWALKMANにしたのはノイズキャンセリング機能を搭載していること。通勤時に使うことを考えるとノイズキャンセリング機能の効果は絶大ですよ！！
その点を考えてもWALKMANにしてよかったかなと。
ただ、データ転送するためにPCに接続しなければならないのが面倒。CDのような大容量なものなら仕方ないにしてもポッドキャストとか少量データはWiFi経由で自動的に取り込めればとても便利。
AndroidならDropboxのようなソフトと組み合わせてもなかなか使えるし、勉強用としてEvernoteと組み合わせても面白いし。
早いところ出してくれないかな～。
こちらが公式発表ページ(英語）。
iPod touch対抗のAndroid Walkmanはぜひ欲しいと思っていたんですよね～。音楽クラウドもいっしょに考えてくれるなら結構欲しいですね。
つい先日WALKMANを購入したのですが、iPod touchではなくWALKMANにしたのはノイズキャンセリング機能を搭載していること。通勤時に使うことを考えるとノイズキャンセリング機能の効果は絶大ですよ！！
その点を考えてもWALKMANにしてよかったかなと。
ただ、データ転送するためにPCに接続しなければならないのが面倒。CDのような大容量なものなら仕方ないにしてもポッドキャストとか少量データはWiFi経由で自動的に取り込めればとても便利。
AndroidならDropboxのようなソフトと組み合わせてもなかなか使えるし、勉強用としてEvernoteと組み合わせても面白いし。
早いところ出してくれないかな～。
Android 3.0のgetResources()でNullPointerException [スマートフォン]
LGのOptimus Pad (L-06C)をお借りできたので、アプリケーションをテスト！！
と思ったのですがいきなり起動時からView.getResources()でNullPointerException・・・。えー、なんでー。
APIの仕様が変わったかな～とJavadocを確認するも特にそうした記述はなく・・・。
実はこのアプリケーション、メインActivityが表示する前(onResume)で特定の条件の場合に別の画面に遷移しているんです。どうもこれが悪い可能性が・・・。
起動時のNullPointerExceptionはいったん無視しても問題ないので、その回避コードを埋め込み再度テスト。
おお、今度は動く・・・・。
ソースコードをちゃんと確認していないのですが、View.getResources()で取得できるResourcesオブジェクトがlate bindingでもされるようになったのかなーと勝手に想像して、今回は回避コードをとりあえず正式コミット。
Android2.xまではこんな現象発生しなかったんだけどな～。
どなたか同じ現象に遭遇し、ちゃんと原因を特定した方がいらっしゃいましたらぜひお教えいただきたく。
と思ったのですがいきなり起動時からView.getResources()でNullPointerException・・・。えー、なんでー。
APIの仕様が変わったかな～とJavadocを確認するも特にそうした記述はなく・・・。
実はこのアプリケーション、メインActivityが表示する前(onResume)で特定の条件の場合に別の画面に遷移しているんです。どうもこれが悪い可能性が・・・。
起動時のNullPointerExceptionはいったん無視しても問題ないので、その回避コードを埋め込み再度テスト。
おお、今度は動く・・・・。
ソースコードをちゃんと確認していないのですが、View.getResources()で取得できるResourcesオブジェクトがlate bindingでもされるようになったのかなーと勝手に想像して、今回は回避コードをとりあえず正式コミット。
Android2.xまではこんな現象発生しなかったんだけどな～。
どなたか同じ現象に遭遇し、ちゃんと原因を特定した方がいらっしゃいましたらぜひお教えいただきたく。
やっとIS03電池充電器が登場・・・ [スマートフォン]
バッテリーの消費がかなり激しいIS03。日々実感しています。
発売前キャンペーンでKDDIさんから予備電池を貰っていましたが本体に入れないと充電できないという片手落ちなサービス・・・。単体充電器出さないと意味ないんじゃない？？とずっと思ってきましたがやっと願いが通じました。
でもね・・・3,000円弱ってちょっと高くないですか？？発売前キャンペーンで予備電池をプレゼントした人全員にこの充電器もプレゼント！！ってことにはならないかな～。
発売前キャンペーンでKDDIさんから予備電池を貰っていましたが本体に入れないと充電できないという片手落ちなサービス・・・。単体充電器出さないと意味ないんじゃない？？とずっと思ってきましたがやっと願いが通じました。
でもね・・・3,000円弱ってちょっと高くないですか？？発売前キャンペーンで予備電池をプレゼントした人全員にこの充電器もプレゼント！！ってことにはならないかな～。
「Androidアプリケーション開発ガイド ―HTML＋CSS＋JavaScriptによる開発手法」 [スマートフォン]
以前チェックしていた「Building Android Apps with Html, Css, and Javascript」の日本語版が出るようです。
実は「Building Android Apps .. 」は電子書籍で手に入れて読んでいるのですが、その内容は「iPhoneアプリケーション開発ガイド・・」とかなり重複していました。すでに「iPhone～」を購入している人は一度実際に中身をみてから「Android Apps・・・」を購入するか考えたほうがよいと思う・・・。ここまでそのままか～と驚くくらいですから。
実は「Building Android Apps .. 」は電子書籍で手に入れて読んでいるのですが、その内容は「iPhoneアプリケーション開発ガイド・・」とかなり重複していました。すでに「iPhone～」を購入している人は一度実際に中身をみてから「Android Apps・・・」を購入するか考えたほうがよいと思う・・・。ここまでそのままか～と驚くくらいですから。
「Building Android Apps With Html, Css, and Javascript」
「iPhoneアプリケーション開発ガイド ―HTML+CSS+JavaScript による開発手法」のAndroid版が9月に発売されるようです～。
iPhone用、Android用ではなくって様々なスマートフォンデバイスをまとめてサポートできるようにしてくれないかな～。
Androidアプリケーション開発ガイド ―HTML＋CSS＋JavaScriptによる開発手法
- 作者: Jonathan Stark
- 出版社/メーカー: オライリージャパン
- 発売日: 2011/02/24
- メディア: 大型本
iPhoneアプリケーション開発ガイド ―HTML+CSS+JavaScript による開発手法
- 作者: Jonathan Stark
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/08/07
- メディア: 大型本
Android:EditText入力時に改行できない！？ [スマートフォン]
自分が持っているIS03（iWnn for SH）では発生しない問題だったのですが、以下のような現象がいくつかの端末で発生していました。
端末を横向きで使用する際、EditTextのフィールドでソフトキーボード上の改行を押しても実際には改行されず空白となる。ただし、改行されないのはIMEの表示上だけで実際には改行コードが設定される。
この現象は端末を縦向きで使用した場合は発生しません。横向きでIMEが画面を奪うケースで発生しました。
解決法
EditTextのsetRowText()で
android.text.InputType.TYPE_TEXT_FLAG_IME_MULTI_LINE
を指定すると改行されるようになります。
なぜ縦だと問題が発生しないのか、iWnn for SHと他のiWnnと何が違うのか、そういったことはよくわかりませんが・・・。
同じことで悩んでいる人がいるかもしれないので一応メモということで掲載しておきます。
端末を横向きで使用する際、EditTextのフィールドでソフトキーボード上の改行を押しても実際には改行されず空白となる。ただし、改行されないのはIMEの表示上だけで実際には改行コードが設定される。
この現象は端末を縦向きで使用した場合は発生しません。横向きでIMEが画面を奪うケースで発生しました。
解決法
EditTextのsetRowText()で
android.text.InputType.TYPE_TEXT_FLAG_IME_MULTI_LINE
を指定すると改行されるようになります。
なぜ縦だと問題が発生しないのか、iWnn for SHと他のiWnnと何が違うのか、そういったことはよくわかりませんが・・・。
同じことで悩んでいる人がいるかもしれないので一応メモということで掲載しておきます。
たーとる さん
-
nice! 475
記事 4429
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
携帯版URL
