[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. 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! :-) 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 reply, I will start a new thread with a copy of this message so that it gets the attention I think it deserves. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
