Reflex Framework new features-local transaction, no longer worry about the program crashes!

We know that the usability or robustness of the program is very important, if a program crashes during user use, or the data errors are catastrophic.

In order to minimize the probability of error, we think of various methods to reduce errors, fault tolerance, error correction. No matter how you subtract errors, such as improved code quality, test-driven development, extensive testing, and so on, it's still inevitable that there are a variety of bugs to come. Especially if you have a UI that requires the user to be involved, there will be more errors because you don't know how the user is using the application. So fault tolerance is unavoidable!

In Java, there are two types of errors, error and exception. What we can deal with is mainly exception. If you want fault tolerance, you first need to limit the error to a certain range, catch the exception, and more importantly, to ensure the integrity of the data. For example, an action task would have several small tasks, half done, and an exception occurred. What to do? At this point, if the exception is caught, but not enough, the action stays in the middle position, this is a wrong state, need to jump to the correct state. How to do it? That's what we're talking about today--The local firm's work.

The example address is here.

1, first of all, you need to add annotations on the Feel method @transacational

    /** Feel the way, listen to all the buttons in the GridView. */@Recept (Target= "grid.*", stimulation= "Android.view.view$onclicklistener") @Transactional ("Input")    Private voidOnitemclick (TextView view) {String text=View.gettext (). toString ();        Stringinputcenter.input (text); if(Text.equals (stringconstant.exception)) {int[] A =NULL; System.out.println (a.length); //An exception occurred        }    }

In this way, the method is managed by the local transaction, and when an exception occurs inside the method, the exception is automatically caught and the data is rolled back by default.

2, if you need to handle the exception yourself, you can implement the Irollbackthrowableaware interface .

@Receptor Public classStringinputreceptorImplementsirollbackthrowableaware{{...//other omitted
@Override Public BooleanOnrollbackthrowable (FinalTransactionManager TransactionManager, String transactionname, Throwable throwable) {Stringinputcenter.info ("The exception was caught in transaction:" + Transactionname + ":" +throwable.getmessage ()); FinalHandler Handler =NewHandler (); Handler.postdelayed (NewRunnable () {Private intCount = 5; @Override Public voidrun () {Stringinputcenter.info ("Ready to roll back, countdown:" +count); if(count = = 0) {transactionmanager.rollback (); Stringinputcenter.info ("Rollback succeeded!");                Stringinputcenter.refresh (); }                Else{handler.postdelayed ( This, 1000); } Count--; }        }, 2000); return true; }}

In this case, the exception is handled in this way. The user is first prompted for an exception, and then the countdown is rolled back so that the user has reaction time.

Isn't it simple?

Note that the local transaction rollback is data-based, so there are two issues:

1. The data type needs to be of a special type. This is a lot of people are not happy, or like Java native. But actually does not matter, the habit is good, also did not increase how much workload, for the procedure stability, for the user, can endure only, who lets the customer be God. Also, data currently supports only value<t> types, and T is all types except list and map. As for list and map, the next step is to add.
2. For view development, data driven is required. But many GUI frameworks are not designed this way, which is where reflex needs to be adapted.

PS. Reflex Frame Address

Reflex Framework new features-local transaction, no longer worry about the program crashes!