Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
briar
briar
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 675
    • Issues 675
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 11
    • Merge Requests 11
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • briar
  • briarbriar
  • Issues
  • #753

Closed
Open
Opened Nov 11, 2016 by akwizgran@akwizgranOwner
  • Report abuse
  • New issue
Report abuse New issue

Listener interfaces have mixed responsibilities

The UI makes heavy use of listener interfaces that inherit from either DestroyableContext or BaseFragmentListener. These are used for various purposes:

  • Callbacks from a controller to the UI (e.g. TransportStateListener#stateUpdate())
  • Injecting dependencies into fragments (BaseFragmentListener#getActivityComponent())
  • Manipulating other parts of the UI (e.g. CreateGroupListener#showSoftKeyboard())
  • Running tasks (DestroyableContext#runOnUiThreadUnlessDestroyed(), BaseFragmentListener#runOnDbThread() (deprecated))

These different purposes would ideally be separated into different interfaces. Maybe it would clarify things if communication from controllers back to the UI used the "listener" name and communication between fragments and their activities used some other name.

Listeners are usually provided by casting an Activity or Context (passed to ActivityLifecycleController#onActivityCreate() or Fragment#onAttach()) to an arbitrary listener interface. This is a bit of a hack - it would be nice if we could provide listeners in a type-safe way, for example by injection.

Related to #752 (closed).

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: briar/briar#753