apache/cordova

Remove platform-centered workflow support

Opened this issue · 7 comments

brodycj commented

ref: [1]

(seems to be in very limited use)

As discussed in apache/cordova-ios#769 (comment) and apache/cordova-ios#791 (comment):

  • known to be broken on Android for a number of years
  • known to be affected by Python 2 vs 3 incompatibility, needs a workaround such proposal in apache/cordova-ios#769
  • documentation known to be outdated for iOS
  • lack of resources that would be needed to get this functionality working correctly

We would like to focus our resources on the Cordova CLI workflow, as proposed by @erisu in apache/cordova-ios#769 (comment).

[1] https://cordova.apache.org/docs/en/latest/guide/platforms/ios/#platform-centered-workflow

brodycj commented

If we do this, it would need to be done very carefully as @NiklasMerz said in apache/cordova-electron#138 (comment).

I am actually not yet convinced to drop this functionality, downvoting my own proposal for now. I continue to like the idea that someone could develop and build an app for Android or iOS without the full weight of the entire framework.

  • 👍1
NiklasMerz commented

For Android and iOS we should come up with an idea how relevant the platform centric workflow is. Ideas like asking on the list, Slack, writing a blog post with a proposal.

For Cordova Electron I don't think it is really used after discussing with @erisu . If someone does not want to use the Cordova CLI they probably just use plain Electron.

  • 👍2
jcesarmobile commented

I think I was mistaken with the platform-centered workflow. What I was referring was embedding Cordova WebView into native projects.

Docs about that:
https://cordova.apache.org/docs/en/latest/guide/platforms/ios/webview.html
https://cordova.apache.org/docs/en/latest/guide/platforms/android/webview.html

The platform-centered workflow docs also mention using Cordova WebViews in native projects, but don't give any specifics. I've never tried that, so I'm not sure if it's been broken or not.

What have been broken for a long time are the docs about how to embed the Cordova WebView into native projects, specially the Android ones.

Phonegap team published newer docs on their site that used CocoaPods for iOS and Maven for Android http://docs.phonegap.com/tutorials/develop/1-embed-webview/ios/
But that requires all plugins to be CocoaPods libraries, which they are not at the moment.
And for Android it requires using plugman for installing the plugins and has not worked for a long time.

raphinesse commented

Here are my two cents about the problems with the platform-centered workflow.

It severely lacks documentation, making it often unclear how things are supposed to work. It is virtually untested, making it probable that it is already largely broken. The little documentation that exists suggests using plugman which is terribly maintained, untested and broken and thus should be deprecated as well.

But most importantly, trying not to break a largely undocumented and untested set of features is an incredible impediment when trying to refactor Cordova components toward a more reliable, modern and maintainable state. I cannot stress this enough, but this fuzzy concept that we call "platform-centered workflow" has complicated an awful lot of the refactorings that I planned or attempted. Examples include efforts to simplify/eliminate dependency management done by Cordova itself and stop copying our platform build tool libraries to the platform projects (which causes all kinds of nasty problems. See #32 for an example).

I think removing platform-centered workflow support from Cordova would mean getting rid of a lot of technical debt.

  • 👍2
msmtamburro commented

I came across this thread today as I am moving away from Cordova CLI, and wanted to better understand the (sounds like once-upon-a-time available) platform-centered workflow as it compares to other options out there today, like https://ionic.io/docs/portals. I wonder if there's some happy medium here: a low-overhead way to support a more native-friendly approach through an alternate workflow. Happy to discuss, if anyone is still thinking about this.

One idea: Forget plugman, and and use appropriate package managers for each platform (e.g., plugin authors could add a package.swift much like they add a plugin.xml... or a server-side script could serve up a package.swift dynamically based on the existing plugin.xml)

breautek commented

and wanted to better understand the (sounds like once-upon-a-time available) platform-centered workflow

Wasn't something I used but from what I understand, Cordova's platform-centered workflow is native-first approach where you were in complete control over the native project, and you imported in the cordova native libraries yourself, as opposed to the cordova CLI workflow where cordova manages the native project configuration for you.

It was an approach that didn't see significant usage, especially as Cordova evolved. Cordova's appeal is to web developers, not native developers after all.

I think plugins in general does a pretty good job to provide the ability to extend the native platform. You're able to import third-party libraries/frameworks, provide native source, and extend the configuration files.

msmtamburro commented

Thanks @breautek . It turned out to be pretty easy to spin up a blank native project (or your existing native-centric one) and integrate Cordova's Platform Centered workflow. If anyone ends up trying this, here are some helpful notes:

  • Use the config.xml and www folder in the staging directory from your "regular" (CLI) cordova project
  • Set the -ObjC other linkers flag because Cordova uses Obj-C Categories (think Swift extensions)
  • Adding files and selecting these two directories from your original project gets you 99% of the way there: plugins, resources
  • Bridging headers in your mixed language (Swift/Obj-C) plugins will not automatically combine, so you'll need to import them in to your blank project's bridging header