Is there any way to tell Flutter use more newer dart sdk version? I found it a bit tricky, because it checks some hashes in flutter/bin/cache/*.stamp. And when I'm trying to make a symbolic link to homebrew installed dart sdk it cannot build flutter_tool. To do that I've removed flutter_tool.stamp and flutter_tool.snapshot files. Something else needed?
I'm not actually sure if it is a need or not, but these tools are still in beta, for me it sounds logic to use edge versions.
Flutter ships with a customized Dart SDK (for example with the web parts stripped).
The Flutter SDK is tightly bound to a specific Dart SDK version and there is no reliable way to make Flutter work with any other Dart SDK than the one it is installed with.
Related
I am working on the dart_ping package and although it currently is tagged with iOS support, it does not actually support iOS. This is due to the way pub.dev detects supported platforms. I have filed an issue on dart-sdk repo.
Nonetheless, I would like to add iOS support while still preserving support for dart native. Right now, dart_ping works by calling the host OS's ping binary. The ping binary is available on Windows, macOS, Linux, and Android but not on iOS.
Current methods of performing a ping on iOS use native Objective-C code and call them via either method channels or ffi. Since method channels are a flutter feature rather than a dart feature, using them would require dart_ping to depend on the flutter sdk, which would prevent it from being used in a dart native application (perhaps server side).
Ffi on the other hand, is a dart native feature and is capable of doing what I want. However, I cannot seem to find a way to include the iOS framework/library/binary for ping in my dart_ping package in a way that instructs a flutter application to include it and link it to the iOS target/runner.
Is there any way to keep dart native support in my package while also supporting the edge case of iOS needing an extra non-dart framework? Even federated plugins depend on the flutter sdk. It seems to me that we need a pure dart equivalent to the federated plugin system.
TLDR: How do I add a pre-compiled iOS framework or binary to a dart package without depending on the flutter sdk and call it only when the package is used on iOS ?
For your specific case of adding iOS support only for Flutter users of your package but keeping the package as pure Dart without a dependency on the Flutter SDK should be possible by having a Flutter plugin package that depends on your Dart package.
In the pure Dart package you can have FFI calls to a native iOS library, but its actually the Flutter plugin package that supplies the native iOS library per the Flutter documentation for using FFI.
You would of course need to make it very clear in the documentation for your pure Dart package that for iOS, it should only be used via the "wrapper" plugin package.
Unfortunately this is a rather convoluted way to do it, but I don't know of a better way to achieve this as of now.
There is further discussion on this topic in the comments in this issue, which as of today is still open.
I am working on a Kotlin Multiplatform Mobile project. Tried adding in libraries for KMM, but I am getting
There are __ third-party libraries attached to the project that were compiled with an older Kotlin/Native compiler and can't be read in IDE.
The android project builds without problem so I was wondering if whether this error is only a warning and doesn't not affect the application at all?
Is there anyway to avoid this issue? How can I know if a library could be used for Kotlin Native?
Kotlin/Native doesn't guarantee binary compatability between versions - although as of 1.4 minor versions are experimentally binary backwards compatible. e.g. 1.4.10 should be compatible with 1.4.20 in the same project.
The easiest way to avoid the error is to ensure you're using KMM libraries with the same kotlin version as the kotlin version your project uses. Same goes for the IDE plugin.
Generally kotlin libraries by Jetbrains stay very up to date, as well as bigger libraries like SqlDelight. But smaller third party libraries can fall behind.
This issue is being actively worked on.
Since dart:ffi is available from Dart 2.2.0-dev.2.0, I've been trying to use that library. The sample app works fine for me and I also tried to use it for my Flutter app but I couldn't call it with import "dart:ffi", although Flutter on my machine was HEAD of master that used Dart 2.3.0-dev.0.0.
I checked what happened, then I found that sky_engine didn't contain ffi.dart while it contained other libraries (e.g. "dart:core"). Also I noticed that the source files of those libraries were copied from $FLUTTER_ROOT/bin/cache/dart-sdk/lib to $FLUTTER_ROOT/bin/cache/pkg/sky_engine using BUILD.gn or _embedder.yaml and that seemed to be why I couldn't use the dart:ffi in my Flutter app.
However, in the first place, why does Flutter need sky_engine, which is "the interface between Dart and the Flutter Engine"? Why not calling them directly without this glue code?
Flutter has a good documentation for FFI to be able to call native C APIs. Adding import 'dart:ffi' as ffi; on the Flutter app works without issues as of my testing with Flutter 2.5. If you're able to provide a minimal repro of your issue, this will help folks to understand the question better.
As for the question on why sky_engine is used by Flutter, that's just simply because it's the "flutter_engine" - similar to what has been already mentioned in the comments.
I came across a websocket example that I would like to use. However it uses import 'dart:html';. When I introduce that in my Flutter project seems like its not being picked up. Do I need to add additional dependencies to the pubspec.yaml?
dart:html can't be used in Flutter.
It is for browser applications only.
dart:html also only comes with the regular Dart SDK, not with the Dart SDK shipped with Flutter.
I know this is an old question but let me drop this answer here.
I've searched for a web crawler/scraper for Flutter for a while now. I've tried to use FlutterWebview and also the HTML package but no way. Recently I've found a new package for this.
The advantage of this package is that it is really cross platform as explained:
Cross-platform dart:html that works in the browser, Dart VM, and Flutter.
Typical use cases are:
Cross-platform application development (e.g. Flutter mobile and web versions).
Web crawling and scraping
you can use universal_html for any scraping/crawling purpose
Since the merge of Flutter-web into the main Flutter repository, it's no longer possible to directly add imports for web libraries (e.g. dart:html) in a Flutter project on the main channel when targeting Web, Android and iOS.
Use the universal html package which provides extensive support for multiple platforms and web libraries.
From the root level of your project, command
1.
flutter pub add universal_html
2. import 'package:universal_html/html.dart' as html
This package isn't required to run some web files (e.g. dart:js). In my case, I just had to remove the import 'dart:js' import statement.
I have made a project in xcode4.2 and when i opened it with xcode4.5 ,iOS 6 SDK it gives error 255 and the reason seems to be absence of libxml2.2.7.3.dylib.
What are my options is there any other substitute provided?
thanks
Xcode 4.5, or more precisely the iOS6 SDK (because the libraries available are dependent of the SDK, not the Xcode version) still has libxml2.2.dylib.
It is just probably not the version 2.2.7.3 but a newer, up-to-date 2.2.x.y version that is embedded in the SDK now.
You should generally not link your application with a specific version of libraries like that, but better with a generic version like libxml2.dylib or libxml2.2.dylib.
Generally libraries respect the semantic versionning, meaning that:
their major version change only when the API is not backward compatible with the previous major version,
the minor version change only when new methods are introduced in the API, but are still compatible with the previous API,
patch version means that some bug fixes have been made, but the API hasn't changed.
So if libxml respect this semantic versioning (and I guess is does, like quite every standard library), every version 2.2.x.y of libxml is API-compatible with any other 2.2.x.y version and will continue to work with your program. A hypothetic new version libxml2.2.x.z will simply fix bugs, but won't introduce any change in its API. And when a version of libxml2.3.x.y will arise, it will still be backward compatible with 2.1 and 2.2 too (just adding new features but not dropping the existing ones).
Thus, you can safely link your application with the generic library version libxml2.dylib, which will automatically point to the latest 2.x.y.z version available in the current SDK. Or link with libxml2.2.dylib which will point to the latest 2.2.x.y version (these are symbolic links to the latest versions, as all UNIX-like OSes use to do)
I think SDK for iOS6 just contains different version of libxml