プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

Android のストレージ関係のパーミッションについて

Android の外部ストレージ関係のパーミッションの扱いって、API レベルでいろいろと変わってわかりにくいので、まとめてみました。何かのご参考にしてください。

ただ、いろいろとドキュメントを読んではみたものの、理解不足から間違っている可能性もあります。その点を踏まえてご覧になる際は自己責任でお願いします。ということで、最終的にはご自分で公式ドキュメントを確認することをお勧めします。

なお、下記表で

です(ともに dangerous パーミッションです)。

外部ストレージの READ, WRITE を行う際に必要となる権限について

ターゲット manifest 宣言, READ manifest 宣言, WRITE Runtime Permission 処理 備考
API 3
( Android 1.5 ) 以前
- - - 常に許可される
API 4
( Android 1.6 ) ~
- 必要 - WRITE 導入
API 19
( Android 4.4, Kitkat) ~
必要、一部不要 ※1 同左 - READ が必要になる
API 23
( Android 6 ) ~
同上 同上 必要 Runtime Permission が導入
API 29
( Android 10, Q ) ~
必要、一部不要 ※2 同左 たぶん必要 対象範囲別ストレージ導入

※1 一部不要:特定の領域へのアクセスは宣言不要です(『アプリ固有のディレクトリ』と呼ばれており、具体的には getExternalFilesDir(), getExternalCacheDir() で取得されるディレクトリになります)

※2 一部不要:対象範囲別ストレージになり、アプリ固有のディレクトリには、そのアプリ以外のアプリはアクセスできなくなります

対象範囲別ストレージはまだ試してないので、ちょっと自信ありませんが、たぶんこんな感じになると思います。

ご参考までに。

Twilio Programmable Fax サービス終了の代替案について

去年末(2020/12)に最初のアナウンスがあったのですが、いままで FAX 送受信に使っていた Twilio の Programmable FAX が 2021/12/17 でサービス停止になります。

お安く使えて、APIで送受信できるようにしたので、気に入っていたので非常に残念なのですが、これも世の流れ、致し方ないですね。

少なくなったとはいえ、まだ FAX を受け取ることも時々あるので、Twilio に代わる FAX サービスの代替案を検討しました。

ちなみに、 Twilio からは、 InterFax が日本でのマイグレーション先として紹介されています。

InterFax へのマイグレーションガイド

ですが、ちょっと調べてみたら、(私としては) InterFax は月額料金が結構高いです。送受信を契約すると月額3000円オーバーです。

自分の場合、そこまでコストをかけるほど FAX を使ってないので、どう対応するかいろいろ検討してみました。何かのお役に立つかもしれませんので、その際に調べたことをメモっておきます。

求める機能

今の使い方(多分、今後も同じ)で FAX に求めるものは

  • メールで FAX の文面を受信可能
  • メールまたは API にて送信可能
  • FAX 機は置きたくない
  • 月額の固定費をできるだけ安く

というものです。

参考までに、Twilio の場合、月にかかる固定費としては電話番号代の 110円/月 のみだでした。

また、利用頻度は、

  • 受信頻度:月に数通
  • 送信頻度:年に数通

というところです。基本的に、ほぼ受信目的で使っており、送信することはほぼない感じです。

これを実現できるサービスを探しました。もちろん、このあたりの求めるものや送受信数の条件で、最適なサービスが変わってきますので、ご自分の用途を踏まえてご検討していただければと思います。

代替案

上記の条件に合いそうな FAX サービスや API を調べてみました。思ったよりたくさんのサービスがあるのと、思ったより月額料金が高くなりそうで、いろいろと驚きがありました。

ついでに、日本だと FAX はまだまだ健在なんだなと改めて痛感しました( FAX 無くすといってた政治家さんがいましたよね、ぜひ頑張ってほしいものです)。

で、比較の詳細このあと述べますが、結論からいうと今回は、 faximo を使うことにしました。

決め手は、

  • kintone アプリが使える
  • 月額料金が 1034 円(請求書レスの場合)
  • API も叩ける

というあたりです。

kintone アプリは何か具体的な用途があるというわけではないのですが、 kintone + FAX の組み合わせで何かできそうだと思ったので、一度試してみようかなと思った次第です。料金だけならもっとお安いサービスもあったんですが、 kintone に魅かれて、まあこれぐらいならいいか、となりました。

比較

下記の記事などを参考に、いろいろと比較してみました。

これらをざっと見た感じ、自分としては、

あたりが、月額料金が安くて使えそうでした。 特に、秒速FAX Plus ならプランによっては月額 520円とかで使える(送信は 秒速FAX送信 を利用し、基本料金無料)ので、値段だけを求めるならこちらのほうがよさげでした。

にしても、 Twilio の月額にかかる費用の安さが際立ちますねー。重ね重ね残念だ。

ひかり電話

