The first time I used Kendo UI Mobile was earlier this year. And
almost immediately, I noticed that all of the views I built were in
the same .html file. This made sense, given how the navigation between
the pages worked - you specify a #pageName
in a link, and the
framework intercepts this to load a div of that id. It works well,
and it allows for optimizations in performance, etc.
But a view views in to building an app, I wanted to have my views in separate files. At first I tried to do some complex things with build tools that would concatenate my files in a build step. This works, but it adds some additional process in development and testing that I didn't want at the time. Fortunately, there's a solution built in to Kendo UI Mobile now: remote views.
Remote views are easy to set up and use. Add a secondView.html
file (or whatever
file format your server will parse and render) to your project and
build the standard <div data-role="view">...</div>
setup for a
view in to this file. Now instead of specifying a #secondView
in a
link, you can specify /secondView.html
in your links. Kendo UI
mobile will recognize this as a "remote view" - a view that has to be
loaded from the server before it can be displayed.
Rather than just copy & paste code samples at this point, though, it is much more effective to see this in action. So I've put together a quick video demonstrating the remote views.
As you can see, it's easy to get an existing application to work with a remote view setup. You just put the view definition in a separate file, and then change the links to point to that files instead of a hash fragment.
If you'd like to learn more about remote views and Kendo UI Mobile, be sure to check out these resources:
And then head on over to the downloads so you can grab your copy of Kendo UI Mobile and give it whirl for yourself!
About the Author
Derick Bailey is a Developer Advocate for Kendo UI, a developer, speaker, trainer, screen-caster and much more. He's been slinging code since the late 80’s and doing it professionally since the mid 90's. These days, Derick spends his time primarily writing javascript with back-end languages of all types, including Ruby,