Cocoa Touch Framework support with public headers

[adil-hussain-84]

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]

@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]

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]

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 [email protected]
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
#593 (comment)
.

[advayDev1]

@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]

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]

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.