Android 不按顺序调用方法

Question

这真的让我卡住了，在我的 Android 应用程序中单击 Button 时，似乎调用的方法不同步。当我点击下面的 Button 时，我想调用:

loc = new Location(Options.this);

完成后我想调用:

setLocationPref();

实际情况是，当我的程序进入“displayLocations”下面的方法时，它会再次跳回到按钮并调用:

setLocationPref();

我认为错误在于两行代码:

builder.setItems(cs, new DialogInterface.OnClickListener(){
    public void onClick(DialogInterface dialog, int item){

如果有人有任何想法请告诉我，非常感谢:)

/** Location selection */
bLocation = (Button) findViewById(R.id.bLocation);
bLocation.setOnClickListener(new View.OnClickListener() {
    public void onClick(View v) {

        loc = new Location(Options.this);

        loc.locationSelection();

        setLocationPref();
    }
});

代码跳回到我写的地方/** FAILS HERE */

/** Display locations in a list */
public void displayLocations(){

Log.d("displayLocations", "displayLocations ");

LocationSQL getSetLocation = new LocationSQL(context);

final ArrayList<String> locations = locSQL.allLocations();
final CharSequence[] cs = locations.toArray(new CharSequence[locations.size()]);
AlertDialog.Builder builder = new AlertDialog.Builder(context);
builder.setTitle("Pick your location.");
builder.setItems(cs, new DialogInterface.OnClickListener(){
    public void onClick(DialogInterface dialog, int item){

        /** FAILS HERE */

        Toast.makeText(context, cs[item], Toast.LENGTH_SHORT).show();
        String selectedLocation = locations.get(item);
        updateLocationInfo(selectedLocation); 
    }
});
builder.create().show();
}

Answer 1

我认为您需要记住，在 Android 中，对话框不是以串行方式处理的。例如。当我在 PC 上编写我的 SWT 应用程序时，我可以等到对话框得到响应，然后我回去做下一步要做的事情。在 Android 中并非如此。你显示一个对话框，生活继续 - 立即。因此，可能发生的情况是:

您对 loc.locationSelection() 的调用会调用 displayLocations()。当 displayLocations() 开始工作时，按钮监听器中的控件开始执行其下一个任务，即 setLocationPref()；

另一件重要的事情是，在 Android 中，您不应该真正尝试像现在这样显示自己的对话框，因为这不会处理诸如屏幕旋转时的状态更改或用户在您的应用程序和其他应用程序之间切换以及您的应用程序被暂停(杀死)了一段时间。您需要在 onCreateDialog() 中创建您的警报，然后在 onPrepareDialog() 中准备它并使用 showDialog() 显示对话框 - 至少在 DialogFragment 出现之前它一直是这样(见下文)。然后操作系统会处理剩下的事情——您需要信任它。

不要直接在对话框上调用 .show()!系统会为您完成。

请注意，这种处理方式已被 DialogFragment 取代。然而，我认为任何人至少用旧方法做一次是好的，也是有教育意义的。这是我在尝试理解状态变化以及如何以传统方式处理对话框时为自己写的评论，在 DialogFragment 之前。希望对您有所帮助。

//=============================================================================
// Note re. handling of application kill, screen rotation and other state
// change events:
//
// Android will re-execute the onCreate() method for such events.
// Actually, the whole object gets re-created even for a screen rotation!
// If you put a static counter in the constructor, you will see that the
// constructor gets re-executed and all the non-static variables get scrapped
// and re-created.  The saving grace is that the rotation or other such events
// do not immediately interrupt when you are in the middle of executing a
// method, but rather it gets queued to be handled when its turn comes (or so
// I hope, else there would have chaos).
// Thus data consistency is not threatened and we can plan to recover from
// such situations gracefully.
//
// The only data that is safe is static class data, or you can - or rather
// should
// - save data as Android advises, by means of
//      onRetainNonConfigurationInstance() and
//      getLastNonConfigurationInstance()
// (deprecated in API 13 and replaced by
//      setRetainInstance(boolean)).
// Note that to save data across complete application restart from a cold
// kill you would need to use:
//      onSaveInstanceState() and
//      onRestoreInstanceState().
// See
// http://developer.android.com/guide/topics/resources/runtime-changes.html ).
//
// Using statics is probably OK if you are feeling a bit lazy.
// It will probably take care of the state changes, but not of the complete
// kill, of course.
//
// If doing it the proper way, however, we use a clear and simple contract
// with the OS:
//
// 1. We need to save/restore our data before/after a state change or being
//    suspended.  We do this using onRetainNonConfigurationInstance(),
//    getLastNonConfigurationInstance() for state changes - or equivalent
//    dialog fragment functionality - and using onSaveInstanceState() and
//    onRestoreInstanceState() for application being suspended.
//
// 2. We also need to ensure that all onCreateDialog() and
//    onPrepareDialog() methods (or their equivalents, if using the dialog
//    fragment API) can be meaningfully executed on the application being
//    re-constituted after a state change or after being suspended and
//    re-activated.  The OS will execute onCreateDialog() always on
//    application re-activation, and will execute onPrepareDialog() if the
//    dialog was opened at the time the state change or application suspension
//    took place (or if it was opened at any time in the past - see below!)
//
// 3. Therefore all data that is required for re-constituting dialogs
//    (for onCreateDialog() and onPrepareDialog() if this model is used in
//    preference to dialog fragment), must be available all the time and must
//    be saved in onRetainNonConfigurationInstance() and in
//    onSaveInstanceState().
//
// 4. It also means that we cannot re-use or clean any variables whose
//    function Is to 'deliver' information to e.g. onPrepareDialog().  If
//    these variables are re-initialized or otherwise overwritten after the
//    dialog has been displayed, they will not be available when the OS
//    attempts to re-run these methods to re-constitute the dialog!
//
// WARNING:
// Remember not to try to prevent the re-creation of these dialogs or
// otherwise hand onto those dialog instances (e.g. by means of static
// variables), because they are likely to reference your screen GUI and if
// you use the old (eg. pre-rotation) instances, they will try to reference
// non-existing variables from the old instance of the application, and things
// might get funny and actually crash.
//
// IMPORTANT:
// Also note that during such re-creations of the screen, user input fields
// (fields that are user-writable) on the screen will NOT be overwritten, even
//  if we try to overwrite them.  This is good, because it means that if we
// preserve our read-only data over the rotation, the system will preserve
// whatever the user might have typed in.
//
// NOTE:
// Additional note re. onPrepareDialog()
// (This actually might be a bug in Android)
//
// It seems the Android will call onPrepareDialog() on screen rotation, even if
// the dialog is not currently displayed.  Perhaps it will also be called at
// other times.  It does not seem to be called on normal app startup or on app
// re-creation after it is suspended, but best to be safe and assume that the
// method will be generally called immediately after onCreateDialog() even if
// the dialog is not active (displayed).
//
// Therefore:
// - All data that the onPrepareDialog() needs must always be provided or
//   suitable dummy substitutes must be given or the method should quietly exit
//   early if such data is not found.
// - The dialog must not try to do any actions that affect the main
//   application data, unless the data we have for it is real and we are sure
//   that the  dialog is really going to be displayed: Such actions are perhaps
//   not common but one could conceivably put such actions in onPrepareDialog()
//   (in places other than listeners, where such actions are common place), but
//   if we use dummy data or exit early, such actions will obviously be
//   nonsensical.
//
//  However, the whole scheme of using onCreateDialog/onPrepareDialog has been
//  deprecated and therefore will not be fixed even if this thing here
//  is an error.
//=============================================================================