The roads I take...

I blogged about Lantea Maps 18 months ago. As its marketplace listing describes, the app's purpose is displaying maps as well as recording and displaying GPS tracks.

I wrote this app both to scratch an itch (I wanted an OpenStreetMap-based app to record GPS tracks) and to learn a bit more of JavaScript and web app development. As maps are a 2D problem and the track display requires drawing various lines and possibly other location indicators, I wrote this app based on 2D canvas. I started off with some base code on drawing bitmap tile maps to canvas, and wrote the app around that, doing quite some rewriting on the little bit of code I started from. I also ended up splitting map and track into separate canvases so I wouldn't need to redraw everything when deleting the track or when moving the indicator of the last location or similar. Over time, I did a lot of improvements in various areas of the app, from the tile cache in IndexedDB via OpenStreetMap upload of tracks to pinch zooming on touch screens.

Still, performance of the map canvas was not good - on phones (esp. the small 320x480 screens like the ZTE Open), where you only have a handful of 256x256 map tiles to draw, panning was slightly chunky, but on larger screens, like my Android tablet or even my pretty fast desktop, it ranged from bad to awful (like, noticeably waiting from any movement until you saw any drawing of a move map). Also, as it takes until images are loaded (cached from IndexedDB or out from the web) and that's all called asynchronously, the positions the images ended up being drawn often weren't completely correct any more at the time of drawing them. I tried some optimizations with actually grepping the pixels from the canvas, setting them in the new positions and only actually redrawing the images on the borders, but that only helped slightly on small screens while making large ones even worse in performance.

