One view with different behaviours

pa3's Avatar


05 Dec, 2012 08:35 AM

Hy, guys!

In my app I have scenario in which I want to use one view which should trigger different framework events, according to the context in which it have been shown. More precisely, I have CallsignChoiceScreen with the the single text input field, some description and "Next" button. This screen could be shown to the user in couple of places (normal registration sequence, during first login via Facebook and in "change your callsign" scenario for already registered users).

I really don't want to place some switch-logic inside of the view, and keep it as simple as possible (i.e. it should only fires CallsignEneteredEvent with text field content as a payload).

So, I see following possibilities:

  • Create three different mediators: OrdinaryRegistartionCallsignMediator, FacebookRegistrationCallsignMediator and ChangeCallsignMediator. And some model or command, lets say PrepareCallsignScreenCommand will create and register appropriate mediator for CallsignChoiceScreen. Every mediator will fire it's own events. For each of that three events it will be three commands each doing it's own stuff.
  • Create only one mediator CallsignChoiceMediator. PrepareCallsginScreenCommand will populate it with the instance of event which CallsignChoiceMediator should fire in response to CallsignEneteredEvent.
  • One mediator populated with value from enumeration CallsignChoiceScenario (e.g. FACEBOOK, ORDINARY, CHANGE). When view dispatches CallsignEneteredEvent, mediator will dispatch ApplyNewCallsignEvent with value from text field and CallsignChoiceScenario value it was populated with. After that, command ApplyNewCallsignCommand will choose what to do with the passed callsign according to the passed CallsignChoiceScenario value.
  • One mediator for all the scenarios without any parametrization. Neither CallsignChoiceScreen nor CallsignChoiceMediator knows anything about current callsign choice scenario. It just redispatch CallsignEneteredEvent forward, and ApplyNewCallsignCommand will ask some cleaver model which knows what the current context is (e.g. NavigationModel) what to do with the passed callsign.

Right now the way with CallsignChoiceScenario enumeration looks most appealing for me. But still, I am not 100% sure which one to choose.

Any thoughts? How do you guys usually deal with such type of issues?

  1. pa3 closed this discussion on 05 Dec, 2012 08:35 AM.

  2. pa3 re-opened this discussion on 05 Dec, 2012 08:35 AM

  3. 1 Posted by pa3 on 05 Dec, 2012 08:36 AM

    pa3's Avatar

    Oups, closed it by mistake.

  4. Support Staff 2 Posted by Ondina D.F. on 05 Dec, 2012 09:11 AM

    Ondina D.F.'s Avatar

    Hi pa3

    I’d choose the version with the “clever” Model, last one in your list :) This way the Mediator and its View are portable and the logic inside your Mediator is kept to a minimum.


  5. 3 Posted by pa3 on 05 Dec, 2012 01:06 PM

    pa3's Avatar

    Hey, Ondina!

    After thinking about your issue for a while, I decided that the way with clever Model makes more sense than what I wanted to do (enumeration stuff). So I think I'll drive that way.

    It's amazing how fast one could get feedback on this site. Thanks for support and for great framework! =)

  6. pa3 closed this discussion on 05 Dec, 2012 01:06 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac