Was this a UX call? It seems strange to me that we reset the picker after the timer is cancelled. iOS keeps the picker state; it seems like the common case the user would want to keep the state too. 

> On Feb 3, 2014, at 2:02 PM, jugglinmike <notifications@github.com> wrote:
> 
> In apps/clock/js/timer_panel.js:
> 
> > @@ -149,7 +149,12 @@ Timer.Panel.prototype.dialog = function(opts = { isVisible: true }) {
> >    }
> >    View.instance(this.nodes.dialog).visible = opts.isVisible;
> >  
> > -  setTimeout(this.picker.reset.bind(this.picker), 0);
> > +  // Only reset the picker to 0:00 the first time it loads. This keeps
> > +  // the user's changes persisted between visibility changes.
> > +  if (!this._initializedPicker) {
> > +    setTimeout(this.picker.reset.bind(this.picker), 0);
> > +    this._initializedPicker = true;
> > +  }
> I don't think this will work because in addition to first load, we also need to reset the picker state when:
> 
> the timer is cancelled
> the timer expires
> I'm not sure we can do this entirely within Timer.Panel#dialog--we might need a reset method we can call from different locations in the code.
> 
> —
> Reply to this email directly or view it on GitHub.