It all started at the Firefox Work Week in Toronto back in April. I managed to find some time during that rather busy week to build a rough prototype of Firefox Mobile’s Reader Mode. I’ve been able to focus on it in the last few weeks and it’s now in good enough shape for wider testing.

Reader Mode is about bringing a smooth and beautiful reading experience to Firefox Mobile. It removes all the clutter from web pages and shows you only what you want to read in a minimalist UI. Here are a few things I’d like to highlight about it.

Read now or later. If the current page is convertible to Reader Mode, you’ll see the reader icon in the browser toolbar (see image above). If you tap on it, the current page will be loaded in the Reader straight away. You can also add it to your Reading List to read it later using the corresponding app menu item.

AwesomeBar integration. Your Reading List items will show up in the AwesomeBar results—just like any bookmark or history item—making it super easy to find specific items. The Reading List items will have a little reader indicator (see image above). The Reading List shows up as a top-level folder in AwesomeBar’s Bookmarks tab, if you want to see the full list of items.

Read your way. The Reader UI is minimal but very configurable. You can set the color scheme (light, dark, and sepia), font size and margins the way you want through a simple set of controls (see image above). We might be adding more options like a toggle to show/hide images in the text.

Read any time. Once you add a page to your Reading List, it will be automatically made available offline so that you don’t need an internet connection to access your Reading List on the go.

Read anywhere. Your Reading List will be synced across all platforms where you use Firefox. This means you’ll be able to add a Reading List item in your Firefox on desktop and read it on the go from your phone using Firefox Mobile. This is not implemented yet as we need to have Reader Mode in desktop Firefox before we can enable Reading List syncing there. So, at least for the initial release, the Reader will only be available on mobile.

Firefox Mobile’s Reader Mode is similar to existing reader apps. But, as you can see, the real difference here is that it is deeply integrated in the browser, where you usually read stuff anyway. As far as I know, Firefox is the first mobile browser on Android to provide this feature.

Reader Mode is now enabled in the Nightly builds of Firefox for Android. It’s still a very early development version so expect bugs. Help with testing and feedback is very welcome. Download the Nightly and try it now!

One of the core goals of Pattrn is to allow users to discover new patterns at any time. As you know, Pattrn can automatically set your Android’s wallpaper every day with the patterns of your choice. This is a great way to give your Android a fresh new look and to discover new patterns—especially if you’re using random pattern wallpapers!

Pattrn shows you the colours used in each pattern inside the extended information pane that expands and collapses when you tap the screen. The latest release has a new fun way to discover new patterns: click on a specific colour and you’ll be able to search for other patterns using the same colour (see image above).

Also new in this update is the “View on Web” option which takes you straight to the respective pattern page at COLOURlovers.com. Enjoy!

Things are going pretty well for Pattrn. In just 22 days, it has got almost 600 downloads, got featured in two Android app designblogs, and got mostly 5-star ratings on Google Play. Not bad! Since its initial release, Pattrn got the ability to save patterns to your Android gallery, a few UI improvements, and some nice performance and stability fixes.

Based on your feedback, I have now pushed an update with a new little feature: automatic wallpaper updates. You can now tell Pattrn to automatically set your Android’s wallpaper every day or every week with your favourite or most popular patterns. Feeling adventurous? You can also set Pattrn to use a completely random pattern as your wallpaper.

Once you update Pattrn on your device and run it for the first time, you’ll be prompted to setup the automatic wallpaper updates. Don’t worry, you can change those options at any time in the Settings screen—accessible via the app menu.

At this point, you have probably heard the news. Yes, we’ve release the first public Beta of Firefox for Android with all the goodness that we’ve been working on in the last 7 months: the brand new native UI that is lighter, faster, and sleeker. Here are some big picture highlights about this Beta.

Design direction. The new native UI design is part of a wider effort in Mozilla to streamline the visual identity of Firefox across multiple platforms—desktop and mobile. Firefox should feel like one consistent product everywhere. Have a look at Madhava’s slide deck for more information on what the Firefox design team has been up to lately.

Keep in mind that this first native UI release is just the first of many iterations. For instance, there’s a lot of interesting changes coming up as part of our work on the native tablet UI that will eventually trickle down to the phone UI as well.

Panning and zooming. If you’re using the Beta already (or have been using the Nightly or Aurora builds) you’ll notice how smoother panning and zooming are. This is because the Beta features a major revamp on the graphics and rendering infrastructure using tiled rendering and an off-main-thread layer compositor. I recommend reading Benoit Girard‘s and Chris Lord‘s blog posts for further details. It’s worth mentioning that the Mobile Platform and Graphics teams did an amazing work to implement all this in a rather short period!

Places and Sync. The Places database has been re-implemented in Firefox for Android as a private Content Provider for two reasons. First of all, it gives instant access to history and bookmarks even before Gecko is up i.e. much faster startup experience. Secondly, it allows the new native Firefox Sync—which is now nicely integrated with the system’s sync UI—to access your browsing history and bookmarks even when Firefox is not running.

