TL;DR Summary; if you have binary (non-alphanumeric) data (or a significantly sized payload) to transmit, use multipart/form-data. Otherwise, use application/x-www-form-urlencoded. The MIME types you mention are the two Content-Type headers for HTTP POST requests that user-agents (browsers) must support. The purpose of both of those types of requests is to send a list of name/value pairs to the se

AsyncTaskって不親切よね だってエラー処理がしにくいもの doInBackgroundの戻り値がResultのみなので、非同期処理中にエラーが発生したとき どんな理由でエラーが発生したとか、その時のメッセージはどれにするとか 指定することができません。 不親切なら自分でよくする 戻り値を独自のクラスにしてしまえばなんとでもなるよね サンプルアプリつくる 画像をダウンロードしてくるアプリを作ろうと思います。 ありがちですね。ぐだぐだ設計します。 しばらく箇条書きが続くので、めんどい人は飛ば(ry 設計 処理の流れ ネットワークから画像をダウンロードしてくる 画像のダウンロードが終わるとUIに表示する ネットワークの障害がある場合、その旨をユーザに伝える クラスの設計とか MainActivity ユーザへの情報伝達は全てActivityが行う DownloadImageTask As

_ mavenを使ったAndroidプロジェクトの構成管理 「maven-android-plugin」と「Maven: The Complete Reference」内のChapter 14を参照しながらやってみた記録。 mavenレポジトリへのAndroidSDKのインストール(maven-android-sdk-deployer) まずは環境変数の確認。 ANDROID_HOME=/path/to/android-sdk-linux_86 となっているのを確認。その後、maven-android-sdk-deployerのgithubからダウンロードしてきたtar玉を展開。展開したディレクトリの中でmvn install $ mvn clean install (略) [INFO] ---------------------------------------------------

2011年08月05日 JUnit 4.4から組み合わせを表現するためのTheoryという機能が導入されています。このTheoryという機能について、日本語での概説がなかったため、調べた範囲で紹介したいとおもいます。 Theoryの実行Theoryは組み合わせテストのための表現方法です。Theoryを利用するためには、@RunWithアノテーションでTheoriesランナーを指定します。すると、@Theoryアノテーションが指定されたメソッドが実行されます。 @RunWith(Theories.class) public class HelloTheoryTest { @Theory public void helloTheory() { System.out.println("Hello, Theory!"); } } 出力は下記の通りとなります。 Hello, Theory! Data

基本：インテントでカメラを呼び出す方法 以下のインテントを使うと標準のカメラアプリを呼び出すことができます。 public void onBasicClick(View view) { Intent intent = new Intent(); intent.setAction(MediaStore.ACTION_IMAGE_CAPTURE); startActivityForResult(intent, 1); } ちなみに、MediaStore.ACTION_IMAGE_CAPTURE = "android.media.action.IMAGE_CAPTURE" に対応したカメラアプリ（Camera 360など）がインストールされていれば選択ダイアログが表示されます。 撮影された画像データは以下のように受け取ります。 @Override protected void onActivit

『フォトショップ・ブイアイピー』の新着記事です。フォトショップやデザインをたのしむウェブサイト。2009年３月創刊以来、3800を超えるコンテンツを更新しています。フリーフォントなどの無料デザイン素材／配色やWeb制作といった最新トレンドも公開中。

「のどが渇いた」というユーザーに何を出す？ ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチYoshiki Hayama

20201028 AWS Black Belt Online Seminar Amazon CloudFront deep dive

今回は直接Railsとは関係ないのですが、先日こういうページを見つけました。 http://redrata.com/restful-uri-design/ これは2009年に書かれたもののようですが、URL設計に関する重要な考え方がいろいろ書かれています。 その中に、このブログのシリーズの(4) スラッシュと「持っている」関係や(5) Railsのリソースパターンの前段階になるような“Choosing a URI schemes for resource hierarchies”という話があったので、かいつまんで紹介したいと思います。 リソースの階層に対して、どういうURLを設計するか？ 前提として、設計するWebサイトには、conversation（会話）というリソースが複数あり、それぞれのリソースはユニークなIDで区別されるとします。（IDは数字とは限らない識別子） /conversa

第4回　JavaScriptでオブジェクト指向プログラミング：連載：Ajax時代のJavaScriptプログラミング再入門（2/4 ページ） プロトタイプ・ベースのオブジェクト指向 ということで、インスタンス共通のメソッドを定義するには、インスタンスに対してではなく、（少なくとも）コンストラクタによって定義する必要があることが分かった。しかし、「少なくとも」とただし書きが付いたことからも予想できるように、コンストラクタでメソッドを追加するのは好ましいことではない。 というのも、クラス（コンストラクタ）はインスタンスを生成する都度、それぞれのインスタンスのためにメモリを確保する。リスト3の例であれば、Animalクラスに属するname、sex、toStringという3つのメンバを設定するわけである。 ところが、toString「メソッド」については、すべてのインスタンスでそれぞれまったく同じ