macOS nativemacOS nativeは 高品質なmacOSネイティブアプリケーション開発を志し、 その技術と知見を共有するためのコミュニティです。 次回イベント
Android/iOSアプリのテストの区分戦略 - クックパッド開発者ブログ
技術部の松尾(@Kazu_cocoa)です。 クックパッドのモバイルアプリ開発では、どのようなテストを書き、どのようなタイミングで、どのようなテストを実施するか？に関してエンジニア各位が意識を合わせるためにテストサイズを定義し運用してきました。ここでは、そんなテストサイズに関して簡単ですがまとめておこうと思います。 テストサイズとは ソフトウェアテストに関わったことがある方なら テストレベル という言葉には出会ったことがあるかと思います。JSTQBでは、このテストレベルは"管理していくテストの活動のグループ"と定義しています*1。 そうでない方も、俗に言う単体テスト/統合テストなど聞いたことがあるかと思いますが、その区分がここで示しているテストレベルとなります。 一方、このテストレベルはV字型と言われる開発工程と合わせて世の中で広く使われているため、社内における共通認識を構築するにあたり個
niw.at — iOS で文字数制限つきのテキストフィールドをちゃんと作るのは難しいという話
「そんなん簡単やろ」と思いますよね。 たとえば、「UITextField 文字数制限」でググれば山のようにブログ記事やらコードが出てくるし、Stack Overflow に載ってるコードのコピペ一発で解決しそうに思えませんか? 実は文字数制限をつけたテキストフィールドはそんなに簡単な話ではないのです。 shouldChangeCharactersInRange:replacementString: は使えない子 今回はこれに尽きます。 UITextField や UITextView のデリゲートで呼ばれる textField:shouldChangeCharactersInRange:replacementString: やtextView:shouldChangeCharactersInRange:replacementString: は使ってはいけません。 より正確に言うと、使うとき
UTF-8 の文字列の長さを正確に求めるためには Normalize しましょう
Twitterにメッセージを送信する際に、クライアント側でメッセージの長さを判定して画面に表示したいというような要件があると思います。当然、このような場合には入力されたメッセージを取ってきてその長さを求めてやれば良いのですが、どうやら UTF-8 などのマルチバイトな文字コードを使っていると文字列の長さを正確に求めるのが大変なようです。 ■何がどう大変なのか 図を書いてみました。「文」が文字数、「ｂ」がバイト数を表しています。 Objective-C の場合は、「文」が ``[NSString length]`` を、「ｂ」が [NSString lengthOfBytesUsingEncoding:NSUTF8StringEncoding] を表します。ほかの言語の場合もそれぞれ相当するメソッドまたは関数が用意されていると思います。 上のケースが一般的な UTF-8 文字列です。この場合
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://hmdt.jp/blog/?p=1129
