Posts

アプリで保存したデータが再インストールで復活する事や、 WebViewで実装した画面のローカルストレージ保存したデータ等が復活する事が気になっていたの調べた. 特にWebViewでログイン画面実装して、アカウント情報などをWebViewキャッシュ保存とかしてると、 再インストールとかしたのに復活するので、開発時などは無効設定が好ましい. 単純にAndroidのバックアップ機能が有効になっていた. AndroidManifest.xml android:allowBackup: バックアップ自体を実施するかどうか <application android:allowBackup="false" ... /> android:fullBackupContent: バックアップする内容を指定 android:fullBackupContent <application android:allowBackup="true" android:fullBackupContent="@xml/backup_rules" ... /> @xml/backup_rules <?xml version="1.0" encoding="utf-8"?> <full-backup-content> <include domain="sharedpref" path="."/> <exclude domain="sharedpref" path="device.xml"/> </full-backup-content> ユーザデータの自動バックアップ設定 Android 6.0（API レベル 23）以上をターゲットとするアプリで、自動的に自動バックアップが有効 アプリデータはGoogleDriveにバックアップされる Android9以降のデバイスでは、デバイスのPIN、パスワード、パターンを使用し、エンドツーエンドで暗号化 アプリ1つあたり25Mb,最新データのみ保存 バックアップデータに関しては追加料金なし Refs 自動バックアップでユーザーデータをバックアップする | Android デベロッパー | Android Developers

