Angular2で使えそうなUIフレームワークメモ。
Angular CLIとの親和性とか、CLIも提供しているやつとか色々ありそう。
でもまあ、まずは本家を試すのかな？
Angular-Material2
https://material.angular.io/
ng2-bootstrap
https://valor-software.com/ng2-bootstrap/#/
ng-lightning
https://github.com/ng-lightning/ng-lightning
PrimeNG
http://www.primefaces.org/primeng/
SemanticUI
https://github.com/vladotesanovic/ngSemantic
Angular2-polymer
https://vaadin.com/vaadin-documentation-portlet/charts/webcomponents-api/charts-angular2.html
https://github.com/vaadin/angular2-polymer
OnsenUI
https://ja.onsen.io/v2/docs/guide/angular2/
Ionic 2
http://ionic.io/2
Fuel-UI
https://github.com/FuelInteractive/fuel-ui
Kendo UI for Angular 2
http://www.telerik.com/kendo-angular-ui/
先日の投稿ではBlueTooth熱いみたいな事言ってた気がするけど、
今度は画像処理が気になっている今日この頃。
例によって、先人の偉大な功績に乗っかって簡単に実装できる方法を模索してるんだが、
どうもこれと言った決め手が無い。。。
一応、OpenCVと言う定番ライブラリがあって、
これがあれば何でもできそうなんだけど、
いかんせん元々がC＋＋のライブラリなのでAndroidではNDKが必要。
更にはAndroidの場合、デバイスが千差万別なのでそれぞれに対応したリソースが必要なようで、
それを判別してダウンロードする為のOpenCV Managerと言うのを、
何とユーザーがアプリとしてインストールしなければならない。。。
こんな面倒なもん使ってられるか！！
てか、怪しまれてダウンロードしてもらえんわ。。。
てかね、俺がやりたいのは実はOCRであって、
その前処理としての二値化をやりたいだけなんだよね。
だったらJavaのスクラッチで良いんじゃねーか？と思い至ったのがつい先ほど。
うん。そうしよう。
それより、プレビュー画面に映像が映らないのはなぜだろう。。。
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にもあります。
その内容については次回。
Android LではAndroid端末もPeripheralモードをサポートするらしいと言う事で、
ついにiPhone,Android横断的なP2Pメッセージングアプリの作成が可能になる様なので、
実験アプリの作成をやって行きたいと思います。
イメージはiPadとAndroid双方にBLE（BlueToothLowEnagy）を実装し、
すれ違い通信が出来る様なアプリを目指します。
なお、現在手元のAndroidは4.4なので、
いわゆる発信機側になれるPeripheralモードはまだサポートされてません。
なので、iPadをPeripheralモード、AndroidをCentralモードで動かす前提で進めて行きたいと思います。
今日のところは、
iPadに「LightBlue」と言うBLE両モードをシミュレートできるアプリをインストールし、
下記ブログで紹介されているAndroid向けサンプルを動かして見ました。
LightBlueでBloodPresureと言う名前のperipheralを公開
サンプルアプリで、BloodPresureを受信できた。
ふむふむ。まあ、ここまでは順調。
明日から、Android版のソースを読み返して行きます。
ここ数年CliphWeather一筋でやって来たわけだけど、
正直ちょっと視野が狭くなっている気がするので、
もう一つプロジェクトを持とうかと思う。
何が良いかずーっと考えているんだけど、
今やってみたいと思っているのは、
幼児向けのコミュニケーション玩具アプリ。
LINEとかTwitterとか大人向けのコミュニケーションツールは、
もう素人の出る幕じゃないんだけど、
幼児専用のサービスだったらまだまだ工夫の余地がある様な気がする。
何より、
うちには3歳と0歳の娘がいるから、
フィールドテストの環境にはかなり恵まれていると思う。
ポイントは、
幼児が楽しく、文字の勉強ができて、
両親も楽しいアプリって感じかな？
お絵かきもできるとなおよし。
ほんとはタブレット位の大きさが子供にはあってると思うんだけど、
タブレット持ってないんだよな～。。。
ふむ。
ま、少し考えてみよう。
これだ。俺が探してたやり方。
ホームウィジェットの中身を入れ子にする方法
本当にいつまで経っても新しい「目から鱗」に出会えるからアプリ開発は止められない。
CliphWeatherは週間天気故、同じレイアウトのパーツがいっぱい並ぶウィジェットな訳だが、
今まではあまり深く調べる事もせず、layout.xmlにぜーんぶ個別にIDを振って書いていた。
結果、ＸＭＬの見通しが悪く、メンテナンスが非常にめんどうくさいものになってしまっている。
実際、今手元にある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が端末登録をサポートしたり、
アカウントセキュリティーに関する取り組みが目立つようになってきた。
実際、そう言った被害も増えている様で、クラウド系サービスを割と使う身としては、
そろそろ、パスワード管理にマジにならないといけないかなと思う今日この頃です。
という事で、私が直近調べて実行した事を書きます。
１．各種ＰＷを個別かつ強固なものに変更
登録サイト毎にパスワードジェネレータで生成した、英数混在のパスワードを設定。
２．確実に忘れてしまうので、パスワードホルダ的なアプリにパスワードを格納。（ネットワークアクセス許可を要求せず、暗号化しているもの）
３．二要素認証をやっているサイトは全てそれを有効に設定。
ここまでやっておけば、かなり防御力が上がったと思う。
とは言え、二要素認証を提供していないサイトについては、
今回はＰＷしか変えておらず、しかも桁数が少し少ない（サイト側の制約もある）ので、
辞書やレインボーテーブルを使ったブルートフォースにやられないかと言うと100%ではない。
でも、これ以上やると日常の使い勝手を大きく損なってしまうため、
便利ツールの本末転倒となってしまう。
ま、この辺が落とし所かな。
それと、やっぱり超重要な情報はクラウドに置かない様にするべきなんだろうと思う。
ずいぶんブログから離れてしまっていたけど、
最近FacebookでAndroid系の話をすると引かれている感があるので、
深い話はこっちに書いていく事にしよーかと思って。
しばらく、休んでいる間にかなりCliphWeather絡みで勉強したので、
書くことはいろいろ溜まってるはず。
特にAndroidのＵＴとか、非同期処理の話とかは俺も忘れてしまいそうだから、近いうちにまとめて書こうと思う。
今日はもう寝るけどね。。。
CliphWeatherの最近の更新で、サイバーエージェント社のアプリ広告商材である、
「AppliPromotion」を導入して見た。
結論から言うと、これはかなり良い！
詳しくはサイトを見てもらえばわかると思うけど、
簡単に言うと、「広告枠の交換」によってアプリ同士が紹介しあうサービスってところだ。
もちろん、有償での広告出稿も可能なんだけど、
基本は自分のアプリに「applipromotion」のアプリ紹介ページを組み込み、
そこで他のアプリを紹介してあげると、そのimpressionに応じて、
他のアプリでの自アプリの露出が増えるという仕組みだ。
よって、それなりのimpressionのあるアプリであれば、
コストアウトする事無く効率的に集客できると言う素晴らしい思想のサービスだ。
ただ、思想は素敵でも実績を伴わなければ意味がないという事で、
今回早速試してみたわけだが、これが意外と良い感じなんだな。
あまり詳しく話す事はできないが、
CliphWeatherでは↓位の勢いで安定的にインストールが増えつつある。
・CTR：0.5～0.7%
・CVR：10～30%
まあ、CliphWeatherは無料アプリだし、
ハードル低いのが当たり前なんだけど、
であるがゆえに、広告費を払って広告を出すつもりはなかったから、
このサービスはまさに打ってつけなわけです。
ただ、こればっかやってると、
CliphWeather唯一の収入源である広告を出せなくなってしまうので、
今後はこれとインストール成果報酬型広告を半々くらいで突っ込んでみようかと思っている。
いずれにしても、このサービスは”あり”だ。
インストール数拡大に取り組んでいるフェーズの無料アプリは導入して見てもいいんじゃないでしょうか。
