Supplementary Files

[Greg_G]

I've been reading through some posts on this subject, but I feel I'm
still not certain about how best to submit my application. In my
case, I only have a single .APK. However, I need to include a
mksdcard image containing files necessary for the demonstration of my
application. In order to fully show off the application's features
the file is currently looking somewhat large, about 80MB. I'm trying
to make this as painless as possible for the judges (for obvious
reasons) while fully showcasing the app.

(a) Will my application be rejected because of this need? If my
current test image is too large, what would be a recommended ceiling
for which I should aim?

(b) How should I submit it? I know we can submit one APK and one
"Notes, documentation or README file". Should I ZIP up the image
along with the former or the latter? Or would it be preferable for me
to include an external link on my website pointed to by the
documentation? Previous posts suggest the ZIP file approach but
didn't specify - that I saw - which of the two "slots" to which I
should attach it in the form.

(c) Additionally, I am using a single LGPLed library for which I'll
have to include the source code to remain compliant with the LGPL.
Can I include that as well? I think making a source download
available on my website with a link to it in the documentation should
probably meet the LGPL requirements. I just don't want to be
disqualified for breaking the terms of a license.

I know I probably should have investigated this going into this
challenge but I had assumed this would be a common situation and never
checked on it until today. Now I'm clearly very concerned that I'll
be disqualified or unable to enter.

Thank you,
Greg

[whitemice]

I just want to add to this question.

As I am submitting a suite of applications (and a platform), instead
of a single readme file, can I submit a ZIP file containing a number
of PDF and APK files?

[Dan Morrill]

Hi, Greg!

On Thu, Apr 3, 2008 at 6:30 PM, Greg_G <greg_a...@bitspring.com> wrote:

However, I need to include a
mksdcard image containing files necessary for the demonstration of my
application.

When a user first downloads/installs your application in the "real world", they would not have any content on the SD card.  Similarly, judges will not be setting up specific SD card images.  You can, however, assume that an SD card will be present, meaning that you can download or copy data onto it. But you'll need to initialize it from within your application, just as you would need to when first installing your application on a user's device.

 

(a) Will my application be rejected because of this need?  If my
current test image is too large, what would be a recommended ceiling
for which I should aim?

Assuming you change your application to do a separate download or installation stage as I mentioned above, you won't be automatically disqualified for having 80MB of data.  However, that's a *lot* of data to ship with your software, and may result in a long wait while it downloads, etc.  Since judges will be reviewing the user experience, you'll definitely want to keep that in mind.  I would suggest making it as small as possible, or only downloading pieces on-demand, etc.

 

(c) Additionally, I am using a single LGPLed library for which I'll
have to include the source code to remain compliant with the LGPL.

