[BUG] Out of memory - hijacked by v9 release info

ozzy1873 commented 1 year ago

What is the bug?

I received an error at startup: IsarError: Cannot open Environment: MdbxError(12) Out of memory

What is the expected behaviour?

No crash

How can we reproduce this issue?

No response

Do you have a potential solution?

No response

Can you provide any other information?

The phone is a Samsung S5 (SM-G900F)

Platforms Affected

Android

Severity

Fatal: Causes the application to crash

Frequency

Consistently: Always occurs at the same time and location

Requirements

[X] I agree to follow this project's Code of Conduct
[X] I have checked for known issues in the GitHub tracker and on the docs site
[X] I have completed the pre-report checks listed on the docs site
[X] If I am using FMTC in a proprietary project, I have read and understood this important legal notice

JaffaKetchup commented 1 year ago

Hey @ozzy1873,

How many tiles are in your store, and now large is the store?

You can try decreasing the databaseMaxSize configuration in the FMTC settings. Alternatively, using multiple stores might help.

Isar depends on MDBX, which is fairly memory intensive. You might think storage and memory aren't linked, but they are in Isar. You may want to open an issue with Isar to see if there's anything they can do about this - I've had another report privately. Additionally, as far as I understand, Isar should be using virtual memory more than real memory.

ozzy1873 commented 1 year ago

Hi Luka,

There are about 3000 tiles in the store and the app is migrating from v6 to v7. Is there a way to catch the error and reset the cache, rather than crashing the app?

Thanks! John

