The Firefox OS marketplace is brilliant
dendory.net
dendory.net
How is a device built on a browser engine supposed to provide good UX on low power devices? My Android tablet has Firefox stutter and wheeze through pages and loading, often freezing up on any reasonably sized amount of javascript, and it has a Tegra 3 (TF700) which many would call the high-end mobile device market.
Firefox on Android has always been fairly fast for me, for what it's worth.
Though I do acknowledge the internal memory is slow as crap.
- Prior to 4.x the "highly optimized JVM" was "highly interpreted".
- Access to the display is gated via userspace (SurfaceFlinger) which must be invoked to composite every frame, and at least in 2.x (if not still true) unconditionally repainted the screen each frame.
- Accelerated 2D did not exist in Android 2.x, I'm not sure if it exists yet.
- None of the standard GUI widgets knew how to handle partial repaint. I think this was fixed in 4.x.
From the perspective of getting lag right, you only need to ensure there is some native code that can scroll around a bitmap efficiently. As for how that bitmap gets rendered, a few hundred thousand lines of C++ stands a much better chance of efficiency than an unoptimized, initially interpreted Java GUI framework that has no native way of expressing "allocate this temporary on the stack" ever did.
The choices made for Android might have been valid when painting a 160x200ish 16bit display (about 64kb per frame), which AFAIK was roughly the original target hardware prior to the Google purchase, but for 800x480 24bit this quickly turns into a need to generate 34mb/sec to render at 30fps, all done in software, chunks of it interpreted, on (what was initially) a 500mhz ARM11 CPU. Really helps frame the panic Google must have been in to get something on the market and fast.
Slight correction: JIT compiler was first introduced in Android 2.2
The way I see Google from the outside they don't seem to be panicky when entering new markets. Half of the internet already belonged to them before Android, it's not like do or die in their case. Maybe Android's technically poor choice of backend architecture may have been due to inexperience in low power device software? Microsoft has much more experience there too, and they seem to have proven my point by releasing a very responsive WP7 about a year after (it should have been). Actually, seeing Microsoft's (and Palm's) situation, Google's 'worse is better' approach may have been just what they needed, so their management certainly deserves some slack there.
From this list of issues some of which are "fixed at 4.x", and from the fact that --based on Google's own stats-- very few people have 4.x (only around 10% of all Android devices have it or have upgraded to it), the whole Android vs iOS fight seems kind of moot. Technology wise iOS wins hands down.
It's interesting to note that the HipTop has always had a modified Java run time, and in later versions even ran on a Unix kernel (NetBSD I think). So the architecture decisions for Android were already familiar to Rubin and the team.
Isn't it the other way around? There's no effective way of publicising you app or helping people to find it in an app store short of hoping that the Apple/Google overlords will decide to stick it on the front page. It's remarkably hard to find apps that you're looking for unless you know the name of it (and it isn't a common name, etc), and there's no way of working around it.
In contrast, on the web, if one site doesn't work very well, you go to another one. If one discovery tool isn't working very well (e.g. Digg), you use a different one (e.g. Hacker News).
The web is very discoverable. It just doesn't force a particular discovery mechanism on people like app stores tend to do.
That said, this is a large part of why FirefoxOS is so promising.
They are subtly different I would say. Though I can't say entirely way.
I think we've been trained to go to google to search for content, but not to search for something to help us get a specific job done.
As for the manifest file, you can get by with as little as:
{
"name":"Example",
"developer": {
"name":"Developer",
"url":"https://example.com"
},
"description":"My Description",
"icons":{
"128":"/img/icon.png"
},
"launch_path": "/",
"installs_allowed_from": ["*"]
}
With this, you can install your app from the Marketplace or from your own site (by serving it with the correct mime-type).It is relatively easy to get the app installed from your own site, if you choose to ignore the Marketplace entirely (our code does it in ~80 lines of CoffeeScript) as seen here: http://www.youtube.com/watch?v=FMxeK1_xY98
One thing to keep in mind is that the window chrome which will house your application does not have back/forward buttons, does not have bookmarks, or an address bar. Remember this when designing your interface (you may been to provide in-app back/forward buttons, bookmarks, etc).
The only problems I ran into when developing this was that the API was unstable at the time (a few months ago) and that relative URLs for installation didn't work (https://bugzilla.mozilla.org/show_bug.cgi?id=745928) but the devs in the mozilla #webapps IRC channel were helpful.
The nice thing about the Marketplace is that you can specify which form factor you want your app available to - Desktop/Laptop, Phone, Tablet.
On the phone side, things are easy:
https://lh3.googleusercontent.com/-7uT3PPCyPD8/UP9RTN-392I/A...
https://lh3.googleusercontent.com/-GB4Vt6YVTKA/UP9RSDzDy8I/A...
https://lh5.googleusercontent.com/-dXnc0iuIBdM/UP9RRW_UILI/A...
https://lh6.googleusercontent.com/-NReWzbudobw/UP9RnJEiHpI/A...
I don't know what an IAP is, so I can't comment. :-)
edit: Thanks to Samuel for the explanation. No, I don't have experience with IAP.
My preference is for app stores that work more or less the way they do now. If under the covers you're rocking some standard web technology, hey great. As long as my app works offline and doesn't randomly change.
Quick, answer this, does Facebook work when you are offline? How about Google Drive? Or the new GMail for iOS?
Mozilla, please create a decent cheapo phone and I'd pay 2x to ship another one to a poor country.
We are working hard to make it easy for you to create and debug your apps because that is a win win for everyone.
It seems we really need a curated site for mobile apps like the Yahoo of old for websites. Essentially, a more functional app store than the app store. Thoughtful reviews on par with those you see on Amazon. Algorithms equivalent to PageRank don't seem to apply to this space, so perhaps human experts like those seen on about.com might work.
Chrome also has their web store. The major bridge is there needs to be a standard interface for web apps, in addition to some standard way to use them offline. Since most local storage limits itself to 5MB max, you don't really have the offline storage you need to run a game, for example.
To a lot of us, Firefox OS sounds like a miserable platform with many serious problems.
1) There are basically no users at this point, of both the platform and the Firefox Marketplace.
2) Firefox OS is far back in line, behind Android, iOS, BlackBerry OS, several Windows variants, Symbian, MeeGo, and various other platforms that currently have actual users.
3) There's nothing really compelling about Firefox OS for customers. There's nothing that makes it more appealing that its competitors.
4) The emphasis on developing apps using HTML5 and JavaScript is not appealing to many good developers. Going from the power of languages like Java, C, C++, and Objective-C on other mobile platforms to HTML5 and JavaScript on Firefox OS is a pretty big step backward.
5) The Firefox Marketplace won't be publicly launched until later this year. Even if that was as early as tomorrow, that's still ages in the mobile world.
6) It looks like Mozilla is just playing catch-up with Apple, Google and others.
So it seems to be a pretty big dead end to a lot of us, that's destined to failure.
iOS is closed / walled garden.
Windows Phone is closed / walled garden
BB is closed / walled garden.
Android is a fragmented, buggy shit tip of an environment and is mostly closed and uncertain.
Symbian is pretty much dead.
MeeGo is dead.
Nokia S40 is still alive but I'll be fucked if I'm writing J2ME any more.
---
Some positive indications of FireFox OS:
It's open.
It's easy to access it.
The environment requires little proprietary knowledge i.e. deep specialist APIs and languages (no obj-c, WPF, XAML, that awful XML thing Android uses).
License cost for hardware manufacturers will be very low if not free I imagine so uptake on carrier's own branded handsets might be high.
As for catch up, I remember everyone complaining about how the original iPhone and Android phones didn't stand a chance against BB and Symbian...
1) It has no current users.
2) Developer preference for what you call 'power languages' as opposed to HTML5/Javascript.
My retort:
1) Google launched behind a hord of other search engines like Lycos, Excite etc, but they conquered the search market. They simply did search better.
2) Show the data. The fact that the existing platforms imposed certain languages on developers doesn't mean that developers would voluntarily work in them if they had an option. Cordova/Phonegap seems to be a counter point to your claim.
Though I am concerned about it's performance. Firefox has always been prone to crashing. Thus I wonder is this a brand new piece of software not built on the Mozilla (Firefox) engine?
I'm my experience, most crashes seem to be related to plugins and/or extensions, with that aside, I seem to get pretty comparable crash frequency from Firefox and chrome while developing code that relies on pretty state-of-the-art APIs (WebGL)
We haven't been able to get our app working in regular Firefox because of this - unfortunately!
Firefox for Android for some devices also supports MP3 and H.264 now.
Desktop support is in progress with Windows and Linux being the furthest along.
I don't know if they do, but it's plausible.
You really need to get some functioning market competition in USA telecommunications, it seems nonexistant.