> (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.)
For the sake of deeply understanding the possibilities of Android, and for those developers that have already large legacy of C++ code, it's definitively adequate to have a C++ SDK available. If the process proves to produce brittle software and thus of little usefulness, only time will judge. Eventually we conclude just the opposite: that this is not so difficult and very useful. The open source spirit is to let developers experience, and see the results. The Android team shouldn't claim that for some reason Java "should" be better for the developer. They should give everything to the developers and let us use the environment the way we like. The consumer should pick up the software that's really good and useful. The maximum the Android team could do is to suggest a development path or instill developers to use certain tools. But not to close the doors. If doors are to be closed, why choose an open-source environment. Perhaps some proprietary option would be better in this case. sbVB --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Internals" group. To post to this group, send email to android-internals@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
