Rawbytes

Category: android

  • Androidアプリ主要な構成要素について要点だけ

    Androidのアプリにはいくつかの重要な構成要素があって、それぞれ大まかには以下のようにとらえれば良い。

    • アクティビティ：画面操作
    • サービス：バックグラウンド動作
    • ブロードキャストレシーバ：システム監視
    • コンテンツプロバイダ：データベース


    (more…)

  • Android Market でのキャリア決済対応状況の要点だけ（2011年4月15日現在）

    先日のポストでdocomoがAndroid Marketでの決済に対応したことを書いたけど、他のキャリアの対応状況を整理してみた。結論として、大手３キャリアの主要端末ではキャリア決済が既に可能、という理解でOKそう。

    いずれもキャリア決済可能なものは日本円で価格設定されている（約○○円と出ない）もの。あと、auは非対応の機種もあるので注意。

    ついでにAndroid Marketでない、Android上でのコンテンツ決済サービスのメモ。こちらはサイト側の対応が必要なので、対応サービスでのみ利用できる。さらにいうと上記のauのプレスリリースを見るかぎり、この決済サービスの「対応サイト」にAndroid Marketが加わった、という関係性みたい。

  • Android Market のdocomo決済について要点だけ

    Xperia arc SO-01C ではSIMカードを指してない状態でも Wi-Fi が利用可能。
    ついでなので、Android Marketの決済まわりがどのような挙動になるのかを
    いくつかの条件で試して、整理してみた。

    １．docomo決済について
    ・Wi-Fi接続だけ（SIMなし）のときはクレカ決済だけが可能。docomo決済はそもそも選択肢として出てこない。
    ⇒docomo決済をするには3G回線が生きていることが条件ということかな。なのでSIMがささっていても圏外では同様、だと思う。
    ・クレジットカード決済はSIMなしでも可能
    ・docomo決済を選択すると、初回には住所氏名の入力が求められる。これはGoogle checkoutの「支払方法」の一つとして、クレカと並列として扱われる。VISA xxxxxxに対して DOCOMO JP xxxxxxxxxxx見たいな感じ。決済完了メールもこのDOCOMO JPで来る。
    ・docomo決済でアプリを購入するには、spモードパスワード入力が必須。
    ・マーケットで「約○○円」と出るもの（たしか外貨払いのもの）は、docomo決済できない（項目としては出てるけど、グレーアウト）

    ２．払い戻しについて
    ・アプリ購入ご１５分間は払い戻しが可能。
    ・購入したアプリのAndroid Marketページに行くと、購入ボタンのところに「払い戻し」というボタンが出る
    ・「払い戻し」をタップすると、払い戻し処理に合わせてアプリのアンインストールも行われる
    ・一度払い戻しをしたアプリは、再購入時は払い戻し対象外。

  • Android App ウィジェットの更新頻度について要点だけ

    • updatePeriodMillsの最低間隔は30分
    • updatePeriodMillsによる更新はデバイスの復帰状態を解除する。要注意。
    • もっと短い間隔で更新したい場合はAlarmManagerを使う。こっちはスリープも有効。

    Android ウィジェット開発の要点だけに書いたとおり、Android ウィジェットの更新はAppWidgetProviderInfoのupdatePeriodMills間隔で行われることになっている。ただし、この更新は端末がスリープも解除して行ってしまうため、あまり頻繁に行う事は推奨されていないし、実際30分より短い間隔でonUpdateは呼ばれないらしい（設定値が無視される）。

    これはデバイスのバッテリー消費を抑えるためでごもっとも。望ましくはユーザに更新間隔を設定させるUIも必要かもしれない。

    仮に30分より短い間隔で更新を行いたい場合にはAlarmManagerからIntentをコールするような方法を使い、こちらはスリープ中にデバイスをウェークアップさせてしまうことはない（でも操作中はバックグラウンドで動作してしまうから、やっぱり過度な更新は控えるべきなんだろう）。

    AlarmManagerを使った更新のやりかたは別途まとめるつもり。

  • Androidロードマップの要点だけ

    POST時点でのロードマップを整理してみるテスト。必ずしも正式発表のものだけではないことに注意：

    ・リリース済み
    2010年1月　2.1　スマートフォン用　API Level 7
    2010年5月　2.2　Froyo　スマートフォン用　API Level 8　高速化（JIT）/Flash 10.1/Web版Android Market（OTAインストール）/etc
    2010年11月　2.3　Gingerbread　スマートフォン用　API Level 9　NFC/センサ（ジャイロ、コンパスetc）/フロントカメラ
    2011年2月　2.3.3　API Level 10　マイナーリリース。
    2011年2月　3.0　Honeycomb　API Level 11　タブレット用　ホログラフィックUI/新しいアニメーションフレームワーク/Hardware-acceralated Graphics/マルチコアCPU

    ・未リリース
    2011年後半？　4.0？　Ice Cream　スマートフォン用とタブレット用が統合される見込み

    http://developer.android.com/intl/ja/sdk/android-2.1.html
    http://developer.android.com/intl/ja/sdk/android-2.2.html
    http://developer.android.com/intl/ja/sdk/android-2.3-highlights.html
    http://developer.android.com/intl/ja/sdk/android-3.0-highlights.html#DeveloperApis

  • Android ウィジェット開発の要点だけ

    （参照：http://developer.android.com/guide/topics/appwidgets/index.html）

    概要
    App Widgetとは、他のView（典型的にはHome画面）に埋め込まれる小さいアプリケーション。

    構成要素
    （１）AppWidgetProviderInfo：XMLで定義。レイアウトや更新頻度などを定義する
    （２）AppWidgetProvider：updated（onUpdate）/enabled（onEnabled）/disabled（onDisabled）/deleted（onDeleted）なとき、このクラスを介して処理を行う。このほかonReceiveメソッドも利用できるが通常不要。onUpdateはupdatePeriodMillis間隔で呼ばれる。
    （３）View layout：Widgetのレイアウトを定義する。使えるレイアウトやウィジェットに制限がある（RemoteViews）

    手順
    AndroidManifest.xmlにAppWidgetProviderのreceiverを定義する。このときintent-filterはandroid.appwidget.action.APPWIDGET_UPDATE。meta-data要素としてAppWidgetProviderInfoリソースのxmlを指定する。AppWidgetProviderInfoで指定できるのは幅（android:minWidth）高さ（android:minHeight）更新頻度（android:updatePeriodMillis）レイアウト（android:initialLayout）および設定用のActivity（android:configure）。

    App Widget Configuration Activity
    App Widget Configuration Activityは通常のActivityとして定義するが、intent-filterとしてandroid.appwidget.action.APPWIDGET_CONFIGUREを設定する。
    そのうえでこのActivityはAppWidgetProviderInfoリソースで宣言される。WidgetがConfigurationActivityを使うとき、このアクティビティはWidgetの状態／設定を更新する責任がある。これはAppWidgetManagerのupdateAppWidgetメソッドを介して行う。

  • Android Content Providerの要点だけ

    http://developer.android.com/intl/ja/guide/topics/providers/content-providers.html
    1.アプリ間でデータを受け渡す仕組み。これ以外には無い。
    2.android.providerパッケージで標準のContentProviderを見ることができる
    3.permissionを宣言しないといけないものもある
    4.独自のものを作ることも可能。その場合、ContentProviderをサブクラス化する。
    5.データモデルは１行１レコードのシンプルなデータベース
    6.データセットにはURIが対応する。CONTENT_URI定数をチェックすれば分る。
    7.典型的な形式はcontent://com.example.transportaionprovider/trains/122。
    　- スキーム部分（content:は固定）
    　- ドメイン部分はauthorityを示す。カスタムの場合、Manifestのandroid:authoritiesアトリビュートで宣言されるもの
    　- パスの部分はデータ種別。0～複数セグメントがあり得る。
    　- 末尾はレコードの_ID値

    以下のブログとかを見ると、Content URIはOSバージョンとかメーカーとかで違っているケースがありそうなので要注意。
    Android 2.2 のカレンダーContentProvier に対応http://d.hatena.ne.jp/rmiya/20100725/1280028729