投稿

2012の投稿を表示しています

[Java]BufferedImageとピクセル操作

JavaのImage関連って思いの外複雑でびっくりした。 古の方法である配列によるピクセル操作をやりたいだけなのにすごく苦労したぞ。 PixelGrabberとか、MemoryImageSourceとかWritableRasterとかかなり迷走した挙句、以下のシンプルな方法に行き着いた。 public void sample() throws IOException { // PNG画像を読み込み BufferedImage img1 = ImageIO.read( new File("ebi02.png") ); int w = img1.getWidth(); int h = img1.getHeight(); // ピクセルを配列として取得 int[] px = img1.getRGB( 0,0, w, h, null, 0, w ); // グレースケール化 for( int i=0; i<px.length; i++ ) px[i] = toGray( px[i] ); // 新しいBufferedImageを作成し、ピクセルを配列でセット BufferedImage result = new BufferedImage( w, h, BufferedImage.TYPE_INT_RGB ); result.setRGB( 0,0, w, h, px, 0, w ); // BufferedImageをPNGとして保存 ImageIO.write( result, "png", new File("gray.png") ); } private int toGray( int argb ) { int a = (argb>>24) & 0xff; int r = (argb>>16) & 0xff; int g = (argb>>8 ) & 0xff; int b = (argb ) & 0xff; int avr = ( r + g + b ) / 3; int gray = avr & 0xff; return (

Android・・・テキスト描画あれこれ, ascent(), descent()等

Androidのテキスト描画に必要なTipsをメモ。 存在に忘れがちな横方向のAlignや、意外に正解がわかりにくい縦方向のセンター合わせ等。 ascentとdescent Paint及びFontMetricsで取得可能なascentとdescent。 テキスト描画の原点となるbaselineから上方向の高さがascentで、下方向の高さがdescentとなる。 baselineを割ってdescent領域に入るのは例えば小文字の"j"等だ。 しかし理解しづらいのは、ascentが負の値であることだ。 これは、画面の座標系を思い浮かべてbaselineを(0,0)と考えるとイメージしやすい。 つまり、画面上にはみ出すascentが負、画面内に入るdescentが正、となる。 テキスト用Paintの作成 TextPaint tp = new TextPaint(); tp.setColor( Color.WHITE ); // アンチエイリアスON tp.setAntiAlias( true ); // 塗りつぶしのみ。STROKEを入れると太くなる。STROKEだけだと中抜き tp.setStyle( Style.FILL ); // テキストのフォントサイズ。Paintに直接指定する場合、Density等の考慮が必要。 tp.setTextSize( 11f * density ); 縦方向にセンター合わせ @Override protected void onDraw(Canvas canvas) { // 領域の高さ int areaHeight = getHeight(); FontMetrics fm = tp.getFontMetrics(); // フォントの高さを求める float fh = fm.descent - fm.ascent; // センター合わせにしたあと、Baselineの位置を求めるためにdescentを引く float ty = (areaHeight/2f) + (fh/2f) - fm.descent; canvas.drawText( "text", 0, ty, tp ); } 横方向に原点を右端で設定する

タッチタブレット「BAMBOO Touch」を買ってみた

イメージ
最近、マウスを持つのがツライ。 接地している手首、及び、左クリックする指先が痛いのだ。 良いマウスに変えたら状況が変わる可能性もあるが、 ここは思い切ってタッチパッドってやつを買ってみた。 スマホやMacのマウス等を見て、タッチもいいかな、と最近思ってきたのが理由だ。 色々迷って、最終的に購入したのは 「WACOM BAMBOO TOUCH CTT-460」 安い割にマルチタッチや、外部機能ボタンが4つあったりと高機能っぽい。 でも、Amazonのレビューが最悪。。 でも、よく見ると「ペンに対応してないので星ひとつ」というようなWACOMならではコメントが多いので、ペン入力が不要な自分には関係のないと判断した。 ところで、調べてみると、このシリーズには上位機種としてペン入力にも対応したモデルがちゃんとある。但しお値段がお高め。ペン入力が必要だったらこちらが必要だ。 というわけで、使い始めて5日間。 確かに、マウスの時、痛かった手首と指先は、痛くない。 しかし、手の甲の筋肉が疲れるようになった。 これは、今までマウスに乗っけていた指を持ちあげなくてはいけなくなったためだ。 (小さいマウスを使っても同じような筋肉を使う) そして、操作に時間が掛かる(笑) やっぱり思ったところにスパっと動かせない。 これは慣れの問題もあるかもしれない。 なんせ、マウスはもう20年近くも使ってきたのだ。 マウスの方が操作しやすくて当然だろう。 というわけで、しばらくはマウスとタッチパッドを使いわけてみようかと思う。 ところで、2本指でスライドするスクロールの精度が悪すぎて使えねぇって思ってたのだが、ドライバを最新版にしたらかなりまともになった。 スマホみたいな慣性もつくようになってる。これなら使えそうだ。 (他にもコントロールパネルの設定が増えていたり、設定が保存されないバグが修正されていたりと、ドライバの更新はマスト事項になっている。ちなみに、上位機種は最近のロットに最新ドライバを適用すると、3~4点タッチが可能になるらしい。コイツはどうやっても2点止まりらしいが)

Bluetooth開発

AndroidとPCを組み合わせて何かできそうだ。。 AndroidでのBluetooth実装 http://www.atmarkit.co.jp/fsmart/articles/android35/01.html PCでのBluetooth実装 http://www.hoge256.net/2009/03/322.html AndroidとMacをSPPで接続 http://d.hatena.ne.jp/propella/20120403/p1 HIDプロファイル・・・PICでHIDデバイスを作成する? http://phys.sci.hokudai.ac.jp/LABS/yts/pic/GB002/hid.html PCをHIDデバイス(マウス)として認識させる実験 http://homebrew.jp/show?page=1203 AndroHid・・・AndroidをHIDデバイスにする? http://code.google.com/p/androhid/wiki/AndroHid やはり、L2CAPを実現するのに、NDKでBlueZを組み込むのか。

Android:端末にインストールされているパッケージ名

端末にインストールされているパッケージ名を参照したい時はadbを使用する。 adb.exeの場所 AndroidSDKのplatform-tools よくある例) C:\Program Files\Android\android-sdk\platform-tools 使い方 コマンドラインで以下のコマンドを使用する。 (adb.exeにパスが通っている必要あり) adb shell pm list packages 抽出したい場合 例)パッケージ名にyyyが入っているもののみ表示 adb shell pm list packages|find "yyy" 参考 http://d.hatena.ne.jp/shima111/20110903/p1

