New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
migrate to AppCompatDialog #3222
Conversation
android:text="@string/registration_problems__some_possible_problems_include" /> | ||
|
||
<TableLayout | ||
<ScrollView xmlns:android="http://schemas.android.com/apk/res/android" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The diff-view here is not optimal, I just encapsulated everything in a ScrollView
:
<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:paddingTop="24dp"
android:paddingLeft="24dp"
android:paddingRight="24dp">
protip: you can append |
@mcginty WOW! so much better 😳 |
sure thing @agrajaghh :) I just self assigned and will check back in after I get a chance to test on my N5 & something gingerbread. |
@agrajaghh while testing
|
also for the record all I did to test this was edit @Override
public void onResume() {
super.onResume();
dynamicTheme.onResume(this);
dynamicLanguage.onResume(this);
getSupportActionBar().setTitle(R.string.AndroidManifest__select_contacts);
startActivity(new Intent(getBaseContext(), PlayServicesProblemActivity.class));
finish();
} and Dialog dialog = /*GooglePlayServicesUtil.getErrorDialog(code, getActivity(), 9111)*/ null; then just click the new conversation button. |
@rhodey Thanks! I could have thought of that by myself 😕 I'm using now Also tested |
}); | ||
final AlertDialog dialog = builder.create(); | ||
dialog.show(); | ||
dialog.getButton(AlertDialog.BUTTON_POSITIVE).setOnClickListener(new View.OnClickListener() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why can't this be done in the empty onClick() handler above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AppCompatDialog
doesn't support .autoDismiss(false)
, so this is a workaround. Otherwise the dialog gets closed immediately. I just tried to stick to the current behaviour (dialog.dismiss()
in onPostExecute()
). But maybe thats not necessary, what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say change handleProvisioning
to accept a DialogInterface instead of an AlertDialog and pass along the dialog
given to you in the positive button listener.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but how can I prevent the dialog from getting closed immediately? If I do it like that, it will be closed right after the call to handleProvisioning()
in the positive button listener and not in onPostExecute()
of the ProgressDialogAsyncTask
.
What do I miss?
570a15b
to
da16b89
Compare
rebased |
da16b89
to
6ecc1b5
Compare
rebased and migrated the dialogs from the recent mute/block change |
6ecc1b5
to
11ff243
Compare
@rhodey should I worry about the failed jenkins build? |
@agrajaghh nope, looks like the test devices we're using for jenkins hit a rate limit with Google Cloud Messaging registration. after making it through ~20 full tests (~400 GCM registrations) all the tests that required GCM registration started to fail persistently. jenkins just finished running through the last of the pull requests this morning so I just shut that down temporarily. I intend to let it idle for a few hours, maybe a day, and then turn it back on and re-run all of the PRs it marked as failed while somehow trying to avoid the GCM rate limit again. I don't expect this GCM rate limit will be a problem once we get over the initial backlog, sorry for the trouble. |
no trouble, just curious, thanks for the explanation |
11ff243
to
28f805b
Compare
rebased, migrated the dialogs in |
28f805b
to
c077825
Compare
This reverts commit 0fbbe399e3fa01c1744321e934d4e4d7a04eae81.
rebased again should I continue/is this on the nearby agenda? 😟 |
c077825
to
ce7883e
Compare
}) | ||
.show(); | ||
AlertDialog.Builder builder = new AlertDialog.Builder(this); | ||
builder.setTitle(R.string.DeviceProvisioningActivity_link_this_device); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not chain these method calls like before?
AlertDialog dialog = new AlertDialog.builder(this).setTitle(R.blah.blahdeblah)
.setPositiveBlahblah()
.create();
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
.setMessage(content) | ||
.setPositiveButton(R.string.DeviceProvisioningActivity_continue, new DialogInterface.OnClickListener() { | ||
@Override | ||
public void onClick(DialogInterface dialog, int which) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd make more sense to have handleProvisioning take in a DialogInterface instead of an AlertDialog and then you can use the normal style of setting OnClickListeners.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel stupid now 😕 I tried that, see my comment above:
but how can I prevent the dialog from getting closed immediately? If I do it like that, it will be closed right after the call to handleProvisioning() in the positive button listener and not in onPostExecute() of the ProgressDialogAsyncTask.
What do I miss?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah sorry, my comment got hidden so I didn't think I posted it for some reason!
I see what you're saying now, yeah we have to either do it this way or implement a custom non-alert dialog. The latter is probably less hacky but more effort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
puh, I thought I missed something obvious 😌
Thats your call, I think these +7 lines are okay and way less than a custom dialog ;)
wow, I almost lost hope 😝 |
Closes signalapp/Signal-Android#3222 Fixes #291 Upstream commit: signalapp/Signal-Android@c433981
This migrates from
MaterialDialog
toAppCompatDialog
to eventually eliminate this dependency.The last other occurence of
MaterialDialog
is inReceiveKeyDialog
, which I removed in #3225.I couldn't test the
AlertDialog
inDeviceProvisioningActivity
and inPlayServicesProblemFragment
. @rhodey could you help me out there?