We've run into an issue while developing our application that appears to be a serious design flaw in the way Kendo Mobile handles parameterized remote views.
Our app will be relatively large; large enough that putting all the HTML in a single file and using local views for everything is not an option. So we are using remote views, but all remote views are still going to be static HTML files living inside the app (we are using PhoneGap), and we plan to pass parameters to the remote views through the query string. Unfortunately we've run into problems with this. Let me try to explain the issue:
When calling a local view and passing parameters, the first time it is called the view is initialized, then the "show" event is called, passing the parameters. Subsequent calls to the local view will skip the initialization, and only the "show" event is called with the new parameters.
When calling a remote view with parameters, the first time it is called the view is loaded and initialized, then the "show" event is called, passing the parameters. Subsequent calls to the remote view with the same parameters then skip initialization, and the "show" event is called passing the parameters. However, if you pass different parameters, the view is loaded and initialized again, creating a copy of the original remote view, then the "show" even is called on this new instance of the remote view. Calling it again with different parameters will create yet another copy of the view, and so on until you have potentially many, many copies of the same remote view.
This behavior is very inconsistent, and causes a host of issues, including:
- Multiple copies of the same view unnecessarily consume additional resources
- Scripts included in the remote view are loaded multiple times, causing hard to debug issues
- Elements with IDs get duplicated, creating issues when trying to target elements inside a view
- The same remote view is initialized multiple times, reducing performance
- It's inconsistent with the way local views work, causing confusion for the developer
The main problem is that there is no way to call an existing instance of a remote view with different parameters. As far as I can tell, with the current design it is impossible.
According to the answer in this thread, this behavior is by design: http://www.kendoui.com/forums/mobile/general-discussions/remote-views-querystrings-odd-behaviour.aspx. It was also suggested that a possible solution is to remove the remote view from the DOM on hide. This causes its own set of issues, and is only a work-around for a design limitation in Kendo Mobile.
Now I realize that in some cases it may be desirable to have a remote view be loaded as a separate instance based on the parameters, but that would be the special case in my opinion, and it would be more common to want the remote views to work in a way consistent with local views.
I hope I have described the issue clearly enough. Here are some possible solutions that I can think of:
- Make an option on the Application object that lets developers choose how they want parameterized remote views to function
- Allow passing parameters to remote views through the URL fragment (after the '#' character). These parameters would be ignored when determining if a remote view is already loaded or not, but would be passed to the 'show' event
- Allow passing parameters to views through some other means. For instance, the navigate() function could take an additional parameter that is passed to the show event (this could also be useful because it would allow us to pass JS objects to other views)
For now in our project, I have been forced to implement a work-around that overrides the showView and _createRemoteVew functions to use the urlPath variable instead of the full url when reading and writing to the data-url attribute of the view element. This simple change brings the behavior of parameterized remote views in line with local views, allowing us to continue development of our application.
Please consider changing the behavior of Kendo UI Mobile for future releases, or at least giving us viable options, so I don't have to resort to nasty hacks and workarounds.