While registering to a website, it has 2 fields. Email and email confirmation.
The thing is, people are copying what they're writing on first field and pasting on the other field.
I'd like to disable it, is it possible?
<h:inputText id="email" value="#{registerBean.email}" maxlength="60" />
One of the most important things to track in UI design (if you care about a consistent user interface) is all of the nuances which people come to expect.
If you disable the "copy" hot key sequence, then many people will feel frustration because your interface doesn't conform with the nuances that hold for the rest of the operating system. While I understand why you might want to do this, that's not going to convince people that your code isn't broken. After all "Ctrl+c" works every where else.
Once you deviate from enforcing expected UI control nuances, then you need to indicate where the nuance is permitted and where it is denied. That's the DEFINITION of an inconsistent user interface. As the user isn't going to have you there to explain the "why" when the UI does something that they don't expect, they will invariably consider it a bug. If they did have you there telling them why they couldn't do something allowed in every other part of their operating system, they will invariable consider you overzealous in enforcing something stupid which everyone else allows.
The solution is to use a better solution. Enforce what is already expected to reduce the learning curve, or select something (OpenID has been mentioned) that sidesteps the objectionable task(s).
This page suggests the following solution:
<script language="javascript">
function onKeyDown() {
// current pressed key
var pressedKey = String.fromCharCode(event.keyCode).toLowerCase();
if (event.ctrlKey && (pressedKey == "c" || pressedKey == "v")) {
// disable key press porcessing
event.returnValue = false;
}
} // onKeyDown
</script>
I should add though, that in general it is impossible for a webpage to tell the client browser to "disable cut and paste".
Btw, I never use Ctrl+C for copying text. I'm on XWindows so simply selecting the text will copy it. If I'm on a windows system I usually do Ctrl+Insert
I'm thinking that this question is pretty similar to yours: Disable pasting text into HTML form
My summary of the answers: You can, but it's messy and it's poor UI design. They also have some good suggestions for better UI design.
Please don't do that. I hate having to copy my email address, and if I actually had to type it twice, I would just leave unless I was being forced to make an account for some reason.
Related
I have heard that using editor.putString("Message","Hello"); is bad practice, and you should instead do editor.putString(getString(R.string.messagestring),"Hello");. But why? It is longer and has the same result, and looks more messy imo. Is it because it's harder to make a typo?
Here is an example from Signal:
Source
if (params[0] < SCREENSHOTS) {
boolean screenSecurity = PreferenceManager.getDefaultSharedPreferences(context).getBoolean(TextSecurePreferences.SCREEN_SECURITY_PREF, true);
TextSecurePreferences.setScreenSecurityEnabled(getApplicationContext(), screenSecurity);
}
String values in code for human readable text are bad.
Doing so makes localization impossible.
Values from R.string. on the other hand automagically use the right language (given that you use values, values-es, values-fr, ... and put translations)
Note: You should probably not translate the key of a SharedPreference but the value ("Hello") part since that's presumably the human readable thing.
editor.putString("message", getString(R.string.messagestring));
The key could change if the user changes device language which means the old stored value will no longer be found under the new key. If you want keys in a central place it's a good idea to have them defined as static final constants in code.
editor.putString(MyPrefConstants.PREF_MESSAGE, getString(R.string.messagestring));
I would actually consider using keys that come from R.string a very questionable design decision. This applies to anything that is intended to be machine-consumed rather than visible text to the user. There are a few exceptions but they are rare.
It's Not Necessary but Good Practice.
eg.
editor.putString("Message","Hello");
here the key -> "Message"
it is possible that sometimes you make a TYPING ERROR or SPELLING MISTAKE of writing "Message" to "Massage" or something else.
to avoid these type of situations, we should write in this way
editor.putString(getString(R.string.messagestring),"Hello");
It's all about maintenance, reusability, cleanness and if needed easier localization. Take for example "Message".
How many times would you use this string in your code if it is the key for Preferences? More than 1, right? Imagine that you write over and over "Message". Isn't it possible to misspell it at least once? Well you can't misspell a string resource, because the compiler won't let you.
Another thing: you know where all your UI strings are so you know where to look when you need to change 1 of them and once you do it is changed throughout the app.
Finally if you want your up to be multilingual this is the only way with the Editor provided by AS.
Edit: As for the question if strings like keys for Preferences should be in the Resources my answer is yes. It's up to the programmer to give proper ids to the string resources so to distinguish the UI items from the in-app items.
I have a really weird problem, one of the windows in my app (let's call it "Window A") is consistently placing itself (or being put) behind the window that brings it out ("Window B"). Even if I click on Window A, Window B immediately comes forward again.
There's nothing obvious in the code as to why this might be happening. I can write a windowActivated() or windowDeactivated(), but by the time they're called the information on who actually switched the windows is of course long gone.
How can I get to the point where those events are fired?
I've found what was causing the bug and thought I'd post it here in case it's of use to others. I never found an answer to my original question, and I still think it may well have shown me where the bug was coming from. It certainly was non-obvious.
It turns out that if you have a custom focus traversal policy (Container.setFocusTraversalPolicy(FocusTraversalPolicy)) and its getFirstComponent() passes back a component which is not focusable[*], then whenever the window is brought to the front either programmatically or by the user, it will be sent back one step in the z-order hierarchy.
I found the problem by good old brute force: the offending window is part of an inheritance hierarchy like so:
AbstractSuperclass
/ \
/ \
BuggyWindow NonBuggyWindow
I made a ToyWindow class to also descend from AbstractSuperclass. It didn't have the bug. I laboriously copied in code from BuggyWindow until the bug exhibited. That was in a long method which is called when the window is first displayed; by successive deletion I arrived at the offending block of code, where a number of widgets have their isEditable() and isEnabled() set to false. Since other windows have all their widgets disabled (in View mode), there was obviously more to it than that. Then I remembered the custom focus traversal policy.
I wrote a toy program with the important elements, and was able to reliably trigger the bug. I added checks for focusability to all of the methods in my custom focus traversal policy. Bug go bye-bye.
Thanks to those who responded and I do apologise for the lack of information. I didn't want to waste people's time by shoving huge amounts of code at you. It meant you didn't get what you're used to here, and that was unfortunate.
[*] I'm taking non-focusable as !(isFocusable() && isEnabled()) since I couldn't quickly get sufficient information to understand exactly when a component might be focusable but not enabled (or the other way around), and it was good enough for my purposes. (Oh, how I wish the JRE would have comments better than e.g. "isFocusable() returns whether this component can be focussed"..."isEnabled() returns whether this component is enabled" -- ##&$!!!)
Is there any way in java to make code: Example if someone clicks on skipAd on adf.ly link Int will increase. Example 2: I click the button, it will take me to a adfly link. and when i click skipAd on adf.ly: in the app int will increase for 1(int++).
Is there any way to do that?
First of: StackOverflow hates it when people come here showing that they have taken zero effort to find a solution for the problem.
Secondly:
Your question is very unspecific.
Are you and your friend on the same network? If so, you might want to consider using ARP-Poisoning in order to inject custom JavaScript into the webpage that will function as an EventListener. Obviously this will only work if he is visiting AdFly via an HTTP connection and since Adfly-Links are generated with an HTTPS prefix, you will rarely find people using HTTP (despite the fact that they still don't enforce HTTPS, grumpf).
There are probably tons of other solutions but they will all involve tinkering with his/your webtraffic. And no offense, but I feel like you should probably learn some more Java before taking on such a big task.
More than in 'java' it would be easier to do it in 'JavaScript'. You'll have to monitor the onClick event of that SkipAd button and then you can increase your counter.
I advise you to make your question even more clearer in why-you-have-to-do-it department to avoid down votes
Probably a simple question, I can call a native function from the JavaScript, for example:
Android.setVolume(0.7)
However, I do not know how to trigger (from Android/Java), or handle events (JS) that are not caused by user interaction, for example, alerting the JS when the user's network state changes, the battery gets below a certain point etc.
Any help greatly appreciated.
However, I do not know how to trigger (from Android/Java), or handle events (JS) that are not caused by user interaction, for example, alerting the JS when the user's network state changes, the battery gets below a certain point etc.
As with the answer you linked to, use loadUrl() with a javascript: URL, akin to how a bookmarklet works.
The answer is over a year old and is labelled as a hack, is this still the best way to do it?
I am not completely clear why the author of that answer described it as a hack. Certainly, it's viable and is used a fair bit.
I have a JTextField in a GUI Java App. It's not connected to a Database so I'm not worried about SQL injection or anything like that, but I wonder if I need to worry about a stack overflow or another problem.
For example if the user decides to hold his finger on "A" ad nauseum. My Java reference book offered no procedures to prevent misuse of the application like this.
Each key-press produces a KeyEvent, which (over some steps) is translated to a call to insert the text in the Document of your JTextField. If the user inputs really really much text (many megabytes) (then more probably by cut'n'paste), you could get an OutOfMemory error, but this is still nothing that damages you, only the user, since he can't work with the application.
So, nothing really Security-relevant here.
You should be fine with the text field from a security standpoint. I would suggest worrying more about what the code does with the text or in response to the text. SQL injection being one of the most common concerns.