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).
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.
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.
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.
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.
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).
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.
