Develop Reference

How to add "show text" in Android(x) password preference dialog

There doesn't appear to be a specific password text dialog in the Androidx (or Android) library.
I want to add a button so that the user can switch between text view and password text view (asterisks instead of letters) for this preference even though, as someone might want to tell me, it's not a fabulous idea to store passwords as preferences. Eventually I'll have a more robust approach but in the meantime this is what I've got.
I'm using the code that Android Studio (generously) offers me for "Preference Activity". In all other respects it seems pretty good, and better than I can manage myself yet. It's just got this (annoying lack of) feature.
This question is a little too old to reference Androidx, and according to the (main) relevant answer to my context, I can't use AndroidX here. However, using the code from the Settings Activity I don't explicitly mention DialogPreference at all.
So, is there a way to slot in a "reveal" button in this situation, or should I either not use the "textPassword" input type, or completely rebuild this activity?

I was messing round with something similar the other day. I didn't use a reveal button, but just got it to never show the password:
input_password.setText(prefs.getYourPassword().toAsterix())
private fun String.toAsterix(): String {
return replace("[.]", "*")
}
With a PreferenceActivity, you would have to make a custom view. It would be an EditText and a Button. Clicking the button would set the text to either prefs.getYourPassword() or prefs.getYourPassword().toAsterix().

setPositiveButton in AlertDialog, using strings?

I'm trying to add a string to the following alert box's positive button, but it keeps spamming out error messages.
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage(R.string.checkNetwork).setTitle(
R.string.checkNetworkTitle);
builder.setIcon(R.drawable.ic_warning);
builder.setPositiveButton(android.R.string.continue, new warningContinue());
AlertDialog dialog = builder.create();
dialog.show();
Any help? It does seem to work for the title and the message, however not for the button...
Thanks in advance.
EDIT: The error says:
The method setPositiveButton(int, DialogInterface.OnClickListener) in
the type AlertDialog.Builder is not applicable for the arguments
(Class, warningContinue)
So it seems to expect an integer, but I was wondering if there's any way to use strings for localization-purposes?
EDIT2:
Ok what the hell. Problem lied in the string name; it won't let me name my string continue for some reason. o_O

You don't want to use "android.R.string.continue". "package name".R.string.continue is what you want. Thats the usual way you're doing localization in android. The id provides multilanguage support automatically based on the users system language. You just have to create multiple "values" directories. https://developer.android.com/guide/topics/resources/localization.html provides you more information about localization.
Also you can't use "continue" as a name, use "str_continue" or something like that (it's the same for "return" or "break" ect.). They are reserved in java. For more information you could read the link: http://java.about.com/od/javasyntax/a/reservedwords.htm
Because you don't post the code of "warningContinue()", i think you know that it has to extend "DialogInterface.OnClickListener()". Also you should consider to write your classes first character uppercase for convention reasons, for more information read this answer on stackoverflow: https://stackoverflow.com/a/414029/2238341

R.string.warningButton is just the int in your R.java file. To get the associated string use the following line:
builder.setPositiveButton(getString(R.string.warningButton), new warningContinue() );
As other mentioned, don't use android.R.string.continue as it doesn't exist in system.

try, first go to res / values / strings.xml and declare your string as follows
<string name="checkNetwork">your String...</string>
Then you can take it as follows
R.string.checkNetwork
Just like this one and be happy ....

Blocking dialog like construct in android

Looking for a blocking,value returning dialog like custom construct in android.
Something like this:
Output outValue = MyPopupBuildingClass.showWindow(inValue, R.layout.my_layout);
Yes that's the all too familiar MessageBox for Windows programmers :) and I think there is JOptionPane in Swing too.
The complexity here is that I don't want a small default android dialog, but more of a popup fragment with some detailed layout and functionality. It accepts an object, pops up a window, lets user do something to it and return it back when user accepts or dismiss.
Any thoughts?

Like #Luksprog said in comments, Blocking dialogs in android are hard to implement and should be avoided.

Why strange naming convention of "AlertDialog.Builder" instead of "AlertDialogBuilder" in Android

Why not
AlertDialogBuilder builder = new AlertDialogBuilder(this);
builder.setTitle("foo");
instead of
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setTitle("foo");
Update: I want to know the reason behind this kind of writing/organization

