Android design pattern (15th)-Memorandum pattern, android Design Pattern

Android design pattern (15th)-Memorandum pattern, android Design Pattern

In Android, The onSaveInstanceState () used to save the Activity state and the onRestoreInstanceState () used to restore the Activity state (),

Isn't this a memorandum model?

1. Definition:
Capture the internal state of the object without damaging the encapsulation, and save the state outside the object so that the State can be restored later;

2. Use:
The memorandum mode is suitable for classes that have complex functions but require maintenance and record history, or classes that need to save one or more attributes,

Restore it to the original record status when required in a certain period of time in the future;

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

3. Others:

The memorandum mode is also called the Snapshot Pattern or Token mode, which is the behavior mode of the object;

4. Simple demo:

First, the object data to be processed:

Package com. example. demo. memento;/*** object * @ author qubian * @ data June 20, 2015 * @ email naibbian@163.com **/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 createmento (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 store the same data as the processed object, or you can modify and set your own data as needed;

2. The explicit function is only used to store and restore the objects to be processed. Therefore, the data in it can be agreed at will,

3. The problem arises. The backup data is generally stored in the memory and used to restore objects. If the processed objects are serialized, or use reflection and other technologies for storage and recovery. Is it meaningful to store the data in the disk, or is it against this design pattern?

4. That is, the original problem. In Android, data in onSaveInstanceState is generally stored in Android to restore the Activity after being destroyed in the memory, the object stored in the memory in the memo mode does not seem to make any sense at this time !?

Package com. example. demo. memento;/*** memo data * @ author qubian * @ data June 20, 2015 * @ email naibbian@163.com **/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 ;}}

Memorandum managers and users:

Package com. example. demo. memento;/*** memorandum mode * administrator * @ author qubian * @ data June 20, 2015 * @ email naibbian@163.com **/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 status MementoManager manager = new MementoManager (); manager. setMemento (bean. createMemento (bean. getName (), bean. getAge (); // change the status bean. setAge ("23"); // restore the original state bean. restore (manager. getMemento ());}}

The Data Object Memento can be stored in the administrator for unified management;

There can also be multiple Memento statuses in the manager. In the above example, only a simple state is stored;

5. In the definition of the memorandum mode, it means to save the state of this object outside of this object. If so, there is memory and disk, after processing, the system returns the original object data, which seems to be a memorandum mode ?!

6. Android:

1. In this case, the Activity itself uses this design pattern,

2. When switching between the portrait and landscape screens, the Thread will be restarted. This problem needs to be handled during the switching of the landscape and landscape screens. Therefore, we need to consider this mode here, this is the data in the thread when the thread is restarted. We must also use this mode to save the original data;

3. Does the local JNI code Save () and Restore () in the Canvas of JNI call local data also use this design pattern ?!

public class Canvas {        /**     * Saves the current matrix and clip onto a private stack. Subsequent     * calls to translate,scale,rotate,skew,concat or clipRect,clipPath     * will all operate as usual, but when the balancing call to restore()     * is made, those calls will be forgotten, and the settings that existed     * before the save() will 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 will all operate as usual, but when the balancing     * call to restore() is made, those calls will be forgotten, and the     * settings that existed before the save() will 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 are directed there, and only when     * the balancing call to restore() is made is that offscreen transfered to     * the canvas (or the previous layer). Subsequent calls to translate,     * scale, rotate, skew, concat or clipRect, clipPath all operate on this     * copy. When the balancing call to restore() is made, this copy is     * deleted and the previous matrix/clip state is restored.     *     * @param bounds May be null. The maximum size the offscreen bitmap     *               needs to be (in local coordinates)     * @param paint  This is copied, 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 is used to remove all     * modifications to the matrix/clip state since the last save call. It is     * an error to call restore() more times than save() was called.     */    public native void restore();}