Megha,
Thank you for the prompt reply. I see you're working Sunday also. :-)
Trying to beat the last minute rush, I have already made what I
thought would be the last submissions of my two applications. The
documentation accompanying them does mention SDK / emulator bugs and
deficiencies, but does not include e-mail links documenting them. I
will try to add those to the documentation and submit them once again.
As to not being negatively marked on account of SDK / emulator bugs
and deficiencies, I ask the following with my tongue firmly planted in
my cheek:
If the judges don't use the helpers to see what the applications
can really do,
how will the judges know what to not mark them down from?
I suppose you'll just have to take my word for it that the
applications should score perfect tens, or whatever the best possible
grade is. :-)
Again, thank you for all your help with this.
Jim Renkel
On Apr 13, 3:43 pm, "Megha Joshi" <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 12, 2008 at 1:43 PM, jim.renkel <[EMAIL PROTECTED]> wrote:
>
> > [This message is a copy of a reply I made in another thread. I am
> > using it to start a new thread in hopes that it will get the attention
> > I think it deserves.]
>
> > Megha (and others),
>
> > Again, thank you for your prompt reply.
>
> > As to having multiple services in a single .apk, uh, my bad, and my
> > apologies. I'm sure I saw somewhere that you could only have one
> > <service> tag in a manifest, but I can't now find that. Oh, well. :-(
>
> > I have successfully combined my two applications into a single
> > project, and after a little twiddling they both seem to be working the
> > same as when they were separate projects.
>
> Glad that worked out well!
>
>
>
>
>
> > That leaves the issue of java helper applications running along side
> > the emulator.
>
> > I agree with your comment that "The judges should be treated as end
> > users.". But the logical implication of that, at least in my mind, is
> > that they would be provided with EITHER real Android handsets OR
> > "vanilla" emulators that accurately emulate real Android handsets. (By
> > "vanilla" I mean with no command line options, no configuration
> > alterations made, e.g., with adb, no helper applications, etc.)
>
> > I don't think anyone could argue with the statement that NEITHER of
> > those things can be done at this time, at least in a way that would
> > satisfy the requirements of applications such as the ones I have
> > developed.
>
> > To the best of my knowledge real Android handsets don't yet exist (or
> > are not available in sufficient quantities, or ....).
>
> > The emulator and SDK have known and, in most cases, well documented
> > deficiencies, bugs, etc., that we as application developers have to
> > circumvent in one way or another to best show off our exciting and
> > compelling applications, which as I understand it was what the ADC was
> > all about: develop exciting and compelling applications to jump start
> > the Android platform.
>
> > I believe (hope?) I have created two such applications, but they need
> > to circumvent emulator and SDK deficiencies to work to their full
> > capabilities. In particular, the deficiencies in the "vanilla"
> > emulator / SDK that I have had to work around are:
> > * applications running under the "vanilla" emulator cannot receive
> > TCP connections and cannot send UDP datagrams to or receive them from
> > the world outside of the emulator, they can only initiate TCP
> > connections;
> > * applications running under the "vanilla" emulator cannot
> > determine the IP address of the emulator (actually the IP address of
> > the host on which the emulator is running; and
> > * applications running under the "vanilla" emulator cannot get the
> > caller ID for voice calls to the emulated handset.
>
> > I reported the first problem very early, and received no reply other
> > than the issue was accepted to be fixed in the future. Later, folk in
> > the discussion group reported that if you open up emulator ports via
> > the emulator console you can, at least to a limited extent, receive
> > TCP connections and send and receive UDP datagrams.
>
> > To the best of my knowledge, even when you open up ports via the
> > emulator console, you still cannot get the accurate IP address of the
> > host on which the emulator is running.
>
> > The issue of making call ID available I believe has been accepted as
> > an issue to be fixed in the future. (Megha: I think it was you that
> > officially created this as an issue, for which I thank you. :-) )
>
> > In light of the above and desiring to show off my applications to
> > their best, I felt I was left with no option but to create helper
> > applications that run along side the emulator. The helper applications
> > (One for each of my two ADC submitted Android applications.) are
> > written in pure java and contain no application logic, only
> > circumventions of emulator / SDK deficiencies. If it's important to
> > anyone to verify that claim, I will provide the source for the helper
> > applications to them.).
>
> > One helper application simply accepts TCP connections from the outside
> > world: the Android application in the emulator makes a TCP connection
> > to it on start up, and when another handset / emulator / host makes a
> > connection to the helper application from the outside world, the
> > helper application simply copies data between the two connections. No
> > application logic there that I can see, but the handset application
> > wouldn't work in a "vanilla" emulator without the helper application.
>
> > The second helper application is similar but works on UDP datagrams.
> > Again, the Android application in the emulator makes a TCP connection
> > to it, then the helper application opens a UDP socket can copies
> > datagrams back and forth between the TCP connection to the application
> > in the emulator and the outside world.
>
> > That gets me around the first issue listed above.
>
> > The second issue is circumvented by having the UDP helper application
> > have source / destination IP addresses of the datagrams added to the
> > TCP messages. That was necessary so that the UDP helper would know
> > where to send the datagram. But it also allows the application in the
> > emulator to learn the emulator's host IP address: it is the
> > destination address of the datagram, which the UDP helper application
> > has included in the TCP message.
>
> > The third issue was circumvented by assuming that the caller ID for
> > incoming calls would be in an "extra" on the broadcast ANSWER_ACTION
> > intent that announces the arrival of an incoming call (That may not be
> > the way that caller ID is eventually officially implemented, and if
> > it's not I'll be among the first to change my applications to
> > conform.). I have included in one of my applications a little activity
> > that prompts for the phone number to which a call should be placed,
> > then uses the UDP helper application to send a datagram with the
> > calling and called phone numbers to the handset emulator that "has"
> > the called number, where it is turned into a ANSWER_ACTION intent and
> > broadcast within the emulated handset and / or used to trigger another
> > little activity that simply displays the caller ID in case no other
> > application consumed the ANSWER_ACTION broadcast event. How does the
> > originating emulated handset get the IP address of the emulated
> > handset to receive the call, just knowing its phone number? Ah, you
> > see, that's what makes this application so exciting and
> > compelling! :-) But I can't demonstrate that without the helper
> > application.
>
> > To complete the picture here, my other exciting and compelling
> > application is a peer-to-peer application that provides a unique
> > service for the users of two Android handsets. One way in which this
> > application establishes a connection between two handsets to provide
> > that service is to respond to incoming voice calls and use the caller
> > ID to establish a connection back to the originating handset. For now
> > it uses a TCP connection directly between the handsets (It will
> > eventually use UDP for a number of arcane reasons.) and again it can't
> > do that with the "vanilla" emulator, it needs a helper.
>
> > With 20/20 hindsight (Ain't it great!), I might have been able to do
> > all of this (Except to find the IP address of the host running the
> > emulator: that's still a gotcha) by opening up ports via the
> > emulator's console. At the time I made the decision to go with helper
> > applications, I had no confidence that opening up emulator ports would
> > work, and I didn't really have the time to try that when I know I
> > could make it work using a helper application. (Risk management in an
> > uncertain world under tight deadlines in practice! :-) )
>
> > So now I'm stuck having to have two little pure java helper
> > applications running alongside the emulator in order to really show
> > off my applications. The two helper applications are each started with
> > a single command, and in the documentation accompanying the
> > application submissions, I provide full details on how to enter those
> > two commands. And it's really simple: open a command prompt, enter two
> > commands, end of story.
>
> > If I had gone the "open emulator ports" route, the commands necessary
> > to do that would have been much more involved and less likely to be
> > entered correctly by anyone other than really experience emulator
> > users.
>
> > In light of all of this, I am asking and hoping that the ADC team will
> > allow these two helper applications to be used in evaluating my
> > submitted applications. In an ideal world, they wouldn't be necessary.
> > And certainly the need for them will be eliminated before we "go
> > production".
>
> > I will submit my two applications (twice, one for each application) as
> > a combined .apk file so you only need to do one install to use both
> > applications, include the helper applications and complete
> > documentation on the applications (Including instructions on how to
> > start the helper applications.) in an accompanying .zip, file, and
> > hope for the best.
>
> > At this point, I don't see that I've been left with any alternative.
> > But if someone does see another alternative, let me know: there's
> > still 56 hours to the submission deadline! :-)
>
> For issues related to the SDK, like known bugs, performance issues, please
> mention those in the documentation, along with a link to the email to
> android issue tracker where that issue was discussed and your application
> will not be negetively marked on account of those. I understand that the
> helper applications will help to show the functionality of your applications
> better, but as I said earlier the judges are not expected to run additional
> desktop applications alongside the emulator. That said, you are welcome to
> submit those if you want to(Keep in mind that there is a 10MB limit per
> submission).
>
>
>
> > Again, thank you everyone for your past, present and future attention
> > to these issues. And good luck to all in the ADC.
>
> > Jim Renkel
>
> > P.S.: in addition to this
>
> ...
>
> read more ยป
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Android Challenge" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-challenge?hl=en
-~----------~----~----~----~------~----~------~--~---
