作者別: hiro

スマートロックがすごく安く良くなってた。

今回は、最近発売されたスマートロックを家の玄関に取り付けたというお話です。

 

ご存知の方も多いとは思いますが、既存のドアの鍵などを後付けでスマホなどから開閉出来るようにするシステムのことをスマートロックといいます。たいていBluetoothでスマホなどと通信して施錠・解錠するものが多いです。

 

スマホに専用のアプリをインストールして管理者から許可してもらえば鍵の開閉が可能になり、もしスマホを紛失しても管理者が許可を取り消せば操作できなくなるとか、操作可能時間帯や曜日などを指定できたり、操作記録が残ったりと、なかなか便利そうです。

  

ただ、これまでは3万円以上するものばかりで、別に普通の鍵で使えているのにわざわざ導入するにはちょっと高価ですし、性能がイマイチだったりして導入に踏み切れていませんでした。

  

ところが今回、Makuake というクラウドファンディングサイトで「セサミMini」というスマートロックが1つ9,800円で支援募集していたので、1万円以内なら一度使ってみてもいいか、ということで申し込んでみました。

  

  

  

付けました。

  

  

高さを合わせるスペーサーをネジで止めて、両面テープでピタっと貼り付けるだけ。非常にカンタンです。

  

  

正直あまり期待してなかったのですが、これ、いいです。(・∀・)イイ!!

  

  

扉が金属なのでやっぱり外からの接続には若干時間がかかりますが、普通に解錠・施錠できます。AppleWatchでも解錠出来るので、スマホすら出さないで解錠出来るのはスゴくラクです。(ただスマホより若干接続に時間がかかるみたいですが、、、)

電源はCR123Aという乾電池ですが、500日持つということなので年に一回交換しておけば電池切れで閉め出されるということもなさそうです。

  

家族も最初は使うのイヤがってたんですが、最近は慣れたみたいで全員スマホで解錠しています。わざわざ鍵をカバンから出すより便利なことに気がついたようです。まあスマホは大体手に持ってますからね。

  

私などはすでに普通の鍵は持たずに外出することも多いです。そのくらい安定して動作してるってことですね。

  

  

これ正式発売はまだのようですが、数ヶ月以内に発売されるみたいですので、みなさんも設置してみてはどうでしょう。

鍵を持たずに外出出来るって意外に気持ちいいですよ。

  

  


Apple Watchのある生活

 

こちら、新旧のAppleWatchを並べてみました。

左が新(44mm)右が旧(38mm)です。

 

そう、私2台持ちなんです。古いほうも運動するときとか寝ている時のデータ取得用として活躍しています。

 

 

私はおととしくらいからAppleWatchを使っていて、最初はiPhoneの通知を見逃さないから便利だなとか、ApplePayで買い物が出来るのが便利だなとか、そんな感想でした。そして

 

「これしばらくしたら飽きるかもな。。。」

 

とも思っておりました。

 

しかし2年経過した今、ほぼ24時間着用するヘビーユーザーになっていまして、外すのは入浴時くらいです。

 

 

こんなにヘビーユーザーになった理由は、「アクティビティ」アプリの存在です。

AppleWatchに最初からインストールされています。

 

  

 

 

心拍計、GPS、モーションセンサーを駆使してヒトの活動をトラッキングする、いわゆる活動量計機能で、消費カロリー・エクササイズ時間・立った回数、などを常にAppleWatchに表示させることが出来ます。そして1日の目標に満たないときは何回もお知らせしてくれたり、目標達成するとお祝いのメッセージが表示されたりします。

 

これが地味にウレシくなってきて(笑)、とにかく毎日の目標を達成しようと1駅手前で降りて歩いてみたり、バスに乗らないで歩いてみたりと、徐々に運動が習慣化されるようになり、今ではほぼ毎日目標達成、休日も欠かさず運動するようになってきています。

 

また私のように2台使っていても、iPhoneを介して自動でデータは統合されますし、その他の諸々もiPhoneとペアリングするだけで大した設定もせずにいい感じにやってくれます。

AppleWatchは他の活動量計と比べて安くはないものなのですが、私の運動習慣を支えるデバイスとして欠かせない存在になってしまいました。

 

 

iPhoneをお使いの方でなんとか運動習慣を定着させたいと思っている方にはぜひ使ってみてもらいたいとオススメできるデバイスです。

最新型は5万円くらいしますのでちょっとお高いのですが、、、これで運動習慣が定着するなら安いものじゃないかな、と思いますよw

 

 


弱かった胃腸が治ってきました

 

