はじめに SharedPreferenceは今までちゃんと使ったことがなく、調べてもすぐに忘れるの繰り返しでした。 そこで、今回はsharedPreferenceのCRUD(Create,Read,Update,Delete)のやり方を見ながら基本を整理していこうと思います。 あくまで自分の備忘録として記していますが、もしも 基本的なsharedPreferenceの書き方が知りたい方 どれがファイル名でどれがキーでどれがバリューなのかを整理したい方 のお力になれることがあれば大変幸いです。 実行環境 項目 情報 PC MacBook Pro (14-inch,2021) CPU Apple M1 Pro 10-core GPU Apple M1 Pro 16-core OS macOS Monterey (12.0.1) Android Studio Arctic Fox 2020.3.1 Patch4 目次 共通処理 Create : 新規作成・書き込み READ : 読み出し UPDATE : 編集 DELETE : 削除 詰まりポイント Create :新規作成・書き込み MainActivity.kt fun sharedPreferenceTest(){ // インスタンスを取得 val sharedPreferences: SharedPreferences = getSharedPreferences("FileName" , Context.MODE_PRIVATE) // 書き込み sharedPreferences.edit() .putString("これはキーです","これはバリューです") .apply() } val sharedPreferences: SharedPreferences = getSharedPreferences("FileName" , Context.MODE_PRIVATE)でsharedPreferenceのファイル名とモードを指定しつつ、変数にsharePreferenceのインスタンスを入れています。 この部分は編集・読み出し・削除でも使う共通部分です。 インスタンスを取得した後はsharedPreference.edit()以降でキーバリュー形式で値を入れています。 今回は文字列を保存するためputStringを使っていますが、他にもputInt putBooleanなどがあります。 全体に共通することですが、sharedpreferenceのデータに変更を加える場合は.editをまず呼び、次にそれぞれの編集処理（今回は.putString(）を行い、最後に.apply .commitで変更を保存するというイメージです。 ※ちなみに.apply .commitの違いは .apply→非同期で値を保存 .commit→メインスレッドで値を保存 という感じらしいです。基本的にはapplyを使うことが推奨されています。詳しくは公式やこちらのstackoverflowをぜひ見てみてください！ 結果 fileName.xml <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="これはキーです">これはバリューです</string> </map> Android Studio右タブのDeviceFile Explorerを開き、data > data > パッケージ名 > shared_prefsの中に上記のようなxmlファイルが作成されています。 今回はファイル名を指定して書き込みを行ったため、ファイル名がFileName.xmlとなっています。 READ：読み出し 上記で保存した値をエミュレーター上で表示させてみたいと思います。 この検証ではTextViewに渡す処理が必要なので、onCreateとレイアウトファイルを含めたコード全体を載せておきます。 ちょっと長いですが、要はsharedPreferences.getStringで読み出せるよということです。 MainActivity.kt override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val binding: ActivityMainBinding = DataBindingUtil.setContentView(this,R.layout.activity_main) binding?.activityMainText?.text = sharedPreferenceTest() } fun sharedPreferenceTest(): String?{ // インスタンスを取得 val sharedPreferences: SharedPreferences = getSharedPreferences("fileName" , Context.MODE_PRIVATE) // 読み出した結果を戻り値として渡す return sharedPreferences .getString("これはキーです","キーが見つかりませんでした") } onCreate内はレイアウト作成とtextViewに値を入れる処理をしているだけなので、ここでは詳細な説明は省かせていただきます。 書き込んだ値を取得するにはgetStringを使います。これも書き込み時と同じくgetIntやgetBooleanなどがあります。 第一引数では参照したいキー名を、第二引数にはそのキーに値が存在しなかった場合に表示する値を設定します。 結果 ↓データが存在した時 ↓データが存在しなかった時 UPDATE :編集 Create :新規作成・書き込みと全く同じです。 同じキー名を指定し、好きな値を設定すると上書きされます。 MainActivity.kt fun sharedPreferenceTest(){ // インスタンスを取得 val sharedPreferences: SharedPreferences = getSharedPreferences("fileName" , Context.MODE_PRIVATE) // 上書き sharedPreferences.edit() .putString("これはキーです","これは新たなバリューです") .apply() } 結果 fileName.xml <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="これはキーです">これは新たなバリューです</string> </map> DELETE : 削除 sharedPreferenceの値を削除する場合は.removeを呼びます。 sharedPreferenceのデータをいじるわけなので、.edit で変更開始、最後に.applyで締めています。 MainActivity.kt fun sharedPreferenceTest() : String? { // インスタンスを取得 val sharedPreferences: SharedPreferences = getSharedPreferences("fileName" , Context.MODE_PRIVATE) // removeで削除 sharedPreferences.edit() .remove("これはキーです") .apply() 結果 fileName.xml <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map /> 綺麗さっぱり消えてますね！ その他メモ AndroidStudioからsharedPreferenceを閲覧するとき、リアルタイムで更新されない時がある どうやらビルドしても値が更新されない時があるようです。その場合は端末名(下記画像の「KYOCERA S6-KC」の部分)を押すと再読み込みされて最新のデータが取得できます。 インスタンスの取得方法 MainActivity.kt fun sharedPreferenceTest(){ // インスタンスを取得 val sharedPreferences: SharedPreferences = getPreferences(MODE_PRIVATE) 今回は上記のような形でファイル名を指定しつつインスタンスを取得していました。 インスタンスを取得する方法はgetPreferences以外にgetPreferenceもあるようです。 こちらを使うと1Activityに対して1つだけsharedPreferenceファイルを作成するという使い方ができるようになります。そのためファイル名も以下のようにActivityのクラス名がそのままが適用されます。 MainActivity.kt fun sharedPreferenceTest(){ // インスタンスを取得（この場合はファイル名を設定する必要なし） val sharedPreferences: SharedPreferences = getPreferences(MODE_PRIVATE) // 値の書き込み sharedPreferences.edit() .putString("これはキーです","これはバリューです") .apply() } 結果↓ MainActivity.xml <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="これはキーです">これはバリューです</string> </map>

はじめに 皆さんは、少し前に話題になった九州大学アプリをご存知でしょうか？ 本アプリはTwitterなどのSNSで拡散されるなどして、AppStoreにて97位を記録いたしました。1 また、現在のインストール数は、九大生人口の20%を超えております。2 今回は、制作時に得た知見を共有することで、皆さんのお力になれたらと思います。 また、皆さんからいろんなアドバイスをいただきたいとも思っているので、ぜひよろしくお願いします。 自己紹介 省略? アプリ概要 主な機能は3つ クラウド過去問 デジタル学生証 ニュース を実装しています。 また、PVとして以下の動画（18秒ほど）を制作しているので、見て頂けるとわかり良いかと思います。 制作背景 コロナ禍で繋がりにくさを感じる学生が、情報過少で悩むことを無くしたい との思いから、制作することになりました。 実際コロナ禍になって、多くの人が鬱や不登校になっていると言われています。中でも大学生（低学年）は、「実家を離れて異郷の地でチャレンジする」人が多いために、相対的に該当者が多いようなことを考察しました。 本学（九州大学）においても状況は例外でなく、救済を意図としたメンタルヘルス予約アプリ 3 4の開発・リリースを外注するなど、大学としても対応をおこなっていたことを知りました。 また、僕の経験談にはなりますが、コロナ禍になってからというもの、可愛がっている後輩らから落ち込んでいるなどの相談を受けたり、友人づてに鬱になった学生らの噂を何度か聞くなど、身の回りでも、そういった学生がいることを知りました。その度に、何かできることはないかな、と感じてはおりました。そんな中、僕の大学一番の親友も、ついに不登校になってしまいまして5それがきっかけで、もう本当に危機感と救命心で心がいっぱいになりました。卒論や就活の最中でしたが、本アプリの着想を始めました。 技術選定 こんな状況だったため、とにかく早くリリースに漕ぎ着けようと思い、以下のような技術を選びました。 Flutter Firebase Pub.dev外部パッケージの多用 なぜFlutterを選んだかを述べます。 私自身、普段はUnityを利用してゲームを制作しているのですが、ツールアプリ＆時短を考慮して、宣言的UIかつクロスプラットフォームを候補にした結果、 Flutter React Native Bubble.io が挙がり、それぞれの特徴を調べたところ「情報多そう、バグ少なそう」という2点に目が行き、Flutterを利用することにしました。 機能案 アプリのサブタイトル「過去問と学生証をスマホで」の通りメインの機能は、 クラウド過去問 デジタル学生証 の二つであり、おまけとして ニュース を実装しています。 なぜ上記三つの機能を実装したのかを、時系列順に説明します。 ニュース Flutterを初利用する上で、練習がてらにプログラムしたのが、ニュース機能です。これは、公式ページをスクレイピングするだけで実装できるので、練習にちょうど良かったです。 当初は、⚡️公式ページよりも早く表示できるということをウリに差別化していました。（実際、先んじてデータをスクレイピングしておいたり、スクレイピングの際に簡素なデータのみを抽出することで高速化を図っていました。ただ、利便性重視のアップデートを行うことでその速さはほとんど軽微なものになりましたが。） 利用技術と使い方 pub.dev のパッケージを利用することで、制作しました。動作はYahoo!ニュースに近いです。 クラウド過去問 外せないと思った機能は、クラウド過去問です。 周りの状況から鑑みるに不登校や鬱になった学生の共通点として 真面目 頼るのが苦手 完璧主義 がみて取れました。逆に、いわゆるウェイ系（飲み会好き）やサボリ系（適当主義）、リア充（彼氏彼女持ち）は該当することが少ないようでした。 そう言うわけで、彼らを救うために、 情報の提供 コミュニティの提供 価値観変更の促し などを考えましたが、その中でも新規アプリとして提供できる純度の高いものは、情報の提供になるのではないかと仮説しました。念の為、友人へLINEやTwitterで「上記3種のアイデアのどれが有用だと思うか」を尋ねた結果、ほとんど私と同じで「作るなら過去問のアプリだろう」とのことでした。 実際に、過去問の機能（有志によるアップロードと、無償で可能なダウンロード）を実装した初版をリリース後、学内のいろんな人にビラを配ったり触ってもらいつつ、所感を述べてもらったりインストール率を確認することで、需要の度合いを確認してみました。（計500名ほど）すると、次のことがわかりました。 ⭕️ 大学1,2年生はかなりの確率でインストールしてくれる。 ❌ 大学3,4年生、大学院生はほとんどインストールしない。 考えたら当たり前のことでしたが、実際に経験するとショックな出来事でした。やはり下級生は過去問で困っている人が多いようで、ベータ版にも関わらず、砂漠でオアシスを見つけたかの如く「ありがとうございます！！完成したら絶対使います！」と言っていただく機会が多かったです。 反対に上級生は、そもそも過去問が必要な学年ではないという前提もありますので、「後輩を救うためにアップロードしてほしいです！」という文言でビラを配りましたが、あまり共感を得られませんでした。彼らの意見として「アップロードに対してのインセンティブがないとやらないな」とか「自分はもう、過去問を利用する年齢じゃないので使わない。」などが多く寄せられました。また、そもそもビラを受け取ってくれない人も多く、ここに、コロナ禍を経験した層としていない層の大きな隔たりを見て取れました。 もちろん、上級生であっても即インストールして頂ける方も少なからず居て、彼らはコロナ禍の後輩の現状を知っている人だったり、共感性の高い人だったりしました。ですが、多くの上級生は、コロナ禍の後輩の現状を知らない方が多いようでした。 そこで、上級生がインストールするメリットを感じられる機能を追加することにしました。 利用技術と使い方 Firebase Strage Firebase Authentication UIはGoogle Driveに近いです。 デジタル学生証 「学生証がアプリになった」というパワーワードが上級生のインストールにつながるだろう、とのことで学生証機能を実装しました。 最初は、学生証のICをスマホのFelicaで反映できないかと考えましたが、どうやら本学の学生証は、富士通？の独自IC技術を取り入れているようで、スマホに入れられる形式ではありませんでした。そこで、いわゆる学生番号（バーコード形式）のみをスマホに反映することにしました。同時に、大学事務室や学内図書館に掛け合って、このバーコードシステムを学内利用できないか掛け合うご相談をいたしました。結果、大人の事情で難しいだろうということで、現在は未だ「使い道のない学生証システム?」です。この点は、大学公認サークル6と連携しまして、着実に新ルール提案からしていこうか、という話になっております。 ただ、本アプリの目的は、学生証システムではなく、あくまで「過去問など、情報提供によってコロナ禍の後輩を救うこと」であり、本筋と外れていますから、優先順位は高くありません。 利用技術 pub.dev のパッケージを利用することで、制作しました。学生番号を入力するか、スマホカメラにて学生証を読み取ると使えるようになります。UIはPayPayに近いです。 信頼性 信頼性については、以下の2点の対応を行いました。ただ、開発よりもこの部分にかなりの時間を費やすことになりましたし、私の知識不足から未だ上手い対処ができておりません。ぜひ皆さんにアドバイスしていただきたいです? プログラム的な信頼性 開発元の信頼性 プログラム的な信頼性というのは、「勝手に情報が抜き取られているのではないか」という点の対処です。結論、本アプリは個人情報を抜き取ったり、どこかにストックしたりということはありません。 一番気になるのは、学生証を読み取る機能の部分だと思いますが、こちらはスマホ内での計算とストレージにのみ頼っており、この際情報が外部に通信されることは一切ありません。 ただ、これを証明するいい案が思いつかず、、、皆さまどういった案があるでしょうか？? また、開発元の信頼性というのは、「開発者は信頼できるのか」ということですが、ユーザーのアドバイスによると、個人でやっている限り懐疑心は高いのでは、とのことだったので、色々な学内団体に掛け合い、大学公認サークル6と連携することになりました。また、アプリ内で収益を得ないということも、間接的に信頼につながるだろうとの意見もありましたので、無広告・アフィリエイト無しにしました。また、過去問用のサーバー費を私が負担することで、赤字前提で、後輩を救うために運営しているということが伝わればと思っています。ただ、こちらも上手い伝え方が分からないのでいい伝え方があれば、是非とも教えていただきたいです?‍♀️ 許可等 アプリに関する許可等については、事務室など色々な場に掛け合うことで対応中ですが、こちらは本当に難しいです。大人の方には、かなり誠意的に相談に乗って頂いているので、有難い限りです。ただ、大人の事情がどうしてもありまして、ご相談の結果、連携する大学公認サークル6にて対応することにしました。 お忙しい中、ご相談用の会議を開いていただいた事務室の方や、色々な大人の方にはこの場を借りて感謝申し上げます。?‍♀️ 最後に AppStore、Google Playにて公開しておりますので、ぜひダウンロードして頂けると嬉しいです。 改善点やレビュー等、お待ちしております。 日本国内の教育カテゴリーにて、2022/02/03 現在 ↩ 九大人口を18,000人とした時に、AppStore,GooglePlay両者の総インストール数が3600を超えるため。2022/03/31 現在 ↩ https://www.kyushu-u.ac.jp/ja/topics/view/1677 ↩ https://apps.apple.com/app/id1562248417 ↩ 現在は復帰して無事卒業しました? ↩ 九州大学起業部と2022/03より。 ↩ ↩2 ↩3

はじめに 皆さんは、少し前に話題になった九州大学アプリをご存知でしょうか？ 本アプリはTwitterなどのSNSで拡散されるなどして、AppStoreにて94位を記録いたしました。1 また、現在のインストール数は、九大生人口の20%を超えております。2 今回は、制作時に得た知見を共有することで、皆さんのお力になれたらと思います。 また、皆さんからいろんなアドバイスをいただきたいとも思っているので、ぜひよろしくお願いします。 自己紹介 省略? アプリの概要 主な機能は3つ クラウド過去問 デジタル学生証 ニュース を実装しています。 また、PVとして以下の動画（18秒ほど）を制作しているので、見て頂けるとわかり良いかと思います。 制作背景 コロナ禍で繋がりにくさを感じる学生が、情報過少で悩むことを無くしたい との思いから、制作することになりました。 実際コロナ禍になって、多くの人が鬱や不登校になっていると言われています。中でも大学生（低学年）は、「実家を離れて異郷の地でチャレンジする」人が多いために、相対的に該当者が多いようなことを考察しました。 本学（九州大学）においても状況は例外でなく、救済を意図としたメンタルヘルス予約アプリ 3 4の開発・リリースを外注するなど、大学としても対応をおこなっていたことを知りました。 また、僕の経験談にはなりますが、コロナ禍になってからというもの、可愛がっている後輩らから落ち込んでいるなどの相談を受けたり、友人づてに鬱になった学生らの噂を何度か聞くなど、身の回りでも、そういった学生がいることを知りました。その度に、何かできることはないかな、と感じてはおりました。そんな中、僕の大学一番の親友も、ついに不登校になってしまいまして5それがきっかけで、もう本当に危機感と救命心で心がいっぱいになりました。卒論や就活の最中でしたが、本アプリの着想を始めました。 技術選定 こんな状況だったため、とにかく早くリリースに漕ぎ着けようと思い、以下のような技術を選びました。 Flutter Firebase Pub.dev外部パッケージの多用 なぜFlutterを選んだかを述べます。 私自身、普段はUnityを利用してゲームを制作しているのですが、ツールアプリ＆時短を考慮して、宣言的UIかつクロスプラットフォームを候補にした結果、 Flutter React Native Bubble.io が挙がり、それぞれの特徴を調べたところ「情報多そう、バグ少なそう」という2点に目が行き、Flutterを利用することにしました。 3つの機能 アプリのサブタイトル「過去問と学生証をスマホで」の通りメインの機能は、 クラウド過去問 デジタル学生証 の二つであり、おまけとして ニュース を実装しています。 なぜ上記三つの機能を実装したのかを、時系列順に説明します。 ①ニュース 開発背景 Flutterを初利用する上で、練習がてらにプログラムしたのが、ニュース機能です。 これは、公式ページをスクレイピングするだけで実装できるので、練習にちょうど良かったです。 当初は、⚡️公式ページよりも早く表示できるということをウリに差別化していました。（実際、先んじてデータをスクレイピングしておいたり、スクレイピングの際に簡素なデータのみを抽出することで高速化を図っていました。ただ、利便性重視のアップデートを行うことでその速さはほとんど軽微なものになりましたが。） 使用技術 pub.dev のパッケージを利用することで、制作しました。 使い方 動作はYahoo!ニュースに近いです。 ②クラウド過去問 開発背景 外せないと思った機能は、クラウド過去問です。 周りの状況から鑑みるに不登校や鬱になった学生の共通点として 真面目 頼るのが苦手 完璧主義 がみて取れました。逆に、いわゆるウェイ系（飲み会好き）やサボリ系（適当主義）、リア充（彼氏彼女持ち）は該当することが少ないようでした。 そう言うわけで、彼らを救うために、 情報の提供 コミュニティの提供 価値観変更の促し などを考えましたが、その中でも新規アプリとして提供できる純度の高いものは、情報の提供になるのではないかと仮説しました。念の為、友人へLINEやTwitterで「上記3種のアイデアのどれが有用だと思うか」を尋ねた結果、ほとんど私と同じで「作るなら過去問のアプリだろう」とのことでした。 実際に、過去問の機能（有志によるアップロードと、無償で可能なダウンロード）を実装した初版をリリース後、学内のいろんな人にビラを配ったり触ってもらいつつ、所感を述べてもらったりインストール率を確認することで、需要の度合いを確認してみました。（計500名ほど）すると、次のことがわかりました。 ⭕️ 大学1,2年生はかなりの確率でインストールしてくれる。 ❌ 大学3,4年生、大学院生はほとんどインストールしない。 考えたら当たり前のことでしたが、実際に経験するとショックな出来事でした。やはり下級生は過去問で困っている人が多いようで、ベータ版にも関わらず、砂漠でオアシスを見つけたかの如く「ありがとうございます！！完成したら絶対使います！」と言っていただく機会が多かったです。 反対に上級生は、そもそも過去問が必要な学年ではないという前提もありますので、「後輩を救うためにアップロードしてほしいです！」という文言でビラを配りましたが、あまり共感を得られませんでした。彼らの意見として「アップロードに対してのインセンティブがないとやらないな」とか「自分はもう、過去問を利用する年齢じゃないので使わない。」などが多く寄せられました。また、そもそもビラを受け取ってくれない人も多く、ここに、コロナ禍を経験した層としていない層の大きな隔たりを見て取れました。 もちろん、上級生であっても即インストールして頂ける方も少なからず居て、彼らはコロナ禍の後輩の現状を知っている人だったり、共感性の高い人だったりしました。ですが、多くの上級生は、コロナ禍の後輩の現状を知らない方が多いようでした。 そこで、上級生がインストールするメリットを感じられる機能を追加することにしました。 使用技術 Firebase Strage Firebase Authentication 使い方 UIはGoogle Driveに近いです。 ③デジタル学生証 開発背景 「学生証がアプリになった」というパワーワードが上級生のインストールにつながるだろう、とのことで学生証機能を実装しました。 最初は、学生証のICをスマホのFelicaで反映できないかと考えましたが、どうやら本学の学生証は、富士通？の独自IC技術を取り入れているようで、スマホに入れられる形式ではありませんでした。そこで、いわゆる学生番号（バーコード形式）のみをスマホに反映することにしました。同時に、大学事務室や学内図書館に掛け合って、このバーコードシステムを学内利用できないか掛け合うご相談をいたしました。結果、大人の事情で難しいだろうということで、現在は未だ「使い道のない学生証システム?」です。この点は、大学公認サークル6と連携しまして、着実に新ルール提案からしていこうか、という話になっております。 ただ、本アプリの目的は、学生証システムではなく、あくまで「過去問など、情報提供によってコロナ禍の後輩を救うこと」であり、本筋と外れていますから、優先順位は高くありません。 使用技術 pub.dev のパッケージを利用することで、制作しました。学生番号を入力するか、スマホカメラにて学生証を読み取ると使えるようになります。 使い方 UIはPayPayに近いです。 信頼性を高める。 信頼性については、以下の2点の対応を行いました。ただ、開発よりもこの部分にかなりの時間を費やすことになりましたし、私の知識不足から未だ上手い対処ができておりません。ぜひ皆さんにアドバイスしていただきたいです? プログラム的な信頼性 開発元の信頼性 プログラム的な信頼性というのは、「勝手に情報が抜き取られているのではないか」という点の対処です。結論、本アプリは個人情報を抜き取ったり、どこかにストックしたりということはありません。 一番気になるのは、学生証を読み取る機能の部分だと思いますが、こちらはスマホ内での計算とストレージにのみ頼っており、この際情報が外部に通信されることは一切ありません。 ただ、これを証明するいい案が思いつかず、、、皆さまどういった案があるでしょうか？? また、開発元の信頼性というのは、「開発者は信頼できるのか」ということですが、ユーザーのアドバイスによると、個人でやっている限り懐疑心は高いのでは、とのことだったので、色々な学内団体に掛け合い、大学公認サークル6と連携することになりました。また、アプリ内で収益を得ないということも、間接的に信頼につながるだろうとの意見もありましたので、無広告・アフィリエイト無しにしました。また、過去問用のサーバー費を私が負担することで、赤字前提で、後輩を救うために運営しているということが伝わればと思っています。ただ、こちらも上手い伝え方が分からないのでいい伝え方があれば、是非とも教えていただきたいです?‍♀️ 許可を得る。 アプリに関する許可等については、事務室など色々な場に掛け合うことで対応中ですが、こちらは本当に難しいです。大人の方には、かなり誠意的に相談に乗って頂いているので、有難い限りです。ただ、大人の事情がどうしてもありまして、ご相談の結果、連携する大学公認サークル6にて対応することにしました。 お忙しい中、ご相談用の会議を開いていただいた事務室の方や、色々な大人の方にはこの場を借りて感謝申し上げます。?‍♀️ 最後に AppStore、Google Playにて公開しておりますので、ぜひダウンロードして頂けると嬉しいです。 改善点やレビュー等、お待ちしております。 日本国内の教育カテゴリーにて、2022/02/03 現在 ↩ 九大人口を18,000人とした時に、AppStore,GooglePlay両者の総インストール数が3600を超えるため。2022/03/31 現在 ↩ https://www.kyushu-u.ac.jp/ja/topics/view/1677 ↩ https://apps.apple.com/app/id1562248417 ↩ 現在は復帰して無事卒業しました? ↩ 九州大学起業部と2022/03より。 ↩ ↩2 ↩3

はじめに 皆さんは、少し前に話題になった九州大学アプリをご存知でしょうか？ 本アプリはTwitterなどのSNSで拡散されるなどして、AppStoreにて94位を記録いたしました。1 また、現在のインストール数は、九大生人口の20%を超えております。2 今回は、制作時に得た知見を共有することで、皆さんのお力になれたらと思います。 また、皆さんからいろんなアドバイスをいただきたいとも思っているので、ぜひよろしくお願いします。 自己紹介 省略? アプリの概要 主な機能は3つ クラウド過去問 デジタル学生証 ニュース を実装しています。 また、PVとして以下の動画（18秒ほど）を制作しているので、見て頂けるとわかり良いかと思います。 制作背景 コロナ禍で繋がりにくさを感じる学生が、情報過少で悩むことを無くしたい との思いから、制作することになりました。 実際コロナ禍になって、多くの人が鬱や不登校になっていると言われています。中でも大学生（低学年）は、「実家を離れて異郷の地でチャレンジする」人が多いために、相対的に該当者が多いようなことを考察しました。 本学（九州大学）においても状況は例外でなく、救済を意図としたメンタルヘルス予約アプリ 3 4の開発・リリースを外注するなど、大学としても対応をおこなっていたことを知りました。 また、僕の経験談にはなりますが、コロナ禍になってからというもの、可愛がっている後輩らから落ち込んでいるなどの相談を受けたり、友人づてに鬱になった学生らの噂を何度か聞くなど、身の回りでも、そういった学生がいることを知りました。その度に、何かできることはないかな、と感じてはおりました。そんな中、僕の大学一番の親友も、ついに不登校になってしまいまして5それがきっかけで、もう本当に危機感と救命心で心がいっぱいになりました。卒論や就活の最中でしたが、本アプリの着想を始めました。 技術選定 こんな状況だったため、とにかく早くリリースに漕ぎ着けようと思い、以下のような技術を選びました。 Flutter Firebase Pub.dev外部パッケージの多用 なぜFlutterを選んだかを述べます。 私自身、普段はUnityを利用してゲームを制作しているのですが、ツールアプリ＆時短を考慮して、宣言的UIかつクロスプラットフォームを候補にした結果、 Flutter React Native Bubble.io が挙がり、それぞれの特徴を調べたところ「情報多そう、バグ少なそう」という2点に目が行き、Flutterを利用することにしました。 3つの機能 アプリのサブタイトル「過去問と学生証をスマホで」の通りメインの機能は、 クラウド過去問 デジタル学生証 の二つであり、おまけとして ニュース を実装しています。 なぜ上記三つの機能を実装したのかを、時系列順に説明します。 ①ニュース 開発背景 Flutterを初利用する上で、練習がてらにプログラムしたのが、ニュース機能です。 これは、公式ページをスクレイピングするだけで実装できるので、練習にちょうど良かったです。 当初は、⚡️公式ページよりも早く表示できるということをウリに差別化していました。（実際、先んじてデータをスクレイピングしておいたり、スクレイピングの際に簡素なデータのみを抽出することで高速化を図っていました。ただ、利便性重視のアップデートを行うことでその速さはほとんど軽微なものになりましたが。） 使用技術 pub.dev のパッケージを利用することで、制作しました。 使い方 動作はYahoo!ニュースに近いです。 ②クラウド過去問 開発背景 外せないと思った機能は、クラウド過去問です。 周りの状況から鑑みるに不登校や鬱になった学生の共通点として 真面目 頼るのが苦手 完璧主義 がみて取れました。逆に、いわゆるウェイ系（飲み会好き）やサボリ系（適当主義）、リア充（彼氏彼女持ち）は該当することが少ないようでした。 そう言うわけで、彼らを救うために、 情報の提供 コミュニティの提供 価値観変更の促し などを考えましたが、その中でも新規アプリとして提供できる純度の高いものは、情報の提供になるのではないかと仮説しました。念の為、友人へLINEやTwitterで「上記3種のアイデアのどれが有用だと思うか」を尋ねた結果、ほとんど私と同じで「作るなら過去問のアプリだろう」とのことでした。 実際に、過去問の機能（有志によるアップロードと、無償で可能なダウンロード）を実装した初版をリリース後、学内のいろんな人にビラを配ったり触ってもらいつつ、所感を述べてもらったりインストール率を確認することで、需要の度合いを確認してみました。（計500名ほど）すると、次のことがわかりました。 ⭕️ 大学1,2年生はかなりの確率でインストールしてくれる。 ❌ 大学3,4年生、大学院生はほとんどインストールしない。 考えたら当たり前のことでしたが、実際に経験するとショックな出来事でした。やはり下級生は過去問で困っている人が多いようで、ベータ版にも関わらず、砂漠でオアシスを見つけたかの如く「ありがとうございます！！完成したら絶対使います！」と言っていただく機会が多かったです。 反対に上級生は、そもそも過去問が必要な学年ではないという前提もありますので、「後輩を救うためにアップロードしてほしいです！」という文言でビラを配りましたが、あまり共感を得られませんでした。彼らの意見として「アップロードに対してのインセンティブがないとやらないな」とか「自分はもう、過去問を利用する年齢じゃないので使わない。」などが多く寄せられました。また、そもそもビラを受け取ってくれない人も多く、ここに、コロナ禍を経験した層としていない層の大きな隔たりを見て取れました。 もちろん、上級生であっても即インストールして頂ける方も少なからず居て、彼らはコロナ禍の後輩の現状を知っている人だったり、共感性の高い人だったりしました。ですが、多くの上級生は、コロナ禍の後輩の現状を知らない方が多いようでした。 そこで、上級生がインストールするメリットを感じられる機能を追加することにしました。 使用技術 Firebase Strage Firebase Authentication 使い方 UIはGoogle Driveに近いです。 ③デジタル学生証 開発背景 「学生証がアプリになった」というパワーワードが上級生のインストールにつながるだろう、とのことで学生証機能を実装しました。 最初は、学生証のICをスマホのFelicaで反映できないかと考えましたが、どうやら本学の学生証は、富士通？の独自IC技術を取り入れているようで、スマホに入れられる形式ではありませんでした。そこで、いわゆる学生番号（バーコード形式）のみをスマホに反映することにしました。同時に、大学事務室や学内図書館に掛け合って、このバーコードシステムを学内利用できないか掛け合うご相談をいたしました。結果、大人の事情で難しいだろうということで、現在は未だ「使い道のない学生証システム?」です。この点は、大学公認サークル6と連携しまして、着実に新ルール提案からしていこうか、という話になっております。 ただ、本アプリの目的は、学生証システムではなく、あくまで「過去問など、情報提供によってコロナ禍の後輩を救うこと」であり、本筋と外れていますから、優先順位は高くありません。 使用技術 pub.dev のパッケージを利用することで、制作しました。学生番号を入力するか、スマホカメラにて学生証を読み取ると使えるようになります。 使い方 UIはPayPayに近いです。 信頼性を高める。 信頼性については、以下の2点の対応を行いました。ただ、開発よりもこの部分にかなりの時間を費やすことになりましたし、私の知識不足から未だ上手い対処ができておりません。ぜひ皆さんにアドバイスしていただきたいです? プログラム的な信頼性 開発元の信頼性 プログラム的な信頼性というのは、「勝手に情報が抜き取られているのではないか」という点の対処です。結論、本アプリは個人情報を抜き取ったり、どこかにストックしたりということはありません。 一番気になるのは、学生証を読み取る機能の部分だと思いますが、こちらはスマホ内での計算とストレージにのみ頼っており、この際情報が外部に通信されることは一切ありません。 ただ、これを証明するいい案が思いつかず、、、皆さまどういった案があるでしょうか？? また、開発元の信頼性というのは、「開発者は信頼できるのか」ということですが、ユーザーのアドバイスによると、個人でやっている限り懐疑心は高いのでは、とのことだったので、色々な学内団体に掛け合い、大学公認サークル6と連携することになりました。また、アプリ内で収益を得ないということも、間接的に信頼につながるだろうとの意見もありましたので、無広告・アフィリエイト無しにしました。また、過去問用のサーバー費を私が負担することで、赤字前提で、後輩を救うために運営しているということが伝わればと思っています。ただ、こちらも上手い伝え方が分からないのでいい伝え方があれば、是非とも教えていただきたいです?‍♀️ 許可を得る。 アプリに関する許可等については、事務室など色々な場に掛け合うことで対応中ですが、こちらは本当に難しいです。大人の方には、かなり誠意的に相談に乗って頂いているので、有難い限りです。ただ、大人の事情がどうしてもありまして、ご相談の結果、連携する大学公認サークル6にて対応することにしました。 お忙しい中、ご相談用の会議を開いていただいた事務室の方や、色々な大人の方にはこの場を借りて感謝申し上げます。?‍♀️ 最後に AppStore、Google Playにて公開しておりますので、ぜひダウンロードして頂けると嬉しいです。 改善点やレビュー等、お待ちしております。 日本国内の教育カテゴリーにて、2022/02/03 現在 ↩ 九大人口を18,000人とした時に、AppStore,GooglePlay両者の総インストール数が3600を超えるため。2022/03/31 現在 ↩ https://www.kyushu-u.ac.jp/ja/topics/view/1677 ↩ https://apps.apple.com/app/id1562248417 ↩ 現在は復帰して無事卒業しました? ↩ 九州大学起業部と2022/03より。 ↩ ↩2 ↩3

私の車は今まで中華Android搭載カーナビを入れて使っていたのですが、最近タッチパネルが全く反応しなくなり（操作するときはグローブボックスに入れているマウスでやってます）、新しくしたくなりました。 といっても最近はBluetoothオーディオ再生機としてしか使っていなかったので、適当なBluetooth対応オーディオデッキを入れても良かったのですが、それだとちょっと寂しいなと。 個人的に、Tesla Model 3みたいに、大きめディスプレイにいろいろな情報を（かっこよく）表示させて近未来的な感じにしたいと思っていました。 で、いろいろ考えた結果、余っているAndroid端末、ESP32、温度センサなどを使ってディスプレイオーディオ的なものを作ることにしました！！ 構成 こんな感じです。 結構複雑ですね。。。 ディスプレイ（Android端末） Android端末です。 キーオンで電源オン、ESP32にWiFiで接続します。 自作Androidアプリ ディスプレイ用Android端末で動かすアプリです。 自動起動するよう設定します。 機能としては、 Mapboxを用いて現在地地図を表示（経路案内は必要ないので実装しない） 時計表示 車側モジュールから受け取った環境情報を表示 車内温度 車外温度 GPS測位状況 車側モジュールから受け取った再生している曲の情報を表示 音楽再生の操作ボタンによって、車側モジュールに対して再生制御コマンドを送信 各種設定（車側モジュールのIPアドレス、TCPポート番号など） 車側モジュール ESP-WROOM-32 ESP32のボードです。 こいつが結構仕事が多いんですが、 WiFiアクセスポイント（ホスト） 車内外温度センサーからの環境情報（車内外気温、車内湿度、車内気圧）をTCPでAndroidのアプリへ送信 Bluetooth A2DP Sinkとして手持ちスマホ（ディスプレイではない）と接続し、音声をI2Sを通じてDACへ送り、車のスピーカーを鳴らす A2DP再生をしている際、AVRCPを通して曲の情報を受取り、Androidのアプリへ送信 A2DP再生をしている際、AndroidアプリからTCPで受け取った再生制御コマンド（再生、停止、前の曲、次の曲）を解釈してAVRCPを通して手持ちスマホの再生をコントロール 車内外温度センサ 車外用にはOneWire接続のDS1820搭載防水温度センサ、車内用はI2C接続のBME280を使っています。 BME280は気温だけでなく、湿度や気圧まで測ることが出来るので、これらもついでにアプリに表示出来るようにします I2S DAC ESP32にも内蔵DACはありますが、分解能が8bitですし、実際にイヤホンをつないで聞いてみると結構ノイズが多かった（WiFiとBluetoothを同時に動かしながらだから仕方ないと思われる）ので、別に16bitのステレオDACを用意することにし、I2Sという通信方式でデジタルデータを送る形にしました。 誤算 今回は家で眠っていたKindle Fire 7（2017）をディスプレイとして利用しようと思っておりました。 ですが、この端末はGPSを内蔵していないということに後で気づき、頭を抱えましたw GPS搭載のタブレットを買うというのもアリだったんですが、流石に1万円は超えてしまうなーと思い、できるだけ安く作りたかったので回りくどい方法を取りました。 GPSモジュール(NEO6M)を利用することにしました。 ESP32へUARTを通してNMEAを受け取り、ESP32がそれを端末へTCPで垂れ流します。 NMEAというのは、この手のシリアル通信のGPSモジュールが吐き出すテキストベースのフォーマットで、 緯度や経度、標高だけでなく、設定によっては測位衛星数などの細かい情報まで取得することができます。 後は端末側でNMEAから緯度、経度、移動方位、移動速度、標高など必要な情報をパースしてマップに渡したり表示したりするわけですね。 （画像左上の基盤と四角いやつがGPSモジュールとアンテナ） またESP32の仕事が増えてしまいましたが、致し方無いですね... 実装 意外とサクサクと実装できましたが、いくつか躓いたポイントがありました。 ESP32のメモリ不足 ESP32が担う仕事が多すぎて、コードもデカくなってしまって（特にESP32-A2DPがでかい)書き込みできない問題が発生しました。 問題は、書き込み時にパーティションの設定を変えることでどうにか解消しました。 https://asukiaaa.blogspot.com/2019/03/esp32-wroom032ota.html どのパーティション設定を利用したかは失念してしまったのですが、パーティション設定を変えてユーザー領域を多くすることによってコードはすべて書き込めたという形になります。 基板実装 ユニバーサル基板上に部品を配置して、エナメル線orスズメッキ線で配線をしています。 流石に部品が多く配線も多い上に基盤1枚に収めたかったので、事前にちゃんと配線取り回しを考えてから実装しました。 2DINスペースの下側にALPINEの1DINオーディオを取り付けて、その上の1DINスペースにモジュールを置きたかったので、ショート防止の為にコチュジャンの入っていたタッパーにUSBケーブル用の溝だけ空けて置きました。力技ですが、見えない所なので問題ないでしょう。 Kindle固定 最も苦労したかもしれません。 Fusion360と3Dプリンターを使用してチルト・取り外し可能なマウントを作りました。 Kindle側はケースを外して裏から皿ねじを使ってステーを固定するという力技を発揮して固定し、車両側は2DINのステーにホムセンL字金具と3Dプリンタで印刷したチルト機能付き差し込み部品を使って固定してます。 Kindleを差し込んで、上から適当な釘で閂（かんぬき）を刺すことで固定する手筈でした。 実際はチルト部分はモーメントに耐えられず水平にしか固定できず、閂を刺すために指を入れるスペースもほとんど取れなかった（シフトレバーへの干渉を恐れてKindleをダッシュボード側に近いかたちで設計したため）ので、まあ固定はできたのですがうまくいったとは言えませんでした... （そして固定した状態の写真も見つからなかった...） 結果 見た目はいい感じになりました。 チルト機能と脱着機構は犠牲にしましたが、一応固定はできています。 動作 GPS測位について 一応問題なく測位できていました。 何度か取り外して家に持ち帰って修正をしていると、GPS測位ができなくなることもありましたが、接触不良か、GPSアンテナ位置の問題な気もします。 Bluetoothについて 音楽再生は問題なくできました。 極稀にESP32の動作すべてが落ちることもありましたが、頻度はだいぶ低いので一応見て見ぬふりをしています。RAM使用量の問題かもと思っています。 TCPでのタブレットとの通信 最初は問題ないのですが、しばらく動かしていると反応がなくなってしまうのでコネクションが切れているようです。 ちゃんと検証できていないですが、TCPコネクションの確認の為に数秒ごとにハートビートを送って、コネクションが切れていたら再接続を行う機能を実装する必要があると考えています。 開発途中でバグが多かったのですが、このあたりで本格的に卒業研究が始まってしまい、卒業研究が終わったあと引っ越す頃には愛車ジムニーを手放す（実家に保留中）することになってしまったのでこれらのバグ修正はできずに終わってしまいました? 学びを得た 完成までできず大変悔しいですが、いろいろと学びました。 Androidアプリ開発 今までも開発はしたことがありましたが、MapBox、別スレッドでのTCP通信、設定画面の実装などのノウハウを学ぶことができました。Kotlinにもだいぶ慣れてきました。 ESP32での開発 ESP8266での開発は経験がありましたが、Bluetooth機能を使えるESP32での開発は初めてだったので大変勉強になりました。 TCP通信 オーバーヘッドの大きなHTTPではなくTCPをそのまま用いて簡単なテキストメッセージフォーマットを決めて実装し、通信は成功したのですが、コネクションがよく途切れること、そしてそれをAndroid側で検知できなかったことからコネクションの生存確認の必要性を感じました。 記録は大事 ちゃんと日記というか、記事にまとめながら作るのは重要だと感じました。。。 今後 車は手放しましたが、東京に引っ越してからもオートバイには乗っていますので、いろいろと落ち着いてから開発を再開したいと思っています。 オートバイになれば音楽再生と車内温度の計測は不必要になり、タブレットは大きすぎるのでディスプレイをスマホに変更することになればGPSモジュールも（おそらく）必要なくなります。 一方、オートバイならばGPSログ機能やジャイロセンサでの斜度計なんかも欲しくなるなーと妄想をしています。 次こそはちゃんと逐一Qiitaに記事をあげようと思います。。。

