Flipping the phone closed when entering data erases any currently added data

[GoogleCodeExporter]

On both the Filters and Actions page.  If you're phone is open exposing the
keyboard after you've create a new filter or action, and you close the
keyboard before you move on to the next page.  The filters or actions you
entered will be erased when the keyboard closes.

What is the expected output?

It should keep this data.

Original issue reported on code.google.com by case.and...@gmail.com on 4 Jun 2009 at 6:54

[GoogleCodeExporter]

There's a problem at least with the 1.1 OS when orientation changes, this isn't 
specific to omnidroid. I'll go back to the android forums to figure out what 
the work 
around is.

Original comment by mar...@gmail.com on 4 Jun 2009 at 8:22

• Changed state: Started

[GoogleCodeExporter]

This is tough to test without an actual device, but I think what's happening is 
a signal 
to orientation change. When the orientation changes, the current Activity has 
its 
onCreate() method called again. So it appears like all data is lost when this 
happens. 
Here's a brief sketch, consider the user has the keypad open already:

// User enters some data without saving.
// User now closes keypad, starting an orientation change.
onPause()  // Our chance to save input data 
onStop()
onDestroy()
onCreate() // called again after rotation is done, restore inputs from above.

To test this in the emulator, hit ctrl+F12 on win or linux (not sure on mac).

So for every activity, we have to make sure that onPause() saves Activity state 
if we 
want to restore it between orientation changes (which for now is only signaled 
by the 
user opening or closing the keypad).

The Activity lifecycle documents this here:
http://developer.android.com/reference/android/app/Activity.html

Original comment by mar...@gmail.com on 9 Jun 2009 at 4:01

[GoogleCodeExporter]

The fix for this seems easy now that Android introduced the SharedPreferences 
class. 
This should be done for all Activities, especially ones that allow user input, 
which 
is where this problem is most apparent:

public class YourActivity extends Activity
{
    /** Will store state between onCreate() calls. */
    private SharedPreferences m_prefs;

    protected void onCreate(Bundle savedInstanceState) 
    {
        ...

        // Restore saved state if possible.
        m_prefs = super.getPreferences(MODE_PRIVATE);
        m_editField.setText(m_prefs.getString("itemName", ""));
    }

    protected void onPause()
    {
        ...

        // Save state.
        SharedPreferences.Editor ed = m_prefs.edit();
        ed.putString("itemName", m_editField.getText().toString());
        ed.commit();
    }
}

The above example is easy, but can be a bit trickier for other cases where we 
may 
have opened child dialogs and such. We'd probably want to save the fact that 
they're 
open etc, and restore it to that exact state. This really only probably becomes 
a 
problem during data entry!

Original comment by mar...@gmail.com on 9 Jun 2009 at 6:54

[GoogleCodeExporter]

Original comment by mar...@gmail.com on 15 Jun 2009 at 8:41

• Changed state: Fixed

[GoogleCodeExporter]

Mark,  This is great.  I think r457 addresses FiltersAddData, but this bug still
needs to be addressed in following classes:
  Filters
  FiltersAddType (*)
  Actions
  ActionAdd (*)
  ActionData (*)
  ActionDatumAdd
  ActionType (*)

(*) - May not suffer from this problem but, is suspect to needing a patch.

Removing "Fixed" status since more classes still need to be modified.

Original comment by case.and...@gmail.com on 15 Jun 2009 at 11:00

• Changed state: Started

[GoogleCodeExporter]

Andrew, no prob, I agree. I wasn't sure if I should close it because yeah, 
every 
Activity we make is going to need this small code update to handle orientation 
changes. 
I was thinking we may be replacing a lot of the Activities with the updated UI, 
so I 
just put a bug note in this issue about Activities. Not sure what to do, should 
I fix 
the remaining Activity classes, put a note in them, or wait until we talk about 
whatever new UI we want before doing anything else?

Original comment by mar...@gmail.com on 16 Jun 2009 at 5:15

[GoogleCodeExporter]

Until there is new UI code to replace the current UI or a published design for 
a new
UI proposed with mock-ups that invalidate this bug, then I think this should be 
kept
open.  Has the UI team developed any new mock-ups for this (I haven't seen any 
put up
in the SVN or Wiki).

Original comment by case.and...@gmail.com on 16 Jun 2009 at 5:33

[GoogleCodeExporter]

The new UI system has support for orientation change. This is no longer an 
issue.

Original comment by mar...@gmail.com on 3 Aug 2009 at 5:54

• Changed state: Fixed