Canmove, confirm, emeritus
2,798
edits
Changes
Created page with "It's always nice to have a bird's eye view of how something is working to help make it easier to understand. With that in mind here is quick summary of the current Java Fennec sy..."
It's always nice to have a bird's eye view of how something is working to help make it easier to understand. With that in mind here is quick summary of the current Java Fennec system. Please correct and add details where needed:
==Overview==
* Application UI is comprised mainly of Android Java and layout XML files found in embedding/android
** GeckoApp.java and gecko_app.xml comprise the main UI.
** AwesomeBar.java and awesomebar_search.xml are the main UI for the awesomebar screen. aweseombar_row.xml is the layout for a row in the list.
** SQLite is currently used to store the history. DatabaseHelper.java seems to be used to make the DB.
* XUL/JS and still used primarily as a communication shim from the Gecko platform to the Java UI.
** browser.js and browser.xul create a single <browser> "UI" for only displaying the web contents.
** Some helpers in browser.js are used to communicate network activity and mouse gestures to Java. More helpers will be needed for adding support for different Gecko features. Easily poached from the current code.
** A JSON based message system is used to 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.
** I don't see much of a formal communication system from Java to XUL. For example, I see the Java UI forcing a full load of a previous URL on refresh and back (using GeckoAppShell.sendEventToGecko) instead of sending a message to XUL and telling the <browser> to simply reload or go back.
==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.
==Overview==
* Application UI is comprised mainly of Android Java and layout XML files found in embedding/android
** GeckoApp.java and gecko_app.xml comprise the main UI.
** AwesomeBar.java and awesomebar_search.xml are the main UI for the awesomebar screen. aweseombar_row.xml is the layout for a row in the list.
** SQLite is currently used to store the history. DatabaseHelper.java seems to be used to make the DB.
* XUL/JS and still used primarily as a communication shim from the Gecko platform to the Java UI.
** browser.js and browser.xul create a single <browser> "UI" for only displaying the web contents.
** Some helpers in browser.js are used to communicate network activity and mouse gestures to Java. More helpers will be needed for adding support for different Gecko features. Easily poached from the current code.
** A JSON based message system is used to 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.
** I don't see much of a formal communication system from Java to XUL. For example, I see the Java UI forcing a full load of a previous URL on refresh and back (using GeckoAppShell.sendEventToGecko) instead of sending a message to XUL and telling the <browser> to simply reload or go back.
==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.