We’ve already started working on new features for the following releases including the native UI for Firefox on Android tablets and a reader mode. As you can see, the upcoming Firefox for Android is a whole new beast. We are working hard to make it the best mobile browser out there. You can help us now testing the Beta as part of our Mobile Test Drivers Program!

With the native UI, we’re creating a new baseline for innovation on Firefox Mobile. And it will only get better from now on. What are you waiting for? Download the Firefox for Android Beta now!

I’m a COLOURlovers fan. They provide a nice set of simple creative tools that empower a vibrant community to produce awesome design pieces such as patterns, palettes, shapes, colors, etc. It’s a simple yet powerful idea. Inspiring stuff.

I’ve been doing Android-based development for a few months now but I wanted to play a bit more with the platform to get a better grasp on the developer experience for building apps with it, from development to distribution. There’s no other way to do that than building an app. This is why I created Pattrn as a weekend project.

Pattrn gives you access to all the patterns created by the COLOURlovers community. You can browse through the latest and most popular patterns and search by keyword or color. You can also keep a list of your favorite patterns and use them as your Android wallpaper. Pattrn is meant to be simple, cute, and snappy.

I’ve just released Pattrn’s first public beta on Google Play. Install it and let me know what you think. I hope you enjoy it!

I went to Évora this week to give a talk about Mozilla and our mobile projects (Firefox Mobile, B2G, Open Web Apps, Identify, etc) at an event organized by the students’ union of the local university. Here’s my talk’s deck of slides (in Portuguese)—not very useful as it has very little content but it does contain a few useful links.

My main conclusion from this event is that we, Mozillians, should probably dedicate some more time spreading the word about our mission and projects to Uni students, especially in CS. There seems to be little awareness of why we’re different, why our mission matters, and what we’re working on right now.

From my experience, universities are usually a great source of potential long-term open source contributors. Getting students excited about our projects is likely to help us have a constant flow of new contributors in our community.

Big thanks to the event organizers for inviting me and for the hospitality! It was great to see Joaquim Rocha (Igalia) again and also meet interesting people like Thomas Perl (gPodder) and Steven Goldfarb (CERN). It was a quick yet pleasant visit to Portugal.

I’ve been messing around with Android-based code for a few months now while hacking on Native Firefox for Android. I noticed that the performance tips for ListViews are a bit scattered in different sources. This post is an attempt to summarize the ones I found most useful.

How it works.ListView is designed for scalability and performance. In practice, this essentially means:

It tries to do as few view inflations as possible.

It only paints and lays out children that are (or are about to become) visible on screencode.

The reason for 1 is simple: layout inflations are expensive operationscode. Although layout files are compiled into binary form for more efficient parsingcode, inflations still involve going through a tree of special XML blockscode and instantiating all respective views. ListView solves this problem by recyclingcode non-visible views—called “ScrapViews” in Android’s source code—as you pan around. This means that developers can simply update the contents of recycled viewscode instead of inflating the layout of every single row—more on that later.

In order to implement 2, ListView uses the view recycler to keep adding recycled views below or above the current viewport and moving active views to a recyclable pool as they move off-screencode while scrolling. This way ListView only needs to keep enough views in memory to fill its allocated space in the layout and some additional recyclable views—even when your adapter has hundreds of items. It will fill the space with rows in different ways—from top, from bottom, etc—depending on how the viewport changedcode. The image below visually summarizes what happens when you pan a ListView down.

With this framework in mind, let’s move on to the tips. As you’ve seen above, ListView dynamically inflates and recycles tons of views when scrolling so it’s key to make your adapter’s getView() as lightweight as possible. All tips resolve around making getView() faster in one way or another.

View recycling. Every time ListView needs to show a new row on screen, it will call the getView() method from its adapter. As you know, getView() takes three arguments arguments: the row position, a convertView, and the parent ViewGroup.

The convertView argument is essentially a “ScrapView” as described earlier. It will have a non-null value when ListView is asking you recycle the row layout. So, when convertView is not null, you should simply update its contents instead of inflating a new row layout. The getView() code in your adapter would look a bit like:

View Holder pattern. Finding an inner view inside an inflated layout is among the most common operations in Android. This is usually done through a View method called findViewById(). This method will recursively go through the view tree looking for a child with a given IDcode. Using findViewById() on static UI layouts is totally fine but, as you’ve seen, ListView calls the adapter’s getView() very frequently when scrolling. findViewById() might perceivably hit scrolling performance in ListViews—especially if your row layout is non-trivial.

The View Holder pattern is about reducing the number of findViewById() calls in the adapter’s getView(). In practice, the View Holder is a lightweight inner class that holds direct references to all inner views from a row. You store it as a tag in the row’s view after inflating it. This way you’ll only have to use findViewById() when you first create the layout. Here’s the previous code sample with View Holder pattern applied:

Async loading. Very often Android apps show richer content in each ListView row such as images. Using drawable resources in your adapter’s getView() is usually fine as Android caches those internallycode. But you might want to show more dynamic content—coming from local disk or internet—such as thumbnails, profile pictures, etc. In that case, you probably don’t want to load them directly in your adapter’s getView() because, well, you should never ever block UI thread with IO. Doing so means that scrolling your ListView would look anything but smooth.

