Fennec/NativeUI: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 78: Line 78:
* Setting the FilterQueryProvider automatically processes the SQL in a background thread (see http://developer.android.com/reference/android/widget/CursorAdapter.html#runQueryOnBackgroundThread%28java.lang.CharSequence%29). I verified this by adding a Thread.sleep() call in the filter - the UI remains responsive.
* Setting the FilterQueryProvider automatically processes the SQL in a background thread (see http://developer.android.com/reference/android/widget/CursorAdapter.html#runQueryOnBackgroundThread%28java.lang.CharSequence%29). I verified this by adding a Thread.sleep() call in the filter - the UI remains responsive.
* Better to use styles in layout. This helps in reusability. (sriram)
* Better to use styles in layout. This helps in reusability. (sriram)
* GeckoApp activity uses a lot of static variables. This has issues while rotation (they tend to hold previous values). It's better to avoid static variables and use getter and setters. [see http://stackoverflow.com/questions/2475978/using-static-variables-in-android] (kats)
* <strike>GeckoApp activity uses a lot of static variables. This has issues while rotation (they tend to hold previous values). It's better to avoid static variables and use getter and setters. [see http://stackoverflow.com/questions/2475978/using-static-variables-in-android]</strike> (done as of 0c46f65505f0)
* Change directory structure under embedding/android to follow a more traditional Android app layout (src, res, gen, etc) for better integration with Eclipse.
* Change directory structure under embedding/android to follow a more traditional Android app layout (src, res, gen, etc) for better integration with Eclipse.
* Take into account best-practices and coding conventions from http://developer.android.com/guide/practices/design/performance.html since the whole point of this is to speed up the UI. In particular, the current code:
* Take into account best-practices and coding conventions from http://developer.android.com/guide/practices/design/performance.html since the whole point of this is to speed up the UI. In particular, the current code:

Revision as of 17:52, 17 October 2011

Features

  • Awesome Bar – Go to your favorite sites in just a couple of keystrokes with intelligent and personalized searching
  • Firefox Sync – Sync your Firefox tabs, history, bookmarks and passwords between your desktop and mobile device for a seamless browsing experience
  • Tabbed browsing – View open tabs as thumbnails to easily identify and select the Web page you’d like to go to next
  • Fast - Instantly startup (<300ms)
  • Small - Low memory usage (consistent with other browsers)
  • Energy - Doesn't eat your battery

Background

[1]

How To Build

The project repository is here: http://hg.mozilla.org/projects/birch

Follow the instructions from Mobile/Fennec/Android. Build as you normally would (make -f client.mk), just with a different mozconfig.

Here's an example mozconfig:

# Add the correct paths here:
ac_add_options --with-android-ndk="$HOME/android-ndk-r6"
ac_add_options --with-android-sdk="$HOME/android-sdk-linux_x86/platforms/android-13"
ac_add_options --with-android-version=5

# android options
ac_add_options --enable-application=mobile
ac_add_options --target=arm-linux-androideabi
ac_add_options --with-endian=little
ac_add_options --with-ccache
ac_add_options --enable-tests

mk_add_options MOZ_OBJDIR=./objdir-droid
mk_add_options MOZ_MAKE_FLAGS="-j9 -s"


hg clone http://hg.mozilla.org/projects/birch/ src
cd src
vi mozconfig-droid
...
export MOZCONFIG=~/src/mozconfig-droid
make -f client.mk

Architecture Overview

Get a bird's eye view of how the native UI version of Fennec is structured. There are also some examples of messaging between Java and XUL/JS.

Design

The UI design is under revision, to make it simpler and to make more use of standard Android controls (i.e. hardware/system menu button, back button) and to make sure that more touchevents can be passed directly to web content.

Works-in-progress:

Known Issue

Near Term

Mid Term

Longer term

  • addons (going to use jetpack - mossop)
  • login/password management
  • Download
  • find on page
  • selection
  • removing xul
  • profile migration
  • Touch events

Low priority bugs

  • OpenURI is not supposed to load the frame, only provide the frame:

http://hg.mozilla.org/projects/birch/file/2f3d39316c54/mobile/chrome/content/browser.js#l80

Other

  • 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. - mostly done in multiple changesets
  • 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? done - cd8813d5469d
  • We are not using favicons in awesomebar. Just missing? or intentional?
  • URL edit box is not of "URL" type. The keyboard should change to show URL keys. done - b4bbaa96238a
  • I like the JSON messaging from XUL to Java, but I think we need the reverse too. done - ca107c8ed542
  • Also, GeckoAppShell.handleGeckoMessage could use a good refactor. It's already 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.
  • investigate using system sqlite, system zlib
  • about:crashes sounds broken

QA