String Validations

[Muchey]

I am doing string validations on input fields.

However, using these static methods: Character.isAlphabetic(codepoint) or Character.isDigit(char c) keeps returning: "Cannot find symbol".

Those same lines work outside the plugin in normal Java apps. 

Are there any methods with same functionalities in CN1 or any workaround to achieve same function?

Please assist as these methods are cleaner than regex expressions.

[Muchey]

I realized no method in the Character class is valid as ALL returns same error message: ' cannot find symbol'.

The import class is called, and the method parameters are used with required data types, yet same erorr persist.

[Shai Almog]

The Character class is supported but some methods aren't see the JavaDoc https://www.codenameone.com/javadoc/

Specifically https://www.codenameone.com/javadoc/java/lang/Character.html

isDigit() is supported and should work. isAlphabetic isn't supported, it's a bit complicated with some of the more complex charsets out there. If you have a specific use case for it let us know.

[Muchey]

I am trying to validate where user's input is only Characters with symbols excluded. Hence the need for method: isAlphabetic().

Reveiwed the Character class in CN1 and cant find method(s) with similar functionality as isAlphabetic().

Negating isDigit() would allow symbols which is not required for the field value.

Any sample procedure, code snippet, method/class to achieve this would be greatly appreciated!

Thanks!

[Thomas]

You can easilly test for alphanumeric characters with a regexp of the RE class: https://www.codenameone.com/javadoc/com/codename1/util/regex/RE.html

[Dave Dyer]

Just a word of caution; this whole area is fraught with subtle hazards, especially if unicode characters outside of

the traditional ascii range are allowed.  Codenameone ought to just slavishly implement what standard java does,

and maintain compatibility with whatever legacy code and possibly faulty assumptions the user brings to their program.

[Shai Almog]

Which character regions do you target? Do you want to accept input in Chinese? Dutch? Klingon?

All of those would be accepted by isAlphabetic(). Most developers just check the character ranges of the languages they support e.g. if you just want to support English you can use toLowerCase() then check c >= 'a' && c <= 'z'.

OTOH There are some really complex cases with surrogate pairs which mean a character isn't a character... So you'd have symbols like nikud in Hebrew or the apostrophes that appear in multiple languages that are a part of the word but aren't a character. I think Thomas's suggestion is probably the best direction.

@Dave. No. That would make your app x8 times larger than it is now.

[Dave Dyer]

@Shai, I meant only to implement the standard definitions of Character.isAlphabetic() and similar methods, not java as a whole.

There are lots of these little things missing, mostly just inconsequential speed bumps; but character handling is one of the more

annoying for examples.

[Shai Almog]

And who determines what's needed and what isn't?

We implement things based on valid requests. This method seems like a great example of a feature that might make sense if you are building a backend data processing tool but doesn't make much sense for mobile UI. 

More than a decade ago Sun went over the JDK and extracted a minimal baseline (CLDC) that was our starting point. From that point we added additional features as needed. We didn't strip down an existing JDK. It's the other way around.

[Dave Dyer]

On Saturday, July 21, 2018 at 8:13:04 PM UTC-7, Shai Almog wrote:

And who determines what's needed and what isn't?

 

Your own best judgement of course.