Closed GoogleCodeExporter closed 9 years ago
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
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
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
Original comment by mar...@gmail.com
on 15 Jun 2009 at 8:41
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
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
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
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
Original issue reported on code.google.com by
case.and...@gmail.com
on 4 Jun 2009 at 6:54