Androidで画像処理

On 2015年2月23日, in 未分類, by cliph

先日の投稿ではBlueTooth熱いみたいな事言ってた気がするけど、
今度は画像処理が気になっている今日この頃。

例によって、先人の偉大な功績に乗っかって簡単に実装できる方法を模索してるんだが、
どうもこれと言った決め手が無い。。。

一応、OpenCVと言う定番ライブラリがあって、
これがあれば何でもできそうなんだけど、
いかんせん元々がC++のライブラリなのでAndroidではNDKが必要。
更にはAndroidの場合、デバイスが千差万別なのでそれぞれに対応したリソースが必要なようで、
それを判別してダウンロードする為のOpenCV Managerと言うのを、
何とユーザーがアプリとしてインストールしなければならない。。。

こんな面倒なもん使ってられるか!!
てか、怪しまれてダウンロードしてもらえんわ。。。

てかね、俺がやりたいのは実はOCRであって、
その前処理としての二値化をやりたいだけなんだよね。
だったらJavaのスクラッチで良いんじゃねーか?と思い至ったのがつい先ほど。

うん。そうしよう。

それより、プレビュー画面に映像が映らないのはなぜだろう。。。

 

BLE基礎まとめ

On 2014年10月14日, in Android開発, BlueTooth Low Enagy, by cliph

BLE(BlueTooth Low Enegy)の仕様をざっくり理解したのでまとめておきます。

BLEの通信はCentralとPeripheralと言う二種類のロール(役割)に分かれて行われます。

既存の概念で言えば「クライアント・サーバー」モデルに似ています。

Centralがサーバーで、peripheralがクライアントと言った感じです。

例えばiBeaconの場合、
iBeacon端末がperipheralで、iPhoneがCentralとなります。

※ちなみにiBeaconはBLEの仕様に則ってAppleが提供する独自のサービスです。BLE=iBeaconではありません。
 イメージ的にはBLE>iBeacon(BLEにiBeaconが含まれる感じ)

で、peripheralとCentralがそれぞれ何をするかと言うと、

peripheralはAdvertisingによって、自分の存在を周囲に発信します。

逆に、CentralはAdvertisingを受信し、その中から目的のperipheralをScanします。

更に、Centralは目的のPeripheralを見つけると、Connectionを確立し、
Peripheralから送信される情報を受信し、任意の処理を実施します。
必要があれば、処理結果をPeripheralへ返却する事も出来ます。

尚、Perepheralから送られる情報単体はcharactaristicと呼ばれる文字情報です。
それを目的別にまとめたものがServiceと呼ばれます。
ちょうど、Object志向プログラミングで言うクラスとプロパティの関係の様なものです。

また、それぞれのServiceやCharactaristicにはそれぞれUUIDが振られています。

これらの一連の処理を簡易に実装できるフレームワークがAndroidにもiOSにもあります。
その内容については次回。

 

BlueTooth LowEnagyの活用

On 2014年10月10日, in Android開発, BlueTooth Low Enagy, by cliph

Android LではAndroid端末もPeripheralモードをサポートするらしいと言う事で、
ついにiPhone,Android横断的なP2Pメッセージングアプリの作成が可能になる様なので、
実験アプリの作成をやって行きたいと思います。

イメージはiPadとAndroid双方にBLE(BlueToothLowEnagy)を実装し、
すれ違い通信が出来る様なアプリを目指します。

なお、現在手元のAndroidは4.4なので、
いわゆる発信機側になれるPeripheralモードはまだサポートされてません。

なので、iPadをPeripheralモード、AndroidをCentralモードで動かす前提で進めて行きたいと思います。

今日のところは、
iPadに「LightBlue」と言うBLE両モードをシミュレートできるアプリをインストールし、

下記ブログで紹介されているAndroid向けサンプルを動かして見ました。

IMG_0053
LightBlueでBloodPresureと言う名前のperipheralを公開
Screenshot_2014-10-10-01-30-14
サンプルアプリで、BloodPresureを受信できた。

ふむふむ。まあ、ここまでは順調。
明日から、Android版のソースを読み返して行きます。

 

次のアプリのアイデア

On 2012年11月12日, in ブログ, by cliph

ここ数年CliphWeather一筋でやって来たわけだけど、
正直ちょっと視野が狭くなっている気がするので、
もう一つプロジェクトを持とうかと思う。

何が良いかずーっと考えているんだけど、
今やってみたいと思っているのは、
幼児向けのコミュニケーション玩具アプリ。

LINEとかTwitterとか大人向けのコミュニケーションツールは、
もう素人の出る幕じゃないんだけど、
幼児専用のサービスだったらまだまだ工夫の余地がある様な気がする。

何より、
うちには3歳と0歳の娘がいるから、
フィールドテストの環境にはかなり恵まれていると思う。

ポイントは、
幼児が楽しく、文字の勉強ができて、
両親も楽しいアプリって感じかな?

