先日作った、Androidスマフォの画像をLinuxPCにWi-Fiで取り込むプログラム(システム)だが、その後、使ったり試行錯誤したり考えたりしているうちにいろいろアイデアが浮かんで、(まだ細かい確認・調整点はあるものの)最初の要望どおり、以下のようにできた。

スマフォをPCに繋がなくても、操作なしで自動的にPCに画像が取り込まれる

それまで難しいと思っていたのは、元々の要望の重要な点とか使い方とか全体としての流れを整理し切れていなかったからだと思う。

僕の使い方と期待する動作を整理すると、以下のようになる。

  1. 外でスマフォで撮影したり画面をキャプチャして帰宅したら、それほど待たずに(家のWi-Fiに繋がった頃に)PCに画像が取り込まれている。
  2. 家でスマフォで撮影や画面をキャプチャしたあと、そのまま置いておけば(それほど待たずに)PCに画像が取り込まれている。

1は既に前回できた(Wi-Fiの再接続を契機に転送を開始する)。2は、前回はいつ転送(するかどうかのチェック)を始めればいいかの判断をすればいいのか分からなかった。そこで、更に具体的に使い方の流れを考えると、以下になる。

  1. スマフォで撮影やキャプチャする。
  2. 画面をoffにする。

そして、画面がoffになった(→ スマフォがアイドル(使っていない)状態になった)のを契機に処理を開始すれば良いことに気付き、実装した。かなり手こずったが、概ねうまく動くようになった。処理の流れの概要は以下である。

  • スマフォ
    1. スマフォがアイドル状態になったことを検知する。
      1. 画面がoffになるのを待つ。
      2. 数分後(例: 5分)にタイマーがイベントを出すように設定する。
    2. タイマーイベントを待つ。
    3. 前回の転送終了時刻より新しいファイルを探す。
    4. 新しいファイルがあれば、PCに転送開始要求を出す。
  • PC: スマフォから新しいファイルを取得する。

以下に難しかったことを書く。

アイドル(スマフォを使っていない)状態の検出

画面がoffになってすぐ転送を行うと、例えば、画面のタイムアウトで暗くなったなどで、また画面をonにして使い出して画像を追加する可能性があるから無駄である(無意味ではないが、まだ作業が終わっていないものを転送する可能性があるし、新規ファイルのチェックや転送(通信)の回数はなるべく減らす方が良い)。そこで、スマフォがアイドル状態であることを検知して転送を行うことにした。

アイドル状態は、一定時間(例: 5分間)画面がoffになっていることで判定するようにした。また、その時間より早く画面がonになったら、アイドル状態でないとして処理を打ち切る(「なかったこと」にする)。具体的には、画面がoffになった時にタイマーを設定し、タイマーの期限が来たらアイドルとし、それより前に画面がonになったら、(アイドルでないとして)タイマーを解除する。

なお、スリープ中はSSHDroidがうまく動かない(スマフォが完全にスリープしている訳ではないが、SSHDroidがスリープしているようだ)ので、スリープを解除するために画面をonにするのだが、その後の画面offもアイドルの開始と判定してしまう問題があるので、自分で画面をonにした場合には少しの間(例: 30秒間)画面offを無視するようにした。なお、なぜか、自分(このプログラム)で画面をonにした場合には、画面onのイベントは起こらないようだ(将来問題になりそうなので、再確認が要りそうだ)。

「前回の転送終了時刻」の取得

スマフォはPCに(「新しいファイルがあるよ」と)転送開始要求を出すだけで、実際の転送はPCが行うため、PCが本当にファイルを取得したか・できたかは基本的には分からない。しかし、転送に使っているrsyncコマンドはリモート(この場合、スマフォ)に転送のログを書くことができるので、その機能を使うことにした(これは邪道なやり方なのだが、一応、rsyncの機能しか使っていないので、許すことにした)。転送が成功しているとすれば、ログの更新時刻=転送終了時刻なので、新規ファイルの検索に手軽に使える(転送中に画像を作成するなどして食い違いが生じる可能性もあるが、その前にアイドル(放置)状態であることを確認しているので、余りなさそうだ)。

