search

j2objc-contrib / j2objc-gradle

This plugin is no longer actively maintained. J2ObjC Gradle Plugin: enables Java source to be part of an iOS application's build so you can write an app's non-UI code (such as application logic and data models) in Java, which is then shared by Android apps (natively Java) and iOS apps (using J2ObjC), all as part of your usual Android Gradle build.
https://github.com/j2objc-contrib/j2objc-gradle
Apache License 2.0
139 stars 43 forks source link

Cocoa Touch Framework support with public headers #593

Open adil-hussain-84 opened 8 years ago

adil-hussain-84 commented 8 years ago

I'm trying to use this Gradle J2ObjC plugin for creating a Cocoa Touch Framework and I'm questioning whether it is suitable for that purpose in its current form.

My project uses the recommended SharedCode, Android and iOS module setup but what I'm generating from my Android and iOS modules is a library/framework rather than an application.

Here is the problem I'm currently facing...

In my SharedCode module I have an interface called IAppIDManager. This is translated using the Gradle J2ObjC plugin and I can reference it in my iOS module no problem. I have an AppIDManager.h header in my iOS module which is a public header and which imports the translated IAppIDManager.h header as follows:

#import "IAppIDManager.h"

The iOS module compiles fine in Xcode and I can produce my framework.

Now this is where the problem is: when I try to use the generated framework in an iOS application, the application cannot find the IAppIDManager.h file which is imported by the AppIDManager.h header and hence falls over.

So, question is: is it possible to import a header generated by the Gradle J2ObjC output in a header which is public within my Framework? And, if so, how?

brunobowden commented 8 years ago

@adil-hussain-84, thanks for your interest but I do not know enough about Cocoa to answer this. I'd first look up how to see if this is possible with Cocoapods and how'd you do it. Then we can look at how we'd need to modify the plugin to produce the Cocoapods Podfile to generate a framework. We don't have any insights beyond that for now.

adil-hussain-84 commented 8 years ago

Thanks for the response Bruno. Appreciate it. I guess what I'm after is a way to mark some of the headers outputted from the J2ObjC translation as public in my iOS Framework project. I can't see a why to do this right now from what is output by the plugin. I'll do some reading to see if I can propose anything. In the meanwhile, if anyone has any suggestions, please do share!

brunobowden commented 8 years ago

I think you'll really want advice from the Cocoapods and Xcode forums. Then work backwards from that to say "do X in the Podfile" to make this work. Then that's a relatively easy change for us to make. You can also disable the Podfile modifications, so you can control it yourself.

On Wed, Feb 3, 2016 at 5:52 AM adil-hussain-84 notifications@github.com wrote:

Thanks for the response Bruno. Appreciate it. I guess what I'm after is a way to mark some of the headers outputted from the J2ObjC translation as public in my iOS Framework project. I can't see a why to do this right now from what is output by the plugin. I'll do some reading to see if I can propose anything. In the meanwhile, if anyone has any suggestions, please do share!

— Reply to this email directly or view it on GitHub https://github.com/j2objc-contrib/j2objc-gradle/issues/593#issuecomment-179245652 .

advayDev1 commented 8 years ago

@adil-hussain-84 you'll want to start here: http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/

@brunobowden We actually tackled this before and then reverted for reasons that aren't clear to me from the Issue trail - We used to have public_header_files (which are needed for the project to function as a framework) https://github.com/j2objc-contrib/j2objc-gradle/pull/192/files#diff-89d52298867194643bfb75634949bdf4L106 - but since we started using HEADER_SEARCH_PATHS, I'm not sure if we kept public_header_files up to date or not in the intervening time.

brunobowden commented 8 years ago

Thanks @advayDev1. @adil-hussain-84 - I think the best way to approach this is to modify the Podfile entries and then keep running "pod install" from the Xcode directory to see if you can get it working - you would not use the plugin to do this. Then once you get a working Podfile, describe the differences (including HEADER_SEARCH_PATHS if needed) in this issue. At that point, it should be possible to either modify the plugin yourself or educate us enough to do it for you. Though I'd strongly suggest doing it yourself as you'll be able to test it and we can still give constructive feedback.

adil-hussain-84 commented 8 years ago

Hi Bruno, Advay, thanks again for your help in this. The more I read and think about this the more I'm arriving at the conclusion that the right thing to do is not to expose any of the J2ObjC output in the public headers of my framework. The right thing instead I'm thinking is to use the J2ObjC output in the .m files of my framework only. This way should the J2ObjC output ever change (with new releases of the converter etc) or if I were to move to a different to converter, then it's all implementation detail which consumers of my framework are agnostic of. Thanks again for your help and suggestions with this.