This differential extends PlatformSpecificTools.java with method to retrieve notifications olm account path. This functionality requires main application context to be accessible in PlatformSpecificTools. Usually we would pass it in constructor or as method argument, but this
class is designed to be static method only class callable from C++. Therefore we need a "static" way of accessing main application context here. This approach is described here: https://stackoverflow.com/questions/2002288/static-way-to-get-context-in-android. Further diffs will extend
C++ header to include this method.
Details
Details
Call this method from CommNotificationsHandler on each message and log path to the console.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- marcin/eng-2901
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
Looks good to me, but I'd like to give some more context ;) on this.
Exposing app context as a static variable is a common technique. It would be considered an anti-pattern if there was an easy way to do it by passing it through function arguments. In this case, it will be called from JNI, where doing so would be extremely cumbersome, although possible (but requiring much more code). This is why I'm accepting.
Some related threads about this:
- https://stackoverflow.com/questions/2002288/static-way-to-get-context-in-android
- https://stackoverflow.com/questions/2785670/best-way-to-get-an-application-context-into-a-static-method-in-android
- https://riptutorial.com/android/example/11576/activity-context-in-static-classes
- https://bladecoder.medium.com/of-course-on-android-you-must-never-keep-a-static-reference-to-any-context-except-for-the-21553638b58
A counter-argument article describing why this is an anti-pattern:
Generally, doing this is safe unless we're calling it before the main app has been initialized / after it is destroyed - so in practice: always.
| native/android/app/src/main/java/app/comm/android/MainApplication.java | ||
|---|---|---|
| 83–86 | This comment about TurboModules is unrelated to this line ;) | |