また、上記のような FAX サービスを使うのではなく、光回線にひかり電話を付けて、そのオプションサービスの FAX お知らせメールを利用するという方法も検討しました。これは、指定電話番号にきた FAX を指定メールアドレスで受け取ることができるサービスです。料金は、

で、合計月額 770円ぐらいで使えそうです。なので、すでにひかり電話を利用している場合は、 Twilio に遜色のない追加の月額料金で FAX の受信ができそうです。

難点は、

  • 最初に工事費が必要になるので、初期費用が割高になる
  • 指定電話番号に来た電話の着信はできない(電話の発信は可能とのこと)
  • FAX 送信は、別の手段を考えないといけない

などの点です。

なので、当初は、いっそのこと FAX 送信を諦めてこれにしようかとも考えておりました。送信さえ気にしなければ、十分ですよね。

faximo の気になる点

ということで、 faximo を選択したのですが、このサービスで気になる点としては、電話番号として、

  • 03(東京)
  • 06(大阪)
  • 052 (名古屋)

で始まる電話番号しか選択できないことです。個人的には、伊勢(三重県)の個人事業者なのに、他県のFAX番号になるのはちょっといやなので、 050 のほうがよかったんですが、致し方ないですね。

利用開始

faximo を利用すると決めたので、早速申し込みました。 申し込みは、オンラインで手続きできます。

ただ、後日、申し込み時の住所に書類が郵送されてくるので、その指示に従って、身分証明書を送付して、身分確認を行う必要があります。 身分証明書の送付から確認完了まで若干時間がかかりましたが、問題なく完了すればこれで使えます。

まとめ

当初は、 FAX を利用するための API という形で探していたので選択肢が少ないなと感じていたのですが、世の中にはメールでの FAX 送受信サービスにあふれていることに気づいて、いろいろな選択肢があることがわかりました(まあ、 FAX 機はなくせるならなくしたいですもんね)。それに、各 FAX サービス提供企業さんで、 送信・受信ともいろいろと便利な付加的な機能が提供されています。ご自分の目的に合わせて選ぶと幸せになれるかもしれません。

あと、いくつかのサービスで、受信用の FAX 番号を発行することはできても、送信時はこの番号ではなく別の電話番号からの発信になる、というのもありました。このあたりも用途によっては気にしないといけないかもしれませんね。

いずれにしても、しばらく、こちらのサービスを使っていこうと思います。

避難所検索@伊勢 v1.1 をリリースしました

伊勢市のオープンデータを利用した、避難所検索@伊勢ですが、細々と改修しています。 今回は、避難所データを動的に変更できるように改修して v1.1としてリリースしました。

play.google.com

もっとも、使う分には今までと大きく違わないので、変わった感じはしませんけどね。

あと、こちらにサポートサイトという形で、いくつかの情報をまとめるようにしました。避難所をタップした際に表示されるデータについても、ある程度整理してみました。

お暇なときにでも、一度アプリを試してみていただければと思います。

で、以下は、今回の改修に関する雑多なメモになります。

避難所データの更新について

避難所データの更新は、既存のオフラインマップの更新の仕組みと同じ方法を用いています。

具体的にはソースコードを見ていただければいいんですが、簡単に書くと、

  1. 所定のファイル名を持つ避難所データのファイルと、その日時を表すタイムスタンプファイルを S3 にアップロードしておきます
  2. アプリ起動時(または、メニューから更新確認を実行時)に、S3 上のタイムスタンプファイルを確認し、
  3. アプリ内のファイルより S3 側が新しければ、ファイルをダウンロードする
  4. ダウンロードしたファイルに応じたチェック処理を行い、問題がなければ更新する

というものです。

参考までに、S3 へのアップロードスクリプトを gist に載せておきます。

なお、

  • オフラインマップの生成とアップロードについて興味があれば、こちらの記事
  • 避難所データの作り方に興味があれば、こちらの記事

もご参考にしてください。

余談

実は、避難所データの更新は、上記に書いた既存のオフラインマップの更新の仕組みを使うか、 Firebase の Remote Config を使うか、ちょっと迷いました。

で、 Firebase Remote Config のサンプルアプリを動かしたり、ドキュメントを読んだりした感触としては、

  • 今ある避難所データ(初期データ)を与えているファイル形式(CSV)は直接扱えない
  • しかし、 JSON にすれば Remote Config でも扱えそう
  • アプリ側のデフォルト値ももてる

ということでした。

なので、これで進めようかなとも考えたのですが、現状の設計だと、初期の避難所データは SQLite に入れて扱っていて、これとの兼ね合いをどうするか若干すっきりしなかったので、今回は見送りました(順当に更新できるときは問題なさそうなんですが、更新に失敗するような場合の処理がちょっと見えませんでした)。

設定画面で管理するようなデータなら、うまいこと使えそうなんですけどね。まあ、せっかく調べたのでどこかで活かそうと思います。