[SonamGyato]

Wayne,

Like to re-visit the BACK operation from an external site back to the app.

With version 1.5 – on BACK, i get a call to
– documentReadyHandler()
– postPageTransition on the last mobi page.

The problem with above – is that my app doesn’t know it’s a BACK operation
and initializes all the local state variables.

By the time postPageTransition is called – all the state vars are gone.

Any particular reason documentReadyHandler() is called.

If necessary can an arg be passed whether it’s a true startup or a BACK re-init.

Thanks.

p.s. Actually there’s still a problem.

I build the page (i.e. dynamic lists etc) in the prePageTransition event.
This event is NOT called during the BACK operation.

So that’s also causing problems.

Maybe the prePageTransition can be called with the currentPageId param set to “#BACK” or
something.

[SonamGyato]

After further investigation, it looks like when BACK is pressed –

the app javascript instance is fully re-initialized before call
to documentReadyHandler() – so the state variables stored
in javscript vars are gone anyway.

Would this be possible.

Do not call postPageTransition() on the last mobi page.

I cannot see the current mechanism useful to any app that
displays dynamic content.

[SonamGyato]

I put some more thought into this feature.

My app calls multiple mobi pages (i.e. nested)

A >> B >> C

and both B and C have BACK buttons – that mobi handles these
internally. That is – it doesn’t do a full reset – documentReadyHandler()
is not called and all state variables are preserved.

Now when I call an external site from C.

The BACK button event is handled differently.

From what i can tell, documentReadyHandler() is called – everything
is initialized – and the mobi tool calls postPageTransition on C.

So I have just C in my nav history stack.

Now when the user does a BACK from C – it’s not going to go to B right?

This is a problem for any app out there that’s nested more than 1 screen
deep.

—

Bottom line Wayne, this whole process needs to be practical for a live
real-world app.

Here’s my proposal.

on a BACK from an external site.

1. call documentReadyHandler().

2. call prePageTranstion
with currentPageId to a flag (e.g. “#BACK”)
and targetPageId the last mobi page (C in the above example).

This method returns a flag right?
Allow the user to short-circuit the flow by returning false.

3. If prePageTransition returns true – then call postPageTransition.

—

The above allows
– compatibility with static content pages.
– compatibility with dynamic content pages (allows them to build the
page in the prePageTransition call.
– short-circuit the whole flow in certain app cases.

A bonus would be if documentReadyHandler could be called with a flag
whether it’s a true app init or a BACK init. If the latter – the app could
restore some state variables that was saved before navigating to the
external site.

Just my 2p’s worth from studying your tool and my app.

[support-michael]

Thanks for this feedback. Discussing with the dev team now as there is an increasing amount of complexity in the state and event models across platforms. My understanding is that the center of the problem is that there is no universal BACK-navigation caching model for browsers. The Test Center emulator is similar to Chrome and does not implement a back-nav cache. My understanding is that mobile safari and safari work differently when run side-by-side and across versions. Can we guarantee a consistent back-nav state model and callback sequence remains to be seen. I’ll update you as soon as I know more. The fun part (not) is we are expanding beyond iOS and there are more variables to contend with.

[SonamGyato]

I understand it’s not easy – especially for cross-platform.

But if you read my last post carefully – you’ll note that if it’s
not cached by the browser – the mobi solution of initializing
the app and then force navigating to the last page – will not
work.

because users will not be able to navigate to the previous
page – because it’s no longer in the history.

i also understand you’re looking for a solution…

but in the meantime – can i do something in phoneui.js – that’ll
stop after documentReadyHandler() – i.e. not try to transition
to the last mobi page.

this is a temp solution that would work well for me.

[support-michael]

@everest

>but in the meantime – can i do something in phoneui.js – that’ll stop after documentReadyHandler() – i.e. not try to transition to the last mobi page.

The app is your code. You are free to make any changes necessary for your app to function as needed.

[SonamGyato]

I looked at the phoneui.js file and wasn’t able to stop the call to postPageTransition().

Couldn’t find the relevent code.

The framework does the transition automatically – in phoneui or from somewhere else.

i can’t stop it in postPageTransition().

Any help here?

[SonamGyato]

I made some changes in phoenui.js so that only the documentReadyHandler()
is called – not the postPageTransition.

It works most of the time – but once in a while the app seems to lose it’s state.

Any help here would be appreciated.

I can email you the phoneui.js that i edited.

[Author]

Posts