20200522のAndroidに関する記事は4件です。

DribbbleでFlutterのUI実装力を高める

みなさん、こんにちは
とあるサラダ?の会社で開発やってます umatoma です。

最近はFlutterのUI実装力を高めようと、
Dribbbleで公開されているデザインをFlutterで再現してみているので、紹介したいと思います。

Dribbble

https://dribbble.com/

Dribbble is the world’s leading community for creatives to share, grow, and get hired.

Dribbbleには?のように、様々なデザインが投稿されていて、
アプリUIに関するデザインも沢山?あります。

また、動画で投稿されているものもあったりして、
アニメーションを含んだデザインが見れる点はとても良いです?

で、このDribbleで公開されているデザインをFlutterで再現して、
FlutterのUI実装力を高めようと試みています???

スクリーンショット 2020-05-22 19.49.39.png

DribbbleのデザインをFlutterで再現してみる

今の所、こんな感じでDribbbleのデザインをベースにFlutterで再現してみました。

デザイン Flutterで再現してみたやつ
Mobile Digital Wellbeing Application by Umar Abdul Azis on Dribbble sign-in-sign-up.png
Sign In/ Sign Up Page App UI by Md. Hafizur Rahaman on Dribbble
Flight and Hotel Booking App by Subash Chandra on Dribbble flight-booking.png
UI modeling. Admin mobile main views set by Maxim Aginsky on Dribbble

詳しい実装方法の説明は?で紹介しているので、良かったら見てみて下さい?

Flutterで再現してみて

形状が複雑でない多くのパーツは
標準で提供されいるWidgetを組み合わせることで簡単に実装することができました。

ですが、少し凝った形状になるとただWidgetを組み合わせるだけで
実現するのが難しくなりました?

そういった時は ClipPathCustomPaint などを使って、
自分で Path を描きデザインを実装する必要があります。

それがデメリットかと言うと、そうでもないかなと思っています。

UI modeling. Admin mobile main views set by Maxim Aginsky のインジケーター部分のように、
複雑なデザインのパーツがあたっとしても
CustomPaint などを使えば自分で描画すれば実装できてしまうという事です。

Flutterは提供されているWidgetを組み合わせるだけでも整ったUIを実装することができますが、
やはり、凝ったデザインを実装するには CustomPaint などを使いこなす必要がありそうです?

今後は、アニメーションを含めたUIの実装にチャレンジして行きたいと思います。

まとめ

  • Flutterに限らず、UI実装力を高めたい時のデザインを探すにはDribbbleを使うと良い
  • FlutterのUI実装力を高めるには CustomPaint などを扱えるようにする

最後に

今回のデザインの実装方法を含めた、
Flutter入門用のWebサイトを公開しているので、興味があったら使ってみて下さい。

Flutterで始めるアプリ開発
https://www.flutter-study.dev/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Github Actionsにて自動的にビルドする環境作成(Android)

概要

Github ActionsでのCI/CDの検証を行いました。
その中で他の開発プロジェクトにも定常的に適用できるようなテンプレートを作成しました。
作成したテンプレートのプロジェクトは以下になります。
github-actions-examples

今回このような環境の構築にあたっての備忘録としてここに記述しておきます。
また上記のプロジェクトは他の様々な環境において試したものであり、今回はGithub Actionsにおける Androidアプリ での自動ビルドの手法についてを中心に紹介します。

Webサイトでの自動デプロイおよびGithubActionsでの基本的な設定についてなどはこちらの記事を参照してください。
Github Actionsにて自動的にデプロイする環境作成(Webサイト編)

この他に iOSUnity での自動ビルドの環境構築については現在検証しています。こちらも手法が確立でき次第、紹介したいと思います。

やりたいこと

  • Androidアプリを開発し、GithubにpushしたらGithub Actions にて Build が行われること
  • Release用の証明鍵をGithub Actions上にて管理し、その署名鍵を用いて Build が行われること → リリース用Build
  • Build が完了したら apkファイルaabファイル をダウンロードできること → 端末の中に直接インストールする場合は apkファイル Google Play Storeに配信する場合は aabファイル を使用するといい
  • Google Play Storeにリリースするための鍵を使って Build が行われること ← 後日更新

