You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@gmail.com> on 2015/04/01 02:41:35 UTC
[iOS] Converting to use Xcode Workspaces (in cordova-ios 4.x)
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
Re: [iOS] Converting to use Xcode Workspaces (in cordova-ios 4.x)
Posted by Shazron <sh...@gmail.com>.
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
<si...@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 <sh...@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
Re: [iOS] Converting to use Xcode Workspaces (in cordova-ios 4.x)
Posted by Carlos Santana <cs...@gmail.com>.
This is great shaz, I will take a look.
This is something that have come up internally here in IBM from different
groups building native libraries/sdk for mobile services.
And for MobileFirst as we find out that there are developers that start
native only, and then they want to add a cordova web view (inlcuding
plugins) for one of their screens to start adding more web dev into their
complex native mobile apps.
I will check your branch out and make comments in gihub, I'm curios to see
how you are packaging the web parts of the plugin as resources bundle, and
then make it available to the web view, it was the only part I didn't have
a clear picture how to solved.
On Tue, Mar 31, 2015 at 9:28 PM, Sidney Bofah <si...@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 <sh...@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
>
>
--
Carlos Santana
<cs...@gmail.com>
Re: [iOS] Converting to use Xcode Workspaces (in cordova-ios 4.x)
Posted by Sidney Bofah <si...@googlemail.com>.
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 <sh...@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