Sean Kelley wrote: [...] > In other words, it does not seem very appealing to be required to > re-architect an SDL/Gtk+/fill-in-the-blank application to use the Android > Java UI framework and then somehow re-partition the native code into > libraries that may or may not be easy to combine with JNI.
Of course, they wouldn't run anyway because Android phones don't (AFAICT) have X. And even if you could you wouldn't want to do that because they wouldn't integrate with the Android UI and the result would be utterly horrible. *Any* application that has a UI will have to have a UI written, and designed for, Android. And that's almost certainly going to mean Java, because that's what it's written in. (It may be possible to wrap up all the JNI needed to call into the Android UI in, say, a set of C++ classes so that you can write a C++ app that used it; but it would be a repulsive amount of work and would probably be extremely brittle... and even then you wouldn't be able to subclass components, so you'd have to write Java code to receive callbacks. And, frankly, I don't see the benefit; you'll have to rewrite your UI to fit the Android framework anyway, so you might as well do it in the preferred language and save everyone a lot of time.) -- David Given [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Internals" 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-internals?hl=en -~----------~----~----~----~------~----~------~--~---
