The Firefox OS marketplace is brilliant(dendory.net)
dendory.net
The Firefox OS marketplace is brilliant
http://dendory.net/blog.php?id=50ff42f1
13 comments
Android's performance problems are more to do with architecture than anything else:
- 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.
- 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.
Prior to 4.x, the "highly optimized JVM" you speak of was fully interpreted.
Slight correction: JIT compiler was first introduced in Android 2.2
Slight correction: JIT compiler was first introduced in Android 2.2
Thanks, pretty sure the remainder of the version numbers are messed up too.. pulled out of my old and foggy memory. :)
> Really helps frame the panic Google must have been in to get something on the market and fast.
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.
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.
They bought Android the company, who had already picked Java etc. Google just rolled with it. In practice, I hope that Ubuntu Phone is the refinement of the Android platform we need. You don't need a bytecode sandbox if you implement sound MAC, which Android had in its installer. I just hope that Ubuntu Phone adopts wayland instead of X, and not their own window manager mess like surfaceflinger.
Android, the OS and company, was purchased by Google. Its founder, Andy Rubin, was also the founder of Danger, Inc., makers of the HipTop/T-Mobile Sidekick, one of the first mass-market smartphone-like devices.
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.
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.
Wow.
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.
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.
The TF700 has a known problem with its internal storage being incredibly slow, which could be what's causing your problems. http://forum.xda-developers.com/showthread.php?t=2066849
Firefox on Android has always been fairly fast for me, for what it's worth.
Firefox on Android has always been fairly fast for me, for what it's worth.
I bought a cheap TF300 and was blown away to find the same slowness. If you're doing any downloading it's basically unusable. Especially disappointing as the rest of the hardware (including keyboard dock) are great.
I've had the same experience on a Nexus 7, and when I turn on the developer system monitoring it always either pushes memory into swap or maxes out some cpu cores and doesn't properly utilize all 4. The biggest culprit I would say is that you have 4 cores but your computationally expensive javascript is never multithreaded.
Though I do acknowledge the internal memory is slow as crap.
Though I do acknowledge the internal memory is slow as crap.
> Basically, the main reason why an app store or marketplace is important, is because the web suffers from a discoverability problem.
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.
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.
The web has content discovery, the app stores provide function discovery.
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.
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.
I've published an app to the Mozilla Marketplace and for the most part, it just work.
As for the manifest file, you can get by with as little as:
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...
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": ["*"]
}
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...
How do you sell apps or IAPs?
You can't yet. "The Firefox OS Marketplace does not currently support paid apps or in-app payments. We hope to enable this feature for testing late in the first quarter of 2013." (https://developer.mozilla.org/en-US/docs/Apps/Submitting_an_...)
The apps that I have experience with have all been no-cost.
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.
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.
In the context of the Mozilla Marketplace, 'IAP' stands for 'In-App Payment'.
https://wiki.mozilla.org/WebAPI/WebPayment#In-app_payment
https://wiki.mozilla.org/WebAPI/WebPayment#In-app_payment
As a mere mortal I find some aspects of "web apps" confusing. I never know whether I'm running an app locally in my browser, vs. what's happening on a remote server, etc. And I have a hard time knowing which apps are stored locally on my phone, vs merely bookmarked, and whether if they're stored locally they'll update.
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.
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.
Normal apps are confusing in the same way.
Quick, answer this, does Facebook work when you are offline? How about Google Drive? Or the new GMail for iOS?
Quick, answer this, does Facebook work when you are offline? How about Google Drive? Or the new GMail for iOS?
This can't happen soon enough. I hope it supports a terminal and basic dev tools.
Mozilla, please create a decent cheapo phone and I'd pay 2x to ship another one to a poor country.
Mozilla, please create a decent cheapo phone and I'd pay 2x to ship another one to a poor country.
It doesn't yet have a terminal or dev tools on the phone, but this is something I would absolutely love to see in the long run. It's open source, so if you feel like helping out to add these, please do :-)
You can connect to the phone using remote debugging with Firefox's built in Developer Tools (you are best to use the latest nightly). I think that only the debugger and Web Console are remote-able right now but that will change in the near future.
We are working hard to make it easy for you to create and debug your apps because that is a win win for everyone.
We are working hard to make it easy for you to create and debug your apps because that is a win win for everyone.
My only complaint is that the Firefox app manifest and the chrome app manifest aren't the same thing. The Firefox and chrome developers seem like they work together pretty well, it's too bad they couldn't collaborate on this.
I'm sure that's going to happen eventually.
"When you're on a mobile device, you don't have time to go search the web for an app that does a certain function that you happen to require. You want a central place that will list all of the apps that are compatible with your phone"
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.
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.
Mozilla already has that covered: https://marketplace.firefox.com/
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.
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.
[deleted]
This is the first mobile platform that I've been excited about and I've been doing work on mobile devices since Windows CE 2...
Why is that?
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.
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.
Your list of 'serious problems' mostly seem to be social issues, i.e.
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.
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.
I've written software for all the main platforms apart from BB. My rationale is:
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...
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...
did you ever use maemo? nokia may have mishandled it into an early death, but from a developer perspective that thing was gorgeous. i was very excited about it for a while (and correspondingly disappointed later, of course, but what can you do).
I did actually - it was very nice. With some polish, it would have been awesome.
I'm very interested in Firefox OS as we skipped the native app route and just created a web app.
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?
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?
FirefoxOS does indeed run on Gecko, the Firefox rendering 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)
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)
Cool .. also i wonder since our app is an audio app of sorts does Firefox OS's audio tag play .mp3s or still stuck with ogg vorbis?
We haven't been able to get our app working in regular Firefox because of this - unfortunately!
We haven't been able to get our app working in regular Firefox because of this - unfortunately!
MP3 and H.264 should play fine on Firefox OS if the device vendor includes hardware support for it. The initial devices do support this as far as I know.
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.
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.
Yes, Firefox OS plays mp3 (and h264 videos), using the hardware decoder from the device.
I'd hold on with the 'brilliant' qualifier until we see the interface, but the concept certainly looks fitting to the OS model. Is this the entire JSON though? I'm missing at least a keywords child there.
You can see the early version at marketplace.firefox.com
Looks quite neat. I'd like someone to bring some fresh approaches into this however, instead of just basically the Appstore interface with a different skin. Especially for web-apps I'm still not that sure how important the appstore starting point for finding apps actually is. How about a unified search built into the OS with priority set like 'installed apps > other available apps > local data > Google Search' ? Of course, for those who want to search by category it's still good to have a curated list somewhere. But isn't the search for webapps basically the same as a Google search with some meta information sugar on top?
Well, the store has a search bar that returns web-apps of any category. But these web-apps are meant to be installed. Some web-apps will be the same as navigating to a mobile version of a site, but many web-apps are developed to work offline.
I would not mind to own a cheap phone like these ones but in US you have to pay $70/month for the voice and data plan so it is way more expensive than the phone itself.
That's a pain. Here in Europe I've got a cheap voice/data plan for 6$/mth; if/when I start hitting the 2gig cap then I can switch to 10$/month for unlimited. I do have to pay full price for the phone(s), though.
You really need to get some functioning market competition in USA telecommunications, it seems nonexistant.
You really need to get some functioning market competition in USA telecommunications, it seems nonexistant.
That is paying for the iPhone, if you go with monthly-prepaid you can get a good plan for $30/mo or $40/mo
This really looks like an package manager with a name "market place"
refreshing!
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.