Build

結論

以下の内容をそれぞれ参照してください

各種解説

JDKのセットアップ

AndroidアプリのBuildはJava製のアプリケーションとしてBuildします。今回はBuildするために JDK を使用してBUildを行います(Kotlinで開発していても同じです)
Github Actionsでは action/setup-java を使用することで JDK のsetupができます。また、今回はJava version 1.8 でBuildするので使用するバージョンを指定します。ymlファイルには以下のように記述します。

jobs:
  build:
    steps:
      ...
      - name: setup JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8

Android SDKのセットアップ

JDKのセットアップができたら次は Android SDK をダウンロードしてセットアップします。
Android SDK は一般的にはAndroid Studioにてダウンロードしますが、今回はCLIで実行すため、Android Studioを使用しない方法でダウンロードします。
Android Studio 内の Command line tools only の項目に Android SDK が入っている zipファイル をダウンロードします。この zipファイル には Android SDK Toolsのバージョンによって変わります。ダウンロードして使用したいバージョンを指定したURLを記載します。以下の処理がzip ファイルをダウンロードして解凍している処理になります。

wget --quiet --output-document=android-sdk.zip https://dl.google.com/android/repository/sdk-tools-linux-${{ matrix.sdk-tools }}.zip
unzip -d android-sdk-linux android-sdk.zip

matrix.sdk-tools には上記の Android SDK のバージョンの値を指定します。今回の例では 4333796 を使用します。

Android SDK のダウンロード、および解凍が完了したら、 build-tools platform-tools などを使用するための設定や環境変数であるPATHを通します。

echo y | android-sdk-linux/tools/bin/sdkmanager "platforms;android-${{ matrix.compile-sdk }}" >/dev/null
echo y | android-sdk-linux/tools/bin/sdkmanager "platform-tools" >/dev/null
echo y | android-sdk-linux/tools/bin/sdkmanager "build-tools;${{ matrix.build-tools }}" >/dev/null
export ANDROID_HOME=$PWD/android-sdk-linux
export PATH=$PATH:$PWD/android-sdk-linux/platform-tools/

次に Android SDK を使用するためにlincenseを承諾します。

set +o pipefail
yes | android-sdk-linux/tools/bin/sdkmanager --licenses
set -o pipefail

これで Android SDK の設定が完了してAndroidアプリをBuildすることができるようになります。

gradleのセットアップ

AndroidでアプリをBuildするにはGradleを用います。Gradleの設定は gradlew を実行することで自動的にセットアップしてくれます。(各種Gradleコマンドもgradlew を使用して実行されます)、gradlew ファイルを実行できるように権限を更新します。

chmod +x ./gradlew

(おまけ) Warning解消

上記までにBuildを行う設定なのですが、このままBuildを行うと Warning が出てしまうので Warning がでないようにするために以下のファイルを作成します。

sudo touch /root/.android/repositories.cfg

Debug Build

Androidアプリをビルドする環境が整ったら、まずは Debug Build を行います。
Debug用のBuildは以下のコマンドを実行することでBuildすることができます。

./gradlew assembleDebug

AndroidアプリをBuildするためには署名が必要なのですが、署名鍵を特に指定しないDebug用はBuildでは Android SDK がインストールされた時点で ~/.android/debug.keystore に生成されている debug用keystore を使用してBuildが行われます。

【参考】
debug用keystoreについて調べてみた

Release Build

Debug Buildの場合はAndroidのdebug用keystore を用いてBuildが行われましたが、Google Play StoreなどにBuildしたAndroidアプリを配布する場合、デフォルトの署名鍵でBuildされたアプリでは配布することができません。
配布するためには署名鍵を自分で作成し、作成した署名鍵を用いてBuildすることでStoreに配布するアプリをBuildすることができます(ここではこのようなBuildをRelease Buildと呼びます)
以降では Github Actions でRelease用のBuildを行う方法を紹介します。
また、鍵の作成についてはこちら などを参考に作成してください。

