Here's some highlights since v8.0:
The NetworkTileProvider has had a massive functionality boost!
Built-in caching helps you, your users, and the tile server, and is enabled by default for maximum ease. You could also switch it out with a custom implementation, or disable it altogether if you prefer. Find out more in .
You may be using the CancellableNetworkTileProvider, which allowed in-flight HTTP requests to be aborted when the tiles would no longer be displayed, helping to improve performance and usability. Unfortunately, it isn't compatible with built-in caching. Fortunately, it's also been deprecated - its functionality is now available in the core! 'package:http' v1.5.0-beta () supports aborting requests with the 3 default clients natively, so Dio is no longer required. This makes it easier for you and for us!
PolygonLayer & multi-yet-single world support for Poly*LayerThis continues the work on multi-world support (thanks monsieurtanuki), and fixes an issue that occured where users used a
Thanks to the community, a new ContainCameraLatitude CameraConstraint is available, which keeps just the world in view at all times. At the moment, it still needs enabling manually.
TileLayer is loaded using one of the OpenStreetMap tile servers (in debug mode)Additionally, where an appropriate User-Agent header (which identifies your app to the server) is not set - for example, through TileLayer.userAgentPackageName
That's already a lot, but it's only scratching the surface. Alongside the community, we've improved our example app, , added even more customizability and fine-grained control - not even to mention the multiple bug fixes and other performance improvements.
Why not check out the CHANGELOG for the full list of curated changes, and the full commit and contributor listing if you like all the details:
v8.2 doesn't contain any API breaking changes, but it does contain deprecations and a small change in potential display output - we suggest preparing for the next breaking release whenever you can
Migrating to v8 should be pain-free for most apps, but some major changes are likely for plugins.
Some breaking changes have been made. The amount of migration required will depend on how much your project uses more advanced functionality. Basic apps are unlikely to require migration.
PolygonThis feature was bounty-funded, thanks to our generous Supporters, and the community! We hope to open more bounties in future.
CameraConstraint.containLatitude() to the MapOptions.cameraConstraint option.The old method of picking a placement algorithm has been deprecated and been replaced with a new, extensible system - it's still just as easy to use as the old one
Thanks to the community, a new placement algorithm has been added: an improved centroid algorithm using the 'signed area centroid' algorithm - this is the new default, but the old algorithm is still available
The polylabel placement algorithm has been given a fresh lick of paint and uses a more modern Dart implementation to improve performance and customizability
See how to migrate to the new system below.
Follow the new guide to setup a TileLayer as we recommend: . More to come soon!
The guide for interactive layers has been simplified, reworked, and example added. Check it out: Layer Interactivity.
We've added some information about using flutter_map with the OpenStreetMap public tile servers: Using OpenStreetMap (direct).
In future, we may block users which do not set a valid UA identifier for this server.
For more information, see Using OpenStreetMap (direct).
Polygon/lineLayer)The Polygon.labelPlacement property & PolygonLabelPlacement enum have been deprecated, replaced with Polygon.labelPlacementCalculator and PolygonLabelPlacementCalculator respectively
Here's the mapping of old enum values to new objects:
old default / .centroid -> .centroid() (new algorithm)
.centroidWithMultiWorld -> .simpleMultiWorldCentroid()
.polylabel -> .polylabel()
(new) .simpleCentroid()
Note that only the simpleMultiWorldCentroid calculator supports polygons which may lie across the anti-meridian.
This reduces internal casting (which we did a whole lot) and usage of generic types (which are inefficient), which has increased performance by around a millisecond or three (in a simple example)
The tooling and functionality provided by Dart/Flutter reduce the amount we need to maintain internally (reducing duplication), and work better together (such as easily building Rects from Offsets and Sizes
This breaks a large number of coordinate handling functions, such as those converting between geographic coordinates and screen space coordinates (the changed ones) in the MapCamera. We've also renamed some of these functions to remove references to 'point' and replace them with 'offset'.
Most migrations should be self explanatory. If necessary, you can view the PR to see what happened to a method you were using - there's very likely a close replacement! Some methods have been moved to internal usage only, but there's always easy alternatives.
Some external libraries still use the previous objects, and some of our use-cases are just not yet ready to be replaced by these options yet, so you may still find some of the old objects hiding around the codebase. IntegerBounds is internal only.