We are not going to be reviewing submissions for things like licensing compliance (and we don't have a way to do so, anyway.)  It's up to developers to comply with the appropriate software licenses.

- Dan

[Greg_G]

Hi Dan,

Thanks for your reply. I have some really important follow-up
comments, however.

> When a user first downloads/installs your application in the
> "real world", they would not have any content on the SD card.
> Similarly, judges will not be setting up specific SD card images.
> You can, however, assume that an SD card will be present, meaning
> that you can download or copy data onto it. But you'll need to
> initialize it from within your application, just as you would
> need to when first installing your application on a user's device.

In the real world, the purpose of my application is a very specialized
kind of media player specifically designed for local files that the
user would provide on their SD card. Without elaborating, streaming
would make no sense for my application. I was, for the judges
convenience, setting up an image with public domain and creative
commons (for obvious legal reasons), purpose-specific media. This is
entirely representative of what the real-world situation would be,
where the user would load the files that they want onto the SD card
for use with my application.

The app would not, in the real world, have any reason to handle the
downloading of files from a remote site. I could add that
functionality, but it wouldn't be at all representative of the
functionality of the software; it would just be something tacked on
for the purpose of the Challenge. That doesn't really make much sense
to me.

If the judges are going to load a blank SD card image for testing
anyways, and they want to test it as a true end-user, then loading my
sample image seems like a much more sensible scenario.

> However, that's a *lot* of data to
> ship with your software, and may result in a long wait while
> it downloads, etc. Since judges will be reviewing the user
> experience, you'll definitely want to keep that in mind. I
> would suggest making it as small as possible, or only
> downloading pieces on-demand, etc.

Again, the real world app would never do the downloading as it doesn't
make sense. The data would already be on the SD card because the
files they would be using would most likely be media they pulled from
their own CDs, etc. And by the very nature of it, the user would want
it all available: on demand doesn't again make must sense here.

Even if you feel a syncing mechanism is necessary, that would most
likely be provided by the android platform syncing files to the unit
(like the shared documents folder used for Windows Mobile devices).
I'm just speculating on that point, but if I found out later a
proprietary syncing mechanism were necessary, I could provide one.
But it wouldn't be necessary for testing the core functionality of the
app for the Android Challenge. What makes this app special will be
evident when it's used. But it needs files available that are
representative of what the end-user would have to demonstrate.

I'd very much appreciate it if you and your team would consider that
some specialized apps may have good, even critical, real-user-
simulating reasons for needing to provide a SD card image (or a .zip
of data to copy onto a real SD card if a device and not the emulator
is going to be used) and permit it for the Challenge.

Thank you,
Greg

[Dan Morrill]

Hmmm.

Thanks very much for this feedback, Greg.  I'll talk to my colleagues and see if there's anything we can do here.

One issue is that since many of the judges are not developers, it may be tricky to get them to successfully set up and use your SD card image.  We'll see if we can figure something out, although I can't promise anything right now.

I'll get back to you as soon as I can.

- Dan

[Greg_G]

Thank you very much for your consideration and explanation, Dan. I
understand your situation better now and will be standing by for the
final decision. I appreciate the effort, whichever way it goes.

Sincerely,
Greg

[Dan U.]

Dan,

I know it's a bit late in the challenge to throw this out, but perhaps
it can be agreed that a completely clean default install of the
emulator is made available on the judges machine (with the tools dir
in the path). And the ADC contestants can submit a zipfile with their
apk, sdcard image, mock location provider files, and a deploy script.
The deploy script would handle starting the emulator with or without
using a sdcard, and would install their apk and any mock location
provider files.

On Apr 5, 4:39 pm, "Dan Morrill" <morri...@google.com> wrote:
> Hmmm.
> Thanks very much for this feedback, Greg. I'll talk to my colleagues and
> see if there's anything we can do here.
>
> One issue is that since many of the judges are not developers, it may be
> tricky to get them to successfully set up and use your SD card image. We'll
> see if we can figure something out, although I can't promise anything right
> now.
>
> I'll get back to you as soon as I can.
>
> - Dan
>

[Greg_G]

Hello again Dan,

Have you and your colleagues come to a decision on this matter? I'm
sure you are all extremely busy at this point, but if I need to
develop a special mechanism for this, I need to find some time to fit
it in before the deadline. So I thought I'd better just post a
reminder since a week has passed. Sorry for the trouble.

Thank you again,
Greg

(Also thanks to Dan U. for his suggestion.)

[Alex Fridman]

Hey Guys,

Has a decision been reached? Without an SD card with some sample
songs, it would be difficult for the judges to test my submission.

- Lex

[Ram]

Based on
http://groups.google.com/group/android-challenge/browse_thread/thread/4412631fb4d5e285/27e9df98fd31c5c1?lnk=st&q=#27e9df98fd31c5c1
, it seems safe to assume that the deploy-script suggestion will not
be accepted.

You might want to wait for an official response to be absolutely sure.
However, in the meanwhile, you could consider storing the content as a
raw resource and then writing it to the SD card on first run.

Of course, you'll also need to make sure that the whole apk takes up
less than 10 MB of space (your earlier post indicates that you have 80
MB of data, but it looks like the ADC submission tool won't accept any
files larger than 10MB)