環境設定ファイル(env.propertiese)に定義したをビルドタイプで設定値を読み分ける関数を定義して、 それぞれの環境ビルド時に buildConfigField で定義 という感じ def envPropertiesFile = rootProject.file("env.properties"); def envProperties = new Properties() envProperties.load(new FileInputStream(envPropertiesFile)) ext.buildConfigFieldFromEnvProp = { env -> def keys = ["apiPrefix", "cognitoPoolId", "cognitoClientId", "cognitoClientSecret", "cognitoRegion"] for (key in keys) { defaultConfig.buildConfigField("String", key, "\"${envProperties["$env.$key"]}\"") } } buildTypes { debug { debuggable true applicationIdSuffix = '.debug' versionNameSuffix = '-debug' buildConfigFieldFromEnvProp("dev") } release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' signingConfig signingConfigs.release buildConfigFieldFromEnvProp("prd") } } dev.apiPrefix=https://xxxx dev.cognitoPoolId=xxx dev.cognitoClientId=xxx dev.cognitoClientSecret=xxx dev.cognitoRegion=xxx

Android で 位置情報取得を定期実行する方法をしらべたので、メモっておく Foreground 実装 フォアグラウンドサービスの最低限の実装について【Kotlin, Android Studio, バックグラウンドでのアプリ実行】 - アンラッキーシステムズのやり方、方法論。 Foreground Serviceの基本 - Qiita AndroidアプリでForeground Serviceを使って、画面スリープ状態でも位置情報を定期取得する | DevelopersIO Android Service の使い方 趣味のプログラム: Android Foreground Serviceのメモ フォアグラウンド サービスの起動に関する制限 | Android 12 | Android Developers Android - Foreground Service実行 長期間Serviceを起動したい時 | 技術情報 | アプリ関連ニュース | ギガスジャパン Auto-Start Foreground Service in Android | by CodingwithSaud | The Startup | Medium Androidアプリでバックグラウンド状態で位置情報が取得できるのか調査した - 酢ろぐ！ バックグラウンドで位置情報アクセスするアプリには特別な審査が必要 審査に必要なものは、Google公式のバックグラウンド位置情報にアクセスするアプリの審査を円滑に進めるためのヒントにも書かれている通り以下のものを準備する必要がある。 機密情報に関わる申請 を行う ・デモ動画が必要 アプリ内での位置情報使用の開示を行う (位置情報許諾ダイアログ) プライバシーポリシー にバックグラウンドで位置情報を取得する件について書く...

ホワイトスペースの削除の意味 次の例のようにテンプレート内で「{{」の代わりに「{{-」と指定することで、テンプレートのレンダリング時にその「{{-」の前にあるホワイトスペース（スペース、タブ、改行）を削除するよう指定できる。同様に「}}」の代わりに「-}}」を指定することで、「-}}」の後ろにあるホワイトスペースを削除できる。 静的サイトジェネレータ「Hugo」と技術文書公開向けテーマ「Docsy」でOSSサイトを作る | さくらのナレッジ

Spring で MyBatis(MySQL) つかって ネストした トランザクション制御しようとして以下エラーに遭遇した Caused by: org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only トランザクションの伝播については、PROPAGATION_REQUIRED の理解が必要 とのことで調べた 要は、明示的に Transaction を貼りたい場合にどういった振る舞いをすべきかを指定する必要があり、 選択肢は以下の2つある PROPAGATION_REQUIRED 存在しない場合は新たに作成、存在する場合は参加 内部スコープがロールバック専用マーカーを設定した場合、外部トランザクションはこれを予期していないため、 予期しないロールバックが発生するとUnexpectedRollbackExceptionがスローされる PROPAGATION_REQUIRES_NEW 常に独立したトランザクションを開始 独立してコミットまたはロールバック可能 以下詳細 PROPAGATION_REQUIREDの理解 tx prop required PROPAGATION_REQUIREDは物理的なトランザクションを強制します。既存のトランザクションがまだ存在しない場合は現在のスコープでローカルに、または大きなスコープで定義された既存の’外部’トランザクションに参加します。これは同一スレッド内の一般的なコールスタックの配置（例えば、すべての基礎となるリソースがサービスレベルのトランザクションに参加しなければならない、いくつかのリポジトリメソッドに委任するサービスファサードなど）では良いデフォルトです。 デフォルトでは、参加するトランザクションは外部スコープの特性に参加し、ローカルの分離レベル、タイムアウト値、または読み取り専用フラグ（あれば）を黙って無視します。異なる分離レベルで既存のトランザクションに参加する際に分離レベルの宣言を拒否する場合は、トランザクションマネージャーでvalidateExistingTransactionsフラグをtrueに切り替えることを検討してください。この非寛容モードは、読み取り専用の不一致（つまり、読み取り専用の外部スコープに参加しようとする内部の読み書き可能なトランザクション）も拒否します。 伝播設定がPROPAGATION_REQUIREDの場合、その設定が適用される各メソッドに対して論理的なトランザクションスコープが作成されます。各論理的なトランザクションスコープは、ロールバックのみのステータスを個々に決定でき、外部のトランザクションスコープは内部のトランザクションスコープから論理的に独立しています。標準的なPROPAGATION_REQUIREDの動作の場合、これらすべてのスコープは同一の物理的なトランザクションにマップされます。したがって、内部のトランザクションスコープで設定されたロールバックのみのマーカーは、外部のトランザクションが実際にコミットする可能性に影響を与えます。 しかし、内部のトランザクショクションスコープがロールバック専用マーカーを設定した場合、外部のトランザクションは自身でロールバックを決定していないため、内部のトランザクションスコープによって黙ってトリガーされるロールバックは予期しないものです。その時点で対応するUnexpectedRollbackExceptionがスローされます。これはトランザクションの呼び出し元がコミットが実行されたと誤って推測することがないようにするための期待される挙動です。したがって、内部のトランザクション（外部の呼び出し元が認識していない）が黙ってトランザクションをロールバック専用とマークすると、外部の呼び出し元はまだコミットを呼び出します。外部の呼び出し元は、ロールバックが実行されたことを明確に示すために、UnexpectedRollbackExceptionを受け取る必要があります。 PROPAGATION_REQUIRES_NEWの理解 tx prop requires new PROPAGATION_REQUIRES_NEWは、対象となるトランザクションスコープごとに常に独立した物理的なトランザクションを使用し、外部のスコープの既存のトランザクションには決して参加しない、という点でPROPAGATION_REQUIREDとは対照的です。このような配置では、基礎となるリソーストランザクションは異なり、したがって、独立してコミットまたはロールバックでき、外部のトランザクションは内部のトランザクションのロールバック状態に影響されず、内部のトランザクションのロックはその完了直後にすぐに解放されます。このような独立した内部トランザクションは、自身の分離レベル、タイムアウト、読み取り専用設定を宣言し、外部のトランザクションの特性を継承しないこともできます。 以下翻訳元 Understanding PROPAGATION_REQUIRED tx prop required PROPAGATION_REQUIRED enforces a physical transaction, either locally for the current scope if no transaction exists yet or participating in an existing ‘outer’ transaction defined for a larger scope....