[Bug-11644] Gateway Receives Events For Missing Views

Missed one in the Coordinate Container, now down to:

INFO | jvm 1 | 2018/11/14 12:06:38 | I [p.ClientSession ] [19:06:38]: Socket connected to session. pageId=37fc0a87 session-project=Perspective_Scan
INFO | jvm 1 | 2018/11/14 12:06:38 | I [p.ClientSession ] [19:06:38]: Client re-synchronizing. protocol=re-sync-views, session-project=Perspective_Scan
INFO | jvm 1 | 2018/11/14 12:06:58 | W [p.ClientSession ] [19:06:58]: Received event for missing view “Navigation@C” project=Perspective_Scan, session-project=Perspective_Scan
INFO | jvm 1 | 2018/11/14 12:07:01 | W [p.ClientSession ] [19:07:01]: Received event for missing view “Navigation@C” project=Perspective_Scan, session-project=Perspective_Scan
INFO | jvm 1 | 2018/11/14 12:07:02 | I [P.InternalDatabase ] [19:07:02]: Creating auto-backup of internal database “config.idb”…
INFO | jvm 1 | 2018/11/14 12:07:02 | I [P.InternalDatabase ] [19:07:02]: Created auto-backup of internal database “config.idb” in 228 ms
INFO | jvm 1 | 2018/11/14 12:07:03 | W [p.ClientSession ] [19:07:03]: Received event for missing view “Navigation@C” project=Perspective_Scan, session-project=Perspective_Scan

I went ahead and opened a bug for this, as the behavior is unexpected.

Log_On.JSON (3.6 KB)
Navigate.JSON (5.9 KB)

Perhaps I didn’t follow the diagram on Perspective structure as closely as I thought?
https://docs.inductiveautomation.com/display/DOC80/Perspective

No, your structure has some unnecessary pieces*, but there’s no reason those Views should generate the warning that they are indeed generating.

*You’re passing a parameter as part of your navigation, but the View you’re navigating to doesn’t “take” parameters (your View correctly ignores them).

check… deleting unused parameters :smiley:

Do these first couple lines apply to the situation? I am attempting to run this on the perspective app on my iPhone 8 Plus using iOS version 12.1(16B92)

INFO | jvm 1 | 2018/11/14 15:31:35 | W [P.Session ] [22:31:35]: Attempted mobile device validation on non-mobile session. route-group=perspective, route-path=/hello/:project_version/:project_name/:tab_id/:device_response
INFO | jvm 1 | 2018/11/14 15:31:39 | I [P.Routes ] [22:31:39]: Encoded Message = AAAAEByXSiYP7RSyjewV0Qt0yw3tkVGC2IkIOQxy0r7SKOQb9Cr08iMe3saTLPUf7-h8C2KEfwtgtNhVIEB7CaBvHTg= route-group=perspective, route-path=/challenge
INFO | jvm 1 | 2018/11/14 15:31:41 | I [p.ClientSession ] [22:31:41]: Socket connected to session. pageId=37fc0a87 session-project=Perspective_Scan
INFO | jvm 1 | 2018/11/14 15:31:42 | I [p.ClientSession ] [22:31:42]: Client Starting. Project=‘Perspective_Scan’. protocol=client-start, session-project=Perspective_Scan
INFO | jvm 1 | 2018/11/14 15:31:59 | W [p.ClientSession ] [22:31:59]: Received event for missing view “Navigation@C” project=Perspective_Scan, session-project=Perspective_Scan
INFO | jvm 1 | 2018/11/14 15:32:07 | W [p.ClientSession ] [22:32:07]: Received event for missing view “Navigation@C” project=Perspective_Scan, session-project=Perspective_Scan
INFO | jvm 1 | 2018/11/14 15:32:13 | W [p.ClientSession ] [22:32:13]: Received event for missing view “Navigation@C” project=Perspective_Scan, session-project=Perspective_Scan