こちら先日開発合宿で訪れた徳島県神山町の地ビールです。
とても美味しかったです。もちろん4本とも飲みました。

 

お酒といえば飲むとお腹がユルくなりがちですよね。
特に男子は元々お腹がユルい人が多いので、飲んだ翌日は朝の電車が憂鬱なヒトも多いはず。
私もご多分に漏れず昔からお酒を飲めばユルくなる、いやむしろ日常的にユルいヒトだったのですが、ここ最近劇的に状況が改善してきております。

 

 

それはコレ、、

 

 

 

なんか英語ばかりのボトルで怪しげに見えますが、これは消化酵素サプリメントです。

日本では医師の処方箋がないと買えないのですが、海外通販だと普通に買えます。
もちろん違法ではありませんのでご心配なく。

 

 

そもそも基本お腹がユルいヒトは胃腸の消化能力が低くて、多めに食事を摂ったり消化しにくいものを食べるとすぐに消化不良をおこし、結果下痢になってしまう、というパターンが多いようで、私もおそらくその1人です。

そこで消化を助けるために消化酵素を補うことで消化不良を起こさずに胃腸が正常な状態になる、ということのようです。

 

もちろん効果には個人差がありますので効果のないヒトもいるかと思いますが、私はこれを飲み始めて1ヶ月くらいで劇的に症状が改善しました。朝の通勤電車もコワくない!もっと早く出会っていれば、、、

 

 

薬ではなくあくまでサプリメントなので飲んですぐに効果が出るというものではないんですけど、飲んで身体に悪いことはないみたいなのでお腹が基本的にユルい方は試してみたらいいんじゃないかなと思います。

 


Flutterが銀の弾丸だったらいいな

 

最近弊社では、 #HASH というWebサービスが、ローンチされたのかされてないのか微妙な状態でなし崩し的にベータ版みたいな感じで公開されております。

 

「ハッシュタグでのゆるいつながり」をテーマにしたサービスで、ハッシュタグの作成や管理も簡単にできるようになっていますのでよろしければ使ってみて下さい。

 

で、まだベータ版みたいな状態ではあるんですがやっぱりこういうのはアプリも欲しいよね!ということでアプリ化の検討を始めました。そして検討する中でiOSとAndroid両方で動かすことが出来るいわゆるクロスプラットフォームな開発ツールの導入を検討してはどうか、という話になり、最近活発に開発が進んでいて(一部で)話題になっているFlutterというSDKを検討してみることになりました。

Flutterとは

 

Flutterは上述のとおり、iOSとAndroid両方で動作するアプリを開発することが出来るクロスプラットフォーム開発用のSDKです。Googleがオープンソースで開発していて非常に活発に開発が行われています。

 

 

こういうクロスプラットフォーム開発SDKにはいくつかのパターンがあるのですが、Flutterは

  • 独自のUIコンポーネントを使って描画を行い
  • 独自のAPIセットが提供されているためプラットフォーム間でコードが共有出来る

というものです。

 

ちなみに有名どころのクロスプラットフォームSDKであるXamarinは、

  • ネイティブのUIコンポーネントを利用してUIを構築し
  • 各プラットフォームAPIに対応する薄いラッパーAPI、もしくは独自のAPIセットが提供、のどちらかを選択できる

といった感じになっています。

 

検証したこと

 

今回はあくまで業務で使えるのか、そしてネイティブ実装で作るより明確なメリットがあるのか、ということが検証の主眼ですので、あまり技術的なことを細かくは書きません。(もちろんすべて実際にコードを書いて検証は行っています)

結局知りたいことって、

  • どこまでコード・UI設計が共通化出来るのか
  • 各プラットフォーム固有の機能がどこまでサポートされているのか
  • 各プラットフォームネイティブの環境でそれぞれのアプリを作ったときと比較してどの程度工期が短縮されるのか

っていうことなんですよね。

 

ではまず、

<どこまでUI設計が共通化出来るのか>

ということですが、UIについてはほぼ共通化が可能です。ただし今のところビジュアル設計ツールはなくコードでUIを記述していく形になります。
ただ、一度ビルドしてテスト端末などでデバッグ実行している状態でコードを変更すると、再ビルドすることなく実行した状態のままコードが反映されるというHot Reloadという機能があるため、意外と面倒には感じないのではないかと思います。

ただし、例えば広告を掲載したい、とかいうことになると現状admobしか対応していない、とか、アニメGIFなどネイティブ実装ではオープンソースのライブラリを使って簡単に表示できたりするのですが、そういったライブラリがまだあまり種類がなく、自力での開発が必要となる場面が多くなるような気がします。

 

