0

Can't capture network reconnect events

I am trying to handle network reconnection, but I seem to be having a problem with the relevant events (onNetworkRestored, onNetworkConnectionReconnect, onNetworkHideDialog) not firing. I've created event handlers for them with the following code in my init.js:

CODE
EventHandlers.onNetworkRestored.subscribeTo(KONtx.application, ['onNetworkRestored','onNetworkConnectionReconnect'], EventHandlers);
EventHandlers.onNetworkHideDialog.subscribeTo(KONtx.application, ['onNetworkHideDialog'], EventHandlers);


For testing, I have just added logging to the event handlers:

CODE
onNetworkRestored: function(event) {
log("NETWORK RESTORED");
}

onNetworkHideDialog: function(event) {
log("NETWORK HIDE DIALOG");
}


I then follow this process:

  • With TV/Simulator off, Disconnect network
  • Turn on TV/Simulator
  • Start widget sidebar - this shows "Connection Unavailable"
  • Close widget sidebar
  • Reconnect network
  • Start widget - Still get "Connection Unavailable"


At this point, I go check the logs, and I am unable to find my log output. Then I try this procedure (restarting the simulator):
  • Turn on TV/simulator
  • Start widget sidebar
  • Close widget sidebar
  • Disconnect network (leaving TV on)
  • Start widget sidebar - note "Connection Unavailable"
  • Close widget sidebar
  • Reconnect network
  • Start widget sidebar - widget loads as expected


In this case, when I check the logs, I DO find the log output.

Based on this, it seems to me that in the first instance, the events aren't firing. So how can I respond to the network reconnection?

