Okay, I think we're splitting hairs here, but I also think that we're mostly in agreement. I agree about flexibility.
I particularly agree with the importance of using the built-in API first, such as for the Geocoder. This way, if the next SDK replaces the hidden implementation of the Geocoder with the real deal instead of a mock, our apps should just work as they were originally intended. If we can't get anything out of the built-in Geocoder, and we fall back to hard-coded support, that's all good too. So in order of preference: 1: Ideally the Geocoder and LBS providers just work. 2: If not, we fall back on our hard coded solutions for the demo But... between those two, I submit this 1.5: In order to make our demos interesting we add information to the geodb and a kml track for gps locations, allowing us to use the built- in mechanism but with more interesting data until the real deal is there. Maybe I went to far in suggesting that hard-coding was not the 'android way', but given the lengths that the android documentation goes to in explaining the file format for creating your own geodb and kml tracks - heck they even suggest you use Google Earth to create your own kml tracks - it is abundantly clear that 1.5 is the way we were intended to test, develop and demo applications. If we have to fall back to hard-coded java mocks to get our applications working, I think that's fine. What is NOT fine is that we should HAVE TO fall back to hard-coded mocks simply because the judges won't support the DOCUMENTED mechanism for creating mocks, due to some arbitrary rule about using adb push (which is also well-documented) What's more, I'm not sure any such arbitrary rule actually exists. I didn't see it in the official rules, only in a forum post one week before the deadline. Google has the right to apply whatever arbitrary rules they want, whenever they want, of course, but this one would be, in my opinion, outside the spirit of the challenge. On Apr 13, 4:28 pm, Kornelius Tuggerson <[EMAIL PROTECTED]> wrote: > I am, of course, not Dan, but I disagree with you about hard coded > locations going against the "android way". The hardest part of ADC is > figuring out how to use what's available to make your idea come to > life. I've spent many nights finding ways to work around the parts of > the SDK that are not available yet. You should make your application > flexible enough to use either the list of locations that the Mock > Location Provider spits out, or the list of locations you hard coded > into your app. If you follow the DAO pattern for data access, that > should be very easy to do. > > On Apr 13, 7:54 am, androider <[EMAIL PROTECTED]> wrote: > > > Change what? The fact that you can or cannot use adb push? > > > As far as I know, there's nothing in the regulations about this, only > > this comment in the forum by Dan. So I'm not convinced that we can't > > use adb push. In fact, I'm convinced otherwise. > > > If we can't provide a geodb or kml file - as the Android documentation > > recommends, then the easiest way to do gecoding and navigation would > > be to put all of our mock data as literals in Java code and totally > > ignore the built-in mock geocoder and providers. > > This would hide the data in our apk, since we don't have to provide > > source. > > > But that's insane isnt it. It would basically mean that the Android > > Developer Challenge would disqualify contestants who try to follow the > > "android way" and stick as close as possible to the published API for > > LBS, while hacky do-it-your-own-way workarounds would be given the > > advantage. > > > Please, say it ain't so, Dan. > > > On Apr 13, 11:36 am, "Harsh Jain" <[EMAIL PROTECTED]> wrote: > > > > Please dont change this now. I have, for instance, created sample data > > > around this route. > > > > regards, > > > harsh > > > > On Sun, Apr 13, 2008 at 3:53 PM, androider <[EMAIL PROTECTED]> wrote: > > > > > Dan, I really think you need to go back and revise this - talk it over > > > > with the Judges or something. > > > > > I mean, keeping the emulator 'pure' by preventing adb push makes some > > > > sense, but the existing gps mock track data and geodb file for mock > > > > geocoding are very limited. > > > > > What's more, the Android official documentation makes it quite clear > > > > that we are _supposed_ to replace or modify the geodb and track/kml > > > > files to properly emulate LBS when working on LBS applications. Why > > > > else does it clearly document the use of "adb push", the geodb file > > > > format (http://code.google.com/android/migrating/m3-to-m5/m5-api- > > > > changes.html#geo-mock<http://code.google.com/android/migrating/m3-to-m5/m5-api-changes.html...>) > > > > , and how to create kml files with Google Earth > > > > (http://code.google.com/android/toolbox/apis/lbs.html) > > > > > To provide all of this functionality and documentation to allow > > > > developers to build a worthwhile and demonstrable application in a > > > > 100% emulated environment, then hamstring us by saying (1 week before > > > > the submission date, no less) that none of this support and > > > > functionality can be used in the competition entry makes no sense at > > > > all. I suspect there's a misunderstanding here - and I, for one, am > > > > going to submit with some files to be pushed, as I suspect are many > > > > others. It makes no sense to do it any other way. > > > > > > On Apr 8, 4:28 pm, "Dan Morrill" <[EMAIL PROTECTED]> wrote: > > > > > > > This is definitely the way to go. Judges will not be able to use > > > > > > 'adb > > > > push' > > > > > > to install content files. > > > > > > One technique that may be helpful is to store the content file as a > > > > raw > > > > > > resource, and then access it and write it to the sdcard upon first > > > > run. > > > > > > > - Dan > > > > > > > On Tue, Apr 8, 2008 at 10:57 AM, Kornelius Tuggerson < > > > > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > I was worried about adb-pushing locations to the emulator too, but > > > > > > > then I decided that it would be better to hard-code a couple of > > > > > > > them > > > > > > > and then document that in the read me file. > > > > > > > > On Apr 8, 10:32 am, Ram <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi, can you please address the adb-push question. > > > > > > > > > adb-pushing the content files will be a prerequisite for my app > > > > and > > > > > > > > I'd like to confirm that judges will be able to do this step. > > > > > > > > > On Apr 7, 4:56 pm, Ram <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Hi, can someone from Google please answer the question below. > > > > > > > > > > Is it reasonable to expect that all judges will know how to > > > > > > > > > run > > > > adb > > > > > > > > > push to install content files (e.g. geodb for geocoding, kml > > > > > > > > > and > > > > > > > > > properties file for locationProvider etc.) ? > > > > > > > > > > I just started learning/writing the geocoding code yesterday > > > > > > > > > and > > > > hope > > > > > > > > > to complete a small app this week. > > > > > > > > > So an early response will be greatly appreciated. > > > > > > > > > --- > > > > > > > > > I don't yet have an answer on my GmmGeocoder question ( > > > > inhttp:// > > > > > > > groups.google.com/group/android-challenge/browse_thread/thread... > > > > > > > > > ) > > > > > > > > > > However, I don't mind using the mock Geocoder functionality > > > > > > > > > *if* > > > > > > > > > judges will be required to adb-push the geodb file that I > > > > provide (and > > > > > > > > > if this extra adb-push work won't be considered as a negative > > > > for the > > > > > > > > > app) > > > > > > > > > > Thanks Ram --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