ルルド マッサージクッションを買ってみた

イメージ
何を隠そうワタクシは「肩コリスト」だ。 まぁ、「肩コリスト」なんて言葉勝手に作ったのだが。 要は、肩こりがヒドイって事だ。 一日中デスクに座って、ディスプレイとにらめっこして、 キーボードカチャカチャやってたらそりゃ肩こるんだが。 特に30代後半になってから、ホント無理できなくなってきた(泣) 整体に通ってみたりもしたが、正直、行くのが面倒なんだよな。。 自宅でなんとかなる方法・・・と考えて、マッサージチェアを思いつくが、 あったら良いが、買う金も置き場所もない。 山善の肩たたき器「トルトン」というのを見つけて 家電量販店で試してみたところ、確かにスゴイその衝撃にびっくり。 しかし、同時に、叩くよりも肩もみしてほしいことに気づき、却下。。 そして、最終的に買ってみたのが「ルルド マッサージクッション」 家電量販店のお試しコーナーの中にコレが置いてあって、 そのもみっぷりに感動し、帰ってからAmazonで注文したのだ。 ポイントは、腰も肩も対応、クッションという手軽さ、おしゃれ、 試しても良いと思える限界ギリギリの値段等があるが、 なんといっても「もみ」がパワフル。 体位は工夫する必要があるが、 もみ疲れするくらいパワフル。 これを2日にいっぺんくらいの頻度でやるようになって、 肩も腰も楽になった。 おすすめ体位その1:「腰」 枕の高さと、足の伸ばすかひざを立てるかで、もみの強さを調節可能。 おすすめ体位その2:「肩」 これはマニュアルにも記載あり。 思ったより気持よく、これをやっていると寝てしまう。 会社にもひとつ欲しいな。

