In Adobe AIR for Desktop, this Timer pattern won't work with the example timerInterval because the resize events fire between 100ms and 150ms. The timerInterval has to be larger than the largest typical resize event interval to reliably detect the end of the resize process.
Here is trace output while the user resizes the stage:
[trace] 15:02:27:128 onResize() - nativeWindows.width: 911
[trace] 15:02:27:239 onResize() - nativeWindows.width: 884
[trace] 15:02:27:358 onResize() - nativeWindows.width: 866
[trace] 15:02:27:475 onResize() - nativeWindows.width: 844
[trace] 15:02:27:593 onResize() - nativeWindows.width: 820
[trace] 15:02:27:677 onResize() - nativeWindows.width: 805
[trace] 15:02:27:762 onResize() - nativeWindows.width: 799
[trace] 15:02:27:842 onResize() - nativeWindows.width: 788
[trace] 15:02:27:935 onResize() - nativeWindows.width: 778
...
However, the trace output process process itself may pollute the measurement a little.
I suppose the RESIZE event intervals could vary between Flash Player and the AIR runtime, so just be sure you test before you choose a resizeInterval. I settled on 250ms in our AIR desktop app and it works pretty well.
But we wouldn't have to do this at all if AIR would just fire a MOUSE_UP event when the user releases the mouse after dragging the window. One could then add an event listener for MOUSE_UP in the first RESIZE event, and wait for the user to release the mouse capture, but the Adobe AIR runtime does not fire a stage MOUSE_UP event after a user resizes the window. I expect the same behavior in Flash Player.
Thanks, Package for your answer. It does work. I just wish there was a better way.