The strategy that I use for server-side processes like urlConnection is to create an instance of urlConnection in the Session class, and create its Events as Methods in the Session class (using AddHandler).
However, I never allow urlConnection to touch the UI. Instead, for example, my handler method for contentReceived would write received data into a pre-defined text property of the Session class. (I do this because urlConnection is asynchronous, and we never know when the content will be received.
I then have a WebTimer object that is in the WebPage class, and I set that timer running in continuous mode (1s interval, perhaps) when urlConnection is first called. The timer’s Action event looks for the text property in Session, and when that property is no longer blank, the timer can be turned off and the text can be copied from Session to a label or textArea on the webpage.
Because the timer is within the webpage class, its webpage (and therefore its textArea) are always in scope whenever the page is on display. urlConnection can do its thing, and the timer can do its thing - the two never meet. Keeping the UI separate from background processes like urConnection always seems to work well.