Based on the great article Chris has posted, I've been playing a little with
the idea about how 'navigation' could fit within the new architecture model
(based on 'threads.js') we are working on for Contacts App.
As we know, there is no clear guidelines regarding how panels should move in
our OS (check how 'Settings' panel is shown in every app in Gaia), so this lack
of specification sometimes has been creating some discrepancies between apps.
This is an issue when thinking about the 'Transition API' proposal in our apps,
because every panel must declare (using <meta> tags) "how" it should be
navigated (both ways). If this panel is reused (or if the UX changes and we
want a different transition), we would need to modify the HTML and the new set
of styles within every view in order to achieve this.
So taking into account all these issues, I've created a library (just a
prototype) in order to expose an API where a 'Content Wrapper' will manage all
transitions between 2 <iframes> in a declarative way, and adding more value
(for example letting us to render something in a panel before the navigation
happens). This is based on 'Threads.js', so all communication is between the
<iframe> and 'navigation.js' worker, which will be in charge of notifying all
events.
API exposed through 'Threads.js' would be something like:
var navigation = threads.client('navigation-service');
navigation.method(
'goto',
origin, // URL or #id
{
destination: destination, // URL or #id
effect: 'fade', // You can specify the transition (left, right, fade...);
params: {...} // All params you want to apss to 'destination'
}
);
As you have noticed, we can pass params to the 'destination' before the
navigation happens, which is great to preload data to show (imagine moving from
the list of contacts to a specific contact, we would have 'Contacts detail'
rendering content before moving from one to the other).
On 'destination' we will receive these params just listening to an event:
navigation.on('beforenavigating', function(params) {
// Do whatever you need
});
When 'origin' is ready, it will notify the service, so the navigation is done
using:
navigation.method('navigationready');
Once the navigation between <iframes> is done, we will notify panels involved
with a 'navigationend' event, so declaring a listener we could do any task we
want.
navigation.on('navigationend', function(params) {
// Do whatever you need
});
This is the ‘minimum’ set of events and methods that I’ve identified for having
a basic navigation model, but it would be great if you can add your ideas and
suggestions about the features that you expected from a library like this.
You can find the example working in [1] (actually it uses threads.js for
retrieving contacts as a ’service', which is really cool!). Feedback and
comments are really welcome!
[1] https://github.com/borjasalguero/contacts_prototype
De: Samuel Foster <[email protected]<mailto:[email protected]>>
Fecha: martes, 28 de abril de 2015, 20:21
Para: Christopher Lord <[email protected]<mailto:[email protected]>>
CC: Ting-Yu Chou <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Asunto: Re: RFC: Navigation transitions
It would be good to know how this plays with the visibility api? When does the
outgoing document become "hidden" - at the end of the animation? And likewise
for the incoming document. If visibility state is being used for say stopping
some media being played, it makes sense to flip the state before animating away
from a page. For the incoming page, I guess the same is true - for the purposes
of the visibility api, the document is only "visible" once the animation ends?
/Sam
On Thu, Apr 23, 2015 at 3:39 AM, Christopher Lord
<[email protected]<mailto:[email protected]>> wrote:
Seems it has, sorry about that - here's a new one:
http://chrislord.net/?p=273&preview=1&_ppp=d17048fbc3
I plan on publishing this (on my blog) today. The proposal and shim source is
also visible permanently in git: https://gitlab.com/Cwiiis/gaia-navigator
This electronic message contains information from Telefonica UK or Telefonica
Europe which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are not the
intended recipient be aware that any disclosure, copying distribution or use of
the contents of this information is prohibited. If you have received this
electronic message in error, please notify us by telephone or email.
Switchboard: +44 (0)113 272 2000 Email: [email protected] Telefonica UK Limited
260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales:
1743099. VAT number: GB 778 6037 85 Telefonica Europe plc 260 Bath Road,
Slough, Berkshire SL1 4DX Registered in England and Wales: 05310128. VAT
number: GB 778 6037 85 Telefonica Digital Limited 260 Bath Road, Slough,
Berkshire SL1 4DX Registered in England and Wales: 7884976. VAT number: GB 778
6037 85
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
