何に悩んでいるのか

・ネイティブ側でこのバリデーションをかける必要があるのか？

・テキストフィールドにその文字数以上入力できないようにするのか、送信時にチェックをしてエラーにするのがいいのか

ネイティブ側でこのバリデーションをかける必要があるのか？

この文字数制限は、無制限に送れるようにしてしまうとサーバやDBの負荷になるため書けることがほとんどだと思う。

そのため、必ずサーバ側で受け取った時にも文字数にバリデーションはかける。(クライアント側しかないならそれは不具合と言っていい)

そうなると、ネイティブ側はなにもしなくてもエラーハンドリングさえしていればいいことになる。

これに関しては、わざわざ通信しないとエラー結果が出ないことが気になるなら文字数チェックをかけたほうがいい。

ユーザの利便性を考えていくと、通信しなくてもエラーがわかるならわかったほうがいい。

文字数の数をころころ変えて仕様の調整をしたいようならサーバ側のみじゃないとだめだけど。

文字数制限をネイティブ側で掛ける場合、maxlength等でテキストフィールドにその文字数以上入力させない方法がある。

一方で、送信ボタン押した時にjavascriptやネイティブコード上で文字数をチェックして、超えるならエラーにするという方法がある。

これに関しては悩みが多くて、

maxlengthを使う方法は、ユーザがコピペでテキストを入力した場合、ペーストする文字列の数が多い場合勝手に切られちゃうため(100文字の制限がかかってるテキストフィールドに101文字をペーストすると最後の文字は切られて無くなるため)不具合というか、ユーザの意図に反する動きになる。

maxlengthをパスワードにかけた結果、意図したパスワードとは違うパスワードが設定されてトラブルになったケースをブログで見たことがあるのであまり使わないほうが良さそう。

送信ボタン押した時にチェックするのはわりと普通のやり方でいい。仕様としてそこの文字数制限が変わらないなら問題ない。

ちょっとエラーにするためのラベル欄の出し分けとかがめんどくさいくらい。

他には10/100的な感じで入力文字数/文字数制限を可視化して超えるなら赤くするのもあって、リッチでいい。

まとめとしては

・サーバに文字数制限はかならず書け、クライアントだけにしない

・クライアントでは利便性を良くするのを目的にする

になる