> Hmmm, no offense but based on my experience applications that cannot
> be easily ported to a new platform is usually because the developer
> has not done a good job of isolating their code and making it modular.
> Any application that follows the Model-View-Controller pattern will be
> relatively easy to port to a new platform, regardless of the platform
> as opposed to an application that did not follow it. Saying that your
> application uses the platform better just because it cannot be ported
> to another platform easily is a bad argument and it only shows that
> you've been writing bad code.
Hi Incognito,
Perhaps I wasn't very clear. I'm not talking about porting the code
per se, my point is that the judges are looking for things that were
previously impossible on the last generation of mobile phones. If you
can just do a couple quick tweaks and the application works
universally, how are you demonstrating the power of the Android
platform? I'd expect that a lot of the winning applications will be
a great fit for the iPhone, but I have a hard time believing that
someone will win submitting an application that can just as easily be
fired up on your free-with-activation $50 Nokia.
I'm not at all criticizing universally compatible applications - Brick
Breaker has been a god send on my blackberry - I'm just addressing
tberthel's list of features and his challenge to "think of a
submission that uses more Android features than
mine." My takeaway point is that any features that can easily be
ported to a 5 year old handset probably aren't ones that will get high
marks from the judges. Do you disagree? I personally will be pretty
upset if an established company ports Bejeweled to Android and wins
over me!
I'm also not saying that all winning applications will use LBS. I've
seen applications that allow you to remotely access your PC, scan
barcodes, and improve web browsing which all do impressive things
without using the GPS function at all, but would have been impossible
on older handsets.
On Apr 28, 9:58 pm, Incognito <[EMAIL PROTECTED]> wrote:
> >>Games that truly highlight the platform are ones like WiFi Army (if
> >>they can actually build it) and Parallel Kingdom, which would be
> >>impossible to create on an existing framework. From my understanding
> >>of the competition, this is the type of creativity the judges are
> >>looking for.
>
> Hmmm, no offense but based on my experience applications that cannot
> be easily ported to a new platform is usually because the developer
> has not done a good job of isolating their code and making it modular.
> Any application that follows the Model-View-Controller pattern will be
> relatively easy to port to a new platform, regardless of the platform
> as opposed to an application that did not follow it. Saying that your
> application uses the platform better just because it cannot be ported
> to another platform easily is a bad argument and it only shows that
> you've been writing bad code.
>
> On Apr 29, 12:24 am, Chris <[EMAIL PROTECTED]> wrote:
>
> > If you are bringing it up for debate, perhaps you are using many
> > features of the Android platform, but I don't think you are truly
> > showing off the Android platform itself. Your list of features are
> > relatively generic and not particularly next-gen -I think your own
> > statement that this was a quick port to J2ME is more telling than
> > anything else. If your application can be ported so quickly to an
> > existing phone, I don't see how you are highlighting the platform
> > regardless of how many bullet points you hit.
>
> > Games that truly highlight the platform are ones like WiFi Army (if
> > they can actually build it) and Parallel Kingdom, which would be
> > impossible to create on an existing framework. From my understanding
> > of the competition, this is the type of creativity the judges are
> > looking for.
>
> > Since you are competing against more non-platform specific games, you
> > are up against entries like the ones from OmniGSoft and a myriad of 2D
> > competitors, which to be frank, look more polished than yours
> > regardless of whose is more powerful from a technical standpoint. I
> > think it is a brutal reality that given the category you entered in,
> > you will be judged on how much fun the judges have playing your
> > application more than anything else.
>
> > I hope I'm not coming across as overly critical, but since you've
> > challenged the group to analyze the virtues of your entry, these are
> > my two cents.
>
> > On Apr 28, 8:59 pm, tberthel <[EMAIL PROTECTED]> wrote:
>
> > > Can you think of a submission that uses more Android features than
> > > mine?
>
> > > On Apr 28, 10:58 pm, tberthel <[EMAIL PROTECTED]> wrote:
>
> > > > I probably have the most performant and processing intensive use of
> > > > the Android Platform showing the most effective use of the platforms
> > > > 2D graphics capabilities. I also use compelling features including the
> > > > following:
>
> > > > * Vibration
> > > > * Orientation
> > > > * Animations
> > > > * Touch Screen
> > > > * Progress Bars/Dialogs
> > > > * Lifecycle Implementation
> > > > * And other Android specific features
>
> > > > Accelerometer is the only major feature I am missing.
>
> > > > On Apr 28, 7:24 pm, Incognito <[EMAIL PROTECTED]> wrote:
>
> > > > > I think my chances are slim, but not because I'm not making effective
> > > > > use of Android. From Judges perspective they will not know the
> > > > > difference. I'm using touch functionality, a lot of the GUI
> > > > > components, pop ups, etc, etc. Based on your logic even tberthel has
> > > > > a worse chance of winning than me. All he is doing is using the
> > > > > drawing utilities from what I've seen from his demos. In fact, a lot
> > > > > of the applications I've seen all they do is use the 3d or 2d drawing
> > > > > utilities and that is it. This is true specially for a lot of the
> > > > > games.
>
> > > > > On Apr 28, 9:11 pm, "Cow Bay" <[EMAIL PROTECTED]> wrote:
>
> > > > > > i feel kinda sorry for your possibility to lose ADC, for it sounds
> > > > > > like you
> > > > > > fail ADC Judging Criteria 2, " Effective Use of the Android
> > > > > > Platform" >:{)
>
> > > > > > still wishing you good lucks....
>
> > > > > > ----- Original Message -----
> > > > > > From: "Incognito" <[EMAIL PROTECTED]>
> > > > > > To: "Android Challenge" <[email protected]>
> > > > > > Sent: Monday, April 28, 2008 4:05 PM
> > > > > > Subject: [android-challenge] Re: Android/Applets/J2ME
>
> > > > > > >sounds like your apps were originally designed and implemented
> > > > > > >platform-agnostic. that is, they were not originally for android
> > > > > > >because,
> > > > > > if
> > > > > > >they had been, imho, it would not seem so easy as you describe.
>
> > > > > > True, that was my goal. I wrote my code so that it would initially
> > > > > > work on J2SE, J2ME, and Android. This forced me to write the
> > > > > > business
> > > > > > layer platform-agnostic and just write interfaces that were platform
> > > > > > specific.
>
> > > > > > >take for examples Android Intent, LBS, content provider,
> > > > > > >AndroidManifests.xml, Services, and other Android-specific
> > > > > > >components,
> > > > > > which
> > > > > > >are seldomly seen in other mobile platforms, not to mention those
> > > > > > >android-specific api "constraints".
> > > > > > >>how did you convert those?
>
> > > > > > I'm not using LBS so no problem there. However, if I were I would
> > > > > > just
> > > > > > put that behind a generic interface.
> > > > > > Services - My application does not require to be running on the
> > > > > > background so I didn't need to convert this.
> > > > > > Android Intent, content provider - I didn't have to use this
> > > > > > feature
> > > > > > so I did not have to create an interface for it. IPhone does has
> > > > > > something very similar to this though.
> > > > > > They pass URL's between applications.
>
> > > > > > What I did have to create interfaces for are the drawing utilities,
> > > > > > Threads, GUI objects, like buttons, text fields, text buttons, touch
> > > > > > and key event handling, etc.
>
> > > > > > On Apr 28, 8:32 pm, "Cow Bay" <[EMAIL PROTECTED]> wrote:
>
> > > > > > > sounds like your apps were originally designed and implemented
> > > > > > > platform-agnostic. that is, they were not originally for android
> > > > > > > because,
> > > > > > if
> > > > > > > they had been, imho, it would not seem so easy as you describe.
>
> > > > > > > take for examples Android Intent, LBS, content provider,
> > > > > > > AndroidManifests.xml, Services, and other Android-specific
> > > > > > > components,
> > > > > > which
> > > > > > > are seldomly seen in other mobile platforms, not to mention those
> > > > > > > android-specific api "constraints".
>
> > > > > > > how did you convert those?
>
> > > > > > > ----- Original Message -----
> > > > > > > From: "Incognito" <[EMAIL PROTECTED]>
> > > > > > > To: "Android Challenge" <[email protected]>
> > > > > > > Sent: Monday, April 28, 2008 2:02 PM
> > > > > > > Subject: [android-challenge] Re: Android/Applets/J2ME
>
> > > > > > > >>So, I'd guess if you want an iphone app in its native platform,
> > > > > > > >>you're
> > > > > > > >>going to have a much easier time just manually building it
> > > > > > > >>after your
> > > > > > > >>java version is done, then update it based on diffs.
>
> > > > > > > At first glance that sounds like a really good idea. It would
> > > > > > > probably
> > > > > > > be true for small apps. i.e. A couple of thousand lines.
> > > > > > > I have tens of thousands of line of code written (distributted
> > > > > > > among
> > > > > > > several applications), easily close to 100,000 lines, and more
> > > > > > > than
> > > > > > > 1000 automated unit test cases.
> > > > > > > Trying to manually convert all this code to objective C would be
> > > > > > > extremely tedious. I would never have the patience to rewrite code
> > > > > > > that I already wrote once in a language and that has been tested
> > > > > > > and
> > > > > > > debugged thoroughly. Automating this is the best route for me.
> > > > > > > Then
> > > > > > > when I want to make changes to my code I make the changes only in
> > > > > > > Java
> > > > > > > and then I run the utility to convert the code to Objective-C,
> > > > > > > thus
> > > > > > > porting the changes over to Objective-C.
>
> > > > > > > >>Even if objective-C has every language feature of Java, and
> > > > > > > >>is syntactially very similar (or easily transformable), you
> > > > > > > >>have all
> > > > > > > >>the dependent libraries to worry about.
>
> > > > > > > Is not as bad as you think. For the IPhone specific functionality,
> > > > > > > i.e. drawing, touch events, key events, I'm using interfaces that
> > > > > > > abstract or hide the actual API. So my applications speak to my
> > > > > > > interfaces and then my interfaces speak to the actual platform
> > > > > > > APIs.
> > > > > > > Very similiar to what Java Standard Edition does.
> > > > > > > So all I have to do is connect my interfaces with the actual
> > > > > > > hardware
> > > > > > > or platform specific API's and I'm all set to go.
>
> > > > > > > On Apr 28, 4:18 pm, "Kevin Galligan" <[EMAIL PROTECTED]> wrote:
>
> > > > > > > > I don't know your software background, and I don't know what
> > > > > > > > objective-C is like, but I'd highly suggest not doing that. I
> > > > > > > > imagine
> > > > > > > > the commercial thing sucks. Rolling your own would be incredibly
> > > > > > > > painful. Even if objective-C has every language feature of
> > > > > > > > Java, and
> > > > > > > > is syntactially very similar (or easily transformable), you
> > > > > > > > have all
> > > > > > > > the dependent libraries to worry about. I'm sure the commercial
> > > > > > > > thing
> > > > > > > > does a partial conversion, which would then require you to
> > > > > > > > massage it
> > > > > > > > into a working application. When you want to update your
> > > > > > > > original
> > > > > > > > app, you'd then wind up manually updating both anyway.
>
> > > > > > > > So, I'd guess if you want an iphone app in its native platform,
> > > > > > > > you're
> > > > > > > > going to have a much easier time just manually building it
> > > > > > > > after your
> > > > > > > > java version is done, then update it based on diffs.
>
> > > > > > > > On
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
