cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [iOS] Converting to use Xcode Workspaces (in cordova-ios 4.x)
Date Thu, 02 Apr 2015 22:57:30 GMT
Thanks Sidney, I'll take you up on that.
Yeah I know the pain of the static framework -- we had cordova-ios as
that once (pre 3.x I think), using that workflow you mentioned, it was
indeed tedious.

As for dynamic frameworks -- I managed to track down an iOS 7 iPhone,
and without any changes to my PoC (aside from fixing a crash because I
used an iOS 8 only API), using it as is with dynamic frameworks, it
all works -- so I'm not sure what the deal is, perhaps it's because I
weak linked them, dunno.

I think this proposed all-encompassing change is risky, and I don't
want to delay cordova-ios 4.x especially since there is still lots to
do, so I'm proposing two stages:

Stage 1:
1. Remove CordovaLib subproject from app template
2. Add workspace with two projects: CordovaLib, and the app template
3. Make the workspace build in Xcode
4. Make the workspace build in the command line
5. Test with cordova-CLI

Stage 2:
0. Whatever tasks needed to get plugins as frameworks, a gajillion
steps, see README

If there's time, do Stage 2, if not, punt to cordova-ios 5.x





On Tue, Mar 31, 2015 at 6:28 PM, Sidney Bofah
<sidney.bofah@googlemail.com> wrote:
> Hi Shaz,
>
> i take my hat off your efforts and initial analysis - after initial “if it isn’t
broken…”-based doubts, i now also think migrating
> the iOS Cordova template structure to XCode workspaces is the best longterm approach.
>
> Addendum to your analysis:
> iOS “.frameworks" are not restricted to iOS 8+ per se, only _dynamic_ frameworks (dylibs)
are. That is, _static_ frameworks can
> be bundled since i-don’t-know-when. From a workflow perspective it used to be tedious
though, as one needs to build for ARM
> and simulator, then merge the resulting Mach-O executables via the lipo CLI, etc. - but
in XCode 6, Apple made this easier by
> providing a template for this (and there were third party framework templates as well).
>
> Based on these experiences, I created a workflow for myself to get from a popular iOS
cocoa control to a Cordova plugin in less
> than a day (for a simple framework with a few methods to expose via CDVPlugin). As we
all know, Plugman has been supporting
> custom frameworks for a while, and can then copy to the platform folders and reference
those files, which works flawlessly.
> Attached my repo links [1], i’d be glad to assist with any questions if that’s useful
for the .xcworkspace migration process.
>
> Best regards,
> Sidney
>
> [1]
> https://github.com/SidneyS/GCDWebServer-static-framework
> https://github.com/SidneyS/MRProgress-static-framework
>
>
>> On 01 Apr 2015, at 02:41, Shazron <shazron@gmail.com> wrote:
>>
>> ISSUE:
>>   https://issues.apache.org/jira/browse/CB-5921
>>
>> PROOF OF CONCEPT:
>>   https://github.com/shazron/CB-5921
>>
>> I took it onto myself to create a proof of concept on how this could
>> work. Check out the README for the conversion details:
>>   https://github.com/shazron/CB-5921/blob/master/README.md
>>
>> TLDR; The essence of it is:
>>
>> 1. There is a workspace that contains: CordovaLib, the user's project,
>> and N plugin framework projects
>> 2. CordovaLib is no longer a subproject of the user's project
>> 3. CordovaLib contains a target that will create a Cordova.framework
>> 4. Plugins are iOS Framework projects (adding a plugin requires adding
>> an xml line in xcworkspace, and framework refs in the user's project )
>> 5. Plugin JS is still installed by the CLI unless we find an alternative method
>> 6. The CLI needs to be changed to do (4)
>>
>> Implementation details are in the README referenced above.
>>
>> BENEFITS
>>
>> This makes it all modular especially the plugins. Plugins are
>> frameworks instead of static libraries because some plugins contain
>> resource bundles that need to be included, and frameworks provide this
>> functionality. Workspaces have been there since Xcode 4, and are used
>> by a bunch of other package managers (Cococapods), it will be good to
>> work well with other packaging systems if we can. Also, plugin
>> installation is simplified.
>>
>> Cordova is a framework so there will be no duplicate symbol problem
>> when linking a plugin into the user's project.
>>
>> POTENTIAL PROBLEMS:
>>
>> 1. I haven't tested this on iOS 7 devices yet though (since iOS
>> frameworks are iOS 8 only -- but they should still work if weak
>> linked), I'll have to find a device and report back.
>> 2. cordova-cli platform version issues: if cordova-ios 4.x supports
>> workspaces, and you are on a cordova-cli that doesn't know about the
>> new template format (but you installed the new platform anyway), it
>> won't work
>>
>> Send me your comments, ideas, etc...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Mime
View raw message