前回API level 26以上　API level 31未満のやり方を書きました。 今回は、API level 31の振動のさせ方を書こうと思います。 Manifestの設定 AndroidManifest.xmlでVIBRATEの許可します。 AndroidManifest.xml <uses-permission android:name="android.permission.VIBRATE"/> Activity MainActivity.kt if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) { val vibratorManager = getSystemService(Context.VIBRATOR_MANAGER_SERVICE) as VibratorManager val vibrationEffect = VibrationEffect.createWaveform(longArrayOf(500L, 1000L),intArrayOf(200, 0), -1) val combinedVibration = CombinedVibration.createParallel(vibrationEffect) vibratorManager.vibrate(combinedVibration) } これで振動できます。 VibrationEffect.createWaveformで振動の設定をします。 第一引数はタイミング/振幅ペアのタイミング値（ミリ秒単位）。タイミング値が0の場合、ペアは無視されます。 今回は500ms振動して1000ms振動しないとなります。 第二引数はタイミング/振幅ペアの振幅値。振幅値は、0〜255、またはに等しい必要があります。振幅値0は、オフであることを意味します。 今回は第一引数で設定した500msの間200の強さ振動をして、1000msの間0の強さの振動(オフ)となります。 第三引数は繰り返すタイミング配列へのインデックス。無期限に繰り返したくない場合は-1 今回は繰り返さないです。無限に繰り返す場合は0を入れてください。 ※第一引数と第二引数のリストサイズは同じである必要があります。 ※第三引数はリストのサイズまでの整数を入れる事ができます。 例:リストのサイズが５で第三引数に３を入れた場合 0->1->2->3->4->3->4->3->4 振動の設定が簡単にできるようになりました。