According to the Javadocs, nested classes (and in this case, static nested classes) are generally used for three things:
Logically grouping classes which will only ever be used together.
Increasing encapsulation.
Increasing readability and maintainability of code.
Point #3 is one reason a lot of developers use static nested classes. Let's take, for example, the ViewHolder pattern in Android development. In a ListAdapter, we can make caching of lists easy by managing the contents of each list element in a ViewHolder (or similarly named inner class). In this situation, it is easy to notice that this specific ViewHolder is only for this class, and when we change this one, we don't change every single one. This means we don't need a List1ViewHolder, List2ViewHolder, ..., ListNViewHolder. Each List-type element can have its own ViewHolder.
Point #2 is a bit less relevant to this point, because we're dealing with static inner classes (that's what Builder is). But in this case, it prevents elements of the inner class from being accessed by the outer class.
Point #1 is the big one here, which is why I've saved it for last. Think of the situations in which you will use AlertDialog.Builder. I can guarantee, with 100% certainty, that every single time you use AlertDialog.Builder, it will be in the building/creation/handling of an AlertDialog. Consequently, this means that every use of AlertDialog.Builder is tied to how AlertDialog works. (This ties in somewhat with point #3; it's easier to maintain two classes in one file than to have them separated.)
Similar to points #1 and #3, but also of its own rite, is the fact that by keeping Builder within AlertDialog, we are not polluting the android.app package namespace. We still keep just AlertDialog within it; but Builder hides within that.
Android is not the only system that does this; the MotiveWave SDK does this also, as do the Adobe Access and eBay SDKs (which I lack links for). I also believe Java EE uses this methodology as well. You will also see it often in Enum types, which in turn is because of the reasons covered in point #1.
Now, you asked why we use AlertDialog.Builder instead of new AlertDialog(), and build it from the object instead of from the builder. The answer here is the same as the factory method pattern seen commonly in Java and other object-oriented programming languages. Notably (from Wikipedia), there are three reasons for this:
The creation of an object precludes its reuse without significant duplication of code.
The creation of an object requires access to information or resources that should not be contained within the composing class.
The lifetime management of the generated objects must be centralized to ensure a consistent behavior within the application.
These explain themselves pretty well; they speak against code duplication (being able to handle all creation functionality within one class), unauthorized access (bad encapsulation practices), and consistent behavior of construction. Also unlisted here is code readability.
I suspect--on a hunch--that AlertDialog is a very resource-intense process. It halts parts of the OS, keeps others running, has to load system resources, and so on. As this answer details, we do not want to provide direct access to the outer class (AlertDialog in this case). This allows the Builder to handle all resource-intensive operations properly. It also keeps us from having to handle esoteric situations which the OS developers considered, but we did not.
So, to conclude, this is actually a decently common design pattern, but not one that has a real explicitly defined meaning. Rather, it is for ease of use, understanding, and maintainability. You mention a concern about design considerations above; I wouldn't worry too much on that. Just keep in mind that static inner classes should always be solely related to their outer class, and you should be fine.

Builder is the static inner class inside the AlertDialog class. So to create a Builder class object, you need to call AlertDialog.Builder.
As there is no class like AlertDialogBuilder so you cannot do that.
If you want you can also use as like bellow.
Builder builder = new Builder(this);
builder.setTitle("foo");
But to use like this you need to import the Builder class to your class like
import android.app.AlertDialog.Builder;
instead of just
import android.app.AlertDialog;
A simple example
class A{
static class B{}
}
you cannot use
AB obj = new AB();
you have to use
A.B obj = new A.B();
Hope you are clear now.

I'll try and clear you up behind this kind of organization.
First of all, Builder is a class inside the AlertDialog class.
Why would you create a class inside another class? I personally only create nested classes if I want to add more functionality to an existing class and don't believe that from a designing point of view that the class should be extended. I'm sure one could argue about this one, since there are tons of different ways to add more functionality to a class; yet nested classes can be preferred above others (for some people).
Here's oracles point of view on nested classes.
I'd only use nested classes if I find that it makes the code more maintainable and intuitive.
In this case I believe the guys over at Google found that instead of creating a new class called AlertDialogBuilder compared to AlertDialog.Builder, is because both yield the same results; a dialog displaying some information on the screen with some buttons. The only difference between both (I think) is that you can set positive, neutral and negative button on the AlertDialog.Builder (which gives more functionality to the class, yet not necessary more that the class should be extended, again personal opinion).
In the end what matters is that the code works (hopefully without any bugs), is maintainable, readable and intuitive. There's no definite answer to your question, since people have different opinions on this topic.
I hope this helps.

The approach used to construct AlertDialog Object is called Builder Pattern to enhance readability. When you want to construct a new object but this object requires a lot of properties to create it like too many parameters (more than 4) passing to constructor you will got confused . If you want to know more about builder pattern I think this answer will satisfy your needs. AlertDialog construction is quite similar to the example in the link :
#Override
public Dialog onCreateDialog(Bundle savedInstanceState) {
return new AlertDialog.Builder(getActivity())
.setMessage("Do you really want to exit?")
.setCancelable(false)
.setNegativeButton("No",
new DaialogInterface.onClickListener() {
public void onClick(DialogInterface dialog,
int id) {
((AlertDialogActivity) getActivity())
.continueShutdown(false);
}
})
.setPositibeButton("Yes",
new DialogInterface.onClickListener()) {
public void onClick(
final DialogInterface dialog, int id) {
((AlertDialogActivity) getActivity())
.continueShutdown(true);
}
}).onCreate();
}
This method return Dialog object that asks user if he/she wants to exit the application as you can see it doesn't make any sense to create an AlertDialog object by calling a constructor with too many arguments. Imagine if AlertDialog has such a constructor :
AlertDialog ad = new AlertDialog(getActivity(), "Do you really want to exit?",
false, "No", .... )//and the list goes on
Compare this approach with onCreateDialog method I think onCreateDialog method wins right ?

Dialog.Confirm that returns boolean in Android

I need a Confirm dialog that returns the boolean value in order to remind the user about the missing series of values in the form that are required based on the settings but not mandatory.
I did lot of research but none of the tell me how to active this.
For example: In a form lets say the user forgot to enter City, State and Zip. I need to throw an reminder asking the user "Did you intentionally not enter the City?" with "Yes" and "No" buttons. If the user answers "Yes" then throw the reminder for State else set the focus to City, so that user can enter the city. And so on....
Any help would be greatly appreciated.
Thanks,
Vincy

First, what you are proposing is not a particularly friendly UX. Use color coding or something to indicate fields that you think should be filled in but are not, rather than forcing the user to have to keep tapping on dialogs to do what the user wants to do.
All that being said, use AlertDialog (perhaps via AlertDialog.Builder) and set up DialogInterface.OnClickListener objects for the buttons. Depending upon the button choice, you either set the focus (via requestFocus(), called on the widget needing focus) or continue with your processing.