Hi, Do you plan to release your work as open-source (hopefully under Apache 2 to be compatible with the rest of Android)?
Best Regards, Gergely On Sat, Jan 2, 2010 at 6:48 PM, Philippe Hausler <[email protected]> wrote: > Thanks for the feedback! I am quite familiar with Cocotron, very cool > project (albeit that it could use some commercial support to drive > more time devoted to development). So far with my tinkering the > compiler fully works, and I have been able to construct from scratch > some of the base classes from Foundation and UIKit. My approach was to > build a static library housing some of the base calls to load a JNI > app that has hooks peering into the base structures of my Foundation > and UIKit classes. Ideally I would like to have the libraries loadable > to a path e.g. /system/Library/Frameworks/Foundation.framework/ > Foundation.so to more closely mimic the loading schemes used in the > iPhone (this would provide more seamless integration between the > "port" and the "original platform"). However this does not seem to be > a valid place to keep them. The /sdcard path is writeable but for some > reason the System.load does not want to load libraries from that > location. So right now the biggest hurdle is where can I store a > shared library that might be utilized by many applications? So far my > code for Foundation and UIKit is fairly small, but I could see where > the library may reach a point at which it would be cumbersome to > require anyone who downloads an application that uses this to have to > download the entire library for each application (these are mobile > devices and memory space is limited). > > So far I think I can keep most of the heavy lifting to create the full > API level runtime in c/obj-c instead of having to do the majority of > the work in Java, but for the UI it is most likely that classes such > as UITextView would have a binding to a jobject pointer to a > android.view.TextView object. The Android platform has some nifty > features like the override methods for theming, I could see where this > advantage might cause some consistency issues with objc iPhone ported > apps if the UIKit classes did not utilize their Java counterparts. And > as per using the existing libraries from the iPhone, this is flat out > not doable, there is a slew of platform issues that would prevent > this, first and foremost the devices are different CPUs (the droid is > an ARMv5te? and the iPhone is ARMv6), second off the iPhone is mach-o > where as the android is ELF so the application architecture is > different from the ground level, direct binary compatibility is not > feasible. As I had mentioned before, I have gcc built to compile objc > for Android, as well as the libobjc.a. > > I had not seen the XMLVM project. Quite interesting, however it seems > after briefly looking at it that is the reverse direction, it takes > the Java VM bytecode and creates native machine bytecode, the reverse > ala llvm -> conversion -> jasmin might be doable but I think might > require more work than its worth to port the libraries into a pure > Java implementation that interfaces on that level. > > On Jan 2, 10:10 am, Gergely Kis <[email protected]> wrote: >> Hi Philippe, >> >> It would be nice to be able to use Objective-C libraries on Android, >> e.g. to port IPhone applications. >> >> Have you looked at Cocotron (http://www.cocotron.org/)?They have an >> implementation of various Cocoa frameworks that work on both Windows >> and Linux. I don't think they started to work on UIKit or IPhone >> specific parts. >> >> I don't think that the Android platform will have ObjC support >> officially in the foreseeable future. So if you want to be able to >> develop for consumer devices (that are not explicitly customized to >> allow ObjC apps), then each application will need to include the ObjC >> runtime + libraries. >> >> This probably means static linking, and some magic to initialize the >> Objective-C runtime from the Java side, because last I checked, >> application lifecycle management was only exposed in the Java API. >> >> Of course, such applications would be larger, but the same has been >> done for IPhone as well, for example with MonoTouch where the whole >> .NET runtime is packaged with the applications. >> >> Regarding Android API / UI integration: It is probably a good idea to >> look at how the Android Scripting Engine integrates different >> languages to the regular Android API. With a sufficiently generic >> Java-ObjC API bridge you can write Android applications in >> Objective-C, and possibly reuse already existing ObjC / IPhone >> libraries. >> Then, when you have a thin Objective-C wrapper over the Java API, you >> can try to build a UIKit wrapper, so that IPhone applications can be >> ported with minimal source changes. >> >> FYI: The XMLVM project (http://www.xmlvm.org) is doing something very >> similar, but the other way around: It allows cross-compilation of >> Android applications to native IPhone / Objective-C applications. It >> has Android API emulation, also a Java wrapper for IPhone APIs, plus >> an ObjC implementation of the Java Runtime (java.lang, java.util ...). >> Of course it is not yet complete, but it is actively developed. (We >> are using it in one of our projects.) >> >> Best Regards, >> Gergely >> >> >> >> On Thu, Dec 31, 2009 at 7:00 AM, Philippe Hausler <[email protected]> wrote: >> > * Post moved from android-platform group * >> >> > First off let me give some background about myself and my inquiry: I >> > am an iPhone developer, and I am an Android developer. I have >> > recently >> > embarked on a potentially interesting side project that others may >> > see >> > some use to. Just as a preamble, I am not looking to have any sort of >> > feedback on the benefits of Java versus Objective-C either >> > linguistically or efficiency etc. I am looking for viability of how >> > this can be accomplished. >> >> > In this project I have started, I have successfully compiled, tested, >> > and verified a variant of the Android NDK to build ObjC binaries for >> > the Android platform. After coercing the compiler to do my bidding >> > (along with hammering Xcode to recognize the new platform), my next >> > trick will be making a code compatible port of some of the base >> > frameworks from iPhone to the Android platform. I need suggestions on >> > the path of implementation for a few fundamentals... >> >> > Dynamic Libraries or Static? >> > Should my port build the framework libraries as dynamic and if so, >> > how >> > and where would they ideally be stored on the device? >> > If the frameworks should be static library inclusions into the built >> > applications, will this have a horrific adverse effect of the device >> > limitations per installed application size (my best guess is that it >> > will be an issue)? >> >> > Inherited UI or ported UI? >> > If I am successful in the port of Foundation, the next logical step >> > will be UIKit. I am a firm believer in consistency of the user >> > experience for operating systems, so a tie-in to the native UI would >> > be the best route in my opinion. This poses a quandary, how can a c/c >> > + >> > +/objc application bind into the Java based UI? Is there a lower >> > level >> > hook point for this? Can the JNI be bi-directional for connections to >> > UI elements? >> >> > The overall aim to this project is somewhat academic at the moment, >> > however for the concept of speed of porting applications to multiple >> > platforms this would definitely be quite attractive to developers >> > currently developing for iPhone and wanting to migrate to the android >> > platform. >> >> > I would love to hear any constructive ideas in regards to these >> > issues. >> >> > -- >> > unsubscribe: [email protected] >> > website:http://groups.google.com/group/android-porting > > -- > unsubscribe: [email protected] > website: http://groups.google.com/group/android-porting
-- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
