I am learning Flutter and Dart. I noticed that thepubspec.yaml file seems to contain more than just dependency versions for third party libraries. For example.
# The following section is specific to Flutter.
flutter:
uses-material-design: true
I understand that the Dart Pub Tool defines the format for the pubspec.yaml and it seems like frameworks like Flutter can enhance the pubspec.yaml with extra settings raising the following questions:
Is pubspec.yaml designed to be used to provide configuration flags or only dependencies?
Does the way flutter use pubspec.yaml idiomatic Dart or unique?
Is pubspec.yaml only parsed by the pub tool or is it parsed at runtime as a generic application config file?
Does Flutter implement it's own parser for pubspec.yaml and make settings like uses-material-design: true available at runtime?
Is pubspec.yaml designed to be used to provide configuration flags or only dependencies?
Historically it also contained build settings in pure Dart projects. For example settings for compiling to JS, but that was moved out to build.yaml. See https://github.com/dart-lang/build/blob/master/build_config/README.md
Does the way flutter use pubspec.yaml idiomatic Dart or unique?
It's unique to Flutter.
Does Flutter implement it's own parser for pubspec.yaml and make settings like uses-material-design: true available at runtime?
yes.
These settings are build-time settings though, not runtime settings.
Actually I find it rather unfortunate that this file mixes up different purposes. In early Flutter days Flutter-specific settings were in a different file, but that also caused some difficulties (don't know details - only saw it mentioned in a GitHub discussion) so they merged it with pubspec.yaml.
Related
Programmatically I want to get all dart files available to import.
How can I achievement this? (programmatically)
In which environment do you want that?
If it's for a single Pub package, ensure that dart pub get has been run, then parse the .dart_tool/package_config.json file and find the roots of all the packages. Then search through those directories for all dart files that are not part files (does not start with part of ...;). The rest should be Dart library files which can be imported.
If you only want the packages that can be imported from inside lib/, you may want to parse the pubspec.yaml file too, so you can ignore the dev_dependencies.
Then you may also want to list the available dart:... platform libraries. Which are available depends on which platform you compile for. You need to figure that out somehow, then you should just keep a list for each platform.
I feel caught between the Carthage world and the Swift Package Manager (SPM) world, like being stuck in purgatory.
I'm developing a Swift library/SDK, and up until now, I've been using Carthage for dependencies. But since SPM finally works with iOS, I feel it would be great for people who want to use this library to be able to include it via SPM.
However, I've hit a wall. One of my dependencies, namely BitcoinKit works with Carthage but SPM support is broken.
In order to distribute my library, I need to have a Package.swift file, and some other critteria (README, source files in Sources, and tests in Tests). I also need to declare my dependencies in said Package.swift file, so that SPM recursivley can resolve all dependencies (when people install my library via SPM). Here's where I get stuck...
Since I'm still using Carthage I need a Xcode Project file to set up this Carthage dependency. But now my source files cannot import the SPM dependencies. They aren't found. Seems like I MUST include the SPM package dependencies using Xcode and Add Package Dependency feature (Apple doc here). This is not what I want right, I want my Package.swift file to declare the same versions of the SPM packages my library uses. To make it clear, this problem arises due to the fact that I need a Xcode project, due to Carthage.
So I thought maybe I could build BitcoinKit with Carthage (as I'm doing now), and include the built binary (.Carthage/Build/iOS/BitcoinKit.framework) my library, referencing it in Package.swift, but that does not work since SPM does not (yet?) support binaries (relevant Swift Forum Thread).
So what are my options?
1) Wait until someone smart fixes the broken SPM support in BitcoinKit (I've tried myself and failed), and then remove my Xcode project file and complete the transition of to only SPM and for now stick with Carthage...
2) Try to use SPM packages internally in my library installed through Xcode Add Package Dependency feature and manually sync those versions with the ones I declare in my Package.swift. Will that even work? Ugh, terrible solution anyway.
3) Hope to include BitcoinKit.framework built through Carthage as a binary when SPM supports it? When? Might take a while?
4) BitcoinKit also works with Cocoapods, but I guess that gets me nowhere, even worse actually, since Cocoapods creates a .xcworkspace file.
5) Wait until Apple hopefully (does anyone know if there are any plans?) changes so that we include Swift Packages via Package.swift file even when used together with an Xcode project file? That we I could keep on using Bitcoinkit via Carthage and only declare my SPM packages in one place and I guess SPM/Xcode/Swift would be responsible for integrating the dependencies into my Xcode project, but updated and managed through the Package.swift file...?
6) Any other alternative, real solution?
Without looking into the whole 'making bitcoinkit work with SPM' bit I think the 'linking a carthage prebuilt binary' idea sounds best as an interim solution at the very least.
It's not possible to link a binary in the package manifest (yet) but you can link it when you're building:
When building an SPM package from the command line using swift build you can link the binary using -Xswiftc or -Xlinker to pass the args -F path/to/bitcoinkit if you're linking a framework. Keep in mind each argument must have a cross argument flag before it.
When building in Xcode you should be able to solve it with an .xcconfig with the contents:
FRAMEWORK_SEARCH_PATHS = path/to/bitcoinkit
You may have to tweak it a bit but I imagine this should work, worst case having a separate .xcodeproj generated by swift package generate-xcodeproj --xcconfig-overrides myconfig.xcconfig.
There is a WalletExample in yenom/BitcoinKit on GitHub. It comes with a workspace and project.
I was able to include yenom/BitcoinKit with SPM in my Package.swift and I don't use any projects/workspaces.
My app is composed of many projects (frameworks), one for each main feature and a common framework with all sorts of things that I need to access in multiple of my features.
I'm using Xcode 11's Swift Package Manager to add dependencies.
The common framework contains a RxSwift dependency, which I use throughout the whole project.
I'm facing problems when I try to use RxTest in any of my feature frameworks.
If I add RxTest via SPM to the test target directly and run the tests, I get
failed to demangle superclass of 'class name' from mangled name 'other class name'
and many
Class 'class name' is implemented in both 'common framework path' and 'test target path'
where all these classes are Rx related. The 'failed to demangle' error crashes the test and only occurs when I try to initialize a RxTest class.
If I add RxTest to the common framework, the tests run fine, but when I run the app, I get
dyld: Library not loaded: #rpath/XCTest.framework/XCTest
Which makes sense, because I'm adding a test framework to a non-test framework, and it's not something good to do.
So basically, I wasn't able to get a configuration where both the tests and the app run fine. Either the app runs or the tests run.
How can I get this working? Is there a way to include RxTest on the common framework only when I build it on a test target? Or should RxTest only be included on the test targets and I'm missing some configuration?
Xcode with SPM dependencies cannot handle same SPM dependency in multiple targets that are dependent on each other right now. Each dependency needs to be only in single target at the moment. I dont know why as of now, but I'll try investigate more and file bug if it is not filed yet.
Your issue is likely that the library is using static linking instead of dynamic linking. In SwiftPM you can specify a library as being static or dynamic if you want or you can just let the build system decide which is what most packages do. Xcode seems to favor the static approach when it builds with SwiftPM which results in the build issues you are experiencing.
If you modify the Package.swift to have RxTest be a dynamic library instead it should work. You can easily test this by cloning RxSwift and modifying this line:
.library(name: "RxTest", targets: ["RxTest"]),
into:
.library(name: "RxTest", type: .dynamic, targets: ["RxTest"]),
and then dragging the local copy of RxSwift into your Xcode Project Navigator.
It will then use your local copy of the package instead of the one cloned by Xcode.
Once you do this you can link it against any targets you need and it should work. If that does actually fix the problem then your long term solutions are likely:
1) Have a fork that simply changes it to a dynamic library.
2) Convince the RxSwift community to change their products to dynamic or to vend dynamic versions in addition to the default.
3) Don't use RxTest or similar things in multiple places.
It is also worth noting, that Xcode 11.3 and earlier do not support archiving with dynamic Swift Packages. So if you go down the dynamic route you will have to wait for Xcode 11.4.
Workaround:
I had the same issues. My project configuration is:
Workspace
ProjectAppOne
AppTargetOne (Embed and sign FrameworkTarget)
ProjectAppTwo
AppTargetTwo (Embed and sign FrameworkTarget)
ProjectCoreFramework
FrameworkTarget
testsTareget
SPM Dependencies (including RxSwift)
My workaround was:
Duplicate the FrameworkTarget and create a FrameworkTargetT (make sure that are both building with no issues).
FrameworkTarget is still used to build the applications targets, so be sure that is the only one used in the imports of the application targets.
Add RxTest to FrameworkTargetT
Remove RxTest from FrameworkTarget
Set in your tests #testable import FrameworkTagetT
Adjust the FrameworkTarget to not run the testsTarget
Set the FrameworkTargetT to run the testsTarget
Adjust your CI fastlane/scripts, that involve testing target and call the FrameworkTarget directly
At the end the project structure was looking like:
Workspace
ProjectAppOne
AppTargetOne (Embed and sign FrameworkTarget)
ProjectAppTwo
AppTargetTwo (Embed and sign FrameworkTarget)
ProjectCoreFramework
FrameworkTarget
FrameworkTargetT
testsTareget
SPM Dependencies (including RxSwift)
I do not think is the ideal solution, it is easy to import the wrong framework in code or test, so double check that you are happy with that. But while we are waiting for the SPM team to sort the problem, it could be used and removed easily. This is also easy if you have already a framework separated code.
PS: you need to remember to add every new file to both of the targets FrameworkTarget and FrameworkTargetT.
I'm completely new to iOS development and coming from an Android background. I was starting to look at what alternatives are out there for dependency management in iOS and found out that CocoaPods seems to be the most prevalent option.
After reading a lot of links about this topic I'm kinda at a loss and wondering what is the usual way dependencies are handled in iOS.
I have two questions:
1) What would the equivalent of using gradle to generate library (.aar) projects be in iOS? If there's any equivalent option. From what I've seen one can wrap static libraries and headers into frameworks and these can be used in other apps, is this the standard way to do it?
2) If (1) is correct, does CocoaPods offer a mechanism to add frameworks as dependencies?
I don't have a Android background but from what I understand of .aar files CocoaPods does something very similar. CocoaPods uses .podspec files (described here) to generate static libraries (and soon dynamic frameworks which are new in iOS 8) that are then linked into your project.
A podspec can define source files, assets, libraries, or frameworks that a source vendors for linking into your application. So yes it does support adding frameworks as dependencies, although until iOS 8 frameworks were not supported at all on iOS.
As far as the 'standard' way to do it, I think that's based on opinion. There are a few general ways to include dependencies you can choose from.
Drag files, frameworks, and whatever else you need into your project manually. Updating these is more difficult and that also means you have to configure your .xcodeproj depending on what features that library needs (such as ARC)
Drag a provided .xcodeproj into your project, and link the relevant target from the given project. This can be nice if the library provides a project that can build a framework or static library, in this case you'd pull in that library but their project would handle custom compiler flags.
Do either of the above while including them as git submodules. Assuming nothing massive changes in the project this helps a lot with updating your dependencies.
Use CocoaPods. CocoaPods will handle all the custom linking and updates based on semantic versioning (usually).
Use Carthage. Carthage is an in- between CocoaPods and the .xcodeproj solution. It will download code based on semantic versions defined by git tags, then you drag the generated frameworks into your project.
All of these options have pros and cons and the decision normally comes down to how you feel about the control you have over the inclusion of the library, and how automated you want it to be.
I do not have android nor iOS background however I've been developing a CI tool for both platforms and here are the answers
As You mentioned this a framework and pods (libraries) from cocoapods are distributed that way. For instance, have a look at Apphance. When spec is clicked it's visible that this library will be accessible as a Apphance-Production.framework.
You add pods to Podfile and download them with pod install command. This command will made classes from Apphance accessible from the code. Some people do commit downloaded pods, other not (it's like adding jars or aars to source control).
I am trying to understand Dart's recommended project structure and not seeing the "forest through the trees".
So, if my project is intended to be a reusable library, say, a logging framework of some sort, then if I understand the above link correctly, I want all of my development to be under a lib and lib/src directory.
But what if I am building a web app? Where do my Dart source files go? Under packages? Specifically:
Where do I place Dart source files for a web app (not a lib)?
Are my web app's "packages" just directories that are logically organized similar to Java packages?
Does Dart recommend a 1-class-per-file convention for its source code?
1)
your_app_package/web
your_app_package/web/src/xxx
static content like jpg, css go to
* your_app_package/asset
2) the packages directory is maintained automatically. You configure in the file pubspec.yaml which 3rd party libraries you want to use and then call pub get or pub upgrade and the packages directory is updated automatically (the Darteditor does this automatically when you update pubspec.yaml).
3) not that I know of.
I had some problems putting additional classed in the code file of a Polymer element though. But I guess this is just a temporary limitation of Polymer.