サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
世界禁煙デー
qiita.com/KeithYokoma
クラス名編をつくりました あるメソッドを定義しようとするとき、そのメソッドを使う人達が名前からどんなことをするか理解できるようにするには、メソッドの内容に応じて適切な情報量の命名が求められます。 この記事では、メソッド名に用いることでどのような情報が提供できるかを見ていきたいと思います。 真偽値を返すメソッド 場所 単語 意味 例
cronJob = require('cron').CronJob module.export = (robot) -> task1 = new cronJob('00 00 00 * * 1-5', () -> envelope = room: "#channel" robot.send envelope, "ほげら" [Mon Mar 02 2015 00:00:00 GMT+0000 (UTC)] ERROR TypeError: Cannot call method 'send' of undefined at SlackBot.send (/path/to/hubot/node_modules/hubot-slack/src/slack.coffee:181:16, <js>:216:33) at Robot.send (/path/to/hubot/node_modules/h
以前の記事 で、CMDを使って Hubot を起動することで、docker run -d時にコンテナを立ち上げるとともに Hubot が動くようになった。 しかしこの方法の場合、Hubot が何らかの時間のかかるタスクを実行すると、Hubot からの ping が帰ってこなくなって Slack とのコネクションが切られてしまう。そうすると、CMDで実行した Hubot の起動コマンドも終了することになり、結果コンテナも止まってしまうことになる。 forever npm にある、コマンドを裏で実行し続けてくれるコマンド。これを使って以下のようにすると、Hubot が永続的に実行される。 forever でハマるポイントはここにまとまっている(http://qiita.com/kacky69/items/ee806b8c17bbd70ca55e)。
Android アプリ全体で統一したデザインスタイルがあると、つぶしが効いて良いですよね。 そのための仕組みとして、Android ではテーマというものが設けられています。テーマを用いることで、アプリケーション全体の配色を決めたり、文字のスタイルを決めたりすることができるようになります。 一つのテーマを全体に適用するだけでよければそれはそれで良いのですが、実際問題としては複数のテーマを画面ごとに使い分けることもよくある話かと思います。この画面はフルスクリーンで ActionBarを消すけど、別の画面ではActionBarを出す、みたいな。 さて、複数のテーマを使う場合、たとえば、Light と Dark でボタンの色みを変えたい、という事が起こります。色合いがよく似ているならともかく、Light と Dark のように大きな違いがある場合は、色の調整をしたほうが良いでしょう。 また、テーマ
クライアントアプリにとって、マルチスレッドプログラミングは避けては通れない重要な概念です。しかし、気をつけないとハマるポイントも多く、初めてクライアントアプリを学ぶ人たちからすると、複雑で難解な取っつきづらいものでもあります。ここでは、スレッドの基本から、効率的な使い方、また複雑化しやすいポイントをシンプルに実装するためのノウハウを見ていきます。 TL;DR スレッドの取り扱い方を知る Threadをそのまま使わず、AsyncTaskやIntentService、時にThreadPoolExecutorを使ってスレッドの使い方を効率化する。 複雑な処理フローをシンプルに扱うためのフレームワークを導入する PromiseやRxAndroidなどで、複雑化しやすいポイントを整理する。 スレッドの基本 スレッドといえば、ThreadクラスやRunnableクラスがベースにあります。以下のようにす
開発のイテレーションを高速に回す上で、CI は非常に重要な役割を担っています。バージョン管理システムにコードをプッシュ(コミット)したと同時に、CI に対してコードのビルドやテスト、解析をリクエストすることで、アプリケーションのデプロイやディストリビューションからユニットテストとコードの静的解析までの流れを自動化し、作業の抜け漏れ防止や効率化が見込めます。 最近では、Jenkins のように自分たちで CI を管理しなくても、ビルドやテストの手順と環境構築に必要な少しの情報を与えれば勝手に動作してくれる CI サービスがいくつか出てきました。代表的なところでは、TravisCI, CircleCI, wercker, drone.io などがあります。この中でも特に、TravisCI は古くから GitHub と連携して自動で動いてくれるようになっており、よく使う人も多いのではないかと思い
【翻訳】AsyncTask と AsyncTaskLoader を rx.Observable に置き換える - RxJava Android PatternsJavaAndroidReactiveExtensionsRxJavaRxAndroid この記事は、Replace AsyncTask and AsyncTaskLoader with rx.Observable – RxJava Android Patternsの翻訳です。多分に意訳が含まれます。あと、そんなに RxJava を使ったことがないせいもあって、若干怪しい記述があるかもしれません…そして、個人的には AsyncTask はやればできる子だと思っています :p はしがき RxJava に関して、はじめの導入に関する記事は至る所で投稿されている。中には Android での事例を取り扱っているものもある。一方で、導入に至
Web な人もアプリな人も、これから新しく Android アプリを作るなら抑えておきたいポイント3選Androidandroid開発 概要 Lollipop が発表されてから時間も立ち、Android Auto、Android Wear、Android TV と、多様性を見せ始めた Android ですが、今後とも多種多様なデバイス向けに様々なアプリを作っていく流れがあるなか、新しくアプリを作るなら抑えておきたい要所をまとめました。 TL;DR 抑えるところは 3 つ。 画面とライフサイクル 非同期処理 互換性 かなり端的にいうと、Activity や Service などのライフサイクルとうまく付き合いながら、コードの構成のレイヤー化を行い、非同期処理を簡潔に記述できる準備をしておくことと、非同期処理とあわせてマルチスレッドプログラミングの基本を抑えておくこと、互換性への準備を最初にし
Intent の中身を見たい Intent を受け取った時、中に何が入っているか気になることがあります。 自分のアプリ内から飛んでくる Intent なら大したことはありませんが、よそから Intent が飛んできた時、中に何が入っているかがとても気になります。 toString() の罠 で 世の中便利なもので、どんなオブジェクトもObject#toString()によって文字列化することで、オブジェクトを人間に読めるようにすることができます(ただし本当に読み取れるようになるかどうかは実装に依存する)。 便利なので、Intent#toString()とか、文字列リテラルで結合して自動で文字列化してもらったりとかするんですが、以下のような文字列が生成されます。 Intent { act=android.intent.action.MAIN cat=[android.intent.categ
前回の Multi-dex Support はい。もうすでに以前書いた情報が古くなってしまったので、改めて書き直します。 Multi-dex Support が一体なんぞやというのは前回の記事を参照してください。 準備 maven にサポートライブラリがあるので、依存関係にそれを追加します。
元記事はこちら どうも、Android Advent Calendar に登録するのを忘れていて、折角の機会を棒に振った KeithYokoma で御座います。 元記事はもう先月の話ですのでご存じの方も多いかと思いますが、ついに、あの Google Play Services の SDK が分割されます。今まで、Jake Wharton があまりのデカさに涙目になったり、これによって 64k のリミットに引っかかってビルドができなくなったり、これを回避するために頑張って MultiDex に対応 したりしてきたことと思いますが、もう悩むことはありません。 Google Maps API として、ナビゲーションの開始をサポートするものが増えるので、簡単にナビゲーション機能が実現できるようになります(もちろん、今までも Intent で頑張る方法があったりはしましたが…)。 また、ライトモード
前提知識 ざっくり言うと Fragment はライフサイクルが複雑で、フレームワークそのものが複雑なので、モジュラーな設計をするには大きすぎる View を継承して自分で CustomView を作るほうが、余分にライブラリを追加する必要がなく、古い端末も同時にサポートできる そもそも Activity も Fragment も Controller なのでロジックをそこに書いたらダメ 読んでおきたいリスト Fragment は本当に多様なデバイスへ対応する唯一の方法なのか Square Fragmentやめるってよ Advocating Against Android Fragment 【翻訳】Android Fragmentへの反対声明 FragmentManager#executePendingTransactions() が怖くて使えないあなたへ 知らないとハマる Fragment
Multi-dex とは 一個の dex に含められるメソッドの総数が 65,535 なのは有名な話ですが、Google Play Services や Guava などの大きなライブラリを使うと、わりとすぐにその数字に達してしまいます。 Guava の場合、ドメインに応じて dependency をつまみ食いできるので、不要なものは dependencies に記述しなければ良いだけで済みます。 しかし、Google Play Services は All in one なライブラリのため、つまみ食いができず、ProGuard で使わないものを無理やり削ぎ落とすなどの工夫が必要です。 それでも、ライブラリへの依存が増えれば、その分だけメソッドの総数も増えていきます。どうしても 65,535 を超える場合、Multi-dex Support を使うことで、この問題に対応することができます。
アプリのバージョンを上げた時、何かしら互換性を保つための作業が必要なことがあります。 たとえば、データベースのマイグレーションをしたり、その他永続化したデータを書き換えたり、など。時間のかかるものもあれば、かからないものもあります。 王道なやり方としては、Application#onCreate()でバージョンを覚えておいて、次にApplication#onCreate()に来た時に覚えておいたバージョンと PackageManager から取ってきたバージョン情報を突き合わせて、バージョンが変わっていたら、バージョンごとに必要な処理をする、と言った感じでしょうか。 public class MyApp extends Application { @Override public void onCreate() { super.onCreate(); if (isVersionChange
参考:Advocating Against Android Fragments Fragment の基本 Fragment といえば、Honeycomb から導入された、多様なデバイスへ対応するための仕組みで、Activity のライフサイクルに合わせて動作するモジュールのようなものです。 Fragment として細かく分けたモジュールを組み合わせることで、多様なデバイスへ対応しやすくする、という寸法です。 ライフサイクル Activity に付随して動くので、Fragment も勿論ライフサイクルを持つのですが、Activity よりもはるかに複雑なものとなっています。 Square のエンジニアブログに曰く、WTFs/min = 2^fragment countであると。 トランザクションとインスタンスの管理 Fragment Transactions によって、Fragment の操
この記事は Mac 向けです。 Android のエミュレータには、arm と atom と mips の 3 つの CPU があって、atom に関しては、Intel が配信しているアクセラレータを SDK Manager でダウンロードし、dmg をマウントしてインストールするようになっています。この辺の作業の話はネットに沢山転がっているのでそちらを参考にしてください。 さて、最近(昨日今日くらいの話) そのアクセラレータである Intel x86 Emulator Accelerator(HAXM) のインストーラのバージョンが上がり、Rev.5 になりました。更新されたので中身を見に行ってみると、インストーラの dmg ファイルが 2 つに増えていることがわかると思います。 以下のような名前の dmg ファイルがあります。 IntelHAXM_1.1.0_below_10.10.d
声に出して読みたいObjective-Cのライブラリ8種(2014.7) に触発されて書いてみます。 第一回はこちら 前回はこちら 今回は、アノテーションを用いた、アスペクト指向っぽいものを中心に紹介します。 hugo 安心と信頼の JakeWharton 先生のライブラリでございます。 デバッグ時にメソッドコールをロギングしてくれるライブラリで、ログ出力をしたいメソッドに対して@DebugLogアノテーションをつけることで、そのメソッドの呼び出しと終了がロギングされます。呼び出されたスレッドと、終わるまでに要した時間も出力されます。 アノテーションの実体はhugo-annotationsにありますが、ログ出力処理そのものはhugo-runtimeにあります。hugo 自体は、AspectJ をベースに、@DebugLogアノテーションのついたメソッドが呼ばれたのを検知して処理を実行してい
メモ書き Gradle 2.1 が必要になるので、${project_root}/gradle/wrapper/gradle-wrapper.propertiesを書き換えましょう(Gradle Plugin のバージョンをあげたら書き換えを促すプロンプトが出るはず)。 テスト用にAndroidManifest.xmlが、src/androidTest以下に配置できるようになりました。 ライブラリモジュールのAndroidManifest.xmlでプレースホルダが使えるようになりました。ライブラリモジュール内で解決されないプレースホルダは、それを使用するプロジェクト側で解決されます。 ProductFlavor や Build Type ごとにプレースホルダが設定できるようになりました。 Variant.getMappingFile()で、ProGuard の mapping.txt へア
Java の列挙型 Java の列挙型は、C 言語の enum と異なり、単なる int の定数列挙ではなく、オブジェクトの列挙になるので、メソッドを宣言したり、メンバ変数を宣言したりと、振る舞いを持たせることが出来る。 内部的には、列挙したオブジェクトは定数として扱われるので、列挙の数だけオブジェクトが予め生成されることになる。 詳細は Effective Java を読もう! 振る舞う enum 通常の enum の宣言は以下のようになる。
声に出して読みたいObjective-Cのライブラリ8種(2014.7) に触発されて書いてみます。 前回はこちら android-promise Android フレームワークにおける Promise の実装です。Bolts は厳密には Promise ではなく(どこでそのスライドを見たのか忘れてしまった…)、継続 をベースにしているライブラリで、なにやら最近はちょっと違うものも含まれるようになってきましたが、こちらは純正の Promise の実装です。もう一つ、jdeffered もありますが、jdeffered についてはこちらを御覧ください。 Android でよくある、非同期処理とライフサイクルオブジェクトの関係で起こる悩ましいバグにうまく対応するため、Promise を生成するときにライフサイクルオブジェクトを登録するのが特徴です。これによって、ライフサイクルオブジェクトが死を
声に出して読みたいObjective-Cのライブラリ8種(2014.7) に触発されて書いてみます。 今回は Square 社製ライブラリを見ていきます。 Picasso 安心と信頼の Square 社製のライブラリです。画像のローディングとキャッシュについて面倒を見てくれますが、画像の加工についても扱っています。 Context、多くの場合Activityのライフサイクルに合わせて画像の読み込みを管理したり、AdapterViewの中にあっては、Viewのリサイクルをハンドリングして、画像のロードをキャンセルしたりもしてくれます。 Transformationインタフェースを実装し、そのロジックを渡すことで、画像の加工もできます。 処理の始まりはPicassoクラスから。Picasso#with(Context)で自動的にオブジェクトの初期化がはじまり(まだの場合)、続けてどこから画像を
非同期処理と言えば、IntentServiceとAsyncTaskのいずれかは使ったことがあると思います。UI スレッドとは別のところで非同期に何かする、という点ではどちらも同じことをこなせるのですが、実際問題として何が違って何が同じなのかというところを踏み込んで見て行きたいと思います。 並行性とパフォーマンス IntentServiceは内部にHandlerThreadを持っていて、このHandlerThreadのなかで非同期処理を実行します。HandlerThreadは、内部に持っているHandlerにメッセージが渡ってきた時、それを順に処理するようできているので、メッセージを同時に複数送ると、ジョブキューのようにシリアルな動作で、メッセージを1つずつ捌いていきます。 Handlerがもっているメッセージキューにメッセージがなくなると、IntentServiceは自らのライフサイクルを
標準の設定画面では、標準のテーマ(Holoとか)に沿った見た目になります。ある程度凝ったアプリを作っていると、設定画面だけが妙に浮いた感じに見えてしまって、統一感が失われてしまいます。 ここでは、設定画面の各項目のレイアウトに焦点を当てて、カスタマイズの方法を見ていきます。 Summary Preferenceの各要素(PreferenceCategoryとかPreferenceScreenとかCheckBoxPreferenceなど)は、カスタムのレイアウトを差し込むためのアトリビュートがある 自分で定義したレイアウトの XML が差し込めるので、カスタム View を作ればより凝った画面を作れる How to customize レイアウトの準備 まずはカスタマイズしたいレイアウトを用意します。 ベースとなるレイアウトはAOSPにあります。 気をつける点は、設定画面で表示する項目に使う
AsyncTaskLoaderやCursorLoaderなど、AsyncTaskでは不便だったいくつかのことがLoaderという仕組みによって解決されました。 主には、AsyncTaskで悩みの種であったActivityのライフサイクルとの分離が、Loaderによって実現されます。これによって、画面回転したときにAsyncTaskのインスタンスをうまいこと作りなおさないようにしつつも、コールバックを受けるオブジェクトの参照は新しいActivityに紐付いたものにしなければならない、ということも、システムが勝手にやってくれるようになるので、管理がとても楽になります。 一方で、結構扱い方には注意が必要なことがあって、実装者が知った上で使用すべきこともいくつかあります。 Loader のライフサイクル LoaderManager のインスタンス取得は Activity#onStart() より前
GitHub や Google Group を眺めていると、実にたくさんのライブラリプロジェクトがあります。 UI に関連するものもあれば、設計を整理するのを助けてくれるものもあり、様々です。 特に、UI に関連するものは、実際に動かすとどうなるのかが気になるところ。しかし、必ずしも README にスクリーンショットがあるとは限らないのが現状です。また、スクリーンショットがあっても、操作感がわからなかったりすることもあります。 そんなあなたへ、いろいろなライブラリのサンプルを寄せ集め、実際に動く様子を手に持って触れるアプリがありますのでご紹介。 for Android: Libraries for Developers for iOS: Libraries for Developers 片っ端からライブラリを寄せ集め、デモも組み込まれているすぐれもの。ライブラリの Author やライセ
コールバック、よく使いますよね。 非同期処理の結果を受け取るには、必ずと言っていいほど付き合うことになるコールバックですが、UI のようにライフサイクルを持つオブジェクトと共存するには、考慮すべきことがいくつかあります。 ここでは、おおまかに、上手にコールバックと付き合う方法を見ていきます。 基本となるポイント なんといってもまず抑えなければいけないポイントは、ライフサイクルを持つオブジェクトとの共存です。世に出回っている様々なコールバック管理のためのライブラリは、このライフサイクルを持つオブジェクトとの共存をいかに楽に、あるいは直感的にするか、ということをもとに作られています。 ライフサイクルとはつまり、オブジェクトが生成されてから消滅するまでの一連の流れのことです。 newしたりallocしたりしたタイミングでオブジェクトが生成され、GC に回収されたりdeallocしたりするタイミン
アプリ用の画像パーツを作ると、どうしても面倒くさいのが、各 dpi 向けに画像を出力する作業です。 初めて作る人にとっては、mdpi を基準として、hdpi は 2 倍、xhdpi が 3 倍…と計算していたら日が暮れた、なんてことも。 そんな時、スクリプト一発で mdpi ~ xxhdpi までのアセットを自動出力してくれるものがあったら… Illustrator 向けですが、JavaScript で書かれたスクリプトが GitHub に落ちているではありませんか!! How to use とても簡単。Illustrator のメニューから、ファイル > スクリプト > その他のスクリプト で、このリポジトリのスクリプトを選択します。そうすると、出力先のディレクトリを選択するよう促されるので、出力したいディレクトリを選択します。 つぎに、Android / iOS それぞれに必要なリソー
authenticator.xml の account type について authenticator.xmlに、AccountManagerに登録されるアカウント認証にまつわるメタデータを記述しますよね。 このとき、android:accountTypeという文字列属性の値に、以下のように書いたことはありませんか? Build Variant ごとにリソースが別れてくれれば、リリース版とデバッグ版で Account Type が切り替わってくれるのでそれぞれにアカウントが分けられて便利!というノリで、このように書きたくなりますが、実は罠があります。 突然の bind failure デバッグをしていると、アプリを何度もインストールしなおしたりすることがあります。そんな時、アカウントの作成を実行していると、唐突に見慣れない例外が飛んでくることがあります。 android.accounts.
Android Open Source Project のコーディングガイドライン には、いくつかのハンガリアン記法があります。 publicでなく、かつstaticでないフィールドにはmを、static なフィールドにはsをつけるのが Android 流のハンガリアン記法のようです。 が、そもそも Java を使って、かつ IDE を使っている時点で、ハンガリアン記法を取り入れるメリットはそんなに無いように思われます。 このあたりは、Twitter での Jake Wharton と Romain Guy のやりとりの中でその経緯が語られています。 このやりとりを要約すると、以下のような内容です。 Jake Wharton: Android の Java にハンガリアン記法を使うことにしたやつ謝れ。 Romain Guy: 激しく同意。C++やってる人とか Vimmer に Java を
次のページ
このページを最初にブックマークしてみませんか?
『@KeithYokomaのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く