I was stepping through the process and watching the wrapper.log file this morning and I noticed something.
the “view missing” message does not hit the wrapper.log until I navigate away from my Main_Views/Navigation view to the Material_User/Log_On view.

The Log_On view Back Button does have an onClick event to take the users back to the Main_Views/Navigation view. This will also apply to other views to assist with the user navigation through the app…
.
Could I be getting this message because it is looking for a view to be present that has been sent to garbage collection (GC) or that is connected to a page that has been sent to GC?

Not likely - it would be a tremendous waste of computing resources to scan everything about a View and make sure it’s all going to work before we need to use it.

As there’s no adverse effects that seem to be stemming from this “missing view” I wouldn’t worry too much about it, but if you want to investigate further you could always provide some logging as a way to lock-down exactly what is happening and when.

While investigating this issue further, I’ve found that use of the system.perspective.navigate() method does not encounter the “missing view” issue.

I also encountered a different issue during the course of my investigation that is leading me to recommend that you switch to using the system.perspective.navigate() method, and that issue is that Script Actions don’t seem to be executing when paired with a Navigate Action.

So would this be a temporary case of “either/or” usage or should this be resolved later in a future build?

Removing the Navigate event also helped resolve my label text not changing due to not updating from the session.custom.key.value

In the “User Log On” Button:
Emp_Role = ‘Operator’
self.session.custom.Emp_Role = Emp_Role
system.perspective.navigate(view=‘Material_User/Log_On’)

And in the “Back Button”:
Emp_Role = ‘’
self.session.custom.Emp_Role = Emp_Role
system.perspective.navigate(view=‘Main_Views/Navigation’)

In the onStartup script for the Navigation View:
Emp_Role = ‘’
badge = ‘’
PW = ‘’
self.session.custom.Emp_Role = Emp_Role
self.session.custom.badge = badge
self.session.custom.PW = PW

Right, that’s because the Script Action was being ignored while using the Navigate Action. Moving to the Script Action with a navigation method will suffice as a workaround for now as the Script Action will now appropriately set the desired variables.

Side note:
If your Navigation View will always set the Session variables onStartup, you don’t need to set them before navigating to it, and you actually shouldn’t set them before navigating, as it will only make your personal debugging more difficult.

1 Like

Cody is doing a great job in helping identify and track these issues, so I don’t have anything to add there. Just wanted to say thanks for providing such helpful reports Brian. These really help us deliver a more polished product come final release.

2 Likes

This is something that we MUST fix; there should be no discernible difference in behavior regardless of which Action you choose to take.

So would there be a better method for making sure that the Emp_Role session variable is reset when users go back to the Navigation screen? I was assuming that if a standard user was done and a Quality Engineer needed to use the same device, I should reset that role variable to null and then allow the selection based on the log on. (BTW, that role is a database defined role with permissions, not an Ignition or gateway/project type role.)

Design in these situations is different for everyone, but if your desire is that whenever you visit this Navigation View those three variables are se to empty Strings, then your onStartup script is 100% correct.

I was only noting that the button which triggers navigation to your Navigation View is performing session.custom.Emp_Role = '', and then immediately when the new View comes into existence it performs the same action again.

If you ever modify the script for the button which does the navigation and say perform session.custom.Emp_Role = null, no null checks in scripts or bindings on the Navigation View will ever come back as True, because that null value has already been overridden with the empty String.

Ok, so that is a View onStartup event, not a Session onStartup event…

And then every time I navigate back to the Navigation view it will run the script as soon as it instantiates, correct?

Correct.

Perspective Views do not “exist” unless they are open (which is why you can’t bind against properties in other Views), so a Session onStartup Script will fire once - as soon as your Session starts.

View onStartup Scripts will fire every time the View “loads”, whether this is through Navigation Actions, the perspective.navigate() method in a Script Action, or using your browser’s back button (remember, “pages” are still Views).

Any kind of ETA on this yet?

If you’re inquiring about ticket 11644 - which is the open ticket about a difference in behavior between using the navigate method and the navigate action - there is no ETA.