Hi Phillippe, Wait... you've coerced GCC into building objective-C for Android, as well as libobjc.a? That's fantastic! Have you tried to compile anything against GNUStep's implementation of Foundation? It's pretty much identical to Apple's, and it might allow Foundation-referencing Objective-C libraries to be linked into Android apps.
I realize you have much greater expectations for this project, but that alone would be a major accomplishment. I've written several apps for iPhone and I'm looking to port one of them to Android. I'd like to avoid translating tons of code from Objective-C to Java, and being able to keep a single copy of the Objective-C source and compile it into a static library for Android devices... that would just be incredible. If there's anything I can do to help you in your efforts, just let me know. I think you could post this as open source donation-ware and make quite a bit. Being able to compile Objective-C static libraries for Android (even without UIKit) would save me weeks of work. - Ben Gotow http://www.gotow.net/ On Jan 5, 3:48 pm, Gergely Kis <[email protected]> wrote: > 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/)?Theyhave 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
