On Mon, 27 Jun 2011 01:55:45 +1200, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
On 2011-06-26 at 11:08:03 [+0200], Clemens <clemens.zeidler@xxxxxxxxxxxxxx>wrote:On the other side I don't know if its a good idea to store unsaved document at all. When closing an application the app ask to save the doc anyway. If the user clicks no it does not make sense to store the doc IMHO. In this case a BMessage should be enough to store the app state. What do you think?IMO session management should persist the complete state, including unsaveddocuments and undo histories. If necessary, a setting could be added, so that the user can disable that behavior and be asked whether to save changes instead.
I think that can become quite complex to implement on app side e.g. the developer has to check if the file has changed since the last session (e.g. by another OS) and handle this case. I'm not sure if it is a good idea to make it a required policy, maybe an optional behaviour for apps who support it. I would let developer the easy option to support session management as good as they can/ as much as it makes sense for their application. Storing and restoring a undo history sounds not trivial but is definitely desirable.
What do you think of the API? Actually I'm a bit unhappy about the new storage classes because they do not fit the Archive api where just one BMessage is used to store all data. What do you think about providing a path in the state message:
virtual status_t SaveState(BMessage* state);This path would point to a directory where additional files for this application can be stored. Its a bit hacky but it would fits more the archive semantics.
Android also just use a Bundle (BMessage like container) for that *) This requires that also unsaved docs are saved in the Bundle...
Regards,
Clemens
*)
http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState(android.os.Bundle)