Buildに使用する鍵を参照できるようにする

作成した署名鍵を指定してBuildをするためには署名鍵ファイルをapp/buld.gradle にて指定することでBuildする場合に適用されます。

この時、storeFile storePassword keyAlias keyPassword の情報が必要になりますので、app/buld.gradle にこれらの情報を指定します。
しかし、これらの情報は秘匿して管理したい環境変数であるので、Androidにて環境変数を記述する local.properties に以上の情報を記述し、その内容をapp/build.gradle 内にて読み込むことでBuildを行うときに参照するようにします。(local.properties はデフォルトで.gitignore に記載されています)

app/buld.gradle への記述は以下のようになります。

build.gradle
Properties properties = new Properties()
def localPropertiesFile = project.rootProject.file('local.properties');
if(!localPropertiesFile.exists()){
    // localPropertiesFileがなければ作成します
    localPropertiesFile.createNewFile();
}
properties.load(localPropertiesFile.newDataInputStream())

上記の例では Build時に local.properties がなければ、新しく作成し、あれば既存のファイルを読み込むことで設定に適用します。(このようにしないと local.properties がない場合(Debug Buildを行う場合などにおいて)、Buildエラーになってしまう)

読み込んだ、local.properties の値をBuildをRelease Build の際に適用するには以下のように記述します。

