Compatibility with desktop apps

[synw]

I would like to integrate this package in a desktop app but there are some blocking dependencies. At least Sqflite and cached_network_image are not available for desktop.

Would it be possible to set some options to not use the incompatible packages when on desktop or is it too tight with the code and not an option?

[cosmotek]

I don't have an answer for you, but I wanted to comment that I've been able to get a demo to compile on linux. It doesn't show a map, but instead draws a grey square with a flutter logo that can be dragged around. Not sure if I am doing something wrong, or if there is incompatibility here..

[cosmotek]

I guess that flutter logo is a marker... so maybe it's just that the map isn't rendering.

[cosmotek]

It's pretty clear to me now that there is something preventing this library from rendering on desktop... granted it silently fails (which I find to be very odd).

[cosmotek]

What I am wondering is if the usage of Sqflite could be swapped for something like Sembast or ObjectDB. Sembast is pure dart, and supports desktop as well as both flutter mobile platforms. The only usage of Sqflite that I could find in the project (aside from the usage within cached_network_image) is in lib/src/layer/tile_provider/mbtiles_image_provider.dart.

It appears to be called for a SQL select query to get tile data. I'm having trouble finding how that database gets into the database in the first place. Either way, it would be a cakewalk to replace a single query like this with a Sembast query.

I may submit a PR for these changes, so please let me know if you have any insight here that could help.

[cosmotek]

Also, flutter_cache_manager is the cache provider used by cached_network_image, and it uses sqflite for storage.

[cosmotek]

@synw I found a fix.

I realized that the only issues with this package arise from the cache mechanisms, and that you can choose a tile provider (documentation shows asset based provider for offline use)... I tried providing the a network provider instead of the default (cached network) and voila!

Container(
            width: 500,
            height: 500,
            child: FlutterMap(
              options: MapOptions(
                center: LatLng(51.5, -0.09),
                zoom: 13.0,
              ),
              layers: [
                TileLayerOptions(
                  tileProvider: NetworkTileProvider(), // <- add this line here and it should work!
                  urlTemplate: "https://api.mapbox.com/styles/v1/rucuriousyet/ck15ozlow33tj1cph5cpt2y79/tiles/256/{z}/{x}/{y}@2x?access_token=pk.eyJ1IjoicnVjdXJpb3VzeWV0IiwiYSI6ImNpdm83MjFwYzAxMnQyeXFyaDR0ZmFxbjkifQ.Ak3DcaxXheiKmTW2TIKY9A",
                ),
                MarkerLayerOptions(
                  markers: [
                    Marker(
                      width: 80.0,
                      height: 80.0,
                      point: LatLng(51.5, -0.09),
                      builder: (ctx) =>
                      Container(
                        child: FlutterLogo(),
                      ),
                    ),
                  ],
                ),
              ],
            ),
          ),

Obviously the long term solution would be to modify the caching to utilize a different database, or get support for sqflite on desktop... but that's not great for those wishing to play with desktop now.

[synw]

Thanks! Using NetworkTileProvider works. But we loose the caching ability.

Obviously the long term solution would be to modify the caching to utilize a different database, or get support for sqflite on desktop

I feel that Sqflite support for desktop is not for tomorrow: there is no up to date Dart module for Sqlite at the moment. We could use Sembast as you suggest or Hive to write a compatible tile provider that can cache

[cosmotek]

I just saw hive yesterday... I think that's the way to go. We should just fork cached network image. Ultimately since hive performs better the community should probably use hive where possible instead of sqlite.

…

On Tue, Oct 1, 2019, 8:38 AM synw ***@***.***> wrote: Thanks! Using NetworkTileProvider works. But we loose the caching ability. Obviously the long term solution would be to modify the caching to utilize a different database, or get support for sqflite on desktop I feel that Sqflite support for desktop is not for tomorrow: there is no up to date Dart module for Sqlite at the moment. We could use Sembast as you suggest or Hive to write a compatible tile provider that can cache — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#431>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AM6PUEO63AZB2QR23TSJPDDQMNAFJANCNFSM4I2KVSRA> .

[GregorySech]

Instead of fully forking the package maybe a PR to inject a different cache strategy would be better. Then the hive cache might become a different strategy outside of the original package.

[JonasVautherin]

@cosmotek @synw: Does this bring Desktop support for sqflite? Or am I misunderstanding it? Would that help?

[moovida]

@JonasVautherin I changed from sqfile to use the sqlite3 package (former moor_ffi) and am happy with it. I am currently building for macos and linux and while sqfilte works on macos, it does not for linux.

Since everything starts in the chache manager, I tried to open a discussion here: Baseflow/flutter_cache_manager#222

Loosing cache management using the NetworkTileProvider is not a good option in my opinion, also because many free tile providers will blacklist you if you request too many images.

[cosmotek]

All good points. I haven't been in this discussion for a while, but I might try to write an alternative lib to replace NetworkTileProvider using Hive. I've used Hive for the last year in a mobile app (we used it in the same way you'd use LocalStorage in the browser) and have nothing but love for it. It's very fast, it provides an interface for custom object conversion (so no need to write SQL or convert to JSON)... overall a really nice utility for storing data in native dart.

[cosmotek]

I will always prefer using native language libraries as opposed to C/C++ bindings. C/C++ bindings will always be costly, and have cross-platform concerns. IMO that's a non-starter for Flutter, given the whole point is to be single framework for all UI platforms.

We should try to push this direction whenever practical as people writing Flutter libs that only work for a few devices will fragment the community.

[cosmotek]

(Sorry for the preaching, leaving my high-horse now).

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.