Bluetoothレシーバー Logitec LBT-AR120を買ってみた

イメージ
っていうかiPod touch買った。 ごめんなAndroid。 まあ、昔から持っていたiPod shuffleが限界に来たからなんだけどね。 で、無線好きの私としてはせっかくなのでBuletoothレシーバーを買ってみた。 レシーバーは、好きなイヤホンやヘッドホンが繋げるのが特徴。 機種はLogitec LBT-AR120。実売価格はヨドバシで3,000円程度。 最低限の機能がついたエントリーモデルだ。 まあ、最初なんで、お試し半分なので安いのでいいやってことで。 ちなもに、写真にはイヤホン付いてるけど、イヤホンは付属してません。 iPod touchとは問題なくペアリング。 使用も全く問題がない。 音質も僕は特に気にならない。 でもLEDが眩しすぎる。 接続中は青色LEDが一定間隔で点滅するのだが、胸ポケットに入れていても光っているのがはっきりわかるくらい眩しい。 テープかなんか貼らないとちょっと恥ずかしいかもね。。 あと、レシーバーを胸ポッケに、iPod touchを背中のリュックに入れて街を歩いていると、音が止まることが度々あった。同じところで同じ現象が発生するので、お店等のWi-Fiと干渉しているんだと思う。ちなみに、iPod touchも胸ポッケに入れてみたら大丈夫だった。距離の問題かもしれない。 とはいうものの、音楽聞いていてもコード気にせずiPod touchいじれるのはやっぱり便利。 そして、イヤホンのコードを長くしなくてよいというのが、自分としてはとってもウレシイ。 耳から胸ポッケまでの長さがあればよいので、取り回しがとっても楽なんだよね。 この長さだったらそれほどコード絡まないし。 いや~便利。

Android...EditText

EditText、地獄だぜ。 ヒントになるサイトをまとめてみた。 文字数制限、入力制限、ヒント表示 EditTextの文字制限/ヒントとかについて EditTextに文字数制限を課す方法。(xmlだとandroid:maxLength) EditText edit = new EditText( this ); edit.setFilters( new InputFilter[]{ new InputFilter.LengthFilter(2) } ); ソフトキーボードを消す http://y-anz-m.blogspot.jp/2009/12/android.html ソフトキーボードを表示する ソフトキーボードの制御 ※「別アクションでソフトキーボードを制御」の項、参照 inputMethodManager#showSoftInput(); TextViewのソース http://tools.oesf.biz/android-2.3_r1.0/xref/frameworks/base/core/java/android/widget/TextView.java

auのxoomでAndroid4.0キタ

auのxoomでandroid4.0のバージョンアップが始まった! 驚いたことにgoogleplayでバージョンアップの案内が表示された。 勝手に表示されたから最初何の事か解らなかった(^_^;) その時に、オプションとして別のバイナリが選べるような表示が出ていたがロクに調べないで普通のダウンロードを開始してしまった。 もしそれが英語版だったら、そっちの方が良かったと若干後悔… (Jerrybeansの時、アップデート早いだろうから…) インストールはいつも通り特に問題なし。 これでついにウチのxoomもAndroid4.0だ! 全体の動作が軽快だが、 何と言ってもChromeだ。動作が軽快すぎる!今までの苦労は何だったのか!? この投稿もChromeでbloggerを開いて入力しているが、まるでネイティブアプリのごとく軽快だ。 但し、物理キーボードによる日本語入力が出来なくなってしまった模様。 コチラは引き続き調査する必要がある。

Android:ArrayAdapterでaddを使う時