From: Luka S @.> Sent: Wednesday, February 22, 2023 10:46 AM To: JaffaKetchup/flutter_map_tile_caching @.> Cc: john osborntech.com @.>; Mention @.> Subject: Re: [JaffaKetchup/flutter_map_tile_caching] [BUG] Out of memory (Issue #105)

Hey @ozzy1873https://github.com/ozzy1873,

How many tiles are in your store, and now large is the store?

You can try increasing the databaseMaxSize configuration in the FMTC settings. Alternatively, using multiple stores might help.

Isar depends on MDBX, which is fairly memory intensive. You may want to open an issue with Isar to see if there's anything they can do about this - I've had another report privately.

— Reply to this email directly, view it on GitHubhttps://github.com/JaffaKetchup/flutter_map_tile_caching/issues/105#issuecomment-1440403577, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACCL55ACTVJMQBGOQDOLVDTWYY7FNANCNFSM6AAAAAAVEHJFDQ. You are receiving this because you were mentioned.Message ID: @.**@.>>

JaffaKetchup commented 1 year ago

I've edited my comment above, please check there.

Unfortunately there's no way to catch this. It seems there are some stability issues, and I may have to workaround them.

Out of interest for the workaround, do you use import/export functionality?

JaffaKetchup commented 1 year ago

Can you also try running a clean version of v7 (no migration), to see if the issue occurs then? There is a possibility the migrator code is causing issues, having looked around Isar's tracker.

ozzy1873 commented 1 year ago

I am not using import/export.

JaffaKetchup commented 1 year ago

Can you also try running a clean version of v7 (no migration), to see if the issue occurs then? There is a possibility the migrator code is causing issues, having looked around Isar's tracker.

Can you also try this please?

JaffaKetchup commented 1 year ago

@ozzy1873 If it is indeed an issue with the migrator, I've implemented a fix that might resolve it. Can you check the 'v7.1.3' branch please, it might fix this issue? To depend on a GitHub repository branch, please see https://fmtc.jaffaketchup.dev/get-started/installation#from-github.com, and ref: v7.1.3 below the url field.

dumabg commented 1 year ago

It occurs the same to me. First time using your libraries, so, new code. Using import/export.

I've run the example and do an export. The file generated has only 198 tiles, only 10MB:

export.fmtc.zip

I've copied this generated file on the assets directory and created this code:

maps_offline_service.dart.zip

Debugging on Android, the FMTCImportSharingModule.manual method throws the exception on Isar.open call:

FMTCRegistry.instance.storeDatabases[id] = await Isar.open( [DbStoreDescriptorSchema, DbTileSchema, DbMetadataSchema], name: id.toString(), directory: FMTC.instance.rootDirectory.directory.path, maxSizeMiB: FMTC.instance.settings.databaseMaxSize, compactOnLaunch: FMTC.instance.settings.databaseCompactCondition, );

ozzy1873 commented 1 year ago

Unfortunately, it will be a few days before I can try out the new version. Also, this is the phone of one of my beta testers, so I do not have direct access to it. Can you think of a way that an emulator could be used to test this scenario?

JaffaKetchup commented 1 year ago

@ozzy1873 Any x64 emulator should work (x86 doesn't). Try to get the specs the same as the real device.

@dumabg Can you say how much memory your testing device has please? I'd like to try and recreate this, as I can't on my device (and obviously my Windows machine doesn't struggle at all).

ozzy1873 commented 1 year ago

The problem with the emulator is setting up the initial conditions so that the v6->v7 upgrade happens on existing files.

JaffaKetchup commented 1 year ago

That's a little more difficult I guess. Can you just test without any migration for me, just to isolate the issue? I don't mind waiting a few days. (Transferring the files could be done with the import/export functionality, but don't worry about setting that up just for this).

dumabg commented 1 year ago

@dumabg Can you say how much memory your testing device has please? I'd like to try and recreate this, as I can't on my device (and obviously my Windows machine doesn't struggle at all).

3GB

JaffaKetchup commented 1 year ago

@dumabg Thanks. Just to confirm, you're not affected by the migration code? And are you importing/exporting the store when the error occurs?

dumabg commented 1 year ago

@dumabg Thanks. Just to confirm, you're not affected by the migration code? And are you importing/exporting the store when the error occurs?

First time using the library. New code. These are the versions on pubspec:

flutter_map_tile_caching: ^7.1.2
  fmtc_plus_sharing: ^7.0.0

And yes, I'm using the FMTCImportSharingModule.manual method. See the sample attached on the previous post.

JaffaKetchup commented 1 year ago

@dumabg When testing with the example app, I can reproduce a different issue on my Windows machine, and on a Pixel 2 x64 2GB RAM emulator. If the store file is imported without the name format 'export_\<name>.fmtc', the store doesn't get properly don't seem to work right: this is a bug, thanks for reporting. In your case, 'export.fmtc' doesn't work correctly. I'll have to fix this, unfortunatley likely with a breaking change, looking at the situation. However, after renaming the file to 'export_catetinho.fmtc', it seems to work correctly. Can you post your console output, and if possible, a screen-recording? Your code looks OK, although I haven't tested it. It does seem a little unusual though to be getting the FMTC store from assets. Thanks for all the help so far.

(My emulator config:)

dumabg commented 1 year ago

I've changed the code and put "catetinho" instead of "map", but continues with the same error:

Debugger screenshoot, stopped on the problematic line. You can see that the input file has the name export_catetinho.fmtc:

After this point, appears this on the debug console:

I/flutter (27813): IsarError: Cannot open Environment: MdbxError (12): Out of memory

W/isarworker(27813): type=1400 audit(0.0:5077): avc: denied { getattr } for uid=10237 path="/persist" dev="mmcblk0p30" ino=2 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:persist_file:s0 tclass=dir permissive=0 I/chatty (27813): uid=10237(catetinho.abdi.app) identical 16 lines W/isarworker(27813): type=1400 audit(0.0:5094): avc: denied { getattr } for uid=10237 path="/persist" dev="mmcblk0p30" ino=2 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:persist_file:s0 tclass=dir permissive=0 I/flutter (27813): IsarError: Cannot open Environment: MdbxError (12): Out of memory

El 22/2/23 a las 17:55, Luka S escribió:

@dumabg https://github.com/dumabg When testing with the example app, I can reproduce a /different/ issue on my Windows machine, and on a Pixel 2 x64 2GB RAM emulator. If the store file is imported without the name format 'export_.fmtc', the store doesn't get properly don't seem to work right: this is a bug, thanks for reporting. In your case, 'export.fmtc' doesn't work correctly. I'll have to fix this, unfortunatley likely with a breaking change, looking at the situation. However, after renaming the file to 'export_catetinho.fmtc', it seems to work correctly. Can you post your console output, and if possible, a screen-recording? Your code looks OK, although I haven't tested it. It does seem a little unusual though to be getting the FMTC store from assets. Thanks for all the help so far.

— Reply to this email directly, view it on GitHub https://github.com/JaffaKetchup/flutter_map_tile_caching/issues/105#issuecomment-1440784741, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIMXZOEH43GW46MVIQV2ZRTWYZ4NTANCNFSM6AAAAAAVEHJFDQ. You are receiving this because you were mentioned.Message ID: @.***>

JaffaKetchup commented 1 year ago

@dumabg Thanks for the info. Tomorrow I'll give it a go on an older physical device of mine to see if that helps me reproduce the issue.

JaffaKetchup commented 1 year ago

To everyone subscribed. I'm currently planning on ways to fix this issue, as a private contact has also confirmed that they recieve this error. Unfortunatley, I am rather busy at the moment. At the moment, my plan is to offer an option to dump tiles onto the filesystem, as in pre-v7. There would be no seperation of them, and choosing this method would disable the import/export functionality on that store. Isar would still be required to manage the tiles and store information, but it would only store IDs/references, instead of the tile bytes themseleves, significantly reducing the strain on Isar. This does have a few catches, that I'd need to work out before implementation. Let me know if this sounds good to you guys. Note that this will be v8.0.0.

ozzy1873 commented 1 year ago

Hi Luka,

Storing the tiles as separate files outside the database sounds like a good idea. There can be a lot of cached files, so this would reduce the load on the database.

Regards, John

From: Luka S @.> Sent: Wednesday, March 1, 2023 2:26 PM To: JaffaKetchup/flutter_map_tile_caching @.> Cc: john osborntech.com @.>; Mention @.> Subject: Re: [JaffaKetchup/flutter_map_tile_caching] [BUG] Out of memory (Issue #105)

To everyone subscribed. I'm currently planning on ways to fix this issue, as a private contact has also confirmed that they recieve this error. Unfortunatley, I am rather busy at the moment. At the moment, my plan is to offer an option to dump tiles onto the filesystem, as in pre-v7. There would be no seperation of them, and choosing this method would disable the import/export functionality on that store. Isar would still be required to manage the tiles and store information, but it would only store IDs/references, instead of the tile bytes themseleves, significantly reducing the strain on Isar. This does have a few catches, that I'd need to work out before implementation. Let me know if this sounds good to you guys. Note that this will be v7.2.0.

— Reply to this email directly, view it on GitHubhttps://github.com/JaffaKetchup/flutter_map_tile_caching/issues/105#issuecomment-1450800894, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACCL55ENLVSF4RJYEW7NUHLWZ6WFNANCNFSM6AAAAAAVEHJFDQ. You are receiving this because you were mentioned.Message ID: @.**@.>>

JaffaKetchup commented 1 year ago

@ozzy1873 @dumabg

I've been having a think about some of the issues with storing tiles in a dump. Whilst many of them could be solved, it would become incredibly complex. These are the main issues:

No fine-grained control of stores
- Inability to delete individual stores
  This would require sorting through all stores and their tiles to find the correct tile IDs to delete: too slow.
- Inability to watch individual stores IO watching watches an entire directory or a single file. Starting multiple watchers is extremely costly, especially on some platforms.
Cannot get size statistics (length is available)
This is just way to slow on IO, and trying to store sizes in the databases would be relatively slow to reach sums as well. Even a solution where storing and deleting tiles updates one value would not be acceptable: guaranteeing sync is impossible (at any reasonable speed/frequency).
No store importing/exporting
This would require sorting through all stores and their tiles to find the correct tile IDs to add to and archive: too slow.
Significant performance reductions throughout
IO operations on multiple files is extremely slow, even on a superfast SSD. Creating, deleting, getting metadata (size, time, etc.), all takes a really long time on 30K files.

Potential, one directory could be used per store, similar to pre-v7, but this has it's issues:

Statistic getting would be very slow
Pre-v7, statistic caching was relied on to get some sort of acceptable performance. I will not be implementing this again.
Store importing/exporting would be very slow
Pre-v7, stores had to be archived (zipped) before sharing: too slow. I will not be implementing this again.

You can see why I migrated to Isar :).

I haven't had too many reports about this issue. In total, including both of you, I've only had 3 reports. In terms of my luck in reproducing, I haven't been able to (with the example app). I've gone all the way back to an Android 6 device (Motorola Moto G 2015) with 1GB LPDDR3 RAM and ~300MB RAM remaining when testing. At most, with ~8000 tiles (~78 MiB), I've only been able to produce a memory consumption of ~110MB: which is a very reasonable amount.

I have recently made some improvements in 7.2.0 that might help some things. Please try running this just to double check if you run into issues.

Please let me know your opinions and thoughts.

tratteo commented 1 year ago

Hello, I am getting the same error IsarError: Cannot open Environment: MdbxError (12): Out of memory running on a Pixel 6, API 27.

Maps downloaded are very small.
I am using different stores to cache different maps: var store = FMTC.instance(activityId);

In my case the error happens when I try to access a second store after a first one has already been accessed. Indeed if I only access the first store, the error is not thrown.

However, testing on a Pixel 6 API 25 (Android Nougat 7) the error was thrown directly at await FlutterMapTileCaching.initialise()

Configuration for the Pixel 6 API 27:

JaffaKetchup commented 1 year ago

Hi @tratteo, and thanks for your report. You may have just caught onto something with the 'using multiple stores'. See https://github.com/isar/isar/discussions/738#discussioncomment-3870228. I've made an offer to the maintainer of a bounty (https://github.com/isar/isar/discussions/738#discussioncomment-5294617) to resolve a few issues, so I'll see if he gets back after that. Note that money for bounties can only come out of donations and alternative license payments, so please consider donating if you can!

tratteo commented 1 year ago

Thanks for the fast reply, I will see what I can do 😅

By the way, if the problem is related to multiple stores, I find it strange that it never happened on API 28+

JaffaKetchup commented 1 year ago

@tratteo That's an interesting point about the API levels. The original device produce to report this issue was a Samsung S5, which appears to ship with Android 5: below API level 28. However, I tested on a device below API level 28 (albeit with only one store), and there was no issue. So it may not affect all devices. I'll test on that device again with multiple stores, to see if that affects things.

(Don't feel pressured into donating, please only do so if you've gotten FMTC working and you want to :))

tratteo commented 1 year ago

Thanks, let me know if you encounter the problem while testing with multiple stores

tratteo commented 1 year ago

Just to throw some more information: I tested again with an emulator of Pixel 6 API 27. I am doing some tests, decreasing the databaseMaxSize down as 64 Mib seems to allow the creation of multiple databases, at least up to 6 stores. To be honest 64 Mib should be more than enough for our purpose but it is assured that it is not something normal on the Isar's side

Edit: Downloading an area of around 8Km in radius (1500 tiles) crashes the app with databaseMaxSize=64, so i guess it requires a bigger db storage somehow.

PS. I noticed that FMTC.instance.rootDirectory.stats.rootSize returns the result in Mib instead of Kib as the division takes places two times:

double get rootSize =>
      storesAvailable.map((e) => e.stats.storeSize).sum / 1024;

and

double get storeSize => _db.getSizeSync(includeIndexes: true) / 1024;

JaffaKetchup commented 1 year ago

@tratteo Thanks for that bug report at the bottom there. If you get time, can you please open a seperate issue?

Downloading an area of around 8Km in radius (1500 tiles) crashes the app with databaseMaxSize=64, so i guess it requires a bigger db storage somehow.

Is there a specific error message? 64MiB is fairly small for a tile store, so I wouldn't be surprised if it was that.

I haven't gotten around to that second round of testing yet, I'll try to do that today or over the weekend.

tratteo commented 1 year ago

At the moment I was not able to reproduce the problem. Downloading tiles for around 40 Mib does not crash the app with a db size of 64, this is indeed weird, as it did cause crash before.

I am noticing something else tho, due to some test I was doing with the package, whenever exceptions are thrown, the size of the store increases enormously. For example when using a cached tile provider for visualising the map offline and moving out of the cached zone, I get tons of these errors:

Whenever this happens, the size of the root folder increases. As an example, just moving a second out of the cached area, increases the root store size of more than 10 Mib. Are these errors and the size increment normal?

JaffaKetchup commented 1 year ago

Hi @tratteo, I can't seem to reproduce the growing database size issue. However, Isar does suggest that long running transactions can cause database growth, so this may be an issue if errors are throwing, but not exiting transactions. You can the adjust databaseCompactConditions, however, which is run on every initialisation. This should remove any of that consumed space.

tratteo commented 1 year ago

I submitted a new issue #115 in order to prevent flooding this discussion

JaffaKetchup commented 1 year ago

Just heard a little bit from Isar's maintainer: https://github.com/isar/isar/issues/686#issuecomment-1493325747. This is great news! v8 will support Isar v4 and flutter_map v4, and will not be released before those.

morfair commented 1 year ago

Have same problem on Xiaomi Redmi A1+ when call

await FMTC.instance('mapStore').manage.createAsync();

Debug log:

Launching lib\main.dart on 220733SFG in debug mode...
Running Gradle task 'assembleDebug'...
√  Built build\app\outputs\flutter-apk\app-debug.apk.
D/FlutterGeolocator( 7170): Attaching Geolocator to activity
D/FlutterGeolocator( 7170): Creating service.
D/FlutterGeolocator( 7170): Binding to location service.
D/FlutterGeolocator( 7170): Geolocator foreground service connected
D/FlutterGeolocator( 7170): Initializing Geolocator services
D/FlutterGeolocator( 7170): Flutter engine connected. Connected engine count 1
Debug service listening on ws://127.0.0.1:53125/PnLEctRPbCw=/ws
Syncing files to device 220733SFG...
W/isarworker( 7170): type=1400 audit(0.0:1125): avc: denied { search } for name="vendor" dev="tmpfs" ino=7352 scontext=u:r:untrusted_app:s0:c177,c256,c512,c768 tcontext=u:object_r:mnt_vendor_file:s0 tclass=dir permissive=0 app=ru.ivjh.esc.esc_driver
W/isarworker( 7170): type=1400 audit(0.0:1126): avc: denied { search } for name="vendor" dev="tmpfs" ino=7352 scontext=u:r:untrusted_app:s0:c177,c256,c512,c768 tcontext=u:object_r:mnt_vendor_file:s0 tclass=dir permissive=0 app=ru.ivjh.esc.esc_driver
W/isarworker( 7170): type=1400 audit(0.0:1127): avc: denied { search } for name="vendor" dev="tmpfs" ino=7352 scontext=u:r:untrusted_app:s0:c177,c256,c512,c768 tcontext=u:object_r:mnt_vendor_file:s0 tclass=dir permissive=0 app=ru.ivjh.esc.esc_driver
W/isarworker( 7170): type=1400 audit(0.0:1128): avc: denied { search } for name="vendor" dev="tmpfs" ino=7352 scontext=u:r:untrusted_app:s0:c177,c256,c512,c768 tcontext=u:object_r:mnt_vendor_file:s0 tclass=dir permissive=0 app=ru.ivjh.esc.esc_driver
W/isarworker( 7170): type=1400 audit(0.0:1129): avc: denied { search } for name="vendor" dev="tmpfs" ino=7352 scontext=u:r:untrusted_app:s0:c177,c256,c512,c768 tcontext=u:object_r:mnt_vendor_file:s0 tclass=dir permissive=0 app=ru.ivjh.esc.esc_driver
W/isarworker( 7170): type=1400 audit(0.0:1130): avc: denied { getattr } for path="/metadata" dev="mmcblk0p13" ino=2 scontext=u:r:untrusted_app:s0:c177,c256,c512,c768 tcontext=u:object_r:metadata_file:s0 tclass=dir permissive=0 app=ru.ivjh.esc.esc_driver
W/isarworker( 7170): type=1400 audit(0.0:1131): avc: denied { getattr } for path="/linkerconfig" dev="tmpfs" ino=9277 scontext=u:r:untrusted_app:s0:c177,c256,c512,c768 tcontext=u:object_r:linkerconfig_file:s0 tclass=dir permissive=0 app=ru.ivjh.esc.esc_driver
E/flutter ( 7170): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: IsarError: Cannot open Environment: MdbxError (12): Out of memory
E/flutter ( 7170): 
D/ProfileInstaller( 7170): Installing profile for ru.ivjh.esc.esc_driver

JaffaKetchup commented 1 year ago

Hi @morfair, This is a known issue, please see https://fmtc.jaffaketchup.dev/known-issues#isar-stability-issues. Once Isar v4 is released, this issue should be fixed, and I will be migrating FMTC to it ASAP.

eidolonFIRE commented 11 months ago

Flutter: 3.13.7
Flutter_map: 4.1.3
flutter_map_tile_caching: 8.0.1
(isar: 3.1.0+1)

I was running into this issue on iOS with multiple tile stores. Seems I was able to get past it for now by:

skipping the auto migrator
reducing databaseMaxSize = 256

JaffaKetchup commented 10 months ago

@eidolonFIRE Thanks for that helpful workaround! Just to note, that will mean you can't store any more than 256 MBs of tiles!

Just an update on how things are going, I've recently written this paragraph to a private user, that I'll share now:

Unfortunately, we haven't heard from Simon, the Isar maintainer, in a couple of months, back when the last Isar prerelease was published.

This means that I'm worried about sticking with Isar. Isar is probably the most performant database available for Flutter (due to it's backend being written in Rust, which is coincidentally what causes issues (along with the MDBX database behing Isar) on iOS devices), particular when using more than one store. However, if it's not being maintained, I'm not 100% comfortable keeping it being FMTC, especially as it's causing many bugs. I have searched for alternatives, but I can't decide on one. Additionally, one of my last remaining aims for v9 is to remove the duplicate of tiles between stores. However, making this performant is difficult now, as 'links' used for expressing relations have been removed from Isar, and alternative joined queries from composite indexes no longer seem to be available either - support for updating records is basic and essentially involves a query lookup, read and write operation for every browsed tile, which is three times as expensive as it is currently. This makes expressing a many-to-many relationship between tiles and stores difficult, especially while keeping it performant at a scale of hundreds of thousands of tiles. Import/export operations with the sharing plugin will also need to be rewritten and will become much slower. I'd be interested to know whether you are using this functionality?

Further compounding the slow development of FMTC recently is that I've started (the equivalent of) college in the last few months, and combined with the development on FM, I've been short on time. Hopefully I can start working more seriously on FMTC again now that FM v6 has been released (although there are more developments going on privately), and I have indeed made a few non-trivial commits to the example application of FMTC v9 within the past week.

My recommendation would be to migrate to v9 now. It has awesome new functionality and performance enhancements, and very few bugs - along with a complete set of up-to-date documentation. FM v6 is also a huge step up. One known bug is with the download recovery system, so you may wish to switch that off, along with the store recovery system if it's causing crashes. I think that the API in the latest prerelease is unlikely to change significantly, even if I tear out the entire database. I think the most likely change is a change to what operations are sync/async. I would recommend however, pinning to the latest prerelease specifically, just so that there aren't any unforeseen issues.

Thank you all for sticking with FMTC through these issues (especially @eidolonFIRE @ozzy1873), I'm hoping that they can be resolved soon! In fact, I'm writing to the maintainers over at ObjectBox to ask for clarification on a few things, and if that all goes well, the database rewriting will begin!

eidolonFIRE commented 10 months ago

Thank you @JaffaKetchup !

Reliability is more important to me than performance. It does appear that Isar has being the source of ongoing disruption and headache. I'm definitely in favor of migrating to something maintained and reliable.

Thank you for the update.

JaffaKetchup commented 7 months ago

Hey there (@ozzy1873 @eidolonFIRE and others)! A little update on how things are going with the v9 upgrade for those interested.

I've been working hard over the past month or two, and I think (hope) most of the new database methods are in place for the management and statistics of stores - bulk downloading methods are on their way, but are a little bit more complex with the new 'detached backend' system I've adopted (which should hopefully allow you to switch out storage mechanisms if ObjectBox doesn't work). It's now about the bulk downloading methods, then finalizing the surrounding framework, connecting everything together, and polishing, then debugging.

I'm still not sure how long v9 will be, but progress is being made slowly. One thing that doesn't help is the virtual lack of ability to test FMTC until the migration is pretty much complete - I've been tearing out whole chunks of poorly designed internals, trying to get it right this time around. I'm essentially coding in the blind, hoping that the decisions I make are mostly bug free and performant.

There could be a significant API difference in v9. I think the idea will remain the same, but there will be no support for synchronous methods - this will take too much time to implement, and I have cut this to save time. There are options for implementing it later. Additionally, there will be no migration support for v9.

If you have any questions, please let me know. You can always follow more closely with my progress on the PR branch.

Also just wanted to make it clear I'm not abandoning this library :D

JaffaKetchup commented 7 months ago

Huge thanks to the author of this comment who may have just found a viable workaround for some cases! Check it out and please let me know if it works for you. If it does, I can document it.

https://github.com/JaffaKetchup/flutter_map_tile_caching/issues/144#issuecomment-1909057930

eidolonFIRE commented 7 months ago

Confirmed!

With those two "Capabilities" added to my xCode project, I am able to run on a device that didn't work before. 🎉 Will post again if I run into issues after deployment, but so far it looks good.

JaffaKetchup commented 6 months ago

Another quick update: v9 has progressed significantly over the past 2 or 3 weeks 🎉 I've now got it to a stage where it does compile the example application, and is not completely broken! Some features are not transferred yet (such as watching), some features haven't been tested, and some are definitely broken. But I believe that the core ideas/template and the vast majority of the implementation is looking good. There's still a long way to go, though. I'm hoping no more than a month or so, and will give progress updates here as I go. There is likely to be one more prerelease before the v9 release, as it would be helpful to get some outsider feedback and testing once it's mostly ready. If you're up for that, please let me know.

eidolonFIRE commented 6 months ago

I'm up for trying the next pre-release! 👍

seabass123 commented 6 months ago

Hey, i'd like to report this bug on v9 on Android

flutter_map: ^6.0.1
flutter_map_tile_caching: ^9.0.0-dev.5
Flutter 3.19.0 • Dart 3.3.0

Phone: Wiko Y81
OS: Android 10
Fatal Exception: IsarError: Cannot open Environment: MdbxError (12): Out of memory

JaffaKetchup commented 6 months ago

(@eidolonFIRE @mohammedX6 and others)

I'm pleased (and exhausted) to announce that the next (and hopefully final) prerelease is now available: https://pub.dev/packages/flutter_map_tile_caching/versions/9.0.0-dev.7. ObjectBox has finally arrived! A provisional CHANGELOG is available at https://pub.dev/packages/flutter_map_tile_caching/versions/9.0.0-dev.7/changelog#900---hundreds-of-hours---2024xxxx.

Some things to note:

148
Importing functionality is not yet working
There is no gurantee for stability in this version: I have done basic testing only
There is little/no documentation available outside of what is in the code, including no migration info; I'll be happy to answer questions here, but some answers can be found in the CHANGELOG
No data from older versions will be available, but the databases will not be modified/deleted - check your storage space if necessary
You will require the latest Flutter and Dart stable releases, and FM v6

I'm really eager to hear feedback. The number one thing I want to hear is that there are no(!?) crashes! But I also want to hear about bugs you've found. At this point, I cannot take further feature requests: I cannot afford the time to expand the scope of this further at the moment.

JaffaKetchup commented 5 months ago

Check out the new v9 documentation: https://fmtc.jaffaketchup.dev/v/v9-beta! (Import/export functionality has not been updated, and no migration guide is available yet).

JaffaKetchup commented 5 months ago

(@eidolonFIRE @mohammedX6 @Soap-141 and others) The final prerelease version is now available. It contains some bug fixes from the previous version, as well as fully functional import functionality. Some migration documentation is available at https://fmtc.jaffaketchup.dev/v/v9-beta/get-started/v8-greater-than-v9-migration. This is the last chance for some bug testing!

JaffaKetchup commented 5 months ago

I'm pleased to announce the release of FMTC v9! Thanks for all the support along the way :)

I would be extremely greatful for any donation you can spare, but of course, there's no need :). If you find any issues with the new release, please create a new issue.

pub.dev: https://pub.dev/packages/flutter_map_tile_caching CHANGELOG: https://github.com/JaffaKetchup/flutter_map_tile_caching/blob/main/CHANGELOG.md Documentation: https://fmtc.jaffaketchup.dev/ Donate: https://github.com/sponsors/JaffaKetchup/

JaffaKetchup / flutter_map_tile_caching