なお、ログから転送が成功したかどうかの判定をして、失敗していたら適切に処理すべきだが、今はいつも成功したとみなしている。そのため、何らかの原因でエラーが起こった場合、転送アイコンを押して(手動で)取得する必要がある。 → ログ中のエラーから失敗を判定する処理を追加した。失敗した場合、下記のログファイルの削除を行わないようにすることで、次回も今回と同じファイルから転送する。ただ、それでうまくいくかは疑問で、通知などが要る気がする。 (3/10 7:20)

また、rsyncのログファイルは毎回追記されるので、サイズが増大するのを防ぐため、転送開始要求を出す前に削除(実際にはrename)している。

 

以上により、基本的には、定期的な新規ファイルのチェックが不要になった(一応、保険として1時間に1回するようにはしている。ただ、アイコンを押せば手動でできるので、そこまでする必要はないのだが・・・ ← 忘れていたが、自動転送要求する時にPCが起動していなかった場合のリトライ用に有用だった(3/10 14:46))。それに加え、前回追加した、PCから最新のファイル名を取得する処理(通信)も不要になり(= 再び転送開始要求だけになった)、電池消費量が(更に?)減ったはずで※、なかなか気分がいい。

※ 8時間のアイドル時の消費電力量は0.4%/hだった。これは先日できたWi-Fiの再接続処理の低い時と同じ値なので、このプログラムの待ち受け時の消費電力は無視できる程度と考えられる。 (3/10 7:29)

そして、結果的にスマフォの転送開始アイコンもPCの状態表示ウインドウも不要になってしまった(後者は、使用中に勝手に出ると邪魔なので、エラー発生時以外は出さないようにしているため)。

 

作った画像転送システムを実際に使っていると、今までは余り興味がなくて魅力を感じていなかった無線や非接触通信がかなり便利に感じる。ケーブルをつながなくていいから手間が省けるし、机の周りがごちゃごちゃしなくて済む(でも、イヤフォンは御免だw)。それで、デジカメの画像もWi-Fiで取り込みたい気分が起こって来た。ちょっと調べたら、FlashAirがなかなかおもしろそうだ。ただ、電池消費量が増えるという情報があるし、そもそもそこまでする必要があるのか(スマフォはあるものでできたから手軽に始められたけど、デジカメだと追加の物が要るのでお金が掛かる)甚だ疑問なので、良く考えたい。

あと、スマフォの充電も非接触にして可能な限りケーブルを排除したいのだが、本体が対応していないので無理そうだ(これもいろいろあるんだろうけど・・・)。

 

PS. 少し話が飛ぶが、日本のメーカーは、ユーザーの要望の真意とか実際に使う手順とかをちゃんと見極めずに、「できるから」、「高機能なら売れる」と思い込んで作り込んでしまったために、機能はてんこ盛りだけど使えない家電とかばかりになってしまったのではないだろうか。挙句の果てに、高いうえに使いにくいから売れずに海外のライバルに負けてしまったという、踏んだり蹴ったり状態だ・・・

PS2. (節操なく宗旨替えするようだがw、)この無線・非接触の時代に、USBは4なんてやり出して、全く理解できない。まあ、あってもいいけど、そこまで高速なのが要るのだろうか。それより、昔諦めたWireless USBを復活させればいいと思うのに。ただ、あれ自体はUWBを使うなんて先進的過ぎて失敗したので、もっと「普通に」やればいいと思うが、そうできないからああなったのだろうか? だったらWi-Fiとかを使えばいいってことだろうか?

(3/10 7:58 加筆・修正)

  •   0
  •   0

コメントを書く

名前    

メール 

URL