[smw]

I don't actually need to run MobileSheetsPro on my phone (a Samsung Galaxy Note 4), but since the newest version is supported I thought I'd give it a try.

...but when I tried to restore a backup made on my tablet, the restore failed with

   The restore has failed to complete due to an error:

        java.lang.NullPointerException

   Your library may no longer work correctly.

[Zubersoft]

Does your phone have enough storage space on the internal SD card to hold all the files from the backup? I just restored a backup on my phone and had no issues. When was the backup created and which options did you choose for it?

Thanks,
Mike

[smw]

Does your phone have enough storage space on the internal SD card to hold all the files from the backup? I just restored a backup on my phone and had no issues.  When was the backup created and which options did you choose for it?

Thanks,
Mike

The backup is 1.4 Gb, and was made tonight expressly for the purpose of copying to the phone.

Backup options were:

   - don't include audo files
   - do include settings

On the tablet the storage settings are

   - do allow MobileSheets to manage
   - storage location is internal memory
   - do expose the database file

I established the same settings on the phone before trying the restore, except that there the storage location is a directory on the external SD card.

Yes, there's enough space on the phone (18 Gb internal, 24 Gb on the external SD card).

...but I think I just realized what happened:  the failure I reported above occurred when I tried to restore settings from the backup; I tried again just now while typing this, and this time (without attempting to restore settings) the restore worked.

The library view shows everything I expect to see.

The first time I tried to view a song MobileSheets crashed, but on subsequent attempts everything looks good.

I'm guessing that the moral of the story is that saving and restoring settings doesn't work perfectly across different devices.

[Zubersoft]

The biggest danger with saving/restoring settings across devices is when it comes to the storage location. Especially if the storage location is set to an external SD card, this probably will not work across devices. I tried to add code to handle this (where it falls back to using the regular storage location) but it sounds like that is not working correctly for some reason. I will work on this as I believe I should be able to address it. I'll also look into that crash you experienced.

Thanks,
Mike

[smw]

The biggest danger with saving/restoring settings across devices is when it comes to the storage location.  Especially if the storage location is set to an external SD card, this probably will not work across devices. I tried to add code to handle this (where it falls back to using the regular storage location) but it sounds like that is not working correctly for some reason. I will work on this as I believe I should be able to address it.  I'll also look into that crash you experienced.

Thanks,
Mike

One idea that comes to mind is than when a restore including settings is initiated, if there are any paths in the backup image which don't exist on the device where the reload is done, bring up a dialog box and ask the user which paths to use.  I don't suggest that this is necessarily the best possible thing to do, just one way it could be done.

...but in general, yes, this kind of thing is really tricky to get right in general.

Meanwhile, thanks again for all the fixes, and also for the ability to put MobileSheets on my phone -- I don't plan to do much reading on the phone , but it's nice to be able to do the occasional lookup when my tablet isn't handy.

[sciurius]

One idea that comes to mind is than when a restore including settings is initiated, if there are any paths in the backup image which don't exist on the device where the reload is done, bring up a dialog box and ask the user which paths to use.

This sounds to me like a good solution.

[BRX]

I won't start a new thread for this since it might be related.

I wanted to mirror my files and database to my phone without creating a backup, but I failed so far.

Mike please tell if this should work at all or if the failure is related to other problems. Here's what I did:

I mirrored my sheets directory from the SD card of the tablet to the SD card of the phone. Files and paths are identical.
Then I copied the contents from the internal storage of the tablet from /android/data/com.zubersoft.mobilesheetspro to the respective dir of the internal storage of the phone.

Can this work or am I thinking to simple?

[sciurius]

At least you're overlooking that the user ids of MSPro will be different on the devices so you may run into file protection problems.
Also "failed so far" is a bit vague. What works, what doesn't work, what messages (if any).
If you want backups and mirrors, I'd advice to use TitaniumBackup.

[BRX]

sciurius, you're not quite seeing my point in trying it this way.

First I want to know if this method may work in general. Maybe there are settings stored elsewhere. There aren't messages so far. I assumed my annotations, cuts and so on would appear in MSP on the phone if I copy it, but they don't.

And I don't want to do complete backups. I know Titanium Backup but I haven't rooted my devices (so far). And - as I wrote in another thread - I already kept a mirror of my files and the sheets dir on my PC. It will be far more efficient and quicker (IMHO) to just keep this dir in sync with the Android devices (manually or with a compare program like Beyond Compare) and just copy the settings and database to the device that needs to be synced/updated. Especially if you have a large amount of sheets.

[Zubersoft]

BRX,

Your approach will work if you can copy the database and settings files into the right location. If you have "Expose Database" checked in the storage settings, then it will be saved in the storage location instead of in private application data, so you can easily replace that file. The settings files would only be accessible if you have rooted your tablet, because they are always stored in private application data (and that can't be changed).

Mike

[BRX]

I didn't check the "expose database". Thought it wasn't necessary since I implied the settings would be saved there as well.

Now it's working as I expected. VERY NICE! :-)

I can live with the settings not being accessible now. Those are easily duplicated manually. Maybe I'll take this as incentive to root my devices finally though.

Thanks.

[Zubersoft]

As far as the suggestion to prompt the user if the storage location specified in the backup doesn't exist, this is actually quite difficult to do. The reason is that all of the backup restore logic takes place in a background thread. Marshalling data between threads and having to use locks to stop background threads while they wait for the primary thread is doable (I've already had to do this in some places like during file imports when conflicts are detected), but it can get quite messy. The bigger issue is when it comes to selecting the path that the user wants to use. Even if I could hack together all the code to make that work on the tablet, it won't work at all from the companion application as I don't currently have a file browser implemented in it that can get all of the paths on the tablet through the wifi connection.

If I wanted to go this direction, I would probably want to add the storage location as a separate field in the backup file so that I don't have to try to parse it out of the settings files. That way I could open the backup file before initiating the restore, check the validity of the storage location path (if one is specified) and then prompt the user to specify a new path. This would work well on the tablet, but I would still have the issue with the companion app (and I couldn't just have them pick the path on the tablet as switching activities would kill the wifi connection most likely).

For now, I'll just try to handle this as gracefully as I can, and the user will have to move files to a different storage location if they don't like the one that is chosen. What I think I will do is cache the storage location before the restore starts, and if the new one is invalid, I will switch back to what was selected before. That way people can set up the storage location they want if they know the current one won't work on a different device.

Mike