お絵かきもできるとなおよし。

ほんとはタブレット位の大きさが子供にはあってると思うんだけど、
タブレット持ってないんだよな~。。。

ふむ。
ま、少し考えてみよう。

 

これだ。俺が探してたやり方。
ホームウィジェットの中身を入れ子にする方法

本当にいつまで経っても新しい「目から鱗」に出会えるからアプリ開発は止められない。

CliphWeatherは週間天気故、同じレイアウトのパーツがいっぱい並ぶウィジェットな訳だが、
今まではあまり深く調べる事もせず、layout.xmlにぜーんぶ個別にIDを振って書いていた。
結果、XMLの見通しが悪く、メンテナンスが非常にめんどうくさいものになってしまっている。

実際、今手元にあるGalaxyS3が妙に横幅が広い端末なので、
既存のレイアウトがフィットせず、新しいレイアウトを作ろうとしているのだが、これがめんどくさい。

そこで、今更ながらにレイアウトのパーツを作って再利用できないものかと調べてみた。

まず見つけたのは、includeタグと云うもので、
別に作ったLayout.xmlをインクルードできるものだ。
早速適用して見たところ、きれいにレイアウトができて感動したのもつかの間、
AppWidgetではこのタグが使えない事が判明。。。泣いた。

で、改めて探してみたところ、見つけたので上のエントリ。

個別に用意したlayout.xmlをjavaコード側で組み合わせて、
remoteviewにaddViewすることで、入れ子構造を作る事ができるというもの。

まだ、試してないので何とも言えないが、
たぶんこれでかなり効率化できるはず。

ただ、難点はlayout.xmlの種類だけでウィジェットの種類を見分けるのが難しくなりそうな点。。。

メンテナンス性と分かりやすさが天秤にかかりそうないやな予感がする。

ま、でもちょっとやってみよう。

 

AndroidのAppWidgetはXMLでサイズおよび適用するLayout.xmlを指定する必要があり、
端末の画面サイズに合わせた動的なサイズ調整が難しいと思っていた。

が、よく調べたら、
LayoutやDrawableのフォルダに適用できるsmall,middiam,largeなどの拡張子が、
XMLなどres/配下の他のフォルダにも適用できる事に気付いた。

加えて、android3.2~は画面の横幅に合わせて自由に設定できる、
sw400dp のような拡張子が使えるようになっていた。

上記のsw400dpをつけたフォルダは、端末の画面横幅が400dp以上の端末の場合に、
適用される事になる。

supporting Different Screen Sizes|Android Developers

たとえば、CliphWeatherの場合で言えば、
Galaxy S等横幅320dpの端末にフィットするWidgetを作っていたのだが、
Galaxy S3では横幅が360dpに広がっているので左右に変な隙間があいたレイアウトになってしまっていた。

そこで、
res/layout-sw360dp/widget-layout.xml
/xml-sw360dp/widget.xml

の様な形で横幅360dp以上の端末用のAppWidget定義とレイアウトXMLを置いてみた。

すると、ちゃーんと、
Galaxy S3で表示した場合だけ、
AppWidgetが適切に広がって表示されるようになった。

これは素晴らしい!

この様な実装を徹底することで、
さまざまなサイズの端末(タブレット含む)に一つのアプリで対応する事ができそうだ。

今日はちょっと実験してみただけなので、
ちゃんと実装したらまた考察を書きます。

以上。

 

最近Yahoo!JAPANがワンタイムパスワードによる認証サービスを始めたり、googleが端末登録をサポートしたり、
アカウントセキュリティーに関する取り組みが目立つようになってきた。

実際、そう言った被害も増えている様で、クラウド系サービスを割と使う身としては、
そろそろ、パスワード管理にマジにならないといけないかなと思う今日この頃です。

という事で、私が直近調べて実行した事を書きます。

1.各種PWを個別かつ強固なものに変更
  登録サイト毎にパスワードジェネレータで生成した、英数混在のパスワードを設定。
2.確実に忘れてしまうので、パスワードホルダ的なアプリにパスワードを格納。(ネットワークアクセス許可を要求せず、暗号化しているもの)
3.二要素認証をやっているサイトは全てそれを有効に設定。

ここまでやっておけば、かなり防御力が上がったと思う。

とは言え、二要素認証を提供していないサイトについては、
今回はPWしか変えておらず、しかも桁数が少し少ない(サイト側の制約もある)ので、
辞書やレインボーテーブルを使ったブルートフォースにやられないかと言うと100%ではない。

でも、これ以上やると日常の使い勝手を大きく損なってしまうため、
便利ツールの本末転倒となってしまう。

ま、この辺が落とし所かな。

それと、やっぱり超重要な情報はクラウドに置かない様にするべきなんだろうと思う。

Tagged with:  

Android開発関連ポスト再開