<どこまでコードが共通化出来るのか>

コードについては、Flutterの標準ライブラリが対応している範囲であれば同一コードで記述できますが、対応していないものについてはChannelという仕組みを使って、ネイティブコードを呼び出す形で実装することになり、この場合swiftやkotlinなどでネイティブ実装する必要が出てきます。

 

ここは結構キモだと個人的に思うところですので、前提知識なくコードを見てもよくわからないかもしれませんが、ここだけは実装コードサンプルを載せてみます。

下記でやっていることは「ネイティブ実装を呼び出して文字列を取得する」という単純なもので、雰囲気だけ伝われば幸いです。

 

 

まずDart側でこのようなメソッドを準備します。ネイティブ側実装を呼び出す際にawaitでブロッキングしますのでこういうメソッド(非同期呼び出し)が必要になります。

Future<Null> _getCallbackDataString() async {
  String dataString;
  try {
    dataString = await platform.invokeMethod('iDataIO_getCallbackData');
  } on PlatformException catch (e) {
    dataString = e.message;
  }

  setState(() {
    _callbackDataString = dataString;
  });
}

この中の

platform.invokeMethod(‘iDataIO_getCallbackData’);

これがmethod channel というネイティブ側実装を呼び出すコードです。

 

 

そしてiOSの場合は、Flutterの動作ベースとなるAppDelegateのapplicationメソッド内に下記のようなコードを記述します。

let dataIOChannel = FlutterMethodChannel.init(name: "net.bugfix.io/dataio",
                                               binaryMessenger: controller)

dataIOChannel.setMethodCallHandler({
    (call: FlutterMethodCall, result: @escaping FlutterResult) -> Void in
    switch (call.method) {
      case "iDataIO_getCallbackData":
        result(dataString)
      default:
        result(FlutterMethodNotImplemented);
    }
});

この中の dataIOChannel が上記Dart側のplatform.invokeMethodで呼ばれるオブジェクトとなります。

そして渡されてきたメソッド名によってコードが実行され、resultで実行結果が返却されます。

 

Androidのコードは省略しますが、MainActivityの初期化コードの何処かに同じようなコードを記述することになります。

 

 

確かに工夫すれば結構なんでもやれちゃいそうではあるんですが、今回はここが一番のネックと感じました。
だってこれは完全にネイティブ実装、これなら全部ネイティブで書いたほうがストレスないと思うんですよね(個人的な見解)。。。

 

<プラットフォーム固有の機能がどこまでサポートされるか>

これも基本的にはコード共有と同じなんですが、例えばiOSの共有メニューに自分のアプリを選択肢として表示させてアクション出来るようにしたい、などについてはその部分はまるっとxCode使ってswiftで記述・plistを編集する必要があります。これも完全にネイティブ実装です。

 

<工期について>

これはもうネイティブ実装がどの程度必要になってくるか次第ですが、もしネイティブ実装の必要がほぼない、ということであれば、iOS、Androidそれぞれネイティブ実装したときが2だとすると、1.6程度かなといったところです。(がっつり作ったわけではありませんのであくまで私の感覚的なものです)

 

ただちょっと触ってみた感覚では、結局かなりネイティブコードを書くことになってしまうのではないか、という印象を持ちましたので、きちんとしたものを作ろうと思うほどにネイティブ実装より時間がかかってしまうように感じました。

 

例えば、オリジナルのソフトウェアキーボードを実装する、とか、上述した他のアプリとデータ共有する(iOSだと共有メニュー, AndroidだとIntent共有)など。
また、プッシュ通知自体はサーバサイドにFirebaseを利用すれば割合簡単に実装可能ですが、これも例えばiOSのプッシュ通知の際の細かな挙動をネイティブと同じように実装するのは、ネイティブ実装呼び出しを利用してもなかなか難しい感じです。

 

結論

 

今回、Flutterで実装することは見送る方向で検討しています。
やはりネイティブ実装が必要となる可能性が高く、それなら最初からネイティブ実装したほうが効率が良いのではないか、ネイティブ実装なら簡単に出来ることが予想外に時間がかかってしまう、という可能性がありそうだな、と感じたことです。

 

あと弊社、一応iOSもAndroidも両方対応可能なエンジニアが私含めていますので生産性という点でもデメリットを上回るメリットがないように感じました。

 

ただFlutterはまだベータ版で活発に開発が行われているようですので、今回私がネガティブに感じた部分がどんどん改善されていく可能性があります。

 

Flutterにかぎらずこういうものは時折チェックして乗り遅れないようにしていきたいですね。

 

開発現場からは以上となります。