ArrayAdapterでaddを使ったら、 java.lang.UnsupportedOperationException なる例外が発生。 ArrayAdapter#addって使えないかなーと一瞬意気消沈したが、 これを使うにはList渡しのコンストラクタにて、"ArrayList"を渡さないといけないことが判明。 今までは、配列渡しのコンストラクタを使っていたのでできなかった。 そうか。。 そういう実装にした気持ちはなんとなくわかるが、そういうことはAPIドキュメントにはっきり書かないと判らないと思うのだが。 自分の英語力が低いからかもしれないが、何回見てもそういったことは書いていないように思えるのだが~

Googleドライブにアップデート?

ウチのXOOMに来たアプリのアップデート通知の中に なぜがウワサの「Googleドライブ」が混じっていた。 インストールしたつもりもないのにアップデートとはこれいかに、と思っていたら ヤツは「Googleドキュメント」がバージョンアップしたものらしい。 なんか一気にテンションダウン(笑) AndroidのGoogleドキュメントって役に立った試しがない・・・ あの中身って結局WebKit使ったブラウザ画面だし中途半端感が否めなかったんだよね。 「Googleドライブ」はどうなることやら。 そして、しかも、「Googleドライブは準備中」とかいって使えなかった(笑) -- 2012/04/27 追記 準備中が解除されて使えるようになった。 第一印象は…Googleドキュメントっぽい(笑)

最低限の機能を持った製品を「MVP」というらしい

最低限の機能を持ったものを「MVP(Minimal Viable Product)」というらしい。 http://jibun.atmarkit.co.jp/lskill01/rensai/scrum/06/01.html (本筋とは関係なくて2ページ目の最後にちょろっと書いてある) 例えば「これがないとリリースできない(リリースさせてもらえない)必須機能」というのがいろんな理由で存在するが、それのみを最低限のレベルでクリアすればMVPってことか。 今まで、+αとなる目標は、「必須じゃないけどやりたい目標」と、長ったらしい言葉で言ってきたが、これからは「非MVPタスク」と呼ぶか。 それとも、最低限しかやってない仕事を「これってMVPじゃね?」と蔑むか。 ROMやCDに焼くゲームを作ってた頃はMVPが全てだったが、今はMVPという言葉が出来るほど後からリカバリをする・できるようになったってことか。 ところで、何をしたらMVPなのかを定義することって、地味にプロジェクトの生命線だよね。。 (これがお客さんと共有できてないと最後の最後でトラブルになるからね。なったしね泣)

Android:Dialogとメモリ解放後の起動

Androidの2.xでDialogを使うとき、onCreateDialog()をオーバーライドして作成するのが正しいやり方っぽい。 その機構を使うことでDialogのリソース管理をActivityが行なってくれるようになり、アプリ側ではその解放処理を考える必要が無くなるからだ。 解放処理以外にも、例えば、ボタンがタップされた時にダイアログを開くとした時、自前でDialog#show()すると、連打された時、その分ダイアログが開いてしまうが、Activity#showDialog()の機構を利用すると、以前のDialogを閉じてから開いてくれるなど、排他処理も行なっている。 そして、Activity#removeDialog()というものがあって、それは管理しているDialogのリソースを解放してくれるらしいのだが、ここでワナ発見。 アプリが復帰する時、ダイアログは閉じておきたいと思い、Activity#onPause()でActivity#removeDialog()してみた。 しかしながら恐ろしいことに、メモリクリア後にアプリを再開しようとした時、Androidったら、表示する必要のないはずのダイアログをActivity#onCreateDialog()で作成しに行くじゃありませんか。 ・・・と思ったら、Android4.0だけかもしれない。 手元のAndroid2.3.5端末ではonCreateDialogを呼んでいないようだ。。 どちらにしても、Activity#onCreateDialog内の処理も、「メモリクリア後の再開」を考慮しておかなくちゃなのね・・・

Logicool ワイヤレス スピーカー アダプターを買ってみた

