Android design mode (15)--Memo mode

Onsaveinstancestate () and onrestoreinstancestate () to restore activity status in Android,

Is this sort of a memo model?

1. Definition:
The internal state of the object is captured without destroying the package, and the state is saved outside the object, so that the later saved state can be restored later;

1. Function:
Memo mode, which is suitable for classes that are complex in function but need to maintain and record history, or a class that needs to hold one or more attributes.

When needed in the future, restore it to the state of the original record;

Originator can be restored to the previous state based on the saved Memento;

3. Other:

The memo mode is also called: Snapshot mode (Snapshot pattern) or token mode, which is the behavior pattern of the object;

4, The Simple demo:

The first is the object data that needs to be processed:

Package com.example.demo.memento;/** * Object * @author Qubian * @data June 20, 2015 * @email [EMAIL protected] * */public class Bean {private string Name;private string Age;public string GetName () {return name;} public void SetName (String name) {this.name = name;} Public String Getage () {return age;} public void Setage (String age) {this.age = age;} Public Memento Creatememento (String name,string age) {return new Memento (name, age);} public void Restore (Memento Memento) {this.name=memento.getname (); this.age= memento.getage ();}}

Memo data object:

1, this can be stored and processed by the same object of data, can also be modified as necessary to set their own data;

2, the need for clear function is only to store and restore the processed objects, so the data can be arbitrarily agreed,

3, then, the problem comes, this backup data, is generally stored in memory, for the recovery of objects, then if the object to be processed, serialization, or use of reflection and other techniques for storage and recovery, then this is stored in the disk, so it makes sense, or violates the design pattern?

4, that is, the original problem, in the Android onsaveinstancestate data, is generally used by the Android storage, is to destroy the activity in memory after the recovery problem, then the memo mode is stored in the memory of the object, At this point, there seems to be no meaning!?

Package com.example.demo.memento;/** * Memo Recorder Data * @author Qubian * @data June 20, 2015 * @email [EMAIL protected] * */public Class Memento {private string Name;private string Age;public Memento (String name,string age) {this.name=name;this.age= Age;} Public String GetName () {return name;} public void SetName (String name) {this.name = name;} Public String Getage () {return age;} public void Setage (String age) {this.age = age;}}

Memo managers and Users:

Package com.example.demo.memento;/** * Memo mode * Manager  * @author Qubian * @data June 20, 2015 * @email [EMAIL protected] * */ public class Mementomanager {private Memento memento;public Memento Getmemento () {return Memento;} public void Setmemento (Memento Memento) {this.memento = Memento;}} Package Com.example.demo.memento;public class Usememento {public void use () {Bean bean  =new bean (); Bean.setname ("Zhang San Bean.setage ("22");//Save state Mementomanager Manager  = new Mementomanager (); Manager.setmemento ( Bean.creatememento (Bean.getname (), Bean.getage ()));//Change State bean.setage ("23");//restore Original state Bean.restore ( Manager.getmemento ());}}

In the manager, the memo data Object Memento, can be placed in the management of the unified administration;

In the manager, can also exist in a variety of state Memento, in the example, only a simple state of storage;

5, in the definition of the memo mode, is said to save the state of this object outside of this object, then, if so, there is memory and disk, then processed to return the original object data, it seems to be a memo mode too?!

6. Android:

1. If so, the Activity itself uses this design pattern,

2, in the context of the screen switch, thread threads will be restarted, this problem is the screen switch between the time needed to deal with, then, we need to consider this in this mode, is the thread restart, the thread of data, we are sure to use this mode, to save the original data;

3. is this design pattern also used in the local JNI Code of Save () and restore () in a canvas in which JNI calls local data?!

public class Canvas {/** * Saves the current matrix and clip onto a private stack. Subsequent * calls to Translate,scale,rotate,skew,concat or Cliprect,clippath * would all operate as usual, but whe  n the balancing call to restore () are made, those calls would be forgotten, and the settings that existed * before     The Save () would be reinstated.        * * @return The value to pass to Restoretocount () to balance this save () */public native int save (); /** * Based on SaveFlags, can save the current matrix and clip onto a private * stack. Subsequent calls to Translate,scale,rotate,skew,concat or * Cliprect,clippath would all operate as usual, and when the Balancing * call-to-restore () is made, those calls would be forgotten, and the * settings that existed before the S     Ave () 'll be reinstated.     * * @param saveflags flag bits that specify which parts of the Canvas state * to Save/restore * @return The Value to pass to Restoretocount () to balance this save () */public native int save (int saveflags); /** * This behaves the same as Save (), but in addition it allocates an * offscreen bitmap. All drawing calls was directed there, and only if * the balancing call-to-restore () is made was that offscreen Transf Ered to * the canvas (or the previous layer). Subsequent calls to translate, * scale, rotate, skew, concat or clipRect, Clippath all operate on the this * copy.     When the balancing-to-restore () is made, this copy was * deleted and the previous Matrix/clip state is restored. * * @param bounds may null. The maximum size the offscreen bitmap * needs to being (in local coordinates) * @param paint This is C     Opied, and is applied to the offscreen when * restore () is called.     * @param saveflags See _save_flag Constants * @return value to pass to Restoretocount () to balance this SAVE () */   public int Savelayer (RECTF bounds, paint paint, int saveflags) {return Native_savelayer (Mnativecanvas, Bounds, Paint! = null?    paint.mnativepaint:0, SaveFlags); }/** * This call balances a previous call to save (), and was used to remove all * modifications to the MATRIX/C Lip state since the last save call.     It is * A error to call restore () more times than Save () was called. */public native void Restore ();

Android design mode (15)--Memo mode