What you want to do is running all per-row IO or any heavy CPU-bound routine asynchronously in a separate thread. The trick here is to do that and still comply with ListView‘s recycling behaviour. For instance, if you run an AsyncTask to load a profile picture in the adapter’s getView(), the view you’re loading the image for might be recycled for another position before the AsyncTask finishes. So, you need a mechanism to know if the view hasn’t been recycled once you’re done with the async operation.

One simple way to achieve this is to attach some piece of information to the view that identifies which row is associated with it. Then you can check if the target row for the view is still the same when the async operation finishes. There are many ways of achieving this. Here is just a simplistic sketch of one way you could do it:

Interaction awareness. Asynchronously loading heavier assets for each row is an important step to towards a performant ListView. But if you blindly start an asynchronous operation on every getView() call while scrolling, you’d be wasting a lot of resources as most of the results would be discarded due to rows being recycled very often.

We need to add interaction awareness to your ListView adapter so that it doesn’t trigger any asynchronous operation per row after, say, a fling gesture on the ListView—which means that the scrolling is so fast that it doesn’t make sense to even start any asynchronous operation. Once scrolling stops, or is about to stop, is when you want to start actually showing the heavy content for each row.

I won’t post a code sample for this—as it involves too much code to post here—but the classic Shelves app by Roman Guy has a pretty good example. It basically triggers the async book cover loading once the GridView stops scrolling among other things. You can also balance interaction awareness with an in-memory cache so that you show cached content even while scrolling. You got the idea.

That’s all! I strongly recommend watching Roman Guy and Adam Powell’s talk about ListView as it covers a lot of the stuff I wrote about here. There’s nothing new about the tips in this post but I thought it would be useful to document them all in one place. Hopefully, it will be a useful reference for hackers getting started on Android development.

As you probably know by now, the DevTools team got together here in London last week. I attended their work week with the specific mission of getting remote debugging to work on Firefox Mobile (a.k.a Fennec).

The result? I wrote a couple of patches that allow you to debug JavaScript code from web pages running on Firefox Mobile. You can add breakpoints, step through your JS code, track the call stack and variable values from the experimental script debugger in Firefox’s Nightly build on desktop.

The script debugger uses the remote debugging protocol to send commands to Fennec via network. You have to connect your Android device to your computer via USB and map a localhost port using the follow adb command:

adb forward tcp:6000 tcp:6000

This will map port 6000 on your computer with the same TCP port on your mobile device. There’s no UI in the script debugger to connect to a remote Firefox instance yet but the DevTools team already have a patch series adding that. My patches simply implement the necessary actors that expose all browser tabs to the script debugger.

Remote debugging is especially important for mobile web developers. They need a way to easily tweak pages on the mobile device and see the results instantly. Right now, the remote debugging protocol only allows you to debug JavaScript code but the long-term goal is to allow web developers to do much more: injecting code, inspecting DOM nodes, tweaking CSS rules, etc.

As you can see, there’s a lot of exciting work in progress here and many patches about to land in our repositories very soon. Stay tuned!

There’s nothing special about today’s date but I feel it’s a good time to write a bit about my experience at Mozilla so far.

First days. Joining Mozilla was, at least in the first few weeks, a rather scary experience. Mostly because it was an unknown territory—both socially and technically—and I had a lot of catching up to do. The amount of information you have to assimilate in order to understand how things are done is a bit overwhelming. But here I am, I survived! And still catching up.

Remote. One of the main concerns I had when I joined Mozilla was the working-from-home part. I’ve done it before but not for so long. It turned out to be a good experience and enjoyed it in many ways. But I still missed meeting workmates in person and having a more clearly separate environment for work. So, I’m glad that the awesome London office is now open!

Hacker-friendliness. Mozilla is a very friendly environment for hackers: meritocratic, pragmatic, and virtually bullshit-free. Feels good. You’re pretty much free to decide what to do next with very simple guidance as to what has higher priority at point in the development process.

Passion. Mozilla’s mission is taken very seriously. You see that reflected in every small and big decision inside the organization. Being a non-profit organization with such a worthy mission is very liberating because you can express your passion with no excuses. Mozillians are very passionate people.

Quick stats. I joined Mozilla 238 days ago. Since then, as part of my work at the company, I pushed 204 changesets, changed ~7,395 lines of code, fixed 106 bugs, gave 2 talks, travelled to 4 countries, and met a huge number of smart people.

This year’s FOSDEM was a special one for me. It was the first time I attended it as a Mozillian! I had already met quite a few European community members at MozCamp Europe last year but this FOSDEM was a great opportunity to meet even more Mozillians face-to-face. I stayed at the Mozilla DevRoom most of the conference but also spent some time catching up with my fellow GNOME hackers.

Chris and I gave a “State of Firefox Mobile” talk on Sunday. I usually don’t share my slides because they tend to be too short in content to be useful. However, we wrote some speaker notes that give enough information and context on what we talked about. So, here’s the deck alternating between slides and speaker notes—I wish Speaker Deck had proper support for speaker notes…

All in all, I had a great time at FOSDEM this year! PS: The weather during the conference was quite special too—in a painful way!