This diff uses MessageOperationsFunctionality and JNI files from previous diff to store notification in CommNotificationsHandler on Android.
Details
- Reviewers
tomek • karol - Commits
- rCOMM3937a61faf82: Use MessageOperationsUtilities on Android
Log message content in C++ when sending notification. Do this for every message type. Additionally temporarily modify send.js prepareAndroidNotification code to send notification as if codeVersion < 31 and check that messages are still parsed correctly.
Comment out set_encryption_key method in SQLiteQueryExecutor (to disable encryption) code build app on an emulator, launch it and immediately kill. Then send a message from another client. Open device file explorer in Android studio and download comm.sqlite database. Examine its content in some sqlite explorer (vscode has a preety good one) to ensure that messages are there even though app was not launched after sending message.
Diff Detail
- Repository
- rCOMM Comm
- Branch
- marcin/store-notifs-android
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
native/android/app/src/main/java/app/comm/android/CommNotificationsHandler.java | ||
---|---|---|
103–104 ↗ | (On Diff #12887) | We should inverse the order here. It's probably cheaper to first check if the notification has message infos than to access the file system. So check the file system only after we're sure we have something to save. |
123–124 ↗ | (On Diff #12887) | That's probably fine - it may happen |
native/android/app/src/main/java/app/comm/android/CommNotificationsHandler.java | ||
---|---|---|
105–112 ↗ | (On Diff #12938) | We don't need this code at all. codeVersion indicates the client version of code. If we have a client with code version < 31, and that client would like to have the code you implemented, an update should be made which will increase the code version. Older code versions should always be handled on server side and never on client side. |
native/android/app/src/main/java/app/comm/android/CommNotificationsHandler.java | ||
---|---|---|
103 ↗ | (On Diff #12982) | This name is misleading as it is a File and we name it path. Maybe just sqliteFile would be ok? |
106 ↗ | (On Diff #12982) | We still need to update the name, right? |
107 ↗ | (On Diff #12982) | In Java we should avoid using toString for any logic - it is ok for debugging purposes but nothing more. It looks like File has getPath method - should we use that? |