And how would you know the first click from a 'series of clicks'? You cannot. You simply have to wait if further clicks happen. When there's only one click in a span of time it's a single click. When there're more than one click in that time span, it's a not-single-click. Are you sure you need both actions (click and double-click) in the way you described?
Lester Burnham wrote:XML can contain just about any character - that's not cause for any exceptions.
I don't fully agree with that. The parser usually is designed to read a defined encoding. In the provided example no encoding is specified. If I try to parse it as 'UTF-8' I'll get an exception and cannot read the document. If I try to parse it as 'ISO-8859-1' (because it is ANSI encoded) there's no problem at all reading the file. So specifying an xml encoding is always a good idea.
And if the document needs to be 'UTF-8' decoded, but it isn't, then you'll have to talk to the document author and tell him to provide documents with the correct encoding...
Spannable is an interface, not a class. I think you want to serialize objects of a class that implement this interface (like SpannableString). So is there any hint on why XStream would not work? Again -> TellTheDetails
That's what you're doing in your main method:
1) Let the user enter a 'phone' and print it out
2) Serialize a list of 'phone' objects that always contains only one element
3) Recreate a list of 'phone' objects that always contains only one element from serialized file and print it out
That's what you probably want to do:
1) Read previously serialized contents
2) Let user enter new 'phone' object
3) Serialize the list
Don't work with 'phoneList' and 'newPhoneList' ... but always with the same list.
For my simple mind the natural approach would be:
- Remember index
- Loop until no replacement keys can be found
- In each loop check all available key positions, replace the smallest with the corresponding value
So all keys should be replaced and the index marker should increase so that already replaced values aren't processed again. Okay, sounds funny, looks funny ... but seems to work ; - )
Thanks for the reply. I already did inspected the actual JNLP file provided by the browser and it had the correct version. Maybe I'm just paranoid because I couldn't recreate the behaviour on friday. I used following script to deploy / start the applciation:
Of course, the WS uninstall isn't executed for the 'new' version of the application but only for the 'old' one. In any case, the misbehaviour never occured (in about 35 test runs). So maybe it really was only some browser cache issue...