ダダ漏れ日記

まあ、Androidのサンプル「ShapeDrawable1.java」にあったんだが、 コピペしやすいようにしてみた。 float[] outerR = new float[] { 4, 4, 4, 4, 4, 4, 4, 4 }; ShapeDrawable d = new ShapeDrawable( new RoundRectShape(outerR, null, null) ); d.getPaint().setShader( new LinearGradient(0, 0, 0, 25, new int[] { 0xFF707070, 0xFF000000 }, null, Shader.TileMode.CLAMP ) );

テキストの色をButton等のstateに合わせて変えることを、 xmlでやらずに自前でやるにはColorStateListを作成し、それをsetTextColorすれば良い。 以下、select状態で色が変わるTextViewを作成するサンプル TextView text = new TextView(this); text.setTextColor( new ColorStateList( new int[][] { new int[]{ android.R.attr.state_selected }, new int[]{ -android.R.attr.state_selected }, }, new int[] { Color.argb(0xff,0xff,0xff,0xff), Color.argb(0xff,0x8f,0x8f,0x8f), } ) );

TextViewに日本語の文字列をセットしてWRAP_CONTENTで表示するのって普通だが、 文字列が長いわけでもないのに、なぜか、最後の文字が改行して、２行表示になってしまうことが時々ある。 ちなみにAndroid2.3.5だ。 3.xや4.xでは検証してない。もしかしたら発生しないかもしれない。 また、xmlでレイアウトしたものではなく、自前でsetTextSize()にて設定を行った時の話だ。 調べてみると、どうもwidthが1pixelだけ足りない。 もしやと思って、フォントサイズを見てみると奇数になっていた。 それを+1して偶数にしたら、改行せず１行表示になった。 なるほど。 残念だ。フォントサイズには注意しよう。

2.x系でしか試していないが、日本語のBoldフォントが載っている機種は少ない。 載っている機種はSHARP製の端末だけのようだ。 これはつまり、せっかくBold設定にしても、ほとんどの端末では英語だけBoldで日本語は細いってことだ。 3.xや4.xでは改善されているのだろうか。 ところで、TextViewにBoldを自前で設定するやり方は下記の通り。 TextView text = new TextView(this); text.setTypeface( Typeface.DEFAULT_BOLD, Typeface.BOLD );

