takeです。 弊社の動画配信サービスをAndroidで利用する際、現在のネットワーク状態により 配信する動画のビットレートを決定していたのですが。。。 当初のアプリ配信時には、ネットワーク状態は3GとWifiしかなくてWifiなら高ビットレート、 3Gなら低ビットレートを選択みたいな事をアプリからやってました。 が、時代の流れとは早いもので昨今ではWiMAX(+WiMAX)やらLTEやら新しいネットワークが増えてきました。 ユーザにとっては回線速度があがってとってもありがたい話しなんですが、開発者にとっては たまったもんじゃありません(汗 上記のように3GとWifiのみで判定していると、プログラムの組み方によっては高速回線であるはずの WiMAXやLTEが『3G』と判断されて画質の悪い低ビットレートの動画が配信されてしまいます。 この状態を回避する為に、正しいネットワーク状態を取得してみ
掲載コードに問題があったので、こっそりエントリを再々修正。 ネットワーク接続状態は必ずConnectivityManagerを使って取得する。なお、ConnectivityManagerを利用するには、AndroidManifest.xmlにを追加する必要がある。 サンプルコード public class NetworkEventActivity extends Activity { private boolean connected = false; private BroadcastReceiver connectivityActionReceiver; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layo
Androidで常駐型アプリケーションを作成する場合に便利なServiceについてライフサイクル・使い方を解説します。サービスの利用例はステータス通知(Notification)を変化させる等をご確認ください。Serviceを使う(1)では簡単化のため、Remote Messenger Serviceを次回以降として、LocalServiceに特化して解説します。 Serviceのライフサイクル onCreate / onStartCommand / onDestroyの3つの状態遷移 サービスの実行方法によってライフサイクルが異なる サービスの実行方法はContext#startServiceとContext#bindServiceの2種類 startService/stopService Service全般として実行中はServiceからActivityへIntentの発行が可能 サー
Binderクラスを使って作る最も一般的なServiceの作成方法です。 bindService()を使ってServiceをBindし、Serviceで提供するユーザー関数を直接コールすることができます。Bindしている間Serviceは存在し、Unbindすると削除されます。複数のActivityからマルチでBindすることもできます。 bindService()を使ったServiceの作り方は3種類ありますが、今回紹介する方法が最も一般的です。なぜなら、アプリ内(正確にはServiceと同一プロセスで動くコンポーネントにServiceを提供する場合)でServiceを提供する場合はこの方法が最も適切かつ簡単なため、他のプロセスやアプリに機能を提供するなど特別なケースでない限り、他の方法を使う必要がないからです。 おおざっぱな流れは、Service側のクラスはBinderを拡張したユーザ
前回の「Android 4.0のサービス/プロセス間通信の基本」ではAIDLを使用した「サービス」の基本を解説しました。サービスのライフサイクル、AIDL、Parcel、Parcelableに関しては、前回の記事を参照してください。 今回の記事で解説するサンプルアプリは、前回と同じものを使用します。以下よりダウンロードしておいてください。 なぜ「プロセス間通信」なのか? Androidの「サービス」は、バックグラウンドで処理を行いたい場合やバックグラウンドに常駐させたい場合に使用するケースがほとんどです。そのバックグラウンドの処理がアプリ固有であれば、同一プロセスで行い、プロセス間通信を行う必要はありません。 つまり、「複数のアプリから使用される可能性のある処理を独立したプロセスとして切り離し、それぞれのアプリから使用できるようにサービス化しておくこと、そのサービスを利用すること」がプロセ
さて前回に引き続きServiceの実装を試してみます。 今回はServiceからのCallbackを利用出来る様にしてみたいと思います。 BackgroundでServiceを走らせておいて「音楽の再生が終わったよ」というようなServiceで行っていた処理に何らかのEventが発生したらActivityに通知したいというような時に使用できます。 今回、実現する機能はServiceからのCallbackをもとにTextViewに表示するStringをupdateするというものです。 実装の要点をまとめます Activity側 Activity用のAIDLにCallback interfaceを定義 ActivityにServiceからのCallbackを受け取るためのCallback interfaceを実装 ActivityにServiceとBindするContext#bindServi
Android Design での Up と Back のガイドライン の振る舞いのパターンの実装方法を紹介します。 まず、Up と Back はそれぞれ次のように使い分けます。 ・Up : 画面間の階層関係に基づいたアプリ内のナビゲーションに使う ・Back : 最近行った操作を逆時系列順にさかのぼるナビゲーションに使う そのため、次のような違いがあります。 遷移範囲 ・Up : アプリ内の遷移だけ ・Back : アプリ内だけでなく別のアプリやホームアプリにも遷移する 振る舞い ・Up : 画面遷移だけ ・Back : 画面遷移の他に、フローティングウィンドウ(ダイアログやポップアップ)のキャンセル、Action Mode のキャンセルや選択中のアイテムのキャンセル、ソフトキーボードを隠すなどの操作にも使われる 基本的には、Up は一つ上の階層に戻るナビゲーションに使います。 http
今日は、NFCタグの基本の情報を読み取る簡単なサンプルを紹介します。 読み取る情報はタグの、アクション、ID、TechListです。 NFCのパーミッションを追加するのを忘れずに AndroidManifast.xml <uses-permission android:name="android.permission.NFC" /> MainActivity.java public class MainActivity extends Activity { private NfcAdapter mAdapter; private PendingIntent mPendingIntent; private IntentFilter[] mFilters; private String[][] mTechLists; TextView nfcActionView; TextView nfcId
参考 Adding Wearable Features to Notifications Creating a Notification Receiving Voice Input in a Notification Adding Pages to a Notification Stacking Notifications 概要 スマホと Wear が接続されていると、Notification が Wear にも表示(同期)される。 Wear では通知はカードとして表示され、このカードが表示されるところを context stream という。 これまでの通知でももちろん Wear に表示されるが、Wear 用に Notification を拡張することができる。 Notification を作る Notification の作成には NotificationCompat.Builder
HIGH以上だと、Heads-up Notificationになる(※priorityだけじゃなく、他の条件も絡む)。 MINだと、ステータスバーに表示すらされず、通知領域を開かないと見られない。 ※ 広告出しまくるアプリが、無闇矢鱈にMAXとかHIGHな通知を出してきて、アンインストールされまくる未来が見える。 適切な優先度設定をする方法 DEFAULT, HIGH, MAX はユーザーに割り込みをかけ、ユーザー操作を中断させてしまうリスクがある優先度レベル。 割り込みレベルは以下の基準 他人を巻き込む 時間が重要。その時である必要がある。 現実のユーザーの行動に直ちに影響を及ぼす可能性がある LOW, MIN はユーザーにとって価値がないわけではない。早急な対応が必要なかったり、気がついた時に通知を開いて見てみても意味があるものとか。 基準は以下 他の人を巻き込まない 時間に関係ない
NotificationManager mNM; @Override public void onCreate() { Log.d("Debug TEST", "onCreate"); mNM = (NotificationManager)getSystemService(NOTIFICATION_SERVICE); showNotification(); } @Override public int onStartCommand(Intent intent, int flags, int startId) { Log.d("Debug TEST", "onStartCommand"); super.onStartCommand(intent, flags, startId); return super.onStartCommand(intent, flags, startId); } @
ググれば出てくるんだけど、情報が古いので書きなおしてみた。 全体 Android OS の起動が終わると android.intent.action.BOOT_COMPLETED がブロードキャストされるので、それを捕まえて任意の処理をする。 起動時に呼び出されるコード ブロードキャストを捕まえたときに呼ばれるコード。MyActivity を開始している。BroadcastReceiver から Activity を開始するには Intent.FLAG_ACTIVITY_NEW_TASK が必要なので注意。 public class StartupReceiver extends BroadcastReceiver { private static final String TAG = "StartupReceiver"; @Override public void onReceive(C
volleyでハマったこと HTTPステータスコード 401 が返却されているはずなのに、ステータスコードが取得できない! (正確には -1が返却されてる) その時は以下の警告が表示された。 java.io.IOException:No authentication challenges found 原因を探る どこでExceptionが出ているのか原因を探ってみました。 まずはVolleyのRequestQueue内を探ってみました。 Volley#newRequestQueue() public static RequestQueue newRequestQueue(Context context, HttpStack stack) { File cacheDir = new File(context.getCacheDir(), DEFAULT_CACHE_DIR); String
Bundle とは Android アプリ開発のさまざまなところに出てくる オブジェクトの入れ物 である。本当に頻出するので Bundle の扱いに慣れているといろいろと捗る。以下例を挙げる。 例1: Activity の状態保存 画面回転や長時間放置してシステムに殺された場合などは onSaveInstanceState() で状態保存して onRestoreInstanceState() で復帰する。主に Activity のフィールドやカスタムビューなどは状態を復元する必要がある。 public class MyActivity extends Activity { @Override protected void onSaveInstanceState(Bundle outState) { outState.putString("hoge", "hoge"); outState.p
Androidで良い感じにテストするために、たくさんあるテスティングフレームワークを試して選定してみる。 環境 OS X Android Studio 1.0.2 テスト用サンプルアプリ 入力された値を足して表示するだけのサンプルアプリ(アクティビティを跨いだテストもしたいので2画面構成)。 リポジトリ https://github.com/shikato/AndroidTestSample 今回はこのアプリに対してテストする。 ロジックのテスト Android Testing Framework 標準でJUnitベースのAndroid Testing Frameworkが使える。 これまではJUnit3ベースだったけど、最近JUnit4がAndroid support libraryに含まれるようになり、JUnit4な記述でも簡単に書けるようになった。 JUnit4の導入 Android
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く