这确实让我陷入困境，在我的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();
}
答案 0 :(得分：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.
//=============================================================================