Given what I read and heard about how today's graphics chips and pipelines work, I figured that the problem was with the drawImage() calls to draw the tiles to the canvas as well as the getImageData()/putImageData() calls to move the pixels in the optimizations. All those copy image data between JS and graphics memory, which is slow, and doing it a lot doesn't really fit well with how graphics stacks work nowadays. The only way I heard that should improve that a lot would be to switch from 2D canvas to WebGL (or go to the image-based tile maps that many others are using, but that wouldn't be as much fun). I don't remember all sources for that, but just did get another pointer to a Mozilla Hacks post that explains some of it. And as Google also seems to being moving their Maps site to WebGL (from image-based tiles, mind you), it can't be a really wrong move.

So, I set out to try and learn the pieces of WebGL I needed for this app. You'd guess that Mozilla, who invented that API together with Khronos, would have ample docs on it, but the WebGL MDN page does only have one tutorial for an animated 3D cube and a list of external links. I meanwhile have filed a bug on a WebGL reference so may improve this further in the future, but I started off first trying with the tutorial that MDN has. I didn't get a lot to work there except some basics, and a lot of the commands in there were not very well explained, but the html5rocks tutorial helped me to get things into a better shape, and some amount of trying around and the MSDN WebGL reference helped to understand more and get things actually right.
One thing that was pretty useful there as well was separating the determination of what tiles should be visible and loading them into textures from the actual drawing of the textures to the canvas. By doing the drawing itself on requestAnimationFrame and this being the only thing done when we pan as long as I have all tiles loaded into textures, I save work and should improve performance.


2D Canvas (left) and WebGL (right) version of Lantea Maps on the ZTE Open

As you can see from the images, the 2D canvas and WebGL versions of Lantea Maps do not look different - but then, that was not intended, as the map is the map after all. Right now, you can actually test both versions, though: I have not moved the WebGL to production yet, so lantea.kairo.at still uses 2D canvas, while the staging version lantea-dev.kairo.at already is WebGL. You'll notice that panning the map is way more fluid in the new version and the tile distortions that could happen with delayed loading in the old one do not happen. I still wonder though why it sometimes happens that you have to wait very long for tiles to load, esp. after zooming. I still need to figure that out at some point, but things render after waiting, so I found it OK for now. Also, I found the WebGL app to work fine on Firefox desktop (Linux), Firefox for Android, as well as Firefox OS (1.1, 1.2, and 1.5/Nightly).

So, I'm happy I did manage the conversion and learn some WebGL, though there's still a lot to be done. And as always, the code to Lantea Maps is available in my public git as well as GitHub if you want to learn or help.

Last month, I was contacted within a few days by a local "open mobile devices" enthusiast, a Mozilla events manager and a fellow German-speaking Mozilla Rep, all of them pointing to an event here in Vienna called Firefox OS DevTreff Austria.

While the local just asked me if I'd go there, the Mozilla contacts had been asked by the organizers for a speaker to open up the event. We were trying to get someone more used to talking about Firefox OS, but everyone's busy this time of year, so in the end we settled with me doing this keynote.

Now, I have been giving presentations on different occasions and events in the last years, but I never have actually keynoted anything, so that made me somewhat nervous. The other talks that were lined up for the evening were about app development, to some part about very concrete pieces of it, so I figured I should give that some frame and introduce people to Firefox OS, starting with why we are doing it, moving to what and where it is and giving a bit of glance onto where we want to take it. So I came up with "Firefox OS: Reasons, Status & Plans" as the title (my slides are behind the link).



The audience was supposed to be about 50 people, I guess 30-35 really showed up (the pictures, taken "in style" with Firefox OS on my Peak, only show one part of the room), but those were an awesome bunch. They were really into the topic, asked interesting questions, and the talks following me were showing that we really had capable developers in the room, from those that do JS in their free time to those who earn their bread and butter by doing apps.
We also had two Mozillians, both of which I had not met in person before, even though I spent a lot of time in this city in the last decade!

As the event was going on, I was often the voice in the room who would have answers from the Mozilla side or could explain our point of view and initiatives - and in quite a few cases, I could loop back to something I said in my keynote. It was really great to see how apparently I had touched exactly on the right things there and gave everything else a good base to build on. Interestingly, there was quite a bit of interest in the DeviceStorage API, probably because accessing local files is something people can refer better to than storing items in-app. I was thankful someone did a talk on our Marketplace and in-app payment API/Services as that's one area I'm actually weak in, but it also sparked quite a bit of interest. The permission model did also get a few questions.

We surely had people with Firefox OS app experience in there, but I think more of those people might pick up web app development, esp. if more similar events come around, which would be cool. And maybe someone should tell them how to do simple apps without larger libraries or frameworks, and explain app manifests in more detail. I hope they will organize more of those and the chance for that will come along!

At Mozilla, as well as a lot of other Free / Open Source Software projects, IRC (Internet Relay Chat) is the backbone of real-time communication within the project.

The beauty of this chat service is that it's a really simple and lightweight protocol and there's a ton of different clients to access it, including for example ChatZilla, which is written completely in JavaScript, and multiple web-based clients. The latter would make nice Firefox OS apps, one might think, but their major downsides are that they are all running on the server-side and not really on the device you installed the app in - and their UI doesn't really fit the phone form factor.

Now, what I'd really like to see, though, is an app that runs locally on the Firefox OS device in its entirety, and which has a UI that is useful and nice on a phone. Especially the latter might mean not implementing all the fancy functionality that many IRC clients have, but only those parts required for some simple chatting.

We have the technology to run a full IRC client on a Firefox OS phone with the TCPSocket API, and the simplicity of the IRC protocol would make it a nice reason for someone who wants to play with this API.

The UI, OTOH, would make a very interesting challenge for someone who like UX design, as on a phone, you need to be way more minimalistic, and you probably need to consciously decide what functionality and which elements to leave out, or implement completely differently than what we might be used to.

I'd really love to be able to have an easy way to tell my manager via IRC that I'll be late for a 1:1 while I'm on my way, or be able to make a quick inquiry in a chat channel while I'm traveling.

Anyone up for the challenge?

We've known for a long time that we'll need some way of displaying crash information on Firefox OS devices for quality assurance (QA) purposes. Anyone helping in debugging crashes needs to deliver crash IDs to developers, and for verifying that crash reporting works and has the correct settings, QA needs to get crash IDs as well and look at the data in those crash reports.

The bug report linked above has not seen any more in 10 months though, as priorities are elsewhere for most of our developers. Also, this functionality can only be achieved via not-yet-existing APIs or via the "apps" DeviceStorage, which requires certified app privileges, which in turn only preinstalled core apps get and 3rd-party apps cannot get at all. The problem is that the submitted (and pending) crash reports are files in a "Crash Reports" directory parallel to the user profile in /data/b2g and we'd need some form of access to that.

In addition, it's pretty unclear how to do a useful UI there. What I personally envision is doing a list of the date/time of the crashes and next to those put a "share" button that allows people to send the crash ID to a larger-screen device via email, bluetooth or whatever. We could directly link the crash reports on https://crash-stats.mozilla.com/ in theory, but the pages there don't have a layout that looks useful on a small phone screen (right now). On future larger-screen Firefox OS devices like tablets, such a direct link will make more sense.

This would be an app (or a screen of Settings, somewhere deep in the Device Information section, probably under the developer settings) that might have a few challenges in creation, but would be huge in reward as a help to improve stability of Firefox OS as a whole.

Right now, people need adb to get info on the crash IDs and dates, with a command like this:
adb shell ls -l '/data/b2g/mozilla/Crash Reports/submitted'
It would be much better and nicer for our work to have that available somewhere via the device's UI.

If you want to help there, please contact me or comment in the bug cited above.

One of my main blockers to using Firefox OS as my main phone system right now is that I didn't yet manage to get all my contacts over to my Firefox OS phones, with neither of the versions I tested. One variant that has applications far beyond initial import is contact sharing via Bluetooth.

It would be great if I could send contacts back and forth between all my devices, including the Firefox OS ones. Other phones usually can send and receive contacts in VCard (.vcf) format via Bluetooth, but Firefox OS so far is missing this functionality (even though some VCard support exists for import from SD card in 1.1, though I could never get that to work for me).

A reasonably usable implementation for sharing could be implemented as an app: It would need to read from the Contacts API, present a selection to the user, assemble VCard files and send those off via a Web Activity so the existing Bluetooth sharing can act on them. With that, the sending side should work.
The receiving side would be a bit more hacky, but also doable: Unfortunately, the existing Bluetooth support does not call a Web Activity for handling not explicitely supported file types, it only ends up saving them on the SD card. So the contact sharing app would need to periodically look for new VCard files in that location, read and offer to import them, and finally use the Contacts API again to write them into the system's database.

If someone would pick up the needed work there, I'm sure the app would be quite popular, and I'd love to use it myself. Ultimately, I think this functionality should be part of the official Contacts apps, so having any such app available under a licence that allows Gaia to use the code would be great. Still, I think it would be awesome to have the app so the soon-shipping Firefox-OS-1.0.1-powered devices can use them.

(This post was written and published from a Firefox OS test device.)