userManager.currentUser was called too often. I was not able to prove that a bug is related to it but i think it may fix some hidden bugs.
CurrentUserProviderImpl is now used throughout the code to access the current user.
userManager.currentUser is only used from CurrentUserProviderImpl whenever the _currentUser was null (should only happen on app startup)
To avoid multiple initialization of CurrentUserProviderImpl it was changed to be a @Singleton
The handling should soon be replaced with coroutine flows. However for the v21.0.0 release it's still done with RxJava to avoid bugs.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
NPE without this fix:
Exception java.lang.RuntimeException:
at android.app.ActivityThread.performResumeActivity (ActivityThread.java:4975)
at android.app.ActivityThread.handleResumeActivity (ActivityThread.java:5008)
at android.app.servertransaction.ResumeActivityItem.execute (ResumeActivityItem.java:54)
at android.app.servertransaction.ActivityTransactionItem.execute (ActivityTransactionItem.java:45)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:176)
at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:97)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2386)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loopOnce (Looper.java:210)
at android.os.Looper.loop (Looper.java:299)
at android.app.ActivityThread.main (ActivityThread.java:8252)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:559)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:954)
Caused by java.lang.NullPointerException:
at com.nextcloud.talk.conversationlist.ConversationsListActivity.onResume (ConversationsListActivity.kt:287)
at android.app.Instrumentation.callActivityOnResume (Instrumentation.java:1565)
at android.app.Activity.performResume (Activity.java:8668)
at android.app.ActivityThread.performResumeActivity (ActivityThread.java:4965)
The root cause may be that the CapabilitiesWorker is not finished so the serverVersion was not added to the user.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
To support federated rooms, capabilities have to be checked from the room which now also has capabilities.
If room is not federated, capabilities fromuser are still checked.
This is why CapabilitiesUtil had to be refactored to accept SpreedCapabilities which can come from room or user.
Other than that, many other changes were made as a result of this change.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
- Fix injection in GetFirebasePushTokenWorker.
injection was not setup correctly in GetFirebasePushTokenWorker so the appPreferences were null. This resulted in the invinite loading screen during account setup if somehow onNewToken did not set the token.
- avoid to register push on every load of ConversationList.
- call GetFirebasePushTokenWorker instead of PushRegistrationWorker to make sure the firebase token is set(if onNewToken somehow fails to set it). Other than that, only call PushRegistrationWorker directly in NCFirebaseMessagingService as there the token is set.
- add logging
- trigger GetFirebasePushTokenWorker daily with periodical worker (instead monthly), and combine this with PushRegistrationWorker as this is defined inside GetFirebasePushTokenWorker
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
- replace remaining controllers with activities
- remove conductor lib
- modify some code related to account management and conductor
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
