app.navigate() to remote view - no header/footer

[Fredrik]

Hi again,

I've run into a somewhat strange issue here, which may or may not be by design once again. And since I only have the minified javascript for now, I can't quite figure out why it does what it does. 

For reasons relating to phonegap, cordova and some nasty bugs in android 4.0*, I've had to rewrite a lot of code from being nice and proper ( a-tags with href attributes linking to remote views with querystrings ) into storing the querystring variables into localStorage and relying on app.navigate to said remote views.

(* There's an unfortunate bug in the Chromium browser which leads to nice 'file not founds' if accessing files with querystrings when deployed through phone-gap, or through file:/// - URL  )

My problem, however: 
If I use a normal A tag with href="remote.html" - it inherits or picks up/duplicates header/footer if the data-id matches, which it does.
If I use app.navigate('remote.html') - it doesn't.  (Neither if I use document.location = 'remote.html')

In what way does a normal a tag linkage differ from app.navigate? Is there a way to (preferably from one centralized place) enforce/check/reinforce the header/footer?

All my views, regardless of whether they are remote or local share this:
(div data-role="layout" data-id="mobile-view")
Header/footer exists only in index.html. Remote views are simply other instances of a div data-role="layout" data-id="mobile-view".

Manually reloading in browser on such a loaded remote view does redraw the header/footer, worth noting.

Is the easiest way to refrain from using app.navigate?
Are there any implications to using document.location = 'index.html#remote.html' instead? That seems to be the easiest workaround at least.

[Petyo]

Hello Fredrick,

This is not a known issue. The mobile application attaches event handlers for the links, and calls app.navigate from there, so in theory there should not be any difference. A thing which comes to mind is that maybe something goes wrong with the browser history and the way the mobile app handles it - but still the layout should be there. 

One thing which I notice (but it is probably due to typing in the forum) is that the views should look like that: 

div data-role="view" data-layout="mobile-view"

While the layout (in fact, a single one, as you have checked) should look like the snippet you have provided:

div data-role="layout" data-id="mobile-vew"

Did you try providing the layout id as a configuration option in the mobile application initialization? I doubt that it will help, though. 

Another question which may help - does the bug occur only on android? Does it happen in desktop chrome/safari? 

Ultimately, what would help is for you to send us a sample project which demonstrates the behavior described (you can use a support ticket if the project is contains some private information). We will do our best to help.  

Kind regards,
Petyo
the Telerik team

[Fredrik]

Thanks for a quick reply.

Uunfortunately - I feel like a slightly silly cow.
The application works exactly as expected, it was more of an error in logic from my part. I'll illustrate the problem with some code, and leave it up to future viewers of the thread to determine my silliness here. After a restful night, I was able to see the error of my ways immediately.

<a data-role="button" data-icon="action"

                    data-item-id="#:No#"

                    data-item-name="#:Name#"

                    data-click="js_navigate">

</a>

and the corresponding javascript:

function js_navigate(e){

        var item = e.button;

        var cat_no = e.button.data("itemId");

        var cat_name =e.button.data("itemName");

        save_QS('category.html', 'category_no='+cat_no+'&cat_name=' + cat_name)

     

        var app = new kendo.mobile.Application();

        app.navigate( 'category.html' );

    }

var app = new kendo.mobile.Application() should of course be var app = window.kendoMobileApplication in this instance...

So, the code did what it should. The newly created Application without params of course has no layout attached to it... ;) 
Replacing it with the proper variation makes it work as intended, so. My bad. :-)