android-money-manager-ex
android-money-manager-ex copied to clipboard
moneymanagerex
Issue with sync
On the latest version of MMEx I have found a few issues. I would consider these major issues.
Issue 1: Add transaction on app on phone and sync. On desktop that transaction is there. Add transaction on desktop. Open app on phone. Transaction not there. Sync phone. The transaction not there. On desktop transaction disappears. This is looking like it is overwriting the file on the synced server.
Issue 2: Add transaction on app on phone and sync. On desktop that transaction is there. Add transaction on desktop. Open app on phone. Transaction not there. Sync phone. App keeps crashing while trying to sync. Only way to sync is clear the app's data and re-setup.
Issue 3: Add transaction on app on phone and sync. On desktop that transaction is there. Add transaction on desktop. Open app on phone. Transaction not there. Sync phone. Says the file has not changed and refuses to sync.
I have seen all of these with both Sync.com and pCloud. Unpredictable which one that will happen.
From my point of view some of these issues discussed in #1306 in detail
Issue 1 seems to be a problem of the SAF (Storage Access Framework) which is used now. I will test this later this day using Google drive
Issue 2 is known bug and should be fixed with #1309. as workaround reopen the database file located on cloude storage again, but be sure that you did not change the local database, because this action overwrite it.
Issue 3 i can confirm and it seems to be a problem of sync function in MMEx which did not recognize the change
As general workaround i did not use the desktop app till sync is working well again.
Looking at those issues, they look like they are practically the same as this one. I searched around for issues like mine, but for some reason did not find any. My work around was to downgrade to pre-SAF to use both desktop and android app.
I agree, there is something wrong with sync in MMEx current version, but i believe downgrade will be a dead-end in the (near) future, but it works for the moment
I have replayed the described issue 1 with current MMEx Version an Adroid Phone and Windows 10 PC with google drive cloude storage and result is different :
Issue 1: Add transaction on app on phone and sync. => ok On desktop that transaction is there. => ok Add transaction on desktop. => ok Open app on phone. Transaction not there. => ok Sync phone. The transaction not there. => transaction is there On desktop transaction disappears. => transaction is there
But, if i delete the both transactions made on app and pc at the phone and sync, the app crashed. The only way to "recover" is to open the mmd file located on the cloud storage (google drive) and loss all the changes made on the phone app.
still an issue and i have no idea what the cause can be. i will take a look at the logcat.
How would downgrade be a dead-end in the future?
Looks like the SAF code needs refinement. I would jump in, but I know nothing of android development.
For me it looks like the app detects a conflict between the locally stored mmd (/storage/emulated/0/MoneyManagerEx/test.mmd) and the mmd file in the cloud and can't handle it.
From my point of view there are two possibilities:
-
build the MMEX sync procedure as follow: a) app detect that local file is more actual as the cloud version => copy local file to cloud folder b) app detect that cloud file is more actual as the local version => copy file from cloud folder to local folder c) app detect that both files are equal up to date => show message and ask which version (local or cloude) should be used => Disadvantage: i) In any case, there is a risk of losing changes, because not the content, but only the change date is compared. But that's how it was pre-SAF. ii) If the clock of a device is going wrong it is not work anymore. But also that has been so far.
-
Do not use a local version of the mmd file, only the one stored in the cloud. => Disadvantage: If you have no access to cloud storage the MMEX app can not be used. Bad idea :-)
Option 1 or a similar solution should be implemented with #1309.
Only my 5 cent, I hope I'm not completely wrong and I'm upset that I can't program and help.
"Dead-end" because you miss all new features and any corrections of errors for the MMEX app and i can imagine after any future Android update the app will not work anymore.
For my opinion it's nessecary to use the latest current version of operating system and applications ...
Ah, I was thinking that it would just stop working for some reason inside the code. I have already experienced issues with apps not working on newer versions of Android with no possibilities of updates. That is the reason I came over to this app.
Number 1: I would suggest to have the user solve any conflict issues and use time stamps down to the second, if using timestamps. Also to save a copy while appending "CONFLICTED" to the database file name like a lot of cloud providers do, to prevent loss of data. I do remember in the pre-SAF app, which I still use for the moment, is if both have been changed, then there is a conflict regardless of dates. I would just have to copy the missing transactions from the mobile to the desktop (by hand) and force the mobile to download from cloud.
Number 2: This could be a problematic setup. I personally would have no issue with no offline access, but would suggest it be in the settings for the user to choose this. I don't usually not have access to the internet on my mobile, but others might have that issue.
Syncbits.com might be a option. It syncs transactions, not entire files. Free account. Also possibly using a Google Sheet as a database?
i completely agree with you, number 2 should be implemented (again)
A spread sheet is'nt really an alternative because a finance app like MMEX has a lot more important functions
But http://syncbits.com/ sounds very good and helpful but i'm not able to rate if it is helpful. Perhaps @MisterY can do this?
I once thought of making just a simple checkbook app using just a Google Sheet, but started trying to learn Android App dev right as I got busy and couldn't focus on it.
Syncbits.com might be outside of the scope of what @MisterY is doing with this. Might rule it out of release on F-Droid. I just have not looked too far into it, and the company behind it might have some rule against using it because they release a paid for competitive product.
For me it looks like the app detects a conflict between the locally stored mmd (/storage/emulated/0/MoneyManagerEx/test.mmd) and the mmd file in the cloud and can't handle it.
This is (or, rather, will be) handled in #1309
From my point of view there are two possibilities:
1. build the MMEX sync procedure as follow: a) app detect that local file is more actual as the cloud version => copy local file to cloud folder b) app detect that cloud file is more actual as the local version => copy file from cloud folder to local folder c) app detect that both files are equal up to date => show message and ask which version (local or cloude) should be used => Disadvantage: i) In any case, there is a risk of losing changes, because not the content, but only the change date is compared. But that's how it was pre-SAF. ii) If the clock of a device is going wrong it is not work anymore. But also that has been so far.
If you look at this, can you tell me how different is it to what you suggest?
Guys, the conflict crash will be handled when #1309 is fixed. At the moment I can't help much with other issues. The things on the MMEX side are extremely simple now. The file is copied from a document provider and dates are stored in the metadata. If files are not updated or the metadata is incorrect, then perhaps bugs can be submitted to the provider apps. If you find out more technical details, please provide them here. Also try another provider (the simplest would be the SD Card) and see if the behaviour is the same. I'm using pCloud but only one-way at the moment.
Well, the issues I saw I saw with two providers. Sync.com and pCloud. I did not mean to report the same issue as #1309. I was searching the issues to see if I found one that matched what I saw so I would not double post. The only issue I saw that #1309 does cover is issue 2. Issue 1 and issue 3 are not a crash issue.
From my point of view wie should wait until #1309 is fixed and then test again. I could not reproduce issue 1 with Google drive. (See above) Issue 3 seems to be related to the sync problem. (See above)
Lets wait and see if sync is fixed and we get messages if sync is runing. I'm sure we will find the cause for issue 3 in a structured analysis.
Right now it sounds like the best course of action is to wait for #1309 to be completed. That is what I will do.
It has been published to Play Store (and hopefully F-Droid). v2019.02.19.995. Please report if other issues are still valid. Thanks!
Unfortunately, it will not show up in Play Store as the update was just rejected. The app has been unpublished from Play Store. You can try the Releases page here on GitHub or wait for F-Droid distribution to finally come alive (the app has been in the pipeline for about a week).
Retesting issues Issue 1: Still an issue. Issue 2: Display message now about being a conflict. Doesn't resolve the issue. To me this is as expected. Issue 3: This now reports there is a conflict. I have to force reopen from the cloud provider. The transaction from the desktop is still there.
Kinda acts like it does not keep track of the version on the cloud and local.
Sorry, accidentally closed issue.
The dates you can test / confirm yourself. Once the file is uploaded, check the database file info in the storage provider app. It will give you the last modification date. Unfortunately, it is not easy to get to the MMEX metadata unless you have root access. In that case it is in the app's installation directory, among the xml files, named something like "recent databases". I might need to expose the metadata, which is used for synchronization, somewhere so that users can troubleshoot directly. Basically, the change date/time is stored once the file is retrieved initially. Afterwards, the provider is queried for the latest server update. I've noticed with KeePass and pCloud that there are multiple listings of the file on Android, but not on desktop. I wonder if the file handle that is sent by the provider is a previous version of the file.
I do have root access. I just did not look for this meta data. I set up the new version of the app. Both Desktop and Android match. I add on the phone and it goes to the desktop perfectly. If I add on the desktop, then the app will overwrite what is on the server. Something is in disconnect with how MMEX compares. I have two providers doing exactly the same thing.
F-Droid updates are on. The current version there is not the latest, though. The latest one should be picked up within the next 24 hours, I guess.
Is it correct that Android MoneyManagerEX and updates for it will no longer be available in the Google Play Store and only in F-Droid? Or in both app stores?
:-) in the meantime I read the messages in Twitter and these answer my question. Thanx
Hi, Could you recommend a sharing service that surely works at this current time? I'm not married with Google drive (mmex does not upload the database also for me), but we would like to use mmex as a family. Thanks
@aranyg, I can't really recommend anything. I'm currently using pClound and am happy with it. Other users are successfully using various other services. Practically, anything that integrates into Android Storage Access Framework can be used so you can try out different services and providers. The replacement of the cloud sync libraries is quite recent and might still need to be polished a bit (as this issue indicates).
@aranyg I have none to recommend, but here are a few that will work because their apps use SAF: pCloud Sync.com (I personally use this one. It is a Zero Knowledge provider.) Box Google Drive
Hi everyone. Just to put my two cents on the issue. I have tried everything I have moved my mmex to OneDrive, DropBox, Google Drive and pCloud. Haven't achieved seamless sync on either of them. The best scenario that I have at the moment is using a 3rd party application named DropSync. That is doing the syncing instantly when mmex is changed on Android and is checking every 15 minutes the cloud for any changes on DropBox made by windows MMEX app. Dropsync is not working as I expected but is the closest to the best scenario of a sync without conflicts. I am not sure If I am doing something wrong using the mmex Android sync. It seems that I have to always manually sync before exiting or starting using the app otherwise it is not syncing automatically. Best regards and keep up the good work.
@CDevel, there are some issues, as you indicate towards the end of your post. This has been reported earlier (before the SAF changes), in a thread about WebDAV support or OwnCloud, not sure. As the system (Android) manages database flushing and reading, and the database is read to memory, you may experience weird issues by overwriting the database file while the app is in memory. To normal users I would not recommend doing this but to power users I certainly would. Then they can discover more details and write to others about it. ;) My feeling is that databases on Android are meant to be in the app-specific folder, accessible only to the app. Other scenarios aren't really accommodated to, unfortunately.
@MisterY Thank you for the answer. I really enjoying MMEX for the last 4 years. I will stick to the plan described above. It seems to works most of the times. I sync with another app the storage/emulated/0/Android/data/com.money.manager.ex/files/databases to my dropbox MMEX folder. Instrant uploade works ok until now and casually checking of the dropbox is ok for me. I did try to create a task with tasker to automatically do a sync every time I launch MMEX on my android but I haven't managed to achieve what I want. I will try again some time. Thanks again.
Maybe @funrider1 suggestion to not download a local copy might be the work around for this issue. I would suggest to have a setting to turn on and off this online only set up though.