On 2012年7月25日, in Android開発, by cliph

ずいぶんブログから離れてしまっていたけど、
最近FacebookでAndroid系の話をすると引かれている感があるので、
深い話はこっちに書いていく事にしよーかと思って。

しばらく、休んでいる間にかなりCliphWeather絡みで勉強したので、
書くことはいろいろ溜まってるはず。

特にAndroidのUTとか、非同期処理の話とかは俺も忘れてしまいそうだから、近いうちにまとめて書こうと思う。

今日はもう寝るけどね。。。

 


CliphWeatherの最近の更新で、サイバーエージェント社のアプリ広告商材である、
AppliPromotion」を導入して見た。

結論から言うと、これはかなり良い!

詳しくはサイトを見てもらえばわかると思うけど、
簡単に言うと、「広告枠の交換」によってアプリ同士が紹介しあうサービスってところだ。

もちろん、有償での広告出稿も可能なんだけど、
基本は自分のアプリに「applipromotion」のアプリ紹介ページを組み込み、
そこで他のアプリを紹介してあげると、そのimpressionに応じて、
他のアプリでの自アプリの露出が増えるという仕組みだ。

よって、それなりのimpressionのあるアプリであれば、
コストアウトする事無く効率的に集客できると言う素晴らしい思想のサービスだ。

ただ、思想は素敵でも実績を伴わなければ意味がないという事で、
今回早速試してみたわけだが、これが意外と良い感じなんだな。

あまり詳しく話す事はできないが、
CliphWeatherでは↓位の勢いで安定的にインストールが増えつつある。
 ・CTR:0.5~0.7%
 ・CVR:10~30%

まあ、CliphWeatherは無料アプリだし、
ハードル低いのが当たり前なんだけど、
であるがゆえに、広告費を払って広告を出すつもりはなかったから、
このサービスはまさに打ってつけなわけです。

ただ、こればっかやってると、
CliphWeather唯一の収入源である広告を出せなくなってしまうので、
今後はこれとインストール成果報酬型広告を半々くらいで突っ込んでみようかと思っている。

いずれにしても、このサービスは”あり”だ。
インストール数拡大に取り組んでいるフェーズの無料アプリは導入して見てもいいんじゃないでしょうか。

 

Mixiのソーシャルバナー事例

On 2011年6月25日, in ブログ, by cliph

先週こんな記事が出てましたね。

mixi のソーシャルバナー通常の10倍以上のCTRを記録

一部抜粋

ミクシィは5月31日から6月20日にかけて展開したナイキジャパンの「NIKEiD FRIEND STUDIO」キャンペーンで、既存のバナー広告にmixiのソーシャルグラフを掛け合わせた「ソーシャルバナー広告」の本格導入を行った。

その結果、通常バナーのCTR(クリック率)平均値と比べて、PC版では約11倍、モバイル版では約16倍の数値を記録したことが分かった。期間中のキャンペーンサイトへの来訪ユニークユーザー数は213万人、「ソーシャルバナー」または「mixiチェック」経由でのキャンペーンサイトへの来訪率を示すソーシャルリーチ率は80%だった。

通常の約11倍てのは中々インパクトありますね。
Mixiの通常のバナー広告のCTRを知らないので何とも言えませんが、
一般的にPC向け純広告のCTRは0.01%程度だったと思いますので、
ソーシャルバナーは0.1%強のCTRだったと言うニュアンスで受け止めれば良いでしょうか。

広告の内容としては、「NIKEiD」と言うシューズの色などを自由に選べるサービスで作成したオリジナルシューズデザインをシェア出来る様にしたもので、特徴はバナーの中にシェアしたマイミクのアイコン等が表示される点。(下図参照)
Mixiソーシャルバナー説明

マイミクの写真や名前を表示する事で、ユーザの関心を集め、CTR向上に繋げたものと見られます。

ただ、この施策の肝はあくまで「NIKEiD」だろう。
このサービスがまさにソーシャルメディアで共有し合いたいネタとして最適だったからこそ、
これ程の反応があったのであって、Mixiのソーシャルバナーだけの効果では無い事は注意したい。

とは言え、国内でこれ程話題になったソーシャルAdの事例は恐らく初めてだと思います。
ネタが面白い事が前提ですが、やはり国内でもソーシャルAdの効果は高いと言う事が示された事例だったと思います。

これを受けて今後、国内の大手企業がこぞってこの手法に取り組む事でしょう。
どんな事例が出てくるか楽しみですね。
(私はほとんどMixiログインしてないんですが。。。)

ただ、こう言う施策が一般化して、ありふれた物になるのもそう遠い日では無いでしょうから、
結局の所みんな同じ土俵の上で、いかに面白いネタを提供するかと言う勝負をする事になるのだと思います。

と言う事で言うと、今すぐにこれ系の施策に取り組むと先行者メリットがあるのかもしれませんね。