build.gradle
android {
    ...
    signingConfigs {
        release {
            // 指定したfileがある場合のみ記述
            if(!properties.getProperty("RELEASE_STORE_FILE", "").empty){
                storeFile file(properties.getProperty("RELEASE_STORE_FILE", ""))
            }
            storePassword properties.getProperty("RELEASE_STORE_PASSWORD", "")
            keyAlias properties.getProperty("RELEASE_KEY_ALIAS", "")
            keyPassword properties.getProperty("RELEASE_KEY_PASSWORD", "")
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

このとき local.properties には以下のような環境変数を設定します。

local.properties
RELEASE_STORE_FILE=署名鍵ファイルのファイルパス(絶対パス)文字列
RELEASE_STORE_PASSWORD=ストアパスワード文字列
RELEASE_KEY_ALIAS=キーエイリアス文字列
RELEASE_KEY_PASSWORD=キーパスワード文字列

※ 上記の設定を適用した場合、ローカルで Release Build を行う場合は local.properties に以上の内容を記述し、署名鍵ファイルの情報を記述してください。

鍵の管理

本来なら署名鍵ファイルはバイナリファイルなのでどこかに保存して取得するかプロジェクトの中に埋め込むかする必要があります。
しかし、それだと署名鍵ファイルが多くの開発者に知られてしまうという問題点があります。

そこで今回、署名鍵の管理をGithub Secretsに保存し、秘密の環境変数として適用します

署名鍵のファイルサイズは軽微なものであるので、base64 でバイナリファイルを文字列化します。
この文字列を Github Secrets に保存し、Github Actions を実行した時にバイナリファイルに戻して保存することで秘匿されたまま鍵の管理が可能となります。まず署名鍵ファイルをbase64で文字列に出力します。

base64 Androidのビルド署名鍵.keystore

このコマンドを実行して出力された文字列を、Github Secrets に登録します。

Github Actions 内ではここで設定した Github Secrets の情報が適用されるので、以下のようにbase64 -d >でバイナリファイルに書き出します。

echo ${ANDROID_REALSE_BASE64_KEY} | base64 -d > ./release-application-key

※ ここでは ANDROID_REALSE_BASE64_KEY にバイナリファイルを base64 にて文字列にした物を Github Secrets に設定しています。
release-application-key が一時的に保存する署名鍵のファイル名となります。

local.properties に上記の各種Release Buildを行うために必要な情報を記述する

Github Actions を行う場合、Release Buildを行うために必要な情報を local.properties に以下の情報を記述します。

local.properties
RELEASE_STORE_FILE=署名鍵ファイルのファイルパス(絶対パス)文字列
RELEASE_STORE_PASSWORD=ストアパスワード文字列
RELEASE_KEY_ALIAS=キーエイリアス文字列
RELEASE_KEY_PASSWORD=キーパスワード文字列

これらの情報は全てGithub Secretsに設定し、設定した内容を以下のように local.properties に追記していくようにします。

echo ${ANDROID_REALSE_BASE64_KEY} | base64 -d > ./release-application-key
echo "RELEASE_STORE_FILE=`pwd`/release-application-key" >> ./local.properties
echo "RELEASE_STORE_PASSWORD=${ANDROID_REALSE_KEY_PASSWORD}" >> ./local.properties
echo "RELEASE_KEY_ALIAS=key0" >> ./local.properties
echo "RELEASE_KEY_PASSWORD=${ANDROID_REALSE_KEY_PASSWORD}" >> ./local.properties

これにより Github Actions にて実行される際に local.properties に値が適用された状態でBuildが行われます。

GradleでRelease Buildを行う

以下のコマンドを実行することで apkファイル を出力するRelease Buildを行います

./gradlew assembleRelease

続けて、以下のコマンドを実行することで aabファイル を出力するRelease Buildを行います

./gradlew bundleRelease

Buildした成果物をダウンロードできるようにする

Debug Build, Release Build共にBuildを実行完了した後のapkファイル, aabファイルなどの各種成果物をダウンロードできるようにには以下の項目を追加します

- uses: actions/upload-artifact@master
  with:
    name: outputs
    path: app/build/outputs/

これにより以下のように成果物をダウンロードすることができます。

release-build-artifact.png

apkファイルの成果物は outputs/apk/release/app-release.apk, aabファイルの成果物は outputs/bundle/release/app-release.aab にあるます。

まとめ

以上が Github Actions でAndroidのネイティブアプリを自動的にBuildするための方法を解説して紹介しました。
いち早くプロジェクトに導入したい場合は以下の内容をそれぞれ参照(コピー)して導入してください

今後の展望

  • Google Play Storeにリリースする方法について
  • Android NDK Buildを行う方法について
  • Android のテストを実行する方法について

を追加したいと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Github Actionsにて自動的にビルドする環境作成(Android編)

概要

Github ActionsでのCI/CDの検証を行いました。
その中で他の開発プロジェクトにも定常的に適用できるようなテンプレートを作成しました。
作成したテンプレートのプロジェクトは以下になります。
github-actions-examples

今回このような環境の構築にあたっての備忘録としてここに記述しておきます。
また上記のプロジェクトは他の様々な環境において試したものであり、今回はGithub Actionsにおける Androidアプリ での自動ビルドの手法についてを中心に紹介します。

Webサイトでの自動デプロイおよびGithubActionsでの基本的な設定についてなどはこちらの記事を参照してください。
Github Actionsにて自動的にデプロイする環境作成(Webサイト編)

この他に iOSUnity での自動ビルドの環境構築については現在検証しています。こちらも手法が確立でき次第、紹介したいと思います。

やりたいこと

  • Androidアプリを開発し、GithubにpushしたらGithub Actions にてビルドが行われること
  • Release用の証明鍵をGithub Actions上にて管理し、その署名鍵を用いてビルドが行われること → Release Build
  • ビルドが完了したら apkファイルaabファイル をダウンロードできること → 端末の中に直接インストールする場合は apkファイル Google Play Storeに配信する場合は aabファイル を使用するといい
  • Google Play Storeにリリースするための鍵を使ってビルドが行われること ← 後日更新

Build

結論

以下の内容をそれぞれ参照してください

各種解説

JDKのセットアップ

AndroidアプリのビルドはJava製のアプリケーションとしてビルドします。今回はビルドするために JDK を使用してビルドを行います(Kotlinで開発していても同じです)
Github Actionsでは action/setup-java を使用することで JDK のsetupができます。また、今回はJava version 1.8 でビルドするので使用するバージョンを指定します。ymlファイルには以下のように記述します。

jobs:
  build:
    steps:
      ...
      - name: setup JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8

Android SDKのセットアップ

JDKのセットアップができたら次は Android SDK をダウンロードしてセットアップします。
Android SDK は一般的にはAndroid Studioにてダウンロードしますが、今回はCLIで実行すため、Android Studioを使用しない方法でダウンロードします。
Android Studio 内の Command line tools only の項目に Android SDK が入っている zipファイル をダウンロードします。この zipファイル には Android SDK Toolsのバージョンによって変わります。ダウンロードして使用したいバージョンを指定したURLを記載します。以下の処理がzip ファイルをダウンロードして解凍している処理になります。

wget --quiet --output-document=android-sdk.zip https://dl.google.com/android/repository/sdk-tools-linux-${{ matrix.sdk-tools }}.zip
unzip -d android-sdk-linux android-sdk.zip

matrix.sdk-tools には上記の Android SDK のバージョンの値を指定します。今回の例では 4333796 を使用します。

Android SDK のダウンロード、および解凍が完了したら、 build-tools platform-tools などを使用するための設定や環境変数であるPATHを通します。

echo y | android-sdk-linux/tools/bin/sdkmanager "platforms;android-${{ matrix.compile-sdk }}" >/dev/null
echo y | android-sdk-linux/tools/bin/sdkmanager "platform-tools" >/dev/null
echo y | android-sdk-linux/tools/bin/sdkmanager "build-tools;${{ matrix.build-tools }}" >/dev/null
export ANDROID_HOME=$PWD/android-sdk-linux
export PATH=$PATH:$PWD/android-sdk-linux/platform-tools/

次に Android SDK を使用するためにlincenseを承諾します。

set +o pipefail
yes | android-sdk-linux/tools/bin/sdkmanager --licenses
set -o pipefail

これで Android SDK の設定が完了してAndroidアプリをビルドすることができるようになります。

gradleのセットアップ

AndroidでアプリをビルドするにはGradleを用います。Gradleの設定は gradlew を実行することで自動的にセットアップしてくれます。(各種Gradleコマンドもgradlew を使用して実行されます)、gradlew ファイルを実行できるように権限を更新します。

chmod +x ./gradlew

(おまけ) Warning解消

上記までにビルドを行う設定なのですが、このままビルドを行うと Warning が出てしまうので Warning がでないようにするために以下のファイルを作成します。

sudo touch /root/.android/repositories.cfg

Debug Build

Androidアプリをビルドする環境が整ったら、まずは Debug Build を行います。
Debug Buildは以下のコマンドを実行することでビルドすることができます。

./gradlew assembleDebug

Androidアプリをビルドするためには署名が必要なのですが、署名鍵を特に指定しないDebug Buildでは Android SDK がインストールされた時点で ~/.android/debug.keystore に生成されている debug用keystore を使用してビルドが行われます。

【参考】
debug用keystoreについて調べてみた

Release Build

Debug Buildの場合はAndroidのdebug用keystore を用いてビルドが行われましたが、Google Play StoreなどにビルドしたAndroidアプリを配布する場合、デフォルトの署名鍵でビルドされたアプリでは配布することができません。
配布するためには署名鍵を自分で作成し、作成した署名鍵を用いてビルドすることでStoreに配布するアプリをビルドすることができます(ここではこのようなビルドをRelease Buildと呼びます)
以降では Github ActionsRelease Buildを行う方法を紹介します。
また、鍵の作成についてはこちら などを参考に作成してください。

ビルドに使用する鍵を参照できるようにする

作成した署名鍵を指定してビルドをするためには署名鍵ファイルをapp/buld.gradle にて指定することでビルドする場合に適用されます。

この時、storeFile storePassword keyAlias keyPassword の情報が必要になりますので、app/buld.gradle にこれらの情報を指定します。
しかし、これらの情報は秘匿して管理したい環境変数であるので、Androidにて環境変数を記述する local.properties に以上の情報を記述し、その内容をapp/build.gradle 内にて読み込むことでビルドを行うときに参照するようにします。(local.properties はデフォルトで.gitignore に記載されています)

app/buld.gradle への記述は以下のようになります。

build.gradle
Properties properties = new Properties()
def localPropertiesFile = project.rootProject.file('local.properties');
if(!localPropertiesFile.exists()){
    // localPropertiesFileがなければ作成します
    localPropertiesFile.createNewFile();
}
properties.load(localPropertiesFile.newDataInputStream())

上記の例では ビルド時に local.properties がなければ、新しく作成し、あれば既存のファイルを読み込むことで設定に適用します。(このようにしないと local.properties がない場合(Debug Buildを行う場合などにおいて)、ビルドエラーになってしまう)

読み込んだ、local.properties の値をビルドをRelease Build の際に適用するには以下のように記述します。

build.gradle
android {
    ...
    signingConfigs {
        release {
            // 指定したfileがある場合のみ記述
            if(!properties.getProperty("RELEASE_STORE_FILE", "").empty){
                storeFile file(properties.getProperty("RELEASE_STORE_FILE", ""))
            }
            storePassword properties.getProperty("RELEASE_STORE_PASSWORD", "")
            keyAlias properties.getProperty("RELEASE_KEY_ALIAS", "")
            keyPassword properties.getProperty("RELEASE_KEY_PASSWORD", "")
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

このとき local.properties には以下のような環境変数を設定します。

local.properties
RELEASE_STORE_FILE=署名鍵ファイルのファイルパス(絶対パス)文字列
RELEASE_STORE_PASSWORD=ストアパスワード文字列
RELEASE_KEY_ALIAS=キーエイリアス文字列
RELEASE_KEY_PASSWORD=キーパスワード文字列

※ 上記の設定を適用した場合、ローカルで Release Build を行う場合は local.properties に以上の内容を記述し、署名鍵ファイルの情報を記述してください。

鍵の管理

本来なら署名鍵ファイルはバイナリファイルなのでどこかに保存して取得するかプロジェクトの中に埋め込むかする必要があります。
しかし、それだと署名鍵ファイルが多くの開発者に知られてしまうという問題点があります。

そこで今回、署名鍵の管理をGithub Secretsに保存し、秘密の環境変数として適用します

署名鍵のファイルサイズは軽微なものであるので、base64 でバイナリファイルを文字列化します。
この文字列を Github Secrets に保存し、Github Actions を実行した時にバイナリファイルに戻して保存することで秘匿されたまま鍵の管理が可能となります。まず署名鍵ファイルをbase64で文字列に出力します。

base64 Androidのビルド署名鍵.keystore

このコマンドを実行して出力された文字列を、Github Secrets に登録します。

Github Actions 内ではここで設定した Github Secrets の情報が適用されるので、以下のようにbase64 -d >でバイナリファイルに書き出します。

echo ${ANDROID_REALSE_BASE64_KEY} | base64 -d > ./release-application-key

※ ここでは ANDROID_REALSE_BASE64_KEY にバイナリファイルを base64 にて文字列にした物を Github Secrets に設定しています。
release-application-key が一時的に保存する署名鍵のファイル名となります。

local.properties に上記の各種Release Buildを行うために必要な情報を記述する

Github Actions を行う場合、Release Buildを行うために必要な情報を local.properties に以下の情報を記述します。

local.properties
RELEASE_STORE_FILE=署名鍵ファイルのファイルパス(絶対パス)文字列
RELEASE_STORE_PASSWORD=ストアパスワード文字列
RELEASE_KEY_ALIAS=キーエイリアス文字列
RELEASE_KEY_PASSWORD=キーパスワード文字列

これらの情報は全てGithub Secretsに設定し、設定した内容を以下のように local.properties に追記していくようにします。

echo ${ANDROID_REALSE_BASE64_KEY} | base64 -d > ./release-application-key
echo "RELEASE_STORE_FILE=`pwd`/release-application-key" >> ./local.properties
echo "RELEASE_STORE_PASSWORD=${ANDROID_REALSE_KEY_PASSWORD}" >> ./local.properties
echo "RELEASE_KEY_ALIAS=key0" >> ./local.properties
echo "RELEASE_KEY_PASSWORD=${ANDROID_REALSE_KEY_PASSWORD}" >> ./local.properties

これにより Github Actions にて実行される際に local.properties に値が適用された状態でビルドが行われます。

GradleでRelease Buildを行う

以下のコマンドを実行することで apkファイル を出力するRelease Buildを行います

./gradlew assembleRelease

続けて、以下のコマンドを実行することで aabファイル を出力するRelease Buildを行います

./gradlew bundleRelease

ビルドした成果物をダウンロードできるようにする

Debug Build, Release Build共にビルドを実行完了した後のapkファイル, aabファイルなどの各種成果物をダウンロードできるようにには以下の項目を追加します

- uses: actions/upload-artifact@master
  with:
    name: outputs
    path: app/build/outputs/

これにより以下のように成果物をダウンロードすることができます。

release-build-artifact.png

apkファイルの成果物は outputs/apk/release/app-release.apk, aabファイルの成果物は outputs/bundle/release/app-release.aab にあるます。

まとめ

以上が Github Actions でAndroidのネイティブアプリを自動的にビルドするための方法を解説して紹介しました。
いち早くプロジェクトに導入したい場合は以下の内容をそれぞれ参照(コピー)して導入してください

今後の展望

  • Google Play Storeにリリースする方法について
  • Android NDK Buildを行う方法について
  • Android のテストを実行する方法について

を追加したいと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

最小 PWA を探ってみた

はじめに

PWA について、Android 版 Chrome が「インストールしますか?」と尋ねてくる最小の内容って何なのか、試してみました。
(オフライン動作は目指していません。)

結論

項目 内容
icon 1つでOK
Service Worker fetch イベントのリスナーのみでOK
fetch リスナー 空でOK

サンプル

manifest.json
{
  "name": "minimum",
  "display": "standalone",
  "start_url": "https://foo.bar/index.html",
  "icons": [
    {
      "type": "image/png",
      "src": "assets/images/icon-512.png",
      "sizes": "512x512"
    }
  ]
}

manifest.json の項目は Chrome のバージョンによって増減があるかと思います。上記は 81.0.4044.117 で確認しました。
アイコンは大は小を兼ねる発想で 512x512 にしておきました。

index.html
<html>
  <head>
    <title>minimum</title>
    <link rel='manifest' href='manifest.json' />
    <link rel='icon'     href='assets/images/icon-512.png' />
  </head>
  <body>
    <center>
      <img src='assets/images/icon-512.png' />
    </center>

    <script>
      if ( 'serviceWorker' in navigator ) {
        navigator.serviceWorker.register('service-worker.js')
          .then(function() {
            console.log('ServiceWorker was registered.');
          });
      }
    </script>
  </body>
</html>

favicon は必須じゃないですし body も真っ白でもいいと思いますが、せっかくモノがあるので書いておきました。
逆に register()catch() 書いたほうがいいですね。

service-worker.js
self.addEventListener('fetch', function(event) {});

install イベントは予めキャッシュにファイルを入れておく機会として利用できますが、利用しなくても別に問題ないです。
activate イベントは古い世代のキャッシュを削除する機会として利用できますが、利用しなくても別に問題ないです。

いずれも fetch が正しく機能するために必要なら利用すればいい、という感じでしょうか。

おわりに

行儀が良いとは言えないですが、「ホームにアイコン設置」が目的ならば、最小の内容でも十分かと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む