Confirmed users
971
edits
(Added note on SOA) |
|||
(7 intermediate revisions by 3 users not shown) | |||
Line 3: | Line 3: | ||
==== As a front-end developer, I need a way to tell the native app to open a new layer containing a specific layer state. ==== | ==== As a front-end developer, I need a way to tell the native app to open a new layer containing a specific layer state. ==== | ||
FrenchToast. | FrenchToast.openAppView(url) | ||
==== As a front-end developer, I need a way to tell the native app to open a URL in the viewer. ==== | ==== As a front-end developer, I need a way to tell the native app to open a URL in the viewer. ==== | ||
FrenchToast. | FrenchToast.openWebView(url) | ||
''I don't think we need the name parameter. I don't think we want layers to be able to talk directly to each other. Instead, I believe we can stick to a service-oriented architecture based on URLs.'' -[[Gbrander]] | ''I don't think we need the name parameter. I don't think we want layers to be able to talk directly to each other. Instead, I believe we can stick to a service-oriented architecture based on URLs.'' -[[Gbrander]] | ||
Line 16: | Line 16: | ||
window.addEventListener('layerFocus', fn) | window.addEventListener('layerFocus', fn) | ||
'' Focus isn't quite the same as active/visible. On the desktop, focus doesn't happen until an element in the window receives focus. I'm not sure how that plays out on touch devices. I think we want visibility'' | |||
''There is an actual API for this: [http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html PageVisibility] but we would have to investigate browser support. As I understand it, our "layers" are going to be window object in UiWebViews or their equivalent, so this seems like the right place to start. I would rather polyfill this though than invent our own.'' | |||
* http://davidwalsh.name/page-visibility | |||
* https://developer.mozilla.org/en-US/docs/DOM/Using_the_Page_Visibility_API | |||
* https://github.com/ai/visibility.js | |||
==== As a front-end developer, I need a way to securely ''verify that the user is authenticated'' so that I do not expose confidential information. ==== | ==== As a front-end developer, I need a way to securely ''verify that the user is authenticated'' so that I do not expose confidential information. ==== | ||
Line 29: | Line 37: | ||
''Can somebody who worked on the session stuff in the past verify that these could satisfy the user story?'' - [[Gbrander]] | ''Can somebody who worked on the session stuff in the past verify that these could satisfy the user story?'' - [[Gbrander]] | ||
''What about the way it works today are we wanting to fix? This functionality currently resides in the misnamed/misplaced [https://github.com/mozillapancake/pancake-ft-client/blob/app-skeleton/js/lib/signin.js lib/signin]. ISTM that the modules under service/* could be FrenchToast.*. Lets talk.'' - [[Sfoster]] | |||
==== As a front-end developer, I need access to a shared store that persists across sessions. All layers should have access to this store. ==== | ==== As a front-end developer, I need access to a shared store that persists across sessions. All layers should have access to this store. ==== | ||
Line 38: | Line 48: | ||
JSON.parse | JSON.parse | ||
''Can we confirm that the same localStorage is available between UIWebViews'' - [[Gbrander]] | ''Can we confirm that the same localStorage is available between UIWebViews'' - [[User:Gbrander | Gbrander]] | ||
''(From mailing list) I found this configuration option: webSettings.setSupportMultipleWindows(true); And now storage events are sent to the other web views that are open in the same app.'' - [[User:St3fan | St3fan]] | |||
=== Discussion === | === Discussion === | ||
''I don't think we need a general message mechanism to talk to the app. I also don't think we need to be able to send messages to specific layers from specific layers. In general, I would like to make the coupling between layers loose, and based on requesting URLs be opened. The layer itself can decide what to do with the URL.'' -[[Gbrander]] | ''I don't think we need a general message mechanism to talk to the app. I also don't think we need to be able to send messages to specific layers from specific layers. In general, I would like to make the coupling between layers loose, and based on requesting URLs be opened. The layer itself can decide what to do with the URL.'' -[[Gbrander]] | ||
''Agreed that urls should be the primary messaging mechanism. We also have storage events which (browser-support willing) should allow us to signal state changes like login/logout across windows/layers. I suspect there's still a need for the native/js messaging though. - [[Sfoster]] |