イメージ
以前書いた ロジクールの「 普通のスピーカーをBluetooth対応にしてしまうアダプター 」を買ってみた。 大きさは、下の写真にあるように食塩より一回り大きいような大きくないようなそんな感じだが結構厚みを感じる印象。 というわけでリビングに置いてあるKENWOOD K'sの外部入力に接続してみた。 電源がACコードしかないことにちょっとびっくりしたが、最終的にアンプに付いている外部コンポーネント用コンセントを使うことで、アンプの電源を入れている時だけ電源が入るようになったので全く問題なし。 XOOMとのBluetooth接続も全く問題なし。 音質も特に問題は感じなかった。 (細かいところを聞き分ける耳もないので。。) それにしても便利な世の中になったものだ~。 コードで接続することなく、CDも不要になり、Youtubeをリビングのアンプで聴けるなんて。

Android:解像度違いの画像が正しく認識されない

hdpiの端末のはずなのに、なぜか「drawable-hdpi」ではなく「drawable-mdpi」の画像が使われてしまう現象が発生していて、しばらく悩んでいた。 ようやく解明した。 AndroidManifest.xmlのanyDensityの設定がfalseにされていた。 (参考ページ: http://y-anz-m.blogspot.com/2010/02/android-multi-screen.html ) これだから 保守不能ソース ってヤツは。。 ちなみに、trueにしたら、あちこちの画面のレイアウトが崩れた(笑) -- 2012/04/26追記 autodensityがfalseの場合、ToastにDensityが適用されないという問題も発覚。 つまり、Toastがやけに小さくなってしまうということだ…。

Android:メモリ解放とアプリ再開の問題の再現

Androidったら、アプリをVMごと停めてしまうくせにそのActivityから再開しようとするニクいヤツだ。 アプリの先頭ではないのにClassLoadから始まっているってことが、 絶妙なイヤらしさ。 メモリ解放したら強制的にアプリの最初から動いてくれれば話は単純なのにね。 (もしかしたらAndroidManifest.xml辺りでそういう設定できそうだな・・・) さらにイヤらしいのは、その動作しても大丈夫だよねっていう確認方法だ。 一体いつメモリが解放されるのかわからなくて、他のアプリを色々起動してみても 再現しなくて諦めたころ発生するという、非常にムキーッ!状態になる。 しかし、よくあるメモリ管理ツールでメモリ強制解放を行うと、その状況が再現できることに気づいた。 (もしかしたら知らないツールがSDKに既に存在していたら悲しい限りだが・・・) 例えば「メモリブースター」っていうアプリの「ワンクリック高速最適化」っていう機能。 (なんだか怪しいので本当はインストールしたくないのだが・・・) これを使ったら一発で発生した。 あとはバグを直すだけだ。。 -- 2012/03/15 メモリブースターはAndroid4.0(104SH)で動かなかった。FMR Memoryは動いた。

なんでもBluetoothスピーカー

今までありそうでなかった 「普通のスピーカーをBuletooth対応にしてしまう」 アダプターがロジクールから発売されたらしい。 http://plusd.itmedia.co.jp/pcuser/articles/1203/06/news030.html これがあったら、家のステレオとXOOMが タップ一発で無線接続できてしまうということだ! すげぇ、CDプレイヤーが本格的に不要になる。。 それに家の中を移動するのにスピーカーとXOOMを持つ必要がなくなる …まぁ、そんなのはワタクシだけだと思うが (「 CREATIVE D100を買ってみた 」参照) 音質はどうだかわからないが、 シャレで買ってもいいくらいの値段だ。 (逆に言うとあまり期待できそうにない程度の値段だ…) -- というわけで、買ってみた記事はこちら → Logicool ワイヤレス スピーカー アダプターを買ってみた

Android:角丸でグラデーションのDrawable

まあ、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 ) );

Android:stateに応じてTextの色を変更する・・・ColorStateList

テキストの色を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), } ) );

Android:TextViewがどうしても2行になってしまう件

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

Android:TextのBoldについて・・・特に日本語

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

Android:ViewのSizeをレイアウトに頼らない・・・onMeasure

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:stateに応じて切り替わるdrawable・・・StateListDrawable

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の使い方がよくわからん。 例えば、下記の設定を行なってみたが効かない。 // 効いていない

