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.
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.
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.
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.
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 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?
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)
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.
"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.
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.
I'm still confused how a platform running only html5 + js applications can target low power devices. Performance on Android, which runs a highly optimized JVM, is only barely reaching acceptable levels in the last year with Project Butter. Ubuntu Phone, targeting the same use case except with native apps (albeit scripted in qml) comes out next year.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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...
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.
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).
> 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.
54 comments
[ 2.8 ms ] story [ 126 ms ] threadAs for the manifest file, you can get by with as little as:
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.
https://wiki.mozilla.org/WebAPI/WebPayment#In-app_payment
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.
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.
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.
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.
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.
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?
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.
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.