Viewのサイズをレイアウトに頼りたくない時、レイアウトに頼れない時、 そんなときはonMeasureをオーバーライドしやがれ。 下記はButtonのサイズを100x100にするサンプル Button btn = new Button( context ) { @Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { super.onMeasure(widthMeasureSpec, heightMeasureSpec); // このようにして自身のサイズをコントロールできるぞ setMeasuredDimension( 100 , 100 ); } }; 次は、親のレイアウト指定がWRAP_CONTENTだったら自分のサイズを主張する現実的なサンプル。 Button btn = new Button( context ) { @Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { super.onMeasure(widthMeasureSpec, heightMeasureSpec); float density = getResources().getDisplayMetrics().density; int hmode = MeasureSpec.getMode(heightMeasureSpec); int wmode = MeasureSpec.getMode(widthMeasureSpec); int hsize = MeasureSpec.getSize(heightMeasureSpec); int wsize = MeasureSpec.getSize(widthMeasureSpec); // 高さを求める int height = 0; if( hmode==MeasureSpec.EXACTLY ) { height = hsize;

Androidでは、pressやfocus等のstatement別にdrawableを指定するdrawableが作成可能だ。 xmlでは<selector>で指定を行う。 ところで、こういったリソースをxmlで書くのは非常にしんどいので事ある毎にコードで実装しているのだが、<selector>を自前で実装する方法を研究してみた。 それを実現するのは、StateListDrawableというDrawableだ。 下記は、StateListDrawableをButtonの背景色に適用するサンプル。 Button btn = new Button( context ); Drawable tomei = new ColorDrawable( Color.argb(0,0,0,0) ); Drawable tap = new ColorDrawable( Color.argb(0xff,0xff,0,0) ); Drawable normal= new ColorDrawable( Color.argb(0xff,0,0xff,0) ); StateListDrawable d = new StateListDrawable(); d.addState( new int[]{ android.R.attr.state_pressed }, tap ); d.addState( new int[]{ android.R.attr.state_focused }, tap ); d.addState( new int[]{ android.R.attr.state_enabled }, normal ); d.addState( new int[]{ -android.R.attr.state_enabled }, tomei ); btn.setBackgroundDrawable( d ); 面白いポイントは以下の通り。 orじゃなくて配列で指定するんだね。 xmlでいうfalseを指定するにはマイナス(minus)にするんだね！(1時間くらい探した・・・) ところで、Drawable.setStateの使い方がよくわからん。 例えば、下記の設定を行なってみたが効かない。 // 効いていない

SHARPは、ハイエンド端末を順次Android4.0(ICS)にバージョンアップしていくようですよ。 http://plusd.itmedia.co.jp/mobile/articles/1202/13/news083.html いよいよ4.0シフトが本格的に始まりつつありますね。 早く、ウチのXOOM（AUの）のバージョンアップ、始まらないかな・・・

for Windows ビルド出来るTarget及びTargetIDをリストアップする > android.bat list targets SDK Managerを起動する > android.bat update sdk プロジェクトをビルドするantを作成する > android.bat update project --path プロジェクトのパス これで作成されたBuild.xmlをantで実行するのだ。 罠 「Please provide a --target to the 'android.bat update' command.」 eclipseで使っているSDKと、Command lineで使ったSDKが異なることに気が付かず、古いTargetがDownloadされてなくてProjectのBuildに失敗する問題に30分悩んだ罠。ちなみにupdate projectに渡す--targetのtargetIDは、「android.bat list target」で得られるものであってAPI番号とは異なることに注意。

（Java+Eclipseが前提） 保守不能ソースに絶望 しても、それに立ち向かわなくてはいけない時、 解読可能な状態に修正したいのだが、 リスクを取らずに定型的に行えることがある。 １）変数とメソッドのスコープを必要最低限にしてみる。 protectedや無印になっている変数をprivateにしてみたり、 内部からしか呼ばれていないくせにpublicなメソッドをprivateにしてみたり。 無駄なSetterだったり。 すると、実は使ってない変数やメソッドが浮かび上がってくるので、それらを思い切って削除する。 削除まで行かなくとも、外部から操作される可能性を絞る事ができる。 ２）privateで一回しか呼ばれないようなメソッドは展開してしまう。 ３）privateで数回呼ばれているけど、数行しかないメソッドは思い切って展開してしまう。 ４）２，３をしたことによって判明した無駄なエラーチェックや重複している処理を省く。 メソッドにわかれているが故に無駄なnullチェックをしている場合がある。 ５）Beanを使っている場合、そのSetterが消せないかどうか検討する。 この場合、BeanとはSetterとGetterをpublicで装備しているクラスを指す。 例えばInputStreamからBeanを作成するような場合、Setterを消して、Beanにファクトリメソッドを作成するのが有効。それだけで、外部から操作される可能性を消すことができる。 ６）直感的に判りにくいクラス名や変数名は、Eclipseのリファクタリング機能でおもいっきり判りやすい名前に変える。 ローマ字だっていいじゃないか。"銘柄"を示すクラスを"Meigara"としてみるとか。 ７）無駄に使い回されているローカル変数は、中カッコを駆使する等して、いちいち宣言しなおすようにする。 アセンブラのレジスタじゃないんだから変数を無駄に使いまわすのはやめようぜ。 これにより、ロジックの切れ目が判りやすくなる。 ８）メンバにする必要のない変数は、メンバから外しローカル変数とする。 ９）パッケージがかなり細かく分かれている場合、特にinterfaceとかlistenerとかで分