SHが4.0(ICS)に順次VerUpしていくらしいぞ

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

android.bat

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

保守不能ソースを生み出す世の中に絶望した

人が作ったプログラムソースをここ5年ほどよく見るようになったが、 最近見ているソースがずば抜け過ぎているために、 それを表現する言葉をずっと探していたのだが、ようやく見つけた。 それが、「保守不能ソース」という言葉だ。 世の中のプログラムソースには二種類ある。 「保守可能ソース」と「保守不能ソース」だ。 で、得てして世の中は「保守不能ソース」を生み出してしまうわけだが、 なんと言ったらよいか、今の気持ちはそんな世の中に絶望した気持ちだ。 などということを考えていたら、テレビで修理に携わる職人たちを紹介していた。 そういえばソフトウェアの修理屋って職業を聞いたことはないが、 人のソースを解析してバグを修正するのは間違いなく修理屋のやる仕事だし、 今、自分がやっていることは、間違いなくその類なのだが。 修理専門のソフトウェア技術者ってのもありなのか、を想像してみた時に、 年がら年中、次から次へと、毎日向かい合うであろうそのソースの、 たぶん多くを占めているのは「保守不能ソース」だろう、ということを ・・・想像してみただけなのに吐き気がしてくる。。

XOOM用にBluetoothスピーカーを買ってみた・・・CREATIVE D100

イメージ
最近、XOOMの使い方が変わってきた。 音楽を聞いたりYouTubeを流すようになった。 ウチの中では、大抵、XOOMもしくはウクレレを抱えながら移動し、 行く先々で音を鳴らしているわけだ。 で、そうなると、どうせなら、もうちょっとだけでいいから、 良い音で聴きたいなぁと思うのは、仕方のないことだ。 というわけで、安いスピーカー、しかもBluetoothで探してみた。 そこで購入したのが「CREATIVE D100」 値段が手頃で、音質も(悪い意味じゃなくて)相応だろうっていうのが理由。 (そりゃBOSEの方がよいだろうが、値段がぜんぜん違う) あと、電池駆動できるのも大きい。 ペアリングは全く問題なく出来た。 (ウチのXOOMはAndroid3.2にアップデート済み) 音もちゃんと出た!爆音まで出したわけではないが ホワイトノイズや遅延なども今のところ無い。 再生ボタンを押した時にレコードの針を乗っけたような プツッってノイズはあるけれど、音に重なるわけではないので気にならない。 音質は、もう少しヌケた感じがあったらいいのに、とか、 言い出すとキリが無いが、間違いなく言えるのはXOOM本体の スピーカーなんかよりはるかに良いってことだ。 これの音を聴いてからXOOM本体の音を聴くと、 「ショボっ!」って思うようになった。。 重低音を強調してるのかもしれない。 ベースの音がはっきり聞こえるようになって、同じ曲でもちょっと印象が変わったり。 それにしても無線は便利だな。 コード要らないって手軽でキレイ。 ただ、XOOMと一緒にスピーカーも持ち歩くことはなさそうだな。 大変だから。 ・・・そうか、部屋の数だけBluetoothスピーカーがあればいいのか(笑) -- 追記 こちらも見てみて 普通のスピーカーをBluetooth対応にしてしまうアダプタがロジクールから発売されるらしい

Android向けGoogle日本語入力アプリ

ウチのXOOMに「 Google日本語入力アプリ 」を導入してみた。 タブレットにもちゃんと対応している。 確かに使いやすい。デフォルトに戻る気は全く起きない。 何が良いって、候補が一度にいっぱい表示されるのがいいかもしれない。 あと、顔文字や記号の充実度に期待がもてる。(まだ使ってないので) 何と言っても動作が軽快。 使えば使うほど、こんなに動作軽かったっけ?っていう場面に遭遇する。 Bluetoothキーボードでのタイプも軽快になった気がする。 以前はもっとイライラしたような気がするんだけど・・・ でも、カラーリングが全体的にグレーだよね。 XOOM全体のブラックの統一感が崩れちゃうんだよね。。 そこが残念。