<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Android Storage</title>
	<atom:link href="http://stuffthathappens.com/blog/2009/11/09/android-storage/feed/" rel="self" type="application/rss+xml" />
	<link>http://stuffthathappens.com/blog/2009/11/09/android-storage/</link>
	<description>Technology and Geek Stuff by Eric Burke</description>
	<lastBuildDate>Sat, 27 Feb 2010 14:52:46 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: architek mobile development</title>
		<link>http://stuffthathappens.com/blog/2009/11/09/android-storage/comment-page-1/#comment-50148</link>
		<dc:creator>architek mobile development</dc:creator>
		<pubDate>Sat, 28 Nov 2009 10:42:30 +0000</pubDate>
		<guid isPermaLink="false">http://stuffthathappens.com/blog/?p=1575#comment-50148</guid>
		<description>I agree with Dennis. The success of the iPhone is not just about the brilliant hardware its all about the user experience. 

Downloading the data for a large app separately opens up a huge can of worms.Not only is there the extra development overhead, and complexity of protecting against the kind of errors mentioned by Dennis, bu but there is the complexity of doing this on a variety of hardware platforms which may have different capabilities and performance characteristics for the storage functionality.   
 
I&#039;m currently working on an android app that uses embedded video clips, the 200Mb limit (remember this is for ALL programs not just mine) is a serious problem and may call the whole idea into question. 


