Good Morning

howdy, Calvin!

What would you recommend as the best way to package 200MB of MP3 files with my Android app?

ship it preinstalled on a phone

beyond that, users will attack you with pitchforks

it flat out won't install on many Android devices

and, if you turn on Android Market copy protection, few if any Android devices will install it

that amount of MP3 data needs to be on "external storage" (SD card)

Is there a way to secure it on SD Card? I need to protect it from getting into others hands...copyrighted material.

No, sorry

bear in mind that everything is copyrighted (at least in the US, at least since 1976)

Is there a way to compress and uncompress files using the Android API?

java.util.zip for ZIP files

GZIP is in there too

based on what you're telling me, I may have a showstopper for my app

I'm trying to port a language app from iPhone to Android

the iPhone package compresses the 200MB MP3 into a 40MB footprint

that doesn't sound possible

MP3 is already compressed

and the iPhone sdk handles the uncompression of the MP3 files when they need to be played

there's no way you can get a 5x compression of MP3 data

howdy, Jake!

Hey

i just subscribed so I was curious to see what this was about

I haven't dug into the details and just going on what I've heard from my colleague

Calvin: Android device manufacturers have not offered much on-board flash, unlike Apple with iPhone

anyways, ill see u giys later... i first to have learn a bit about Android dev before I can ask any questions... ttyl

data sets either need to be small or publicly accessible

I can tell that I zipped the 200MB MP3's into 40MB zip files, so there is some compression

there's something messed up in the MP3 creation, then

try that with regular music files sometime

so u are saying the MP3's I have may not be compressed?

I just compressed a music MP3 file and got 1% compression, not 80%

I see

I can't see how your files can be compressed

so, I'd double-check your MP3 files to start with

if you can get them down to 40MB, that would certainly help

it took a lot of time to record those MP3's so my colleague may be unhappy to hear if there is anything wrong with them

frankly, it feels like they're not MP3s at all, but WAV files

so, there may be nothing strictly "wrong" with them, other than being really high quality

are you familiar with the iPhone SDK feature my friend described? in the IPhone version, the MP3's are compressed on the phone and when the app plays the MP3, it uncompresses it....does Android have anything similar?

As I have been saying, MP3 files are compressed. Android will decode compressed MP3 files. Android will not automatically decode MP3 files that have been ZIPped or GZipped.

Since having MP3 files be ZIPped or GZipped is usually not necessary, they didn't build in that feature

I see

However, even if you got them to be 40MB in MP3 format, that's still plenty big

because there's only 70MB for apps on the phone?

that's the G1

for example, the Nexus One has ~200MB of on-board flash for all applications

the HTC Evo 4G (most advanced Android phone on the market) has around 512MB

how about a Droid

ummm...hold on a minute

while I wait for my DROID to warm up, note that a regular Android application requires twice its size for installation

thanks! so my options are to get the MP3's down to the smallest size to fit on the phone or to wait until Android 2.2 and use it's install app on the SD card feature?

so, a 40MB APK needs 80MB free space for installation, after which it takes up 40MB

yes, Android 2.2 and apps-on-SD may help here

BTW, DROID has around 320MB

great thanks!

Does Android Market handle license codes or do you have to develop your own code for that?

How do you intend to use "license codes"?

BTW, apps-on-SD definitely stores its data encrypted on the SD card

sweet

use license code to stop piracy and make sure a paying user is installing app

the Android Market does not have any form of license codes that you manage yourself

so long as you are not charging for those license codes, you are welcome to develop your own system

How does the Market work now? What happens when a user buys my app? Do they need to type in a code?

No, they just pay for it

They are charged before it is downloaded

I see

They have either 24 or 48 hours to evaluate your app (I forget) and, if they wish, can uninstall it and get a refund

now, you are welcome to sell your app outside of the Market

you mentioned that apps-on-SD definitely stores its data encrypted on the SD card, but before Android 2.2, there is no API to encrypt and decrypt data, right?

no, there are encryption APIs

what package is that?

javax.crypto

however, bear in mind that if your key is in your APK, then somebody sufficiently determined will be able to decrypt your data

they may be able to do that for the apps-on-SD too -- only time will tell there

howdy, Mike!

Hi mark.

Thanks Mark....great answers!

you're welcome

Mike: did you have a question"?

Yes, just writing it up now.

Oooo...sounds long. :-)

Not too bad. Just want to make sure I have it right.

Ok,so calling the "Intent.ACTION_SEND" in one of our Activities to use an email client. Works fine in 2.0.1 but gets the message "No Application can perform this action" in 1.5 and 1.6. Any idea??

on devices or in the emulator?

Looks like it works if the mime type is set to "text/plain" but hen it doesn't pick up an attachment we're trying to send.

On the emulator.

I haven't tried attachments

are you using EXTRA_STREAM?

and do you have a configured email account?

yes for the attachment and yes.

and you're specifying an email address? or just a plain ACTION_SEND?

We don't specify and "to" email address so just ACTION_SEND.

well, you've exhausted all my possible suggestions

again, I haven't played with attachments and ACTION_SEND

What we were doing is setting the mime type to "application/zip", which works in all version higher than 1.6.

the attachment is a ZIP file?

Yes.

where is the ZIP file stored?

on the sd card.

according to that question, attaching image/jpeg worked in August of last year, which would have been 1.5

oh, sorry, image/jpg

so, it may be peculiar to ZIP files and 1.5

Ok, we'll throw that in and try.

Ok, well that actually seems like it works. Weird!

bear in mind that apps have to declare what MIME types they support in their <intnet-filter>

arbitrary MIME types won't work

in 1.6, they presumably added application/zip to their filter

Ah!

Well, looks like we have a way to make it work. Thanks again!

no problem

Mark, thanks again for the help. Jumping off now. Have a good holiday.

thanks, you too!

Keep up the good work and have a good weekend!

thanks! likewise!