Earlier tablet products were user interface disasters. Fiddly pen-based inputs. Bad handwriting recognition. Tiny, mouse-oriented buttons.
iPhone changed the set of expectations for a touch UI. iPhone, Android, Windows Phone 7, and other new-generation touch UIs will leave the old tablet UIs behind. iPad will pioneer a new generation of office productivity software specifically designed for touch interaction.
So, while there is no guarantee this is all enough to make tablets a success, it sure is not a rehash of previous failed products. Tablet prices are also low enough to encourage experimentation rather than to require a business case for a more expensive device.
That Java is something that makes Android superior to iPhone is a dubious claim.
Objective-C has advantages, such as that it is compiled. While Android has lots of libraries implemented in C and C++ that speed execution of Android applications, and developers can choose to implement intensive computations in C using the NDK, Objective-C requires no JNIs or other complications of splitting an implementation between Java and C/C++.
X-Code is a purpose-built, clean-sheet IDE that may lack a few power features found in Eclipse, and Eclipse has numerous plug-ins, but Eclipse also has a pretty diabolical UI, especially compared to software from Apple.
Java, Eclipse, and the other Android SDK tools are more than good enough, but they are not a big advantage, or, depending on your tastes, any advantage. There is a rough equivalence here that will probably extend to Android doing for client Java what iPhone did for Objective-C - making it popular. That is, Android apps will probably be the most common form of interactive client Java apps, if they have not already eclipsed AWT, Swing, SWT, and other Java UI libraries. This is going to have a big influence on Java, considering the fact that iPhone programming books crowd the top of the list or programming books at Amazon.
Android's advantage is in openness. Android developers are not just app developers. They can be system customizers and extenders. They can be technology vendors to a large number of OEMs using Android. They can have all kinds of products, customer, and business models, throughout the mobile economy, not just retail customers of the app store.
The gripes are, unfortunately, mostly off target. But you can't blame a developer for having gripes. They deserve an answer. So here goes:
1. Open Source
The heart of this gripe appears to be "What's worse is Google knows how to protect valued code; Its Maps, Gmail, and Store applications aren't open source. Figuring out when it's okay to include one of those in your own application requires a crack legal team with a hotline to the EFF. "
This is a non-issue. Google hasn't released any proprietary code. Using the capabilities of these applications, or any other FOSS or proprietary applications in Android by means of their remote method interfaces or their Intent filters is OK unless the APIs require a key, as with the maps APIs. The process of getting a Google Maps API key is described here: http://code.google.com/apis/maps/signup.html and most introductory Android programming books cover it, too (http://www.amazon.com/dp/0596521472 in chapter 7). J2ME, BREW, and Symbian all require app signing and all support protected APIs.
2. The Tyranny of the Activity
Android has a unique programming model. It wasn't designed just to make a coder's life difficult. It was designed to prevent a small-screen UI from becoming a maze of hierarchical screen transition and enable re-use of functionality across applications. Android makes "shoveware" ports look bad, which is what Haseman seems to be griping about.
3. Device Debugging
This "gripe" is not really a gripe, but good-natured praise for the ease of debugging on Android.
4. Applications Never, Ever Quit
Android has an interesting and powerful application lifecycle. And, since Android is multi-tasking, more developers will notice that their application has a lifecycle.
5. The Developer Cooperative
This is a valid gripe: On the one hand, Android can manhandle your application's lifecycle, and on the other hand, it is fairly easy for applications to become battery-eaters. Google's developers could have done a better job of automatically detecting battery vampires. Use the "Battery use" in the "About phone" menu in "Settings" to find the applications and other system functions using the battery. That's a tip taken from this article: http://answers.oreilly.com/topic/862-ten-tips-for-android-application-development/
6. Java—Thanks, But I'll Take It from Here
Haseman says: "While it might speed time to market by freeing us from chasing down heap corruptions and memory leaks (two of my least favorite tasks), it can make it nearly impossible to, say, write an anti-aliased font library that renders in a reasonable amount of time. Sure, a developer can write custom libraries in C with their NDK, but now we're debugging two languages instead of one."
Why? The short answer is it is hard to put a JIT compiler in a battery powered device. So the developer has to decide what code belongs in Java and what code belongs in C.
MediaFLO isn't "clunky." The FLO part stands for "Forward Link Only." That means it uses a broadcast channel downstream, so it is bandwidth-efficient for one-way content delivery. It is a Qualcomm proprietary technology, but it is not inherently less good than other DTV technologies applicable to mobile devices. MediaFLO was designed for mobile devices, so it might have advantages over some DTV standards that were not designed with mobile devices in mind.
LTE and WiMAX are the main competing 4G technologies. Both LTE and WiMAX are all-IP networks. No circuits. No dedicated channels for voice. If you run voice on 4G it will be packet voice no matter the other technology choices.
One Voice is what this consortium is calling IMS for 4G. IMS uses SIP for signaling. That makes IMS more like the kind of packet voice you find in Asterisk. Except IMS includes a lot of additional standards that, among other things, enables it to replace the signaling used in circuit switched networks and still interface to those networks. Some people favor IMS because it is the officially accepted 3GPP standard for these types of networks. Other people don't like IMS because it is too complicated and includes a lot of stuff that is unlikely to be used, including stuff like using SIP to initiate Web sessions so you can charge for them. Not that anyone would accept that kind of product.
The other consortium that pushing a voice call standard for LTE is called VoLGaA Forum. VoLGA stands for "Voice over LTE General Access." It works like UMA, which is a way of extending the circuit switched mobile signaling over IP. So you can buy these UMA "femtocells" - a really small cell site - and put them in your home or office and hook them up to your Internet service to extend mobile access to those locations. VoLGA is UMA scaled up to the whole network. Pretty suave, especially for the networks that already support UMA - you can re-use a lot of the same systems.
WiMAX never flirted with UMA (as far as I know) and I think most WiMAX networks that support voice will use IMS. Which is what One Voice is promoting for LTE. So that's no disadvantage for WiMAX.
You may be thinking "If it's all packet voice, why don't I put a SIP client on my smartphone and use my company's IP PBX? Or, why don't I use a smartphone Skype app?" That's called an over-the-top service (OTT). Which is why SMS is so... "important" to this discussion: The only thing you lose by using an OTT service, is SMS.
The book does not cover code obfuscation. I have also not tried obfuscation for Android projects.
Android applications are distributed as archives -.apk files - made mostly of Dalvik bytecode files -.dex files. While you can "dump" a dex file to human readable code, I do not know of a dex to Java decompiler, nor a dex to Java bytecode reverse translator.
This thread in the Android developers group...
http://groups.google.com/group/android-developers/browse_thread/thread/dcc5808b002a47fc?tvc=2...includes an Ant script that the is supposed to obfuscate classes in an Android project. This script uses Proguard, which I used back when I was working on mobile games, but mainly to reduce jar file size. You can see in the discussion in that thread that there are some Android-specific issues to watch out for, such as that classes referred to in Android manifest files and the names of View subclasses used in layout files should be excluded from obfuscation.
You can also use native code libraries and JNIs for the code you are most concerned about, if compiling code to ARM instructions seems more resistant to reverse engineering than Davik byte codes.
That's not really a subject of the book. And I don't have any access to Google's decision-making on that, but one of my co-authors and I created a system that, like Android, used Java on handsets, so we explored this issue in some depth:
1. Making a good JIT is very difficult. Open source JITs, at the time we were putting a Java on ARM-based systems, provided very little performance improvement over an interpreter.
2. Other system components, like the graphics stack and garbage collector have very large impacts on performance, probably larger than the difference a JIT could make. Most interactive applications spend a lot of time drawing the screen, and a JIT won't speed that up.
3. Even if you could magically get a JIT as good as Sun's that worked on ARM, it's an open question if you want to spend CPU cycles, and therefore battery power, JIT-compiling code on a handset. You may need to design a JIT specifically for battery powered devices.
I would guess Google has the resources to explore all the alternatives: JIT, pre-compiled Java, JIT/cached, etc. and will at some point speed up Java execution. But, depending on what your app does, it might make less difference than speeding up graphics.
Alternatively, if you have something that is very compute-intensive, you can put it in a native code library compiled from C or C++, and access the library using JNIs: http://developer.android.com/sdk/ndk/1.6_r1/index.html
I am a co-author of this book. Feel free to ask me about it. If I can't answer, I'll make sure your questions get to the other co-authors and/or our editor.
Chrome OS fills a number of needs. Whether these turn out to be the needs of end-users remains to be seen, but Chrome OS is not just some industry giants engaging in a slanging match:
1. Chrome OS will help segment Atom from Pentium and Core. That's a pretty big need right there, for Intel, anyway.
2. It could fill a not-yet-filled void: There is a very good chance Chrome will end up dominating netbook Linux the way Android is on the way to dominating handset Linux. Android is a really nice system, and deserves to win versus most other mobile Linux alternatives. Android is accelerating the use of Linux in handsets. Chrome might be that much better than other netbook Linuxes that it, too, ends up dominating and expanding it's market segment.
3. OEMs have been porting Android to devices that may not be the best match for Android. Chrome OS is a better answer than diluting or de-focusing Android to make it a more universal OS.
4. It completes the strategic picture for GWT, Gears, and Chrome: Google has a multi-layered strategy to make their applications run on any OS and any browser. If GWT and Gears on IE on Windows 7 are one end of the spectrum, Chrome OS is the other end. Microsoft has an OS platform where they can integrate search and the cloud and local applications. Now Google does, too.
I would not be surprised to see an Android application runtime on Chrome OS, alongside the browser/JavaScript runtime.
X client for Chrome OS written using GWT in 3, 2, 1...
Seriously though, Chrome OS will be more hackable than a phone OS, which, in the form of Android is pretty open anyway. So even if Google intends the userland to be primarily running in the Chrome javaScript runtime environment, it seems inevitable that X and general-purpose Linux desktop apps will find their way onto Chrome OS screens.
As others have pointed out, free online services are no more susceptible to a Black Swan Competitor, or even an ordinary competitor, than any other business. If there is a distinction, it is likely to be that free Web services are especially governed by first mover advantage and category domination such that they are less in danger from Black Swans than, say, a trucking company or a chain of coffee shops.
There are several things wrong with this idea: Nobody has ever supported subsidies for a mobile device with app store sales and it is unlikley to start working in the current pricing environment in app stores. Even the most profitable carrier portals for mobile downloads are a drop in the revenue bucket for carriers. Most of the content in traditional carrier portals is "passive" - ring-tones and wallpaper. App stores for platforms like Android, Pre, and iPhone, and the corresponding developer programs, are meant to benefit the platform, not the network operator. Apple's app store has a unique position alongside the largest music retailer in North America - unless you have a plan to succeed without that advantage in place, success isn't likely. Android is in the process of replacing a lot of "Linux + proprietary UI" in mobile devices - e.g., at Motorola, they have EOL'ed their proprietary Linux-based "high feature" platforms in favor of Android, and Android has an app store. Applications in app stores have very low prices compared to retail games on handheld consoles, and the vast majority of applications - and downloads - are free. Many low-cost mobile games are shovelware copies of Web-based casual games. The packaged software industry died more than 10 years ago, except for holdouts like Adobe and AutoDesk in specialized, high-value markets, and mobile app shops are not going to revive it. So, put a shiny skin on Synaptic and call it a day. Or call it an app store.
Huawei and ZTE already play at the highest levels of the telecom industry. Perhaps in software they are not up to the level where they could make an iPhone or Android by themselves. But underestimating Chinese and Indian companies would be a mistake, especially the most prestigious ones who have their pick of elite university graduates. This change happened within the last 10 years. It may take another 5 or 10 years for Asian software developers to make a breakthrough Web application but do not count them out.
Run of the mill IT outsourcing at second and third-tier firms (or even first-tier firms that grew too fast) is another matter. This is where the horror stories come from, and, often, the people managing these outsourced resources are doing it because they ran out of onshore yes-men.
Google adopted a unique graphics stack, unique IPC, a little-used libc, etc., installed a Java-based managed language system with unique UI classes, replaced the whole suite of UI applications, and sold a million Androids and will sell millions more on the 18 more handsets due this year. Contrast that with the incremental approach taken by Nokia in the 8XX devices with GTK-based Hildon. Or, contrast with Microsoft's approach of not getting rid of C++ as a language for the userland of Windows Mobile once they put C# and NETCF on it. Microsoft could have had an system very like Android 6 or 7 years ahead. They didn't innovate enough.
What that shows is that the desktop Linux userland is still in such an embryonic state that all prior approaches can, still, be replaced by something better. Android applications will likely be able to run on Linux desktops, soon, and some "smartbook" form-factor devices will run the Android UI as the sytem's principal UI framework.
Palm Pre innovates enough. Android innovates enough. There is a lot to be said for incrementally polishing and evolving the Linux desktop, but it hardly innovates too much.
The average of revenues for applications in the iPhone app store might be less than $3000 but this is somewhat misleading. Like any publishing market there are a few winners and many, many also-rans. If you calculated what the average book out of Amazon's 3.5 million books took in, you might conclude you can't make any money at all publishing books. But even a specialized tech book on a current topic is going to rank in the 20,000-40,000 range in sales rank, and that is in the top 2%. There is a lot of obscure stuff that got printed at some time or another that really can't be considered part of the market that real publishing companies participate in.
So, if you put a truly professional effort into a product, you can reasonably expect results that are way above the average, and that seems to be borne out by the tennis application mentioned in the article: It made several times the average. But, due to low prices, that amounts to only a few tens of thousands of dollars over the product lifespan.
The price erosion in the iPhone app store is going to be a real worry to real game publishers. If you can't sell a game for $19.99 you won't get quality studio-produced games, except as an experiment in the market. Good or bad, it sure is different from the DS. At those pricing levels, the number of financial winners will be very small, and since price erosion is hard to undo, new revenue sources will have to be found in order to change the fact that only a very small number of products will make revenue in the hundreds of thousands of dollars.
Mobile handsets, because they are resource constrained, will be the first to implement this simplification:
The OS runs the hardware
There is a small non-application userland with utilities, daemons, etc.
The part of the userland the user uses is implemented using a JavaScript managed language runtime, with enough local access to enable offline operation for applications unrelated to communication.
Not only is the application structure and lifecycle unique and structured around a unique UI flow, Android has unique UI classes in an otherwise mostly standard Java runtime, it uses binder for inter-process communication, it has a unique graphics stack relative to most other Linux systems, and it makes it difficult to put programs other than those written to the Android programming model on the screen, among other differences relative to most Linux-based systems.
But it has already overtaken the Nokia 8xx Web pads, which use Hildon, in user acceptance. Google gambled on establishing an entirely different application layer in the userland for Android and appears to have succeeded.
Android answers the question: "What if Linux had a userland based on a managed language runtime and every application used the same UI classes (and what if a company with sufficient resourced to do it right did it)?"
If Android perplexes you, try this: http://www.amazon.com/Android-Application-Development-Programming-Google/dp/0596521472
It is perfectly fair for a government letting a contract to limit that contract to entities that are not suing it. That's like an arbitration clause in a contract.
One very serious point to being "free" is that, if you are serious about security, you want as much of your software to be available for security audit as possible.
Another serious point to being "free" is reliability. Linux is reliable because it is open. Dilute the openness, and the reliability gets watered down, too.
I was a consultant at Lotus at the time Microsoft started winning in desktop applications.
Bill Gates is essentially correct:
1. Lotus did a much worse job of hiring in professional management and bridging the gap between software development and business.
2. Lotus complicated their tools-set and architecture unnecessarily. This is one factor that killed 1-2-3. Lotus went straight from assembly code speedy to bloated and slow. Ironically, as this was happening, Jon Sachs wrote 1-2-3 C, a simple, fast, and very portable reference implementation.
3. Lotus did a bad job with follow up products. Instead of launching and improving, they would launch, get disappointed, give up, do something else. Or, in the case of 1-2-3, they would overcomplicate. They had very innovative products - ones that could have changed spreadsheets in fundamental ways, and that would still be innovative today. But they did not know how to nurture these products.
Microsoft faces a lot of the same problems now. Microsoft can't seem to make regular incremental improvements to key products, for example. But business isn't about being perfect. It is about being less bad than the other guy.
The U.S. Constitution is written from the point of view of protecting natural rights from government predation.
Copyright is different. It is a created "right." Really, it is more like a "deal" than a right: It is a limited term grant of exclusivity. No real right works that way, and no other right is explicitly created - they are assumed to exist with or without the acknowledgment of the government.
Therefore you do not need to be an "anarcho"-anything to reconsider copyright. The Founders themselves considered it less than a right.
Copyright isn't even a contract. It is a kind of charter that can be revoked or modified at the whim of the granting party. So reducing a copyright term isn't even a "taking."
Copyright was created by the government to benefit the people. If it stops working that way, copyright has no purpose.
Slashdot Mirror
Earlier tablet products were user interface disasters. Fiddly pen-based inputs. Bad handwriting recognition. Tiny, mouse-oriented buttons.
iPhone changed the set of expectations for a touch UI. iPhone, Android, Windows Phone 7, and other new-generation touch UIs will leave the old tablet UIs behind. iPad will pioneer a new generation of office productivity software specifically designed for touch interaction.
So, while there is no guarantee this is all enough to make tablets a success, it sure is not a rehash of previous failed products. Tablet prices are also low enough to encourage experimentation rather than to require a business case for a more expensive device.
That Java is something that makes Android superior to iPhone is a dubious claim.
Objective-C has advantages, such as that it is compiled. While Android has lots of libraries implemented in C and C++ that speed execution of Android applications, and developers can choose to implement intensive computations in C using the NDK, Objective-C requires no JNIs or other complications of splitting an implementation between Java and C/C++.
X-Code is a purpose-built, clean-sheet IDE that may lack a few power features found in Eclipse, and Eclipse has numerous plug-ins, but Eclipse also has a pretty diabolical UI, especially compared to software from Apple.
Java, Eclipse, and the other Android SDK tools are more than good enough, but they are not a big advantage, or, depending on your tastes, any advantage. There is a rough equivalence here that will probably extend to Android doing for client Java what iPhone did for Objective-C - making it popular. That is, Android apps will probably be the most common form of interactive client Java apps, if they have not already eclipsed AWT, Swing, SWT, and other Java UI libraries. This is going to have a big influence on Java, considering the fact that iPhone programming books crowd the top of the list or programming books at Amazon.
Android's advantage is in openness. Android developers are not just app developers. They can be system customizers and extenders. They can be technology vendors to a large number of OEMs using Android. They can have all kinds of products, customer, and business models, throughout the mobile economy, not just retail customers of the app store.
Sponsoring Firefox was a good deal when it was negotiated. However, Google can't easily "own" Firefox as an open source project.
Google does own Chrome, and can be shaped to fit Google's product requirements.
Unless Firefox falls far behind Chrome, there is no reason Firefox can't justify continued support from Google.
The gripes are, unfortunately, mostly off target. But you can't blame a developer for having gripes. They deserve an answer. So here goes:
1. Open Source
The heart of this gripe appears to be "What's worse is Google knows how to protect valued code; Its Maps, Gmail, and Store applications aren't open source. Figuring out when it's okay to include one of those in your own application requires a crack legal team with a hotline to the EFF. "
This is a non-issue. Google hasn't released any proprietary code. Using the capabilities of these applications, or any other FOSS or proprietary applications in Android by means of their remote method interfaces or their Intent filters is OK unless the APIs require a key, as with the maps APIs. The process of getting a Google Maps API key is described here: http://code.google.com/apis/maps/signup.html and most introductory Android programming books cover it, too (http://www.amazon.com/dp/0596521472 in chapter 7). J2ME, BREW, and Symbian all require app signing and all support protected APIs.
2. The Tyranny of the Activity
Android has a unique programming model. It wasn't designed just to make a coder's life difficult. It was designed to prevent a small-screen UI from becoming a maze of hierarchical screen transition and enable re-use of functionality across applications. Android makes "shoveware" ports look bad, which is what Haseman seems to be griping about.
3. Device Debugging
This "gripe" is not really a gripe, but good-natured praise for the ease of debugging on Android.
4. Applications Never, Ever Quit
Android has an interesting and powerful application lifecycle. And, since Android is multi-tasking, more developers will notice that their application has a lifecycle.
5. The Developer Cooperative
This is a valid gripe: On the one hand, Android can manhandle your application's lifecycle, and on the other hand, it is fairly easy for applications to become battery-eaters. Google's developers could have done a better job of automatically detecting battery vampires. Use the "Battery use" in the "About phone" menu in "Settings" to find the applications and other system functions using the battery. That's a tip taken from this article: http://answers.oreilly.com/topic/862-ten-tips-for-android-application-development/
6. Java—Thanks, But I'll Take It from Here
Haseman says: "While it might speed time to market by freeing us from chasing down heap corruptions and memory leaks (two of my least favorite tasks), it can make it nearly impossible to, say, write an anti-aliased font library that renders in a reasonable amount of time. Sure, a developer can write custom libraries in C with their NDK, but now we're debugging two languages instead of one."
Java in Android runs on the Dalvik VM, which, up to now, is a pure interpreter: No precompiler, no JIT. It relies completely on the ability to mix in libraries in C via JNIs http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/jniTOC.html and the NDK http://developer.android.com/sdk/ndk/1.6_r1/index.html.
Why? The short answer is it is hard to put a JIT compiler in a battery powered device. So the developer has to decide what code belongs in Java and what code belongs in C.
7. "Intents"
Here I am right with Haseman, since his gripe is having to write (http://www.amazon.com/Android-Essentials-Firstpress-Chris-Haseman/dp/1430210648/) about classes with names that lend themselves to drifting into being nouns. The Activity, Intent, and Service classes in Android twist up one's prose worse that quarks tha
IP multicast would not help the last-mile issue in using mobile data for TV. MediaFLO has dedicated bandwidth for nearly all the downstream payload.
MediaFLO isn't "clunky." The FLO part stands for "Forward Link Only." That means it uses a broadcast channel downstream, so it is bandwidth-efficient for one-way content delivery. It is a Qualcomm proprietary technology, but it is not inherently less good than other DTV technologies applicable to mobile devices. MediaFLO was designed for mobile devices, so it might have advantages over some DTV standards that were not designed with mobile devices in mind.
LTE and WiMAX are the main competing 4G technologies. Both LTE and WiMAX are all-IP networks. No circuits. No dedicated channels for voice. If you run voice on 4G it will be packet voice no matter the other technology choices.
One Voice is what this consortium is calling IMS for 4G. IMS uses SIP for signaling. That makes IMS more like the kind of packet voice you find in Asterisk. Except IMS includes a lot of additional standards that, among other things, enables it to replace the signaling used in circuit switched networks and still interface to those networks. Some people favor IMS because it is the officially accepted 3GPP standard for these types of networks. Other people don't like IMS because it is too complicated and includes a lot of stuff that is unlikely to be used, including stuff like using SIP to initiate Web sessions so you can charge for them. Not that anyone would accept that kind of product.
The other consortium that pushing a voice call standard for LTE is called VoLGaA Forum. VoLGA stands for "Voice over LTE General Access." It works like UMA, which is a way of extending the circuit switched mobile signaling over IP. So you can buy these UMA "femtocells" - a really small cell site - and put them in your home or office and hook them up to your Internet service to extend mobile access to those locations. VoLGA is UMA scaled up to the whole network. Pretty suave, especially for the networks that already support UMA - you can re-use a lot of the same systems.
WiMAX never flirted with UMA (as far as I know) and I think most WiMAX networks that support voice will use IMS. Which is what One Voice is promoting for LTE. So that's no disadvantage for WiMAX.
You may be thinking "If it's all packet voice, why don't I put a SIP client on my smartphone and use my company's IP PBX? Or, why don't I use a smartphone Skype app?" That's called an over-the-top service (OTT). Which is why SMS is so... "important" to this discussion: The only thing you lose by using an OTT service, is SMS.
The book does not cover code obfuscation. I have also not tried obfuscation for Android projects.
Android applications are distributed as archives -.apk files - made mostly of Dalvik bytecode files - .dex files. While you can "dump" a dex file to human readable code, I do not know of a dex to Java decompiler, nor a dex to Java bytecode reverse translator.
This thread in the Android developers group...
http://groups.google.com/group/android-developers/browse_thread/thread/dcc5808b002a47fc?tvc=2 ...includes an Ant script that the is supposed to obfuscate classes in an Android project. This script uses Proguard, which I used back when I was working on mobile games, but mainly to reduce jar file size. You can see in the discussion in that thread that there are some Android-specific issues to watch out for, such as that classes referred to in Android manifest files and the names of View subclasses used in layout files should be excluded from obfuscation.
You can also use native code libraries and JNIs for the code you are most concerned about, if compiling code to ARM instructions seems more resistant to reverse engineering than Davik byte codes.
That's not really a subject of the book. And I don't have any access to Google's decision-making on that, but one of my co-authors and I created a system that, like Android, used Java on handsets, so we explored this issue in some depth:
1. Making a good JIT is very difficult. Open source JITs, at the time we were putting a Java on ARM-based systems, provided very little performance improvement over an interpreter.
2. Other system components, like the graphics stack and garbage collector have very large impacts on performance, probably larger than the difference a JIT could make. Most interactive applications spend a lot of time drawing the screen, and a JIT won't speed that up.
3. Even if you could magically get a JIT as good as Sun's that worked on ARM, it's an open question if you want to spend CPU cycles, and therefore battery power, JIT-compiling code on a handset. You may need to design a JIT specifically for battery powered devices.
I would guess Google has the resources to explore all the alternatives: JIT, pre-compiled Java, JIT/cached, etc. and will at some point speed up Java execution. But, depending on what your app does, it might make less difference than speeding up graphics.
Alternatively, if you have something that is very compute-intensive, you can put it in a native code library compiled from C or C++, and access the library using JNIs: http://developer.android.com/sdk/ndk/1.6_r1/index.html
I am a co-author of this book. Feel free to ask me about it. If I can't answer, I'll make sure your questions get to the other co-authors and/or our editor.
Chrome OS fills a number of needs. Whether these turn out to be the needs of end-users remains to be seen, but Chrome OS is not just some industry giants engaging in a slanging match:
1. Chrome OS will help segment Atom from Pentium and Core. That's a pretty big need right there, for Intel, anyway.
2. It could fill a not-yet-filled void: There is a very good chance Chrome will end up dominating netbook Linux the way Android is on the way to dominating handset Linux. Android is a really nice system, and deserves to win versus most other mobile Linux alternatives. Android is accelerating the use of Linux in handsets. Chrome might be that much better than other netbook Linuxes that it, too, ends up dominating and expanding it's market segment.
3. OEMs have been porting Android to devices that may not be the best match for Android. Chrome OS is a better answer than diluting or de-focusing Android to make it a more universal OS.
4. It completes the strategic picture for GWT, Gears, and Chrome: Google has a multi-layered strategy to make their applications run on any OS and any browser. If GWT and Gears on IE on Windows 7 are one end of the spectrum, Chrome OS is the other end. Microsoft has an OS platform where they can integrate search and the cloud and local applications. Now Google does, too.
I would not be surprised to see an Android application runtime on Chrome OS, alongside the browser/JavaScript runtime.
X client for Chrome OS written using GWT in 3, 2, 1...
Seriously though, Chrome OS will be more hackable than a phone OS, which, in the form of Android is pretty open anyway. So even if Google intends the userland to be primarily running in the Chrome javaScript runtime environment, it seems inevitable that X and general-purpose Linux desktop apps will find their way onto Chrome OS screens.
As others have pointed out, free online services are no more susceptible to a Black Swan Competitor, or even an ordinary competitor, than any other business. If there is a distinction, it is likely to be that free Web services are especially governed by first mover advantage and category domination such that they are less in danger from Black Swans than, say, a trucking company or a chain of coffee shops.
There are several things wrong with this idea: Nobody has ever supported subsidies for a mobile device with app store sales and it is unlikley to start working in the current pricing environment in app stores. Even the most profitable carrier portals for mobile downloads are a drop in the revenue bucket for carriers. Most of the content in traditional carrier portals is "passive" - ring-tones and wallpaper. App stores for platforms like Android, Pre, and iPhone, and the corresponding developer programs, are meant to benefit the platform, not the network operator. Apple's app store has a unique position alongside the largest music retailer in North America - unless you have a plan to succeed without that advantage in place, success isn't likely. Android is in the process of replacing a lot of "Linux + proprietary UI" in mobile devices - e.g., at Motorola, they have EOL'ed their proprietary Linux-based "high feature" platforms in favor of Android, and Android has an app store. Applications in app stores have very low prices compared to retail games on handheld consoles, and the vast majority of applications - and downloads - are free. Many low-cost mobile games are shovelware copies of Web-based casual games. The packaged software industry died more than 10 years ago, except for holdouts like Adobe and AutoDesk in specialized, high-value markets, and mobile app shops are not going to revive it. So, put a shiny skin on Synaptic and call it a day. Or call it an app store.
Huawei and ZTE already play at the highest levels of the telecom industry. Perhaps in software they are not up to the level where they could make an iPhone or Android by themselves. But underestimating Chinese and Indian companies would be a mistake, especially the most prestigious ones who have their pick of elite university graduates. This change happened within the last 10 years. It may take another 5 or 10 years for Asian software developers to make a breakthrough Web application but do not count them out.
Run of the mill IT outsourcing at second and third-tier firms (or even first-tier firms that grew too fast) is another matter. This is where the horror stories come from, and, often, the people managing these outsourced resources are doing it because they ran out of onshore yes-men.
Google adopted a unique graphics stack, unique IPC, a little-used libc, etc., installed a Java-based managed language system with unique UI classes, replaced the whole suite of UI applications, and sold a million Androids and will sell millions more on the 18 more handsets due this year. Contrast that with the incremental approach taken by Nokia in the 8XX devices with GTK-based Hildon. Or, contrast with Microsoft's approach of not getting rid of C++ as a language for the userland of Windows Mobile once they put C# and NETCF on it. Microsoft could have had an system very like Android 6 or 7 years ahead. They didn't innovate enough.
What that shows is that the desktop Linux userland is still in such an embryonic state that all prior approaches can, still, be replaced by something better. Android applications will likely be able to run on Linux desktops, soon, and some "smartbook" form-factor devices will run the Android UI as the sytem's principal UI framework.
Palm Pre innovates enough. Android innovates enough. There is a lot to be said for incrementally polishing and evolving the Linux desktop, but it hardly innovates too much.
What, you aren't MoVlogTweetStreaming yet? Are you, like, old?
The average of revenues for applications in the iPhone app store might be less than $3000 but this is somewhat misleading. Like any publishing market there are a few winners and many, many also-rans. If you calculated what the average book out of Amazon's 3.5 million books took in, you might conclude you can't make any money at all publishing books. But even a specialized tech book on a current topic is going to rank in the 20,000-40,000 range in sales rank, and that is in the top 2%. There is a lot of obscure stuff that got printed at some time or another that really can't be considered part of the market that real publishing companies participate in.
So, if you put a truly professional effort into a product, you can reasonably expect results that are way above the average, and that seems to be borne out by the tennis application mentioned in the article: It made several times the average. But, due to low prices, that amounts to only a few tens of thousands of dollars over the product lifespan.
The price erosion in the iPhone app store is going to be a real worry to real game publishers. If you can't sell a game for $19.99 you won't get quality studio-produced games, except as an experiment in the market. Good or bad, it sure is different from the DS. At those pricing levels, the number of financial winners will be very small, and since price erosion is hard to undo, new revenue sources will have to be found in order to change the fact that only a very small number of products will make revenue in the hundreds of thousands of dollars.
Mobile handsets, because they are resource constrained, will be the first to implement this simplification:
The OS runs the hardware
There is a small non-application userland with utilities, daemons, etc.
The part of the userland the user uses is implemented using a JavaScript managed language runtime, with enough local access to enable offline operation for applications unrelated to communication.
Not only is the application structure and lifecycle unique and structured around a unique UI flow, Android has unique UI classes in an otherwise mostly standard Java runtime, it uses binder for inter-process communication, it has a unique graphics stack relative to most other Linux systems, and it makes it difficult to put programs other than those written to the Android programming model on the screen, among other differences relative to most Linux-based systems.
But it has already overtaken the Nokia 8xx Web pads, which use Hildon, in user acceptance. Google gambled on establishing an entirely different application layer in the userland for Android and appears to have succeeded.
Android answers the question: "What if Linux had a userland based on a managed language runtime and every application used the same UI classes (and what if a company with sufficient resourced to do it right did it)?"
If Android perplexes you, try this:
http://www.amazon.com/Android-Application-Development-Programming-Google/dp/0596521472
It is perfectly fair for a government letting a contract to limit that contract to entities that are not suing it. That's like an arbitration clause in a contract.
One very serious point to being "free" is that, if you are serious about security, you want as much of your software to be available for security audit as possible.
Another serious point to being "free" is reliability. Linux is reliable because it is open. Dilute the openness, and the reliability gets watered down, too.
I was a consultant at Lotus at the time Microsoft started winning in desktop applications.
Bill Gates is essentially correct:
1. Lotus did a much worse job of hiring in professional management and bridging the gap between software development and business.
2. Lotus complicated their tools-set and architecture unnecessarily. This is one factor that killed 1-2-3. Lotus went straight from assembly code speedy to bloated and slow. Ironically, as this was happening, Jon Sachs wrote 1-2-3 C, a simple, fast, and very portable reference implementation.
3. Lotus did a bad job with follow up products. Instead of launching and improving, they would launch, get disappointed, give up, do something else. Or, in the case of 1-2-3, they would overcomplicate. They had very innovative products - ones that could have changed spreadsheets in fundamental ways, and that would still be innovative today. But they did not know how to nurture these products.
Microsoft faces a lot of the same problems now. Microsoft can't seem to make regular incremental improvements to key products, for example. But business isn't about being perfect. It is about being less bad than the other guy.
The U.S. Constitution is written from the point of view of protecting natural rights from government predation.
Copyright is different. It is a created "right." Really, it is more like a "deal" than a right: It is a limited term grant of exclusivity. No real right works that way, and no other right is explicitly created - they are assumed to exist with or without the acknowledgment of the government.
Therefore you do not need to be an "anarcho"-anything to reconsider copyright. The Founders themselves considered it less than a right.
Copyright isn't even a contract. It is a kind of charter that can be revoked or modified at the whim of the granting party. So reducing a copyright term isn't even a "taking."
Copyright was created by the government to benefit the people. If it stops working that way, copyright has no purpose.
Hence "Hellenic." Ha ha?