モーションセンサーとは ほとんどAndoridには加速度計やジャイロスコープが搭載されていて、そこで検知した内容のことを総称してモーションセンサーと言います。 端末の傾き、振動、回転、地磁気センサーなど端末周りで検知している情報をとっています。 今回はこれを検知する方法を書きます。 SensorEvent すべてのモーションデータは多次元配列でそれぞれ取得できます。 すべてSensorEventパラメータとfloat型の値をセットで送ってくれますので、同時に全部取得して使うものだけ取り出すということが可能です。 サポートされているモーションセンサー TYPE_ACCELEROMETER x, y, z軸の加速力 TYPE_ACCELEROMETER_UNCALIBRATED x, y, z軸の測定加速度 TYPE_GRAVITY x, y, z軸の重力 TYPE_GYROSCOPE x, y, z軸の回転速度 TYPE_GYROSCOPE_UNCALIBRATED x, y, z軸の回転速度（ドリフト補償なし）とドリフト TYPE_LINEAR_ACCELERATION x, y, z軸の加速力（重量を除く） TYPE_ROTATION_VECTOR x, y, z軸の回転ベクトル成分（x * sin(θ/2)）, 回転ベクトルのスカラー成分（(cos(θ/2)） TYPE_STEP_COUNTER 最終再起動時以降、センサーがアクティベートされている間に、ユーザーが歩いた歩数。 よく使われるのは 回転ベクトルセンサーと重力センサーです。 動作検知の対象として回転ベクトルを多く使うので、そこから色々な目的で検知をして利用していくみたいです。 重力センサーは端末の動きの方向性をとりたい場合に有効で使われているようです。 回転ベクトルセンサー取得してみた sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager rotationVector = sensorManager.getDefaultSensor(Sensor.TYPE_GAME_ROTATION_VECTOR) 上記のコードで回転ベクトルセンサーが取得できます。 多次元配列で SensorEvent.values[0]にはx軸のデータ、 SensorEvent.values[1]にはy軸のデータ、 SensorEvent.values[2]にはz軸のデータがありますのでそれぞれ取得。 SensorEvent.values[3]には回転ベクトルのスカラー成分があるので取得。 それぞれ取得した結果を以下のように画面表示。 以上になります。 参考

textViewの属性に android:autoLink = "web" を追加するだけ。 このautolink属性は便利で = の値を　"address"　"email" だったりにも設定できます ですがどんな場合にも使えるわけではなく、例えばurlの後ろにスペースが空いてなければその後の文字列も全部リンク化されてしまいます。 その場合にはこちらの記事が参考になります https://android.gcreate.jp/482/ autoLink公式ドキュメント https://developer.android.com/reference/android/widget/TextView#attr_android:autoLink

この記事は 私がAndroid Dagashiから一つだけ記事をピックアップして読み、理解し、そして私のような初心者のAndroiderもしくはモバイルアプリ開発者が読むと仮定して、「誰でも理解できること」を目的として内容をまとめます！ 今回は第三回です！ よろしくお願いします！！ 今週のピックアップ記事 今週は、2022-03-27の記事の中からピックアップして読むことにします。 そして今回のピックアップ記事は。。。 Exploring User Choice Billing With First Innovation Partner Spotify です。よろしくお願いします！！ Exploring User Choice Billing With First Innovation Partner Spotify 和訳：ファーストイノベーションパートナーであるSpotifyとユーザー選択課金制を模索する いつもと比べると短い記事ですが、アプリ内課金とはアプリ開発者としてもユーザーとしても、両方の立場から身近な話題であるので興味を持ちました。 内容（和訳） モバイルアプリは私たちの生活を一変させました。モバイルアプリは、私たちが情報を得たり楽しんだりするのを助け、私たちを互いにつなぎとめ、世界中の何十億という人々に新たな機会を生み出してきました。Google Play が過去 10 年間にわたり、この世界的な変革に果たしてきた役割に、私たちは身の引き締まる思いがします。 大切なデベロッパーとの緊密なパートナーシップと、デベロッパーのフィードバックを活用し、進化を続けてきたからこそ、私たちはここにいるのです。例えば、パートナーからのフィードバックや競合との競争に基づき、プラットフォームを利用するすべてのデベロッパーが成功できるように価格モデルを進化させ、今日では99%のデベロッパーが15%以下のサービス料で利用できるようになっています。 最近、アプリストアの課金体系をめぐる議論が活発になっています。私たちはこの議論を歓迎し、今日、Playの開発者とともに取り組んでいるエキサイティングなパイロットプログラムを紹介したいと思います。 ユーザーチョイス課金 ユーザーが Google Play を選ぶのは、Google が安全な体験を提供することを期待しているからであり、これにはユーザーのデータと金融情報を保護するアプリ内決済システムが含まれます。そのため、Google Play の課金システムをプライバシーと安全性の最高水準で構築し、ユーザーがアプリ内課金を行う際に重要な支払いデータが危険にさらされることがないよう、安心してご利用いただけるようにしました。 Google Playからアプリケーションをインストールする際に、引き続きPlayの課金システムを利用する選択肢をユーザーに提供すべきであると考えています。また、代替の課金システムが、ユーザーの個人データや機密性の高い金融情報を保護する上で、同様に高い安全基準を満たすことが極めて重要だと考えています。 最近、韓国のユーザーに対してPlayの課金システムと並行して追加の課金システムを許可したことに続き、私たちの原則に沿って、他の特定の国でもユーザー選択型の課金システムを検討することを発表します。 この試験的な取り組みでは、少数の参加デベロッパーが Google Play の課金システムの隣に追加の課金オプションを提供できるようにし、エコシステムへの投資能力を維持しながら、ユーザーにこの選択肢を提供する方法を模索することを目的としています。これは重要なマイルストーンであり、モバイル、デスクトップ、ゲーム機を問わず、主要なアプリケーションストアでは初めてのことです。 Spotifyとの提携 私たちは、開発者とパートナーシップを組み、ユーザーチョイス課金のさまざまな実装を検討します。まずは、Spotifyから。世界最大のサブスクリプションデベロッパーのひとつとして、グローバルに展開し、さまざまなデバイスのフォームファクターに統合されているSpotifyは、最初のパートナーとして自然な存在です。私たちは、消費者によるアプリ内課金の方法を革新し、複数のデバイスで魅力的な体験を提供し、より多くの消費者をAndroidプラットフォームに取り込むために協力していきます。 Spotifyは、Google Playの課金システムを、現在の課金システムと並行して導入することになりますが、最初のパートナーとしての彼らの視点は非常に貴重なものになるでしょう。この試験的な取り組みにより、ユーザー選択課金が、さまざまな国のユーザーや、さまざまな規模やカテゴリーの開発者にとって有効かどうか、またどのように機能するかについて、理解を深めることができます。 フリーミアムビジネス最高責任者のAlex Norströmは、次のようにコメントしています。「Spotifyは、アプリ開発者が自由に革新し、公平な競争の場で競争できるようにするために、何年もかけて旅をしています。この度、Googleと提携し、開発者、ユーザー、そしてインターネットのエコシステム全体にとっての決済の選択肢と機会について、このようなアプローチを模索できることを嬉しく思っています。私たちが共に行う作業が、他の業界にも利益をもたらす道を切り開くことを望んでいます。 このプロセスには時間がかかり、開発者コミュニティとの密接な協力が必要であることを理解しています。しかし、私たちはこの最初のステップに興奮し、今後数ヶ月の間にさらに多くのことを共有する予定です。 要約 ユーザー選択課金というのは具体的にどういうものなのか私なりの理解で説明させてもらいたいと思います。 通常、スマートフォンのアプリストアにおけるアプリの購入や課金は、AndroidアプリならGoogle、iOSアプリならAppleの決済システムを通して行われます。しかし近年では「サードパーティーの決済システムも許可するべき」との声が高まっており、そんな中でGoogleは「開発者がアプリにおいてGoogle以外の決済システムを提供できるようにする」との方針を示した、というのが今回の記事の内容になります。 上は参考になる画像です。画面下部に表示されているモーダルを見ると、Google Play以外のアプリも選択肢として表示されているのが分かるかと思います。おそらく、私たちにもっと馴染みのある決済アプリで言うとpay payとかau payとかがgoogleさんとの契約をモニョモニョしたりすればアプリ内課金の際にそれらのアプリを選択することが可能になる...と言うことかと理解しています。 間違ってたらすみません