talk-android icon indicating copy to clipboard operation
talk-android copied to clipboard

get rid of Conductor

Open mahibi opened this issue 4 years ago • 6 comments
trafficstars

  • [ ] blocked by https://github.com/nextcloud/talk-android/issues/1550

We want to switch to native Android solutions instead to use Conductor.

TODOS:

  • [ ] research how to avoid a big bang switch

mahibi avatar Aug 26 '21 13:08 mahibi

Moved to "To do" to perform the "Research how to avoid a big bang switch" Please let us know if it can be avoided somehow

nickvergessen avatar Jan 14 '22 09:01 nickvergessen

well the picture in picture feature actually made a start to replace a controller from conductor with a native activity. This was possible because there was a controller that was on the top of the stack, which could be replaced easily. However other controllers might be more difficult to replace because they are not always on top of the stack or there is more interaction with other controllers. So some research here still totally makes sense..

mahibi avatar Jan 14 '22 14:01 mahibi

Given @mahibi's remarks I think it is also totally fine if there is no way to easily migrate all conductors but if there is a way to split the work like with the PIP then this would be a valid and helpful approach, so there can be valid, creative approaches. The goal would simply be to find a way to not have to do big bang even when it is a exotic approach :)

AndyScherzinger avatar Jan 14 '22 16:01 AndyScherzinger

If you need any help, ping me :)

tobiasKaminsky avatar Jan 17 '22 11:01 tobiasKaminsky

The goal would simply be to find a way to not have to do big bang even when it is a exotic approach :)

an example for one "exotic" approach: In https://github.com/nextcloud/talk-android/pull/1285 i created a BottomSheetDialog that defined another conductor router: https://github.com/nextcloud/talk-android/blob/master/app/src/main/java/com/nextcloud/talk/ui/dialog/ConversationsListBottomDialog.kt#L274

This was necessary because the BottomSheetDialog just worked differently than the formerly used BottomSheetMenu ( https://github.com/Kennyc1012/BottomSheetMenu )

I introduced the additional router to reuse the existing Controllers for now. So i didn't actually replace Controllers yet, but the router stack was "cut" into pieces with that. Whenever some button in the Dialog should trigger an action in the app, i throw an event like here:

https://github.com/nextcloud/talk-android/blob/master/app/src/main/java/com/nextcloud/talk/controllers/bottomsheet/OperationsMenuController.java#L570

which is catched inside the ConversationsListController...

https://github.com/nextcloud/talk-android/blob/f4cb9578136367f8b85d99834cb3872508a75aa0/app/src/main/java/com/nextcloud/talk/controllers/ConversationsListController.java#L1072

... which then closes the Dialog. So i guess a next step could be to replace the controllers that are used for the Dialogs, as they are not on top of the main router of the app.

mahibi avatar Mar 02 '22 18:03 mahibi

Feels a bit strange that eventbus is needed. If you want, we can have a look together, once you want to use this approach as a blueprint for other migrations.

Same for other migration of entire controller. I had a quick look and I think it should be possible like this

  • move controller (e.g. settingsController) to activity
  • for existing router call use Android's regular intent mechanism

It would then be a migration step by step (controller by controller). If you want to tackle it, just call me.

tobiasKaminsky avatar Mar 07 '22 16:03 tobiasKaminsky