To me, the main attraction of Firefox OS is the fact it is based on HTML5 and CSS and javascript. To those who don't know what that means: those are standards that keep the web open, i.e. you can rely on being able to view and interact with content on a web page on almost any type of PC, tablet or phone, made by any manufacturer, or under an operating system from any vendor. In contrast, mobile phone apps are not like this: android apps work only on devices with Google's android; iOS apps only work on Apple's iThings. But, if you write an app in Firefox OS, it's a simple matter to deploy it as a web app which may be used from any device with a web browser. There are of courses cons against that pro, but that's a discusson for another blog post.
About the time I received my phone, I noticed a message from a well-respected-techy-geeky-sort-of-a-chap, called Jezra, who had also recently acquired the same phone, referring to it as "shitty". Upon asking why, he told me it was because he thought it was hard to get his software on to the phone. Despite my dewy-eyed enthusiasm for this phone driven by open standards, I was soon to discover he had a point.
To start my adventure, I read this article and set about trying to install the Firefox OS Simulator. It's an Add-on to Firefox and should've been a simple matter to install, but I discovered that it's not available for Firefox 17 ESR, which is the default version in slackware 14.0, which I have on my laptop (Patrick Volkerding did provide prompt upgrades to recent Firefoxes, but at 22 he couldn't work around a troubling bug, and decided to go back to 17 ESR for slackware stable). Not wishing to mess with a very stable operating system, I downloaded the linux binary tar ball of Firefox 23.0.1, closed Firefox 17 and ran the newer Firefox binary without installing it - it just sits under my home directory. I was then able to install the Firefox OS simulator version 4.0 as I would any other Add-on, and it seemed to work fine. Soon I had this Hello World app and the Boiler-plate app working without issue.
Next up was the potential "shitty" bit - getting the app onto my phone. Now there are numerous ways of doing this, including via a website, but I wanted to get it done via USB, because that, in my experience, mainly with android, is probably best when developing and debugging an app.
According to the aforementioned article, connecting my phone to my laptop involved creating the file /etc/udev/rules.d/51-android.rules containing the following:
SUBSYSTEM=="usb", ATTR{idVendor}=="19d2", MODE="0666", GROUP="plugdev"
The bit that will vary from phone to phone is idVendor; 19d2 means ZTE. You can look these up online (there's a table somewhere in the android adb documentation), or, you can do what I did under linux, and hunt around in the output of dmesg | tail immediately after plugging the phone in. A restart of udev is recommended after you create the rules file, and the udev folk recommend restarting your system.
Luckily, I happened to have the android adb tool already installed, and from the output of running adb devices, I could see that "roamer2" was listed, which, despite the misleading name, was indeed my ZTE phone.
Now when I fired up the Firefox OS simulator it said "Device connected" and "Push" buttons appeared to the right of my apps. This all looked very encouraging. But, clicking the "Push" button did nothing. Nothing happened in the simulator, not even an error message, and the phone didn't display the connection prompt depicted on the page of instructions (mentioned above). Further down that page, a command line method of pushing apps on to the device was described. OK, I thought, if I try that, even if it doesn't work, at least I'll get some clueful error messages, such is the advantage of the CLI.
The CLI tool is called make-fxos-install, and it needs both the android adb, which I had installed, and xpcshell from Mozilla's xulrunner, which I did not. Luckily, I found xulrunner listed on slackbuilds.org and so within a few seconds I had sbopkg downloading and then building xulrunner.
The source downloaded was 80MB, so I was expecting the compilation to take a while on my rather slow laptop. To pass the time, I decided to play around editing the various demo apps and testing the results out in the Firefox OS simulator. I immediately hit problems. After even the tiniest change to an app's manifest, the simulator kept complaining it couldn't update the manifest cache and something about an NS_ERROR was mentioned amongst other gobbledegook. Frustrated, I decided to launch VirtualBox and try out the simulator under Windows to see if the trouble was caused by some linux-related issue (which I thought very odd and rare). To my astonishment, Virtual box failed to start and also gave an NS_ERROR. I thought for a moment that my dual use of Firefox had screwed up the system. I rebooted the system and found X Windows wouldn't start.
I was just about to hurl myself out the nearest window (OK, I was on the ground floor), when I noticed a little snippet that mentioned a write to /tmp/something had failed. I quickly realised that the disk had filled because of the xulrunner compilation.
I then set xulrunner building on my more powerful desktop machine which has a much larger and less full hard disk. Unfortunately, since I had done this whilst sat at my laptop downstairs, my wife inadvertently shut-down the desktop machine upstairs once our son had gone to bed. Grumble. Once my third attempt at building xulrunner had finished without incident, I scp'd the .txz slackware package over to my laptop and installed it.
I then needed to edit the Makefile that comes with make-fxos-install to specify the path to the xpcshell executable. But it didn't work. After a fair bit of pulling of what little hair I had left, I noticed that the xulrunner version I had built was 15. Guessing this was rather old, on the basis that version numbers track firefox, and unable to face any more compiling, I went to mozilla ftp site and found linux 64bit binaries for xulrunner version 23, which matched the firefox I was using for the simulator. I downloaded the xulrunner-sdk (which is where xpcshell is to be found these days) and stuck it in a directory underneath the Makefile.
But still xpcshell refused to work, complaining about a missing library, but this line in the Makefile got it to play ball:
LD_LIBRARY_PATH=xulrunner-sdk/lib xulrunner-sdk/bin/xpcshell
After a little RTFM I found the command to push the helloworld app to my phone was:
make FOLDER=/home/MyUserName/dev/firefoxos/examples/firefoxos-helloworld packaged install
Did I finally get to rejoice and dance about the room at the sight of this little app installing on my phone? No. Grrrrrr! It complained that it couldn't bind to port 6000. After looking at the Makefile I understood that the android adb tool was trying to forward port 6000 on my laptop to 6000 on my phone. Right. So if local port 6000 was unavailable, for reasons unknown, perhaps I could just tell the Makefile to use 6001 and forward that to port 6000 on the phone, which simply involved a tiny tweak to the thoughtfully constructed Makefile, namely:
PORT_LOCAL = 6001
And now executing the make command above worked! The phone prompted me to accept the connection and the app installed and ran. Phew. But, I wasn't quite satisfied; I had to know what port 6000 was being used for on my system. Executing the command
lsof -i tcp:6000
gave me no output, from which I concluded that no process was actually using the port. But this command
nmap localhost
told me that port 6000 was in some way being claimed by X windows. A bit of web research told me that it was needed for remote sessions, which I never use. To stop it using this port, I shut down X windows and started it again with
startx -- -nolisten tcp
I put PORT_LOCAL back to 6000 in the Makefile and found I could now push to the phone. More than that, I found that the "Push" button in the Firefox OS simulator now worked too.
In summary, to get apps to push to a phone from the FireFox OS simulator, in linux:
- use a recent version of Firefox (23.0.1 worked for me)
- create the udev rule file
- make sure port 6000 is open
- get a recent version of xulrunner sdk which includes xpcshell (23.0.1 worked for me)
- get the android SDK which includes the adb tool
- edit the Makefile to specify paths to xpcshell and adb, and libraries they need
I hope the details above prove useful to someone, and if not, I hope you had a geeky chuckle or two at my FireFox OS misadventure. Hopefully I'll soon write some posts about how easy it is (stifles laugh) to write web apps.
For my own apps, I will be going the "install from a server" route because I want nothing to do with Java or Android when it comes to FireFoxOS development. I'll let you know how shitty it is. ;)
ReplyDeleteMy eyebrows raised when I saw adb mentioned in the FireFox OS docs, but perhaps it's nothing more than pragmatic avoidance of wheel-reinvention.
ReplyDelete