This diff makes succesive calls to CommSecureStore.getInstance().initialize(...) idempotent. We need it since MainApplication and CommNotificationsHAndler may initialize CommSecureStore independently of each other.
Details
Details
Temporarily place logging into initialize() method. Check that logs appear only once between succesive foregrounding/backgrounding of the app. Also make sure that logs do not appear after the app is backgrounded and notification is received (CommNotificationsNahdler gets called).
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
If CommSecureStore has to be threadsafe, I wonder if we should add a comment somewhere so people understand that if they're modifying it
| native/android/app/src/main/java/app/comm/android/fbjni/CommSecureStore.java | ||
|---|---|---|
| 8 ↗ | (On Diff #13438) | Can we put the newline back between import and the class declaration? |
Comment Actions
Use double-check idiom to correctly privide idempotent initialization of CommSecureStore
Comment Actions
This is great, but can be improved by using a Supplier - we will create a new instance of SecureStoreModule only when it's needed
| native/android/app/src/main/java/app/comm/android/fbjni/CommSecureStore.java | ||
|---|---|---|
| 22–30 | ||
Comment Actions
Use supplier pattern for CommSecureStore initialization. Use context for SecureStoreModule instantiation in CommCoreJSIModule