ホームボタン長押しアプリの変更や削除する方法

下のホームボタンの長押しから起動できるコレ.

20160215-225059

通常は「Googleアプリ」になっているはず.

変更や削除をするには,

[設定]

[アプリ]

[Googleアプリ]
※ 設定されているアプリ

[既定で開く] (6.x のみ)

[設定を消去]

デフォルト・既定のアプリ「設定を消去」すると長押ししたときにアプリを選択できるようになります.

また, Android 6.x (Marshmallow) では以下の方法でも可能です.

[設定]

[アプリ]

[右上の歯車]

[既定のアプリ]

[アシストと音声入力]

[アシストアプリ]
※ 歯車ボタンを押さずに 欄自体を押す

[アシストアプリの選択]

いまや設定も複雑で深いとこにあるのよね.

Android 6.x (Marshmallow) ホーム長押し (アシスト機能) アプリの設定

【3年連続3回目】ホームボタン長押し から起動されるアプリの変更は「アシス」で


Nginx の location ブロックのパターン化

簡単そうに見えたのだが思い通りにいかない.

優先順位というか, 処理順序というか. ここらの話.

location  = / {
  # matches the query / only.
  [ configuration A ] 
}
location  / {
  # matches any query, since all queries begin with /, but regular
  # expressions and any longer conventional blocks will be
  # matched first.
  [ configuration B ] 
}
location /documents/ {
  # matches any query beginning with /documents/ and continues searching,
  # so regular expressions will be checked. This will be matched only if
  # regular expressions don't find a match.
  [ configuration C ] 
}
location ^~ /images/ {
  # matches any query beginning with /images/ and halts searching,
  # so regular expressions will not be checked.
  [ configuration D ] 
}
location ~* \.(gif|jpg|jpeg)$ {
  # matches any request ending in gif, jpg, or jpeg. However, all
  # requests to the /images/ directory will be handled by
  # Configuration D.   
  [ configuration E ] 
}

Nginx location priority - Stack Overflow

なので公式 wiki/recipe を見ながら少し整理.

PHP FastCGI Example | NGINX

Codeigniter | NGINX

Drupal | NGINX

osCommerce | NGINX

WordPress | NGINX

公式にて書式はこう.

Syntax: location [ = | ~ | ~* | ^~ ] uri { ... }

Module ngx_http_core_module

複数のlocationブロックがある場合, リクエストのURL内該当文字列に対して優先順位の順番にマッチを確認していき, 最初にマッチしたロケーション設定(処理)ひとつが反映される.

1.「=」完全一致
2.「^~」前方検索 (マッチ文字列の長い順)
3.「~」正規表現 (記述順)
4.「~*」正規表現 (記述順・大小文字を考慮しない)
5.「(なし)」前方検索 (マッチ文字列の長い順)

これに加えて, それぞれの設定(処理)自体の優先順位を考慮しておかないと, 「アクセス拒否したつもりが丸出し」や「PHPスクリプトのダウンロード公開」などとなってしまう.

1. 特殊ファイルのログ制御
2. ディレクトリ単位のアクセス拒否
3. ファイル単位のアクセス拒否
4. PHPファイルの実行 (PHP-FPM)
5. 静的ファイルのキャッシュ期限の設定
6. フロントコントローラへのリクエスト付け替え

これら2つの優先順位を考慮にいれながら書かれている公式wiki/recipeの設定は, ある程度おおまかにパターン化できる.

1.「=」特殊ファイルのログ制御
2. 「^~」ディレクトリ単位のアクセス拒否
3.「~」ファイル単位のアクセス拒否
4.「~」PHPファイルの設定・実行 (PHP-FPM)
5.「~*」静的ファイルのキャッシュ期限の設定
6.「なし」フロントコントローラへのリクエスト付け替え

頻出しそうなのを順序を守って箇条書きに.

# 1. specific files 
location = /favicon.ico {
  log_not_found off;
  access_log off;
}

location = /robots.txt {
  allow all;
  log_not_found off;
  access_log off;
}

# 2. deny directories
location ^~ /conf/ {
  return 403;
}

# 3. deny files
location ~ (^|/)\. {
  return 403;
}

location ~ \.(txt|log)$ {
  allow 192.168.0.0/16;
  deny all;
}

# 4. php scripts
location ~ [^/]\.php(/|$) {
  fastcgi_split_path_info ^(.+?\.php)(/.*)$;
  if (!-f $document_root$fastcgi_script_name) {
    return 404;
  }
  fastcgi_pass unix:/var/run/php5-fpm.sock;
  fastcgi_index index.php;
  include fastcgi_params;
}

# 5. static content files
location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
  expires max;
}

# 6. others(internal rewrite)
location / {
   try_files $uri $uri/ index.php;
}

実際はこれらに加えてさらに, 内部/外部での リライト/リダイレクトなどを記述して location 設定を複数またいでいくことになると, 大量に記述された apache mod_rewrite 設定のように直感的に設定できなくなっていくので locationブロックに関してはテンプレ化しておくのがいいように思う.

