The Message Lifecycle - nsf-open/nsf-ember-message-queue GitHub Wiki

The message-queue service works in "ticks", with one "tick" usually occurring at the end of any didTransition event of the application's router.

Any message provided to the message-queue service, whether it be via the queue or add method, results in the creation of a message object containing a number of attributes which dictate when it is shown, where it is shown, and for how long it is shown based on these "ticks":

Property Default Description
wait queue = 1, add = 0 The number of ticks that will occur before the message reaches its "active" state and is displayed.
lifespan queue = 1, add = 1 The number of ticks that will occur between the time that the message reaches its "active" state (being displayed), and when it is destroyed.

Examples

Default queue

When you queue a message with the default lifecycle values wait = 1, lifespan = 1 here is what happens:

  1. The message object is added to the queue.
  2. On the next didTransition, the queued message has its wait time decremented by 1.
  3. Since the message now has a wait = 0 it is given to its target message-container and is now "active".
  4. On the next didTransition, the "active" message has its lifespan decremented by 1.
  5. Since the message now has a lifespan = 0 it is removed from its target message-container.

This basic flow is something that you have probably come across before. An action is performed, followed by a transition to some other view. Once in the new view you want to display a notification about the status of the previous action. Continue moving through the application and the notification should be removed.

Custom queue

Changing the defaults allow for a lot of customization. If we set the lifecycle values of our message to wait = 2, lifespan = 2 then the following will happen (you should start seeing a pattern):

  1. The message object is added to the queue.
  2. On the next didTransition, the queued message has its wait time decremented by 1.
  3. Since the message now has a wait = 1 it is not removed from the queue.
  4. On the next didTransition, the queued message has its wait time decremented by 1.
  5. Since the message now has a wait = 0 it is given to its target message-container and is now "active".
  6. On the next didTransition, the "active" message has its lifespan decremented by 1.
  7. Since the message now has a lifespan = 1 it is not removed from its target message-container.
  8. On the next didTransition, the "active" message has its lifespan decremented by 1.
  9. Since the message now has a lifespan = 0 it is removed from its target message-container.