Viewing Events with Multiple Actions will Mix Up Parameters

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a new rule with any event.
2. Add a new omnidroid > notify action with "notify" as text.
3. Add a new omnidroid > alert action with "alert" as text.
4. Select the notify action and press edit, then press back when the action 
activity appears.
5. Select the alert action and press edit.

What is the expected output? What do you see instead?
The edit box displays "notify" instead of "alert". This phenomenon also occurs 
from view Rules > select rules with more than one action.

Discovered this bug while performing test cases for issue 99.

Original issue reported on code.google.com by renc...@gmail.com on 28 Jun 2010 at 1:33

[GoogleCodeExporter]

Original comment by case.and...@gmail.com on 28 Jun 2010 at 2:53

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

the actual alert action still executes/alerts with the text "alert", so it 
appears it's just the population of the edit box that displays the wrong 
"notify" text.

Original comment by case.and...@gmail.com on 28 Jun 2010 at 3:47

[GoogleCodeExporter]

Original comment by case.and...@gmail.com on 28 Jun 2010 at 3:47

[GoogleCodeExporter]

I think this is a result of the ViewBuilder doing a loadState on a DataType 
that it's already loaded once before.  In this case the OmniText is loaded when 
you select either the Edit option on notify and then if you hit back and then 
Edit on the other option the ViewBuilder for the new OmniText does a loadState 
that gets the data from the first instance.  We need a ViewBuilder.clear() or 
ViewBuilder.reset() function that gets called between edits.

Original comment by case.and...@gmail.com on 29 Jun 2010 at 1:47

[GoogleCodeExporter]

Start to take a look at this issue.

Original comment by renc...@gmail.com on 30 Jun 2010 at 1:57

• Changed state: Started

[GoogleCodeExporter]

Code review:
http://codereview.appspot.com/1711050

Caused by:
SharedPreference from the previous activity persists even when it was destroyed 
already, causing the SharedPreferences to be loaded to the new activity.

Correction details:
Made sure that the sharedPreference instance is cleared whenever the activity 
is removed from the stack.

Test Cases:
1. Check that data entered in the fields are preserved when switching 
activities:
  1.1 With the ActionInputActivity open, go to home, then go back to omnidroid.
  1.2 With the ActionInputActivity open, open the dialer my pressing the offhook button, go to home, then go back to omnidroid.
2. Check that account name will be refreshed to the new one - With the 
ActionInputActivity (gmail send or update twitter action) open, press setup 
button, create a new account and press ok.

Original comment by renc...@gmail.com on 2 Jul 2010 at 3:20

[GoogleCodeExporter]

Refix part 1 summary:
Correction details:
Instead of using editing the SharePreferences at onPause and loading at 
onResume, the onSaveInstanceState callback function is used and the state of 
the UI is saved in the bundle. Using SharePreferences is wrong in the first 
place since it should only be used to store persistent data and not transient 
data like information on the action fields.

Test Cases (tested with OmniText and OmniPhoneNumber):
1. Check that data entered in the fields are preserved when switching 
activities:
  1.1 With the ActionInputActivity open, go to home, then go back to omnidroid.
  1.2 With the ActionInputActivity open, open the dialer my pressing the offhook button, go to home, then go back to omnidroid.
2. Create any rule with any action and proceed to ActionInputActivity. Set 
arbitrary data on the fields and change the orientation of the phone. The data 
inputted should persists after the orientation has changed.

Note: There are currently no actions that has parameters with datatypes 
OmniArea or OmniCheckbox so these were not tested.

Original comment by renc...@gmail.com on 4 Jul 2010 at 12:18

[GoogleCodeExporter]

Additional test case:
3. Test the param buttons on actions with multiple text fields (like Gmail 
send) and make sure it works.

Original comment by renc...@gmail.com on 4 Jul 2010 at 12:33

[GoogleCodeExporter]

Refix part 2 Summary:
Used the onActivityResult to refresh the user account field whenever user 
setups a new account.

Test Cases:
1. Create a Update Twitter Action > click setup user account > enter/modify 
account details > OK. The new account name should be reflected.
2. Same as #1, but press back instead of OK. The account name should still 
remain the same as before.

Original comment by renc...@gmail.com on 7 Jul 2010 at 4:06

[GoogleCodeExporter]

Part1 checked-in at r795. Part2 checked-in at r798.

Original comment by renc...@gmail.com on 7 Jul 2010 at 10:00

• Changed state: Fixed