そもそもは「if」や「locationを使った入れ子」で混乱したので.

nginxのlocation設定について、優先順位の基本と意外な罠

If Is Evil | NGINX

if ($request_uri = /) { 
  set $test  A; 
} 
  
if ($host ~* teambox.com) { 
  set $test  "${test}B"; 
} 
  
if ($http_cookie !~* "auth_token") { 
  set $test  "${test}C"; 
} 
    
if ($test = ABC) { 
  proxy_pass http://teambox-cms.heroku.com; 
  break; 
} 

nginx hack for multiple conditions

手をつける前に, ある程度の歴史や経緯を分かっておく必要があったかな.

Nginx Configuration Primer

まあいいか.

みんなも reload したらチェックしてみよう.

$ curl -L http://yourhost.com/ -o /dev/null \
     -w '%{http_code} %{content_type} %{size_download} %{url_effective}\n' \
     -s

200 text/html; charset=UTF-8 1334 http://yourhost.com/

Mac OSX El Capitan のターミナルに表示される "[" (角カッコ) は何?

これ.

h6yLA

どこかの設定ファイルに間違えて混入させたのかと思って放置していましたが.

ついに 消そうと思って調べていたら便利な OS X 10.11 - El Capitan の機能「mark」というものらしいです.

Marks_and_Edit

Command + ↑
Command + ↓

で移動できます.

Navigate_and_Edit

コマンドの出力結果が多い時にすぐに実行したコマンドの行に戻ることができます.

また, そのコマンドと出力結果を

Shift + Command + ↑
Shift + Command + ↓

でまとめて選択することもできます.

大量な出力結果のコピー&ペーストなどに便利ですね.

けど, まあ OFF にしておこうかな, とくに理由はないけど.

terminal - Why is there a left bracket before my bash prompt? - Ask Different


Related Categories :  NewbiePreference


「mハンガリアン記法」について自ブログでも発射!!

以前から反対していましたが

Jake WhartonさんはTwitterを使っています: "Someone, somewhere made the decision to use hungarian notation for Android Java sources. I think they owe the community an apology."

ついに自ブログでも言及しています.

Just_Say_mNo_to_Hungarian_Notation_-_Jake_Wharton

Just Say mNo to Hungarian Notation - Jake Wharton

「Androidのサンプルコードが利用している」
→ サンプルコードはAPSPで生まれそのAOSPスタイルに固執しているだけ.

「コードレビュー時に役に立つ」
→ 変更時に更新忘れしたものかもしれない.

「開発時に役立つ」
→ IDEがそれぞれ正しく表示してくれる.
→ 変更忘れが発生する.

「Google のようにコードを書きたい」
→ GoogleやAOSPの一部の会社はハンガリアン記法を禁止している.

WikiPedia をみてみる.

システムハンガリアンを使っているソースコードを修正してデータ型を変更した際、同時に変数名も変更するコストがかかる。変更を怠ると、たちまち不整合となり、保守の障害となるだけで一利もない。

C++やC# のような言語では型付けが存在するためにシステムハンガリアンを使用することによる利点はない。移植性を阻害する。

総称型、メタプログラミングとの相性が悪い。

いわゆる良書と呼ばれるようなC++本で、現在システムハンガリアンを採用している例が皆無。

かつてMFCにおいてハンガリアンを全面的に採用していたMicrosoft自身が、.NET Frameworkではハンガリアンを禁止している。

日本では、情報処理技術者試験などのC言語の問題でシステムハンガリアンが使用されていない。

結局,「IDEの進化」が大きく影響しているといえそう.

間違えたコードが機械的に検出される手法が利用可能ならば、間違えたコードが間違えて見える手法より明白に勝る。

エラー検出に関連する技術は、ハンガリアン記法が考案され成功を収めた当時と比べ大きく進歩している。

コードを間違える原因の中で、変数の意味(=型)の取り違えに由来するものが下位にあるとは言い難い。

ハンガリアン記法 - Wikipedia

なので, Android Studio での設定を.

[Preference] から.

color

prefix

技術も開発手法も変わっていくものなのですね.

Android Code Style で インデントはスペース何個?


Android Studio「Instant Run」の適用範囲や条件

実際使ってみると, 編集したコードが反映されたりされなかったり.

でも確かに高速なときもある.

効果的に高速で動作してくれるためのコードの編集範囲・条件は何なのか.

Instant_Run_-_Android_Tools_Project_Site

Instant Run - Android Tools Project Site

分かりづらいので表に.

instantrun

なんだか...

it seems that this feature is not perfectly stable yet : sometimes the modified code is marked as “pushed” whereas the modification is not really applied on the emulator. It is currently stable when it comes to hot resources or xml file swapping. It is really a great improvement, as we generally have to perform numerous incremental builds when we are tuning our xml files.

Reduce your Android build duration | OCTO talks !

みんなも上手に「Instant Run」を使って高速にアプリを開発しよう!!