This is a massive can of worms. The app needs to be used offline. So it looks difficult to build on Android at this point.</description>
		<content:encoded><![CDATA[<p>I agree with Dennis. The success of the iPhone is not just about the brilliant hardware its all about the user experience. </p>
<p>Downloading the data for a large app separately opens up a huge can of worms.Not only is there the extra development overhead, and complexity of protecting against the kind of errors mentioned by Dennis, bu but there is the complexity of doing this on a variety of hardware platforms which may have different capabilities and performance characteristics for the storage functionality.   </p>
<p>I&#8217;m currently working on an android app that uses embedded video clips, the 200Mb limit (remember this is for ALL programs not just mine) is a serious problem and may call the whole idea into question. </p>
<p>This is a massive can of worms. The app needs to be used offline. So it looks difficult to build on Android at this point.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Atlanta Printing Company</title>
		<link>http://stuffthathappens.com/blog/2009/11/09/android-storage/comment-page-1/#comment-50025</link>
		<dc:creator>Atlanta Printing Company</dc:creator>
		<pubDate>Thu, 19 Nov 2009 11:55:10 +0000</pubDate>
		<guid isPermaLink="false">http://stuffthathappens.com/blog/?p=1575#comment-50025</guid>
		<description>I think those phones cost too much anyways. Droid is now the poster boy for Android, and it&#039;s sales are being regarded as a volley in the Android vs. iphone war.</description>
		<content:encoded><![CDATA[<p>I think those phones cost too much anyways. Droid is now the poster boy for Android, and it&#8217;s sales are being regarded as a volley in the Android vs. iphone war.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dennis</title>
		<link>http://stuffthathappens.com/blog/2009/11/09/android-storage/comment-page-1/#comment-50009</link>
		<dc:creator>Dennis</dc:creator>
		<pubDate>Wed, 11 Nov 2009 00:54:58 +0000</pubDate>
		<guid isPermaLink="false">http://stuffthathappens.com/blog/?p=1575#comment-50009</guid>
		<description>@Cooper -

Sure you can work around this on Android, but think about it from a usabilty standpoint. The memory card can be removed at any time. Now your app has to worry about if it&#039;s assets are actually available. iPhone developers never worry about that generally. If the app is installed on the phone, so are the assets. 

Sure, android could say if the memory card with the app assets isn&#039;t available, then you can&#039;t run the app. But then that leaves the issue of what happens when a user pops the memory card in the PC, sees 800MB of files, and then removes some of them?  Now the app has to deal with a partial installation. Other phones treat the application as a single unit as far as the user is concerned - even if the app is made up of hundreds of files internally. But by placing assets on the SD card and the app on the phone memory, there is no longer a single entity for the app. 

I&#039;m pretty sure this is part of the reason Apple hasn&#039;t added any memory card slot to the iPhone. There are others as well, but UX in this area is easy to screw up. A lot of what ifs that can easily go away if you just put a ton of memory in the device and call it done.</description>
		<content:encoded><![CDATA[<p>@Cooper -</p>
<p>Sure you can work around this on Android, but think about it from a usabilty standpoint. The memory card can be removed at any time. Now your app has to worry about if it&#8217;s assets are actually available. iPhone developers never worry about that generally. If the app is installed on the phone, so are the assets. </p>
<p>Sure, android could say if the memory card with the app assets isn&#8217;t available, then you can&#8217;t run the app. But then that leaves the issue of what happens when a user pops the memory card in the PC, sees 800MB of files, and then removes some of them?  Now the app has to deal with a partial installation. Other phones treat the application as a single unit as far as the user is concerned &#8211; even if the app is made up of hundreds of files internally. But by placing assets on the SD card and the app on the phone memory, there is no longer a single entity for the app. </p>
<p>I&#8217;m pretty sure this is part of the reason Apple hasn&#8217;t added any memory card slot to the iPhone. There are others as well, but UX in this area is easy to screw up. A lot of what ifs that can easily go away if you just put a ton of memory in the device and call it done.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cooper</title>
		<link>http://stuffthathappens.com/blog/2009/11/09/android-storage/comment-page-1/#comment-50002</link>
		<dc:creator>Cooper</dc:creator>
		<pubDate>Tue, 10 Nov 2009 16:20:21 +0000</pubDate>
		<guid isPermaLink="false">http://stuffthathappens.com/blog/?p=1575#comment-50002</guid>
		<description>I think one thing that gets overlooked in this discussion is the only option for data storage on the iPhone is *inside the app space*. Android apps have a whole SD card they can place assets on that are outside the 256MB. People mention Myst on the iPhone is 800MB. Sure, but I doubt there is 800MB of *code* there. It is maybe a few hundred K of code and a TON of video, audio and image assets, and there is not reason those assets can&#039;t be installed on the SD card of a current android phone.</description>
		<content:encoded><![CDATA[<p>I think one thing that gets overlooked in this discussion is the only option for data storage on the iPhone is *inside the app space*. Android apps have a whole SD card they can place assets on that are outside the 256MB. People mention Myst on the iPhone is 800MB. Sure, but I doubt there is 800MB of *code* there. It is maybe a few hundred K of code and a TON of video, audio and image assets, and there is not reason those assets can&#8217;t be installed on the SD card of a current android phone.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Dill</title>
		<link>http://stuffthathappens.com/blog/2009/11/09/android-storage/comment-page-1/#comment-50001</link>
		<dc:creator>Kevin Dill</dc:creator>
		<pubDate>Tue, 10 Nov 2009 15:38:02 +0000</pubDate>
		<guid isPermaLink="false">http://stuffthathappens.com/blog/?p=1575#comment-50001</guid>
		<description>Before the Android came out we saw this would be a major issue.  A powerful multimedia computer in the hand with no reasonable storage space.  That&#039;s why we created Android Storage.  I think the bottom line is companies are cutting costs vs. considering what the consumer wants, which is more storage on the phone.  It makes no sense that there is such limited storage on these smartphones when the masses will/are eventually using them more than the PC. That&#039;s why Dell and HP are getting into the smartphone business.  
If they don&#039;t improve the storage space on the phone, we hope to develop even better technologies for remote storage married to mobile apps.  With 4G coming, it will be an even better option to realize that.</description>
		<content:encoded><![CDATA[<p>Before the Android came out we saw this would be a major issue.  A powerful multimedia computer in the hand with no reasonable storage space.  That&#8217;s why we created Android Storage.  I think the bottom line is companies are cutting costs vs. considering what the consumer wants, which is more storage on the phone.  It makes no sense that there is such limited storage on these smartphones when the masses will/are eventually using them more than the PC. That&#8217;s why Dell and HP are getting into the smartphone business.<br />
If they don&#8217;t improve the storage space on the phone, we hope to develop even better technologies for remote storage married to mobile apps.  With 4G coming, it will be an even better option to realize that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cell phone review</title>
		<link>http://stuffthathappens.com/blog/2009/11/09/android-storage/comment-page-1/#comment-49995</link>
		<dc:creator>Cell phone review</dc:creator>
		<pubDate>Tue, 10 Nov 2009 07:26:31 +0000</pubDate>
		<guid isPermaLink="false">http://stuffthathappens.com/blog/?p=1575#comment-49995</guid>
		<description>Only 256MB of room for apps is a major showstopper.
The onscreen keyboard is almost as bad as the physical.
Multimedia is awful on the Droid.</description>
		<content:encoded><![CDATA[<p>Only 256MB of room for apps is a major showstopper.<br />
The onscreen keyboard is almost as bad as the physical.<br />
Multimedia is awful on the Droid.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dennis</title>
		<link>http://stuffthathappens.com/blog/2009/11/09/android-storage/comment-page-1/#comment-49992</link>
		<dc:creator>Dennis</dc:creator>
		<pubDate>Tue, 10 Nov 2009 04:14:39 +0000</pubDate>
		<guid isPermaLink="false">http://stuffthathappens.com/blog/?p=1575#comment-49992</guid>
		<description>&quot;The solution is easy. Make your app small and download textures and graphics separately to the SD card.&quot;

Doesn&#039;t this mean that now you are potentially distributing 2 required parts of your app through different sources (Marketplace and some web server)?  Seems less than ideal - now you have two things that could break, you have to worry about the user modifying/moving/removing your content off the SD card, the possibility of the SD card either not being there or full, and keeping things in sync for multiple versions potentially. 

Contrast to the App Store model on the iPhone where everything is distributed together and stored in a single file when stored in iTunes. 

Google definitely needs to address this. I&#039;m sure that things like the card being removed and insuring app integrity are just a few of the issues that they need to figure out how to do correctly. But until then, the handset makers need to be putting at least a GB of app space on these devices. Ideally more.</description>
		<content:encoded><![CDATA[<p>&#8220;The solution is easy. Make your app small and download textures and graphics separately to the SD card.&#8221;</p>
<p>Doesn&#8217;t this mean that now you are potentially distributing 2 required parts of your app through different sources (Marketplace and some web server)?  Seems less than ideal &#8211; now you have two things that could break, you have to worry about the user modifying/moving/removing your content off the SD card, the possibility of the SD card either not being there or full, and keeping things in sync for multiple versions potentially. </p>
<p>Contrast to the App Store model on the iPhone where everything is distributed together and stored in a single file when stored in iTunes. </p>
<p>Google definitely needs to address this. I&#8217;m sure that things like the card being removed and insuring app integrity are just a few of the issues that they need to figure out how to do correctly. But until then, the handset makers need to be putting at least a GB of app space on these devices. Ideally more.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eric Burke</title>
		<link>http://stuffthathappens.com/blog/2009/11/09/android-storage/comment-page-1/#comment-49987</link>
		<dc:creator>Eric Burke</dc:creator>
		<pubDate>Tue, 10 Nov 2009 02:07:05 +0000</pubDate>
		<guid isPermaLink="false">http://stuffthathappens.com/blog/?p=1575#comment-49987</guid>
		<description>I&#039;ll comment on my own post first. The Cyanogen Mod does allow app installation to an SD card. The procedure requires formatting and some ability to follow (sometimes cryptic) instructions, but it is technically possible. The instructions I read included all sorts of warnings about data loss, damaging your SD card, or even bricking the phone. If Google were to support this some day, their solution would have to be far easier and more robust.</description>
		<content:encoded><![CDATA[<p>I&#8217;ll comment on my own post first. The Cyanogen Mod does allow app installation to an SD card. The procedure requires formatting and some ability to follow (sometimes cryptic) instructions, but it is technically possible. The instructions I read included all sorts of warnings about data loss, damaging your SD card, or even bricking the phone. If Google were to support this some day, their solution would have to be far easier and more robust.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.275 seconds -->