by
11 Replies
  • Hi Tony,
    Welcome to the fun world of network disconnection. :)Also, your version of the framework may not have the onNetworkHideDialog event. Which environments are you testing on? Please provide OEM and versions of the framework, engine and container.
    0
  • QUOTE (Benjamin Toll @ Apr 6 2011, 11:23 AM) <{POST_SNAPBACK}>
    When you say disconnect/reconnect the network, do you mean the physical network (pulling the cable from the tv, for instance) or pulling the uplink cable? It's an important distinction, as some events only get fired depending on which point failed. See this post for an example.


    For the moment I'm working in the simulator in the Ubuntu test environment. I'm disconnecting the network by clicking on the network connection icon at the top of the screen & clicking "Disconnect". Reconnecting by the same method.

    QUOTE (Benjamin Toll @ Apr 6 2011, 11:23 AM) <{POST_SNAPBACK}>
    Also, your version of the framework may not have the onNetworkHideDialog event. Which environments are you testing on? Please provide OEM and versions of the framework, engine and container.


    Running Konfabulator on Ubuntu - based on what I would have downloaded to install the WDK 2 days ago :)What I'm trying to figure out is how to act on a network reconnection under those circumstances (scenario 1). I see that you recommend onNetworkHideDialog - but even that doesn't seem to be firing under scenario 1. Since I don't have those events to work from, I'm hoping there is another way to handle the network reconnection.
    0
  • Are you making any ajax requests when the app first loads, such as in the onApplicationStartup event? When is the first time that the widget makes a request? Which view? And is it called when the view is first loaded or is it based upon some user interaction?
    0
  • QUOTE (Benjamin Toll @ Apr 7 2011, 06:45 PM) <{POST_SNAPBACK}>
    Are you making any ajax requests when the app first loads, such as in the onApplicationStartup event? When is the first time that the widget makes a request? Which view? And is it called when the view is first loaded or is it based upon some user interaction?


    Yes, there is a request made when it loads. It's called with onApplicationStartup, no user interaction involved. It loads to the snippet view.

    So we're on the same page:

    If I start the simulator with the network disconnected, that request fails and I get an indicator on the snippet. Then I follow the steps in scenario 2 and get the stated results.

    If I start the simulator with the network CONNECTED, I get the snippet data. I then disconnect, and follow the steps in scenario 2, and get exactly the same results.

    I've been going over the event sequence through both scenarios - I will post that shortly.
    0
  • QUOTE (Tony Garcia @ Apr 8 2011, 08:37 AM) <{POST_SNAPBACK}>
    Hmm, as I look at it again, I wonder if that last bit is relevant.

    Back to those events, going with scenario 2 (the one that works), when I activate the snippet & open the sidebar AFTER reconnecting, I get the following events (I'm only tracking ones that seem relevant - not ALL events):

    • onActivateSnippet
    • onUnselectView (on snippet)
    • onShowView (on sidebar)
    • onSelectView (sidebar)
    • onNetworkDown
    • onNetworkRequestFailed (looks like this is being called when executing setNetworkRequestFailed(false))
    • onNetworkRestored
    • onNetworkHideDialog
    • onDialogCanceled (appears to be Network Disconnected dialog)
    • onHideView (snippet)


    with scenario 1 (the one that doesn't work), when I activate the snippet after reconnecting, I get these:

    • onActivateSnippet
    • onUnselectView (snippet)
    • onShowView (sidebar)
    • onSelectView(sidebar)
    • onNetworkDown


    I never get the last four
    • onNetworkRequestFailed (looks like this is being called when executing setNetworkRequestFailed(false))
    • onNetworkRestored
    • onNetworkHideDialog
    • onDialogCanceled (appears to be Network Disconnected dialog)
    • onHideView (snippet)


    Do I have to force onNetworkRequestFailed by calling setNetworkRequestFailed? And is that what triggers onNetworkHideDialog?

    I'm asking that because I DO get those events if I add a setNetworkRequestFailed(false) into onActivateSnippet

    Well, actually, your scenarios make sense. Here's what happens in the first scenario:

    • You open the main sidebar view from the snippet
    • The framework recognizes that the network is disconnected and throws the dialog
    • You have to return to dock, and the widget closes
    • At some point the ajax request that you initiated fails, but that dialog is never raised b/c dialogs cannot be shown while a snippet view is selected (see an example log below)
    • NOTE that even though the dialog isn't shown that calling KONtx.application.setNetworkRequestFailed(true) when the ajax request fails tells the framework that your request had failed and that it won't be cleared until a call to KONtx.application.setNetworkRequestFailed(false) is issued (this is VERY important and could get your widget into an unusable state, which is what is happening here)
    • Your onNetworkRestored and onNetworkHideDialog events are never fired b/c the aforementioned dialog was never shown


    QUOTE
    refusing to show a dialog when we are in snippet mode


    For the second scenario, it sounds as if you had added another request in the main sidebar view that succeeds when the network is restored. This would call KONtx.application.setNetworkRequestFailed(false) as I illustrated before, and then your events would get fired. This will also prevent you from getting into the unusable state I mentioned before.

    So, to sum up, if I have a request in onApplicationStartup but then I don't have another one in my main sidebar view, the widget can get into an usable state if the network is down because the dialog is never cleared. Issuing another request when the main sidebar view loads would then clear that dialog and fire your events when the network is back up.

    Also, it is sufficient to only listen to one event or the other, though I would recommend listening for onNetworkHideDialog (for frameworks 1.3.27 and newer) as it gives you more flexibility. Here is the source for the application class.
    0
  • Ok, digging through the logs and trying a few things, I found something else:

    First, I am able to get rid of the dialog if I recheck network status in onActivateSnippet, and use KONtx.application.setNetworkRequestFailed(false); - this seems to cause onNetworkHideDialog to fire, and I don't get the Network Disconnected dialog after activating the snippet the second time under scenario 2. BUT, I also end up with a blank page on the sidebar.

    Looking in the logs: In Scenario 1 I have the following when I activate the snippet:
    CODE
    WM 00:00:19:983: [T:3041] ******** UI.populate(): starts.  filenames = ["sb_win.xml"]
    WM 00:00:19:983: [T:3041] ******** UI.loadXMLs(): Loading XML: 960x540/sb_win.xml
    WM 00:00:20:112: [T:3041] ******** UI.populate(): ends


    This does NOT appear when I activate the snippet after connecting the second time in scenario 2.

    It appears that the data for the sidebar view gets loaded when the snippet LOADS (onApplicationStartup), so even though I can dismiss the dialog, I never actually get the menu data and I get that blank page. I've duplicated the code that gets the data from EventHandlers.onApplicationStartup to EventHandlers.onNetworkHideDialog, but it doesn't appear to get called...
    0
  • Hmm, as I look at it again, I wonder if that last bit is relevant.

    Back to those events, going with scenario 2 (the one that works), when I activate the snippet & open the sidebar AFTER reconnecting, I get the following events (I'm only tracking ones that seem relevant - not ALL events):

    • onActivateSnippet
    • onUnselectView (on snippet)
    • onShowView (on sidebar)
    • onSelectView (sidebar)
    • onNetworkDown
    • onNetworkRequestFailed (looks like this is being called when executing setNetworkRequestFailed(false))
    • onNetworkRestored
    • onNetworkHideDialog
    • onDialogCanceled (appears to be Network Disconnected dialog)
    • onHideView (snippet)


    with scenario 1 (the one that doesn't work), when I activate the snippet after reconnecting, I get these:

    • onActivateSnippet
    • onUnselectView (snippet)
    • onShowView (sidebar)
    • onSelectView(sidebar)
    • onNetworkDown


    I never get the last four
    • onNetworkRequestFailed (looks like this is being called when executing setNetworkRequestFailed(false))
    • onNetworkRestored
    • onNetworkHideDialog
    • onDialogCanceled (appears to be Network Disconnected dialog)
    • onHideView (snippet)


    Do I have to force onNetworkRequestFailed by calling setNetworkRequestFailed? And is that what triggers onNetworkHideDialog?

    I'm asking that because I DO get those events if I add a setNetworkRequestFailed(false) into onActivateSnippet
    0
  • QUOTE (Tony Garcia @ Apr 8 2011, 08:37 AM) <{POST_SNAPBACK}>
    Do I have to force onNetworkRequestFailed by calling setNetworkRequestFailed? And is that what triggers onNetworkHideDialog?

    I'm asking that because I DO get those events if I add a setNetworkRequestFailed(false) into onActivateSnippet

    Yes, it can trigger onNetworkHideDialog if a previous request had failed, though I highly recommend not doing it this way as it easily may not be representative of its true state. After all, if the network is down, it's down. You shouldn't force it into a state that it's not.

    It's best to fetch data in each view that needs it, or at least in the main sidebar view. I developed a widget that maintains its own cache and will get data from it if it determines that it's not stale. So, I make a request from each view, and I don't have to worry about network resources as the majority of the time it's retrieving the data it needs to paint the view from its cache.
    0
  • Ok, after putting all of this together I finally have an answer. Part of the problem was that there was a separate, unrelated issue that was happening as part of the same event sequence.

    In the end, it seems that the answer is to add a handler for onActivateSnippet, and to run the data fetch there. This attempts the call and allows the sidebar to respond to the current state of the network rather than whatever was last set. By doing this, if the network is up, the network disconnected dialog never appears, and thus never needs to be dealt with. (I'd say this seems pretty close to what you were trying to point out)

    What was throwing me was that the function handling the data fetch wasn't putting that data into the menu, so it APPEARED (to me, at least) that the network request was still failing when it actually wasn't. Once I determined that the data was, indeed, getting back to me, I was able to look in the right place to deal with that problem.

    Thanks for the help!
    0
  • QUOTE (Tony Garcia @ Apr 12 2011, 06:20 AM) <{POST_SNAPBACK}>
    In the end, it seems that the answer is to add a handler for onActivateSnippet, and to run the data fetch there. This attempts the call and allows the sidebar to respond to the current state of the network rather than whatever was last set. By doing this, if the network is up, the network disconnected dialog never appears, and thus never needs to be dealt with. (I'd say this seems pretty close to what you were trying to point out)

    Without seeing your code I can't be completely sure, but yes, it sounds as if this is one way of accomplishing the same thing as what I was describing.
    0
  • i dont fix my problem in ukash and i ll try to find the other forms but dont find
    0

Recent Posts

in General - Yahoo! TV Widgets