Fennec/NativeUI/Architecture Overview: Difference between revisions

Fennec/NativeUI/Architecture Overview (view source)

Revision as of 13:18, 14 October 2011

1,202 bytes removed , 14 October 2011

Moved to /Fennec/NativeUI

MarkFinkle

canmove, Confirmed users, Bureaucrats and Sysops emeriti

2,798

edits

@@ Line 12: / Line 12: @@
 ** A JSON based message system is used to [[Fennec/NativeUI/Messages|send messages]] from XUL to Java. nsIAndroidBridge is the XPCOM object that makes this happen, but the messages are just forwarded to GeckoAppShell and routed out to Java from there.
 ** An event based message system is used to [[Fennec/NativeUI/Messages|send messages]] from Java to XUL. From Java, you create a GeckoEvent with a subject and data strings. This is sent to XUL as an nsIObserver notification.
-==Things we could address==
-* The current helpers in browser.js are wrong or inadequate. This should be easy to fix. The code is also designed for a single <browser>. We need to add tab support (coming) and see that it works well in the XUL/Java setup.
-* We are not using any Gecko session history (back/forward). I think this is a mistake. We should be capturing as much session in Gecko as possible. Any reason not to?
-* We are not using favicons in awesomebar. Just missing? or intentional? Need some UX.
-* URL edit box is not of "URL" type. The keyboard should change to show URL keys.
-* I like the JSON messaging from XUL to Java, but I think we need the reverse too. Also, GeckoAppShell.handleGeckoMessage could use a good refactor. It's already getting too big.
-* Plans for splitting the work between non-visual Java components (like a History or Bookmark object), the visual Java UI (dialogs or buttons that use the non-visual components) and the XUL/JS helpers used to send/receive messages to Java. These seem to be the basic areas of coding. Planning how to attack any particular feature will help make sure we don't have coders stepping on each other and will make the work go faster IMO.
 ==Interaction with Other Teams==
 * Add-ons: The add-on system will be impacted by the native UI change. We need to put together some information about how it's impacted and what we might be able to do to add back some level of support.
 * L10N: Localization of the native UI can work very similar to how we localize Java UI parts now. Even that could be made easier though. The bigger issue is the affect of native UI on the dynamic way we can change localizations of the XUL UI without being locked or affected by the OS locale. I mean, Firefox Mobile (XUL) can be launched in a locale that isn't even shipped with the OS itself. This ability might be affected.