starred/sms-backup-plus-jberkel

Fork 0

mirror of https://github.com/jberkel/sms-backup-plus.git synced 2026-04-26 01:15:58 +03:00

[GH-ISSUE #480] Restore order #408

New issue

Closed

opened 2026-02-26 01:30:28 +03:00 by kerem · 5 comments

kerem commented

2026-02-26 01:30:28 +03:00

Owner

Originally created by @ashh87 on GitHub (Oct 6, 2014).
Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/480

I restored my sms messages and found them to be in the wrong order. From what I can see, this is due to #269, and also maybe #94. I'm not sure if they're the same thing and they've both been inactive for a while, so I've started a new issue.

To get messages in the right order on (for example) Sony phones, it looks like they have to be inserted oldest first, which conflicts with peoples' want to have newer messages available at the start of the restore, so cancelling midway gets the most recent ones restored.

To deal with this, I propose splitting the restoration process into two phases: message download and then message restore. Instead of adding messages one by one, messages should be downloaded newest first and added to a local storage. Instead of the local cache, which I see gets wiped, the messages could be saved locally using something like the k9 LocalStore. If the restore is cancelled, then the messages can be added to the real sms store as a 'tidying up' stage. The downloaded messages would be iterated through in reverse order, meaning they display correctly (hopefully) on Sony etc devices, and fulfill the newest restored first idea. Hopefully, this tidying up should be relatively quick, as the messages are already downloaded...

In #269, MarSoft describes another problem with restoring on Sony devices. If new sms messages aren't synced, then restoring older messages will bury them. I think the solution to this could be to first ensure that a backup is made if the user has allowed it. Remaining unsynced messages should then be added to the (top of the) local storage, and the sync can continue as normal. I've not looked at what duplicate detection the app does, but restoring messages one by one will allow duplicates to be deleted one by one (so crashes/cancelling doesn't trash the lot) and reinserted.

After all this, the workaround linked to in #94 could be considered in necessary. There might also be the possibility of reducing overhead by calling ImapStore's fetch with more than one message at a time, as messages would no longer be processed individually at the download stage.

Originally created by @ashh87 on GitHub (Oct 6, 2014). Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/480 I restored my sms messages and found them to be in the wrong order. From what I can see, this is due to #269, and also maybe #94. I'm not sure if they're the same thing and they've both been inactive for a while, so I've started a new issue. To get messages in the right order on (for example) Sony phones, it looks like they have to be inserted oldest first, which conflicts with peoples' want to have newer messages available at the start of the restore, so cancelling midway gets the most recent ones restored. To deal with this, I propose splitting the restoration process into two phases: message download and then message restore. Instead of adding messages one by one, messages should be downloaded newest first and added to a local storage. Instead of the local cache, which I see gets wiped, the messages could be saved locally using something like the k9 LocalStore. If the restore is cancelled, then the messages can be added to the real sms store as a 'tidying up' stage. The downloaded messages would be iterated through in reverse order, meaning they display correctly (hopefully) on Sony etc devices, and fulfill the newest restored first idea. Hopefully, this tidying up should be relatively quick, as the messages are already downloaded... In #269, MarSoft describes another problem with restoring on Sony devices. If new sms messages aren't synced, then restoring older messages will bury them. I think the solution to this could be to first ensure that a backup is made if the user has allowed it. Remaining unsynced messages should then be added to the (top of the) local storage, and the sync can continue as normal. I've not looked at what duplicate detection the app does, but restoring messages one by one will allow duplicates to be deleted one by one (so crashes/cancelling doesn't trash the lot) and reinserted. After all this, the workaround linked to in #94 could be considered in necessary. There might also be the possibility of reducing overhead by calling ImapStore's fetch with more than one message at a time, as messages would no longer be processed individually at the download stage.

kerem closed this issue

2026-02-26 01:30:28 +03:00

kerem commented

2026-02-26 01:30:28 +03:00

Author

Owner

@matthiasdg commented on GitHub (Nov 15, 2014):

I had this problem too on my new Xperia Z3 Compact. At first I tried avoiding it by using Sony's Bridge application on my laptop to backup and restore SMSes, but there I had some problems as well (could not see sent SMSes, only received ones in most SMS apps, while in the default messaging app I would see everything but conversations with 1 person ended up as group chats with multiple (identical) contacts, and new texts from that contact would even begin a new thread).

As a quick fix (easier than rooting and messing with the database), I simply deleted all messages from my phone, commented eda0822527, rebuilt the app and restored everything. In the default messaging app, all times where now the restore times, but they're ok in e.g. hangouts, textra...

It would be nice if there was some fix; this app is probably mostly used when switching phones, so personally I could even live with the risk of buried unsynced messages

@matthiasdg commented on GitHub (Nov 15, 2014): I had this problem too on my new Xperia Z3 Compact. At first I tried avoiding it by using Sony's Bridge application on my laptop to backup and restore SMSes, but there I had some problems as well (could not see sent SMSes, only received ones in most SMS apps, while in the default messaging app I would see everything but conversations with 1 person ended up as group chats with multiple (identical) contacts, and new texts from that contact would even begin a new thread). As a quick fix (easier than rooting and messing with the database), I simply deleted all messages from my phone, commented eda08225273351997adfa4d87e178e5e70f0580c, rebuilt the app and restored everything. In the default messaging app, all times where now the restore times, but they're ok in e.g. hangouts, textra... It would be nice if there was some fix; this app is probably mostly used when switching phones, so personally I could even live with the risk of buried unsynced messages

kerem commented

2026-02-26 01:30:28 +03:00

Author

Owner

@mathrick commented on GitHub (Dec 20, 2014):

@matthiasdg Do you mind sharing the .apk? I was about to do the same.

@mathrick commented on GitHub (Dec 20, 2014): @matthiasdg Do you mind sharing the .apk? I was about to do the same.

kerem commented

2026-02-26 01:30:28 +03:00

Author

Owner

@matthiasdg commented on GitHub (Dec 20, 2014):

Sure, you should be able to download my build from
https://docs.google.com/file/d/0B-BnWlksRS9QZW5wR2ZUN1RrdWc

@matthiasdg commented on GitHub (Dec 20, 2014): Sure, you should be able to download my build from https://docs.google.com/file/d/0B-BnWlksRS9QZW5wR2ZUN1RrdWc

kerem commented

2026-02-26 01:30:29 +03:00

Author

Owner

@mathrick commented on GitHub (Dec 20, 2014):

Thanks!

@mathrick commented on GitHub (Dec 20, 2014): Thanks!

kerem commented

2026-02-26 01:30:29 +03:00

Author

Owner

@jberkel commented on GitHub (Jun 12, 2015):

@ashh87 the restore improvements you describe sound reasonable. unfortunately i probably won't work on it anytime soon.

@jberkel commented on GitHub (Jun 12, 2015): @ashh87 the restore improvements you describe sound reasonable. unfortunately i probably won't work on it anytime soon.

kerem referenced this issue

2026-02-26 01:32:30 +03:00

[PR #408] [MERGED] Catalan translation #961