<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Continuations - Latest Comments in Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.disqus.com/</link><description></description><atom:link href="https://continuations.disqus.com/mobile_app_development_android039s_missed_opportunity/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Wed, 08 Jul 2009 11:20:40 -0000</lastBuildDate><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12314195</link><description>&lt;p&gt;Yep. The issue then becomes - access to what? and how do you design the user control mechanism. It's all doable - someone just has to figure it. &lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Peter Cranstone</dc:creator><pubDate>Wed, 08 Jul 2009 11:20:40 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12306389</link><description>&lt;p&gt;Agree that privacy and trust are critical here.  Seems to me though that Google could have opened up the browser and still had exactly the same kind of one time or forever approval dialogs on a per domain basis.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">albert</dc:creator><pubDate>Wed, 08 Jul 2009 06:58:10 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12298693</link><description>&lt;p&gt;One word... "Privacy".&lt;/p&gt;&lt;p&gt;(Full disclosure here... we're just getting ready to release a free mobile app for BB and WM that allows you to extend web services to mobile and access any device side capability and then share that with the web service. )&lt;/p&gt;&lt;p&gt;It's taken a lot of time to design the right privacy controls while allowing the customer the flexibility to share data with a single click or not.&lt;/p&gt;&lt;p&gt;The only way we could figure out how to do was to extend the native browser to support a new "tab" (if you like) In there you have access to control the meta data you want to share with the web service. These fields include location (GPS, Cell Tower ID) Device capability and also user information (preferences, keywords etc). All this is customizable and can be extended.&lt;/p&gt;&lt;p&gt;If Google was to suddenly open up their Android browser to allow JavaScript to get access OUTSIDE the sandbox you can just imagine what could happen to the customer experience. The mobile user has to be in control of his/her privacy for this to succeed. Basically it all boils down to Trust. If you trust the web service (whitelist) then share my data - if not then if should not be accessible.&lt;/p&gt;&lt;p&gt;Currently HTML5 and or JavaScript to not support this level of granularity. So you have to do it a different way. Our approach was to simply extend the HTTP protocol to include additional meta data (RFC 2616 says that this is permissible). Then all you have to do at the server side is read the incoming data.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Peter Cranstone</dc:creator><pubDate>Tue, 07 Jul 2009 23:37:44 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12298399</link><description>&lt;p&gt;PhoneGap is actually a little limited (see their matrix) in what they allow you to access.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Peter Cranstone</dc:creator><pubDate>Tue, 07 Jul 2009 23:25:14 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12091600</link><description>&lt;p&gt;Interesting post. In think that the API access to some of the phone services are only half of the problem (the easy half). The harder side of building web application is the performance and memory footprint of HTML and Javascript on the browser (and this is despite Apple exposing some hardware accelerated transformations through CSS). If you look at some of the best iphone apps (facebook, tweetie, etc..) you will notice that they take advantage of the native capabilities to do some very advance caching and rendering. That is the only way you can deliver great experiences to the phone today. You are going to need a couple of additional hardware+memory upgrades on the iphone to have a viable web as a platform story and apple is as well positioned as anyone else to drive that transition (complete HTML 5 support + great CSS tricks). Between now and then, we are prisoner of Objective C and Cocoa!&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Edwin Khodabakchian</dc:creator><pubDate>Fri, 03 Jul 2009 17:57:01 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12062878</link><description>&lt;p&gt;hopefully android can avoid that.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">andrej</dc:creator><pubDate>Fri, 03 Jul 2009 01:37:39 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12057022</link><description>&lt;p&gt;I love feedback. We are still so early in development and planning, we can use all the feedback we can get. If you have any thoughts or comments, please email me: elia at infinitysw dot com.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Elia Freedman</dc:creator><pubDate>Thu, 02 Jul 2009 22:17:25 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12038790</link><description>&lt;p&gt;Sounds interesting - will check it out!&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">albert</dc:creator><pubDate>Thu, 02 Jul 2009 13:09:30 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12032878</link><description>&lt;p&gt;Thanks for asking, Albert. We are developing FastFigures, an application for capturing and analyzing data. Any of our customers can create a template or use an off-the-shelf one, save data and sync it to our web app for more detailed analysis. Spreadsheets were an amazingly powerful tool for desktop systems. They allowed anyone, with or without programming experience, to write an application for analyzing data. But this form factor is horrible on mobile. FastFigures will do this for mobile and web.&lt;/p&gt;&lt;p&gt;We are still pretty early, releasing in stages. Our first FastFigures versions are on iPhone. Over the next few months we will be adding customization, filling out the web capabilities and adding data sync to the cloud. You can check it out in it's alpha/beta form at &lt;a href="http://www.fastfigures.com" rel="nofollow noopener" target="_blank" title="www.fastfigures.com"&gt;www.fastfigures.com&lt;/a&gt;. The first iPhone version is available at &lt;a href="http://www.fastfigures.com/apple" rel="nofollow noopener" target="_blank" title="www.fastfigures.com/apple"&gt;www.fastfigures.com/apple&lt;/a&gt;.&lt;/p&gt;&lt;p&gt;I've been hovering around this business opportunity for the past 12 years, as I started writing mobile software for the Pilot 1000/5000 in 1997. When Palm OS was king, we distributed over 15 million software products, had partnerships with leading providers in tech, industry and education, and almost had a break-out success in 6-12 math education.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Elia Freedman</dc:creator><pubDate>Thu, 02 Jul 2009 10:52:59 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12026000</link><description>&lt;p&gt;It is not necessary for the others to disappear but just to be fragmented enough that developers don't bother writing for them.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">albert</dc:creator><pubDate>Thu, 02 Jul 2009 06:43:08 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12025435</link><description>&lt;p&gt;I don't think they will become the defacto standards. This would be that all other mobile phone manufacturers would disappear. What are sony-ericsson, nokia, thc, samsung, motorolla, and all the other going to do?&lt;br&gt;I think the iphone is only going to become a standard if apple is going to license it's operating system.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">andrej</dc:creator><pubDate>Thu, 02 Jul 2009 05:46:40 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12025390</link><description>&lt;p&gt;html5 has a feature to cache web resources, so you can start your web application without a network connection. This is currently supported in safari, i think in firefox, and also through google gears.&lt;/p&gt;&lt;p&gt;Also the html 5 widget specification (implemented slightly differently on nokia) allows you to download and install html applications, as if they were native applications.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">andrej</dc:creator><pubDate>Thu, 02 Jul 2009 05:42:42 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12012887</link><description>&lt;p&gt;Great posts -- really enjoyed reading them.  Completely agree on the huge value of the payment and actions for a large number of consumers.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">albert</dc:creator><pubDate>Wed, 01 Jul 2009 20:58:14 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12012814</link><description>&lt;p&gt;Customer trust is an interesting angle that I had not considered.  What was the app?&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">albert</dc:creator><pubDate>Wed, 01 Jul 2009 20:54:21 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12012752</link><description>&lt;p&gt;That's what I am hoping to see.  Agree that iPhone browser was complete breakthrough.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">albert</dc:creator><pubDate>Wed, 01 Jul 2009 20:52:13 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12012627</link><description>&lt;p&gt;Great post. I think the browser on mobile devices is playing a much more pivotal role than anyone had imagined and mobile devices are slowly seeing this, hate to sound like an Apple fanboy but Steve Jobs envisioned this from the initial launch of the iPhone and they are slowly adding more access to more things in later releases.&lt;/p&gt;&lt;p&gt;If Android capitilises on this and allows for native like access to the file system through the browser the others will be scrambling to play catchup and this can only mean good things for developers and users.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan</dc:creator><pubDate>Wed, 01 Jul 2009 20:46:21 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12012276</link><description>&lt;p&gt;I appreciate all the technical comments here but the reality is that customers don't trust web-based applications on the device. I tried -- believe me. I developed our latest app as a web-based one and got un-ending flack for it. Our customers insisted on native. They don't trust the connection, let alone it's speed.&lt;/p&gt;&lt;p&gt;This could be overcome if the mobile platform considers the "server side", say a Ruby on Rails runtime. Then it could support HTML/CSS/JS on the front end while providing the back-end support required to run sophisticated apps. Palm's closest but they are missing any semblance of "server side".&lt;/p&gt;&lt;p&gt;And even when we get all the technical details, there's still a mentality that needs to be overcome. Most mobile developers are too small to battle this perception problem of "everything in the browser needs an Internet connection." It's a fight that has to be done by Google or Palm or RIM.&lt;/p&gt;&lt;p&gt;I will promote one very relevant post here. I wrote about how to beat Apple at their own game in August 2008. Included was a discussion of web app development that would work wonderfully. It's here: &lt;a href="http://bit.ly/17uUR3" rel="nofollow noopener" target="_blank" title="http://bit.ly/17uUR3"&gt;http://bit.ly/17uUR3&lt;/a&gt;. No one has done it yet but the one who does can be the major player.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Elia Freedman</dc:creator><pubDate>Wed, 01 Jul 2009 20:29:25 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12010026</link><description>&lt;p&gt;I completely agree that Android should have focused on the web browser as the mobile app platform of choice. Would have fit very nicely with Google's existing emphasis as the web as the most important platform. Palm with their WebOS seems to be making this their bet to an extent, as they are allowing app development in HTML/CSS/Javascript.&lt;/p&gt;&lt;p&gt;I wrote my thoughts recently on how I think the Palm approach of using existing technologies instead of re-inventing a new platform and libraries to be used like all the other native app platforms:&lt;/p&gt;&lt;p&gt;&lt;a href="http://www.sachinrekhi.com/blog/2009/01/12/palm-gets-it-right-with-mojo" rel="nofollow noopener" target="_blank" title="http://www.sachinrekhi.com/blog/2009/01/12/palm-gets-it-right-with-mojo"&gt;http://www.sachinrekhi.com/...&lt;/a&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Sachin Rekhi</dc:creator><pubDate>Wed, 01 Jul 2009 19:29:35 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12009984</link><description>&lt;p&gt;RIMM's market cap is ~40BN, and Palm is around 2. RIMM has about $1.3BN in cash as well.&lt;/p&gt;&lt;p&gt;That said, I don't think the acquisition makes a lot of sense. RIM needs to improve their browser and app platform, not get a new set of devices (that they'd throw away) to manage that run a number of different operating systems (that they don't want).&lt;/p&gt;&lt;p&gt;If RIM got itself away from just Java as the OS, moved to WebKit as a browser, and acquired a small team w/ WebKit experience, they could build a WebOS competitor for a whole lot less, and get it done without having all the overhead of a full-on acquisition and product integration.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">suthakamal</dc:creator><pubDate>Wed, 01 Jul 2009 19:27:38 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12009828</link><description>&lt;p&gt;That does sound like there would be a lot of work to get folks to actually adopt.  So maybe RIM buying Palm as another comment suggested is a possibility - although I have not checked the respective market caps.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">albert</dc:creator><pubDate>Wed, 01 Jul 2009 19:20:21 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12009708</link><description>&lt;p&gt;So I was looking at building a startup to effectively build the browser-based infrastructure that would allow deep, native hooks into the OS for web apps. We thought about a few major components:&lt;br&gt;- push messaging (for efficient network use, and background tasks)&lt;br&gt;- native access (i.e. making native device capabilities available to JavaScript through the DOM)&lt;br&gt;- Native-code runtime (i.e. something like the Silverlight CLR to let apps break free from the requirement to use JavaScript, and the performance issues that come with it)&lt;/p&gt;&lt;p&gt;Ultimately, much of the technology to do this already exists... Though, the actual go-to-market is the tricky bit... i.e. you could build such a plugin and get it out for Windows Mobile and Symbian devices. It would then require either a re-write in Java (a huge undertaking) to get it to work on BlackBerry. Then, you'd either have another Java variant for Android, or take the original, native codebase, and donate an open-source version to the Android alliance, and hope that it made it into the main branch that everyone adopts.&lt;/p&gt;&lt;p&gt;As far as an alliance... maybe... I think Palm's WebOS and Mojo approach is a good one, and actually, alliance or not, guys like RIM ought to seriously look at implementing chunks of Mojo (forget standards, just embrace the de-facto standards that other people have shipped).&lt;/p&gt;&lt;p&gt;Another approach might be for Google to take the already open-sourced Dalvik JVM, and Chrome Lite browser, wrap them as an Android-independent chunk of code and help the other OEM's just integrate that into their platforms... Come to think of it, that wouldn't be a terrible starting point for a startup either... :)&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">suthakamal</dc:creator><pubDate>Wed, 01 Jul 2009 19:14:50 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12009477</link><description>&lt;p&gt;That's a good point.  They are sort of in a tough place between pushing Gears and supporting but waiting for the HTML5 standard.  What will be interesting to see is if some coalition will emerge that has everyone except Apple or if the other players will fight among themselves.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">albert</dc:creator><pubDate>Wed, 01 Jul 2009 19:03:19 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-12000852</link><description>&lt;p&gt;So there're a handful of reasons... the first is that JavaScript interpreters are still slow. They're getting a whole lot faster, but writing complex application logic in JavaScript is still quite slow for many platforms... work needs to be done here before the web becomes a first-class mobile app platform.&lt;/p&gt;&lt;p&gt;The second is that Google's strategy seems to be mixed between HTML5 and Gears: Gears was initially going to provide a lot of the deeper hooks into the OS that a web app would need. Gears let's Google skip all the delays associated with standards bodies, but it relies on platforms that'll let Gears plugins work, and so far that's been hugely limited (i.e. Windows Mobile, and of course Android), so it's been a far-from pervasive way to get additional capabilities.&lt;/p&gt;&lt;p&gt;Ultimately, HTML5 is making great progress... but waiting for standards bodies up-front is a pretty great way to waste time and kill innovation... and that seems to be what's happening in mobile at the moment.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">suthakamal</dc:creator><pubDate>Wed, 01 Jul 2009 18:51:14 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-11998273</link><description>&lt;p&gt;I like the idea of webOS and android on blackberry&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">fredwilson</dc:creator><pubDate>Wed, 01 Jul 2009 18:08:21 -0000</pubDate></item><item><title>Re: Mobile (App) Development: Android&amp;#039;s Missed Opportunity?</title><link>http://continuations.com/post/133482897#comment-11998245</link><description>&lt;p&gt;I think you're on the right track here - i.e. that an open platform will be necessary to compete with the iPhone closed ecosystem, particularly for apps development and sales.&lt;/p&gt;&lt;p&gt;But it's important to remember that the mobile landscape is quite different from the one PCs ever faced. There are a lot of very entrenched handset manufacturers who desperately want to keep control over their hardware and thus hardware margins. You have the OS developers who are much more scattered and diverse than PC OS developers ever were. You have the mobile network operators who are usually huge companies that move extremely slowly and are also very protectionist. Finally, you have confused consumers which can essentially be broken up into two main groups - those that use non-voice features and those that don't.&lt;/p&gt;&lt;p&gt;This ecosystem is quite complex so developers can't just pick a standard and run with it. A collective agreement is usually needed for major change.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Vladimir Vukicevic</dc:creator><pubDate>Wed, 01 Jul 2009 18:07:09 -0000</pubDate></item></channel></rss>