Earlier this year, Mozilla announced plans to create a web-based OS that would help developers create mobile apps that function across multiple operating systems. The company plans to begin testing this quarter and have more advanced functionality completed next year. Check out the details on TechWorld:
Mozilla developers to test Boot to Gecko mobile OS
Mozilla developers hope to start testing phones running its new mobile operating system this quarter, with product demos slated for the first quarter next year and production set for before June 2012, according to a road map on the project’s website.
Mozilla announced the project, called Boot to Gecko (B2G), in July, describing it as an operating system for mobile devices that would run applications primarily on the web.
Developers hope B2G will help solve a problem that has long plagued the mobile industry: Developers must rewrite apps for each operating system. The goal of B2G is to create a framework that would let applications run from the web on any operating system, provided the OS supports B2G’s technology.
By the end of this year, the developers hope to have basic functions built and integrated including the accelerometer, camera, messaging, telephony and power management, according to the road map recently posted on the site.
uTest: In many ways, mobile is still playing catch up to the web. Is there one area in particular where you see the most room for improvement? If so, where?
ME: Well, there are some obvious platform deficiencies around inconsistent UI and whether Flash is going to be fully supported across mobile devices or not. But this is a testing blog, so let’s talk about that. As I mention elsewhere in this interview, mobile is just a really tough testing challenge. The big problem is that there is very little support for cross-platform mobile device test automation. I suspect most of mobile device and application testing is done 100% manually. If any environment needed more test automation, it is mobile. At Palm, we rolled our own test harness that ran on the Pre. This became extremely important for endurance testing and finding memory leaks in the Pre applications.
Mobile software companies have an uphill battle since developing automated system tests for every platform is very costly, both in time and resources. However, reliance on mostly manual testing has lots of quality risks. If the quality of mobile devices and software is to rise about what it is now, we need automated test tool support that works well across all device platforms.
The uTest Blog has just published Part I of a two-part interview with Matt Evans, QA Director at Mozilla. Prior to his role at Mozilla, Evans was a key player at Palm, where he managed the quality program for the WebOS Applications and Services of the Palm Pre smartphone. You should read the entire interview, but here are two questions he answered specific to mobile app testing. Enjoy!
uTest: You were the QA Director for Palm when they launched the Palm Pre Smartphone, as well as the WebOS apps and services. What’s been the biggest difference (if any) between launching a mobile product and a web product?
ME: The biggest difference between a web product and mobile device is the amount of testing and certification that must precede the launch of a mobile product. A smartphone such as the Pre is an incredibly complex and highly integrated piece of technology–much more so than a typical web application. First off, a smartphone contains a fully-functional OS, usually based on some variant of Linux running on very constrained hardware. It must perform all of its concurrent services utilizing limited memory and limited CPU horsepower. The smartphone must also respond correctly to the multitude of many current events, from those generated from the environment–like switching from wifi to a WAN internet connection–to handling data input from the user, as well as handling events from the onboard applications.
Launching a mobile product requires exhaustive certification of individual hardware components such as the CPU, modems, codecs, and displays. Even then, the finished product is really launched by the carrier and must go through their exhaustive certification tests as well. Testing an onboard mobile application is also a much harder testing task. There are so many conditions and constraints that are involved in testing a mobile application.
A typical mobile application is nearly functionally equivalent to any counterpart desktop client-side web application. Take, for example, a mobile email application. It must behave and interact with the server-side application in nearly the same way as a desktop web client. The established protocols were designed for a stable communications environment, but this is just not the case in a mobile environment. The internet connection may be lost and reconnected very rapidly. The connection may even be lost for long periods of time. The application may, at any moment, be swapped out of memory. The system may be shut down abruptly. Lots of system conditions happen in a smartphone that would rarely or never happen in the context of a desktop web client application. However, a mobile application must perform its main functional operations of retrieving and sending messages flawlessly with no loss of data and full operational integrity. Testing mobile applications under these environmental scenarios is a huge challenge. In short, testing a web application is no easy task, but mobile applications and products represent a much tougher and larger testing challenge.
Not too long ago, we blogged about the developments surrounding Fennec – Mozilla’s “Firefox for Android.” Here’s a rather harsh update of their progress (or lack thereof) from blogger Sean Michael Kerner:
So here we are more than two years after Mozilla kickstarted its mobile efforts, and they’ve announce the first beta for Firefox 4 Mobile on Android and Maemo. So forgive me for not being too excited about the this new beta, I’ve heard this song before.
Sure, there are differences this time around. Firefox 4 is a superior browser to the base that Mozilla developers first started with for Fennec and yes Android is likely the best target they’ve ever had for a mobile platform with vastly more users than Maemo (isn’t that supposed to be MeeGo now?!)
The ability to sync desktop and mobile is a great idea and that’s likely the ideal use case scenario under which Firefox 4 Mobile will thrive on Android devices. For iPhone users, there is no Firefox Mobile, but they can benefit from the Firefox Home application instead.
Choice is always a great thing, though in my experience the Android web browser is already a fast and very capable technology. It’s not like Windows users with IE that really need another option, Android users aren’t exactly suffering. Blackberry users, now that’s another story — I haven’t seen any effort from Mozilla to target that platform (and likely won’t either).
Have you tested this beta version? Let us know what you think.
MobileCrunch picked up the news that Firefox Home – what they call the “almost-a-browser” - is now awaiting App Store approval. That’s great, you’re thinking, but what the heck is an “almost-a-browser”? Here’s Simon Chester with an explanation:
Well, rather than just being a Safari replacement, Firefox Home acts as a bridge between your desktop version of Firefox and your iPhone. This is crucial, as apps that duplicate functionality of native iOS apps without adding anything new are a no-no in the App Store approval process.
It uses the Firefox Sync extension to sync your (desktop) Firefox bookmarks and history with your iPhone, and – more interestingly – will allow you to slide tabs open in Firefox over to your iPhone, much like Google’s Chrome-to-Phone functionality in Android 2.2.
You can search for and view any of the pages in your desktop bookmarks or history, as well as view the tabs open on your desktop copy of Firefox, right on your iPhone. Once you’ve found the page you’re after, you can view it either in Safari (an Apple-friendly move), or from within Firefox Home (which may upset Apple). You can also send the links via email.
Make sense? If not, and you’re one of those “visual” learners, here’s a video demonstration:
Exciting news from the mobile front yesterday, as developer Vladimir Vukićević announced that a more usable “pre-alpha” build of Firefox for Android (aka Fennec) is now available to a “broader set of people.” As you would expect from a project in such an early stage, there a number of bugs and other issues that still need to be resolved. Vladimir acknowledges as much in the post, offering a number of specific examples. Here are few of them (verbatim):
It will likely not eat your phone, but bugs might cause your phone to stop responding, requiring a reboot.
Memory usage of this build isn’t great — in many ways it’s a debug build, and we haven’t really done a lot of optimization yet. This could cause some problems with large pages, especially on low memory devices like the Droid.
You’ll see the app exit and relaunch on first start, as well as on add-on installs; this is a quirk of our install process, and we’re working to get rid of it.
You can’t open links from other apps using Fennec; we should have this for the next build.
This build requires Android 2.0 or above, and likely an OpenGL ES 2.0 capable device.
For more on this development – including how you can install and test the build yourself – go read the entire post.
Here’s the second part of Jigar Patel’s post on mobile web app testing.
Safari and Mozilla Firefox support some great extensions that can make testing your mobile sites on desktop browser much easier. You can get more details here.
Testing mobile applications on the desktop browser, as mentioned, does provide several major advantages. Let me illustrate: From the browser metrics of the application, prepare a list of user agent strings for each browser in your metrics. User agent strings can be easily found through a Google search. From there, setup the Firefox browser to test with mobile application as mentioned in this article. Then, set the user agent sting in Firefox for each device, one by one, and navigate to the sign-in page of the application. See if the site renders the mobile version of the application or the PC version if available. If it does, then we are on the right path, and there is a good chance that real handset seating on the end user hand will redirect to the correct mobile version of the site.
If it renders the PC version of the site, this could be a bug in your application. If so, there are less chances for handsets being supported by your application, provided that it doesn’t render the mobile version of your site. Be sure to document each browser on which this behavior occurs and ask dev to fix it. If it can’t be fixed, then there is less of a chance that the real handset will support it. At this point, we can make the decision to cut down the devices/browser from the metrics which doesn’t redirect to the mobile version of the site. Now you can understand the advantage of testing on a desktop browser, that we can kick out the devices from this analysis before purchasing it to test and hence it will help to reduce the cost!