May 2011

Android Widgetのライフサイクルについて要点だけ

Android App Widgetのライフサイクルイベントは4つ。公式ドキュメント読んだだけではいまいち分かりづらかったので調べてみたメモ。 (1)onEnabled(Context context) 一つ目のウィジェットがホームに追加されるとき。 (2)onUpdate(Context context, AppWidgetmanager appWidgetManager, int appWidgetIds) ウィジェットがホームに追加されるとき。一つ目のときはonEnabledの直後に呼ばれる。2つ目以降(=同じウィジェットが既にホームに置かれている場合)はこのonUpdateだけがコールされる。 appWidgetIdsには、アップデート対象のウィジェットのIDが入ってる。なので、widgetの追加時には基本的に1つのIDの配列で、定期更新時には2つ以上のIDが入ってる可能性があるっていうことみたい。 (3)onDeleted(Context context, int appWidgetIds) ウィジェットがホームから削除されるとき。他にウィジェットが残っているとき(=同じウィジェットがまだホームに置かれている場合)はこのonDeletedだけが呼ばれる。 (4)onDisabled(Context context) ホームから最後のウィジェットが削除されるとき、onDeletedの直後にコールされる。 もういっこonReceivedは上記3つが結局コールされるので、通常はあんまり気にしなくて大丈夫みたい。以下4つ以外のBroadcastをなんとかしたい時にきにすれば良い。 ACTION_APPWIDGET_DELETED→onDeleted ACTION_APPWIDGET_DISABLED→onDisabled ACTION_APPWIDGET_ENABLED→onEnabled ACTION_APPWIDGET_UPDATE→onUpdate

Xcode 4のシングルイウンドウUIに垣間見るOSX Lionの本気度

まもなくAppleの開発者向けイベント、WWDC 2011が6月6日(日本時間7日深夜)から10日の予定で開催される。注目はもちろんiPhone 5、iOS 5が発表されるのかというのが一つとしてはあるけれど、もう一つの注目ポイントとしてMac OSXのメジャーバージョンアップ、Mac OSX Lion (10.7) の発表がある。 Mac OSX Lionは2010年の10月に、その概要が発表された。特徴は、iPadに見られるようなフルスクリーンUIをOSXの世界にも導入した「Launchpad」や「フルスクリーンアプリケーション」。これは単純にiPhone、iPadの人気にOSXが便乗しようとしているだけにも見えるけれど、Appleはこの大胆な変更に本気で取り組んでいて、これでiOSのエコシステムをOSXの世界にも広げようとしているように見える。

Titanium Mobileモジュール開発ドキュメント間違いの要点だけ

JavaScriptを使ってワンソースでAndroidとiOSのクロスプラットフォームができるとして話題なTitanium Mobileのモジュールの作り方を調べた。だけどどうも公式ドキュメントが違ってる(古い?)らしくてむしゃくしゃしたので、ついカッとなった部分のメモ。確かめたのはTitanium Mobile 1.6.2とXcode 4とiOS SDK 4.3です。基本的には以下のドキュメントに沿います。 参照:Module Devloper Guide for iOS(Last edited on May 12, 2011のもの) 要点だけ書くとドキュメントで違っている/足りていない記述が2カ所あることに注意: できたモジュール(zip)のコピー先はLibraryじゃなくてアプリのルートディレクトリ Titanium Mobile 1.6.2(Titanium Developer 1.2.2?)とiOS 4.3の組み合わせではLog/Info系の出力がTitanium Developerのコンソールに出ません。Xcodeで直接実行するか、iOS 4.2以前を使えば出る。 markdownモジュールはmarkdown2モジュールに変更されているのでbuild.pyの修正が必要。公式どおりにやるとモジュールのビルド過程でimport errorが出る。 もう少し詳しい手順は続きに:

UIWebViewのバウンスアニメを無効にする要点だけ

アプリ内でUIWebViewを使うときに困るのが、タッチ操作でスクロールできてしまうこと。 ネイティブUIにUIWebViewが入りこんでいることが分かって、UIの統一性が失われてしまう。 WebViewがドラッグ動作で範囲外までスクロールできる「バウンス動作」が無効にできれば良さそうだけど、、ということで調べたら、出てきたのでメモ。 http://stackoverflow.com/questions/500761/stop-uiwebview-from-bouncing-vertically for (id subview in webView.subviews) if ( isSubclassOfClass: ]) ((UIScrollView *)subview).bounces = NO; 要はUIWebViewsのsubViewsで取りだした子要素の一覧からUIScrollViewのインスタンスを取り出し、 それのbouncesプロパティを無効にする。これがうまくスクロールをdisableにできれば、気兼ねなくネイティブUIとのハイブリッドが採用できそう。 まだ実際には試してないけど後で試してみる予定。

Android Manifestのuses-sdkの要点だけ

AndroidManifest.xmlの<uses-sdk>項目について調べた。 Androidにおいて、APIレベルでの複数デバイスへの互換性を確保するにはAndroidManifest.xmlの<uses-sdk>を使う。 この項目はデフォルトでは存在しない。追記は<manifest>の子要素。 android:minSdkVersion、android:maxSdkVersion、android:targetSdkVersionの3属性が設定できる。 値は整数で、Android SDKごとに設定されるAPI Levelの値を指定する。(参照:Android API Levels) 特に重要なのはandroid:minSdkVersion。この設定より古いAPI Levelの端末にはインストールされない。これはデフォルトでは1なので、Android Platform 1.0までアプリがサポートしていることになってしまう。ちなみにdocomoが初めて発売したAndroid端末はHT-03Aで、これはAndroid 1.5=API Level 3。 android:targetSdkVersionは、システムにこのバージョンでテストしていることを示すもの。OSが様々な互換性のための設定を行うときに利用されるみたい。 android:maxSdkVersionというのは設定しないほうが良い。アプリケーションが特定のバージョンより新しいものにインストールされなくできる。 参考:http://developer.android.com/guide/topics/manifest/uses-sdk-element.html たとえばXperia arcで開発していると、ListViewの中身がスクロール時に拡大されてしまう問題というのがあるのだけど、この<uses-sdk>項目の設定で解決するようだ。以下のMLだとminSdkVersionを指定してやると解決すると書いてあるけど、上のドキュメントを読んでandroid:targetSdkVersionだけ設定してあげても解決できたみたい。 参照:http://groups.google.com/group/android-group-japan/browse_thread/thread/78e5b1b66237ee9f

結局スマートフォンとケータイの違いってなんなんだ

昨日(5/17)のdocomoに続いて今日、KDDIも2011年夏モデルの発表を行って、Androidを初めとするスマートフォンへの転換を打ち出した。SoftBankは震災の影響で大規模な発表を行わないものの、今後2〜3年で(ほぼ?)全ての機種をスマートフォンへ以降する意向を表明していて、いよいよスマートフォンへの移行が本格化してきた格好だ。 各社とも様子見な感じが強かったこれまでと違って今回の各社の発表で印象的だったのは、既存のケータイ(ガラケーってやつ)のサービスをスマートフォンにも持ち込もうというもので、これはとくにドコモが強く方針を打ち出している。SPモードはもちろん、iチャネル、メロディコールなど、既存のサービスを順次Android端末でも利用可能にする方針なんだけど、果たしてスマートフォンとケータイの文化というのはそんなに簡単に相容れるものだろうかと考えてしまう。もちろん、技術的には十分に可能なものではあるのだろうし、だからこそそうしているのだろうけど。

Android Platform ロードマップの要点だけ:Google I/O 2011 update

Google I/O 2011 で、Honeycomb新バージョンの3.1、Open Accessory APIがバックポートされたGingerbread 2.3.4、および時期バージョンIcecream Sandwichのロードマップが発表されました。3.1と2.3.4は発表と同時に公開みたいですね。 ・リリース済み 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年5月 3.1 Honeycomb API Level: 12 タブレット用 http://developer.android.com/sdk/android-3.1.html…

Google I/O 2011: Android Honeycomb 3.1の要点だけ

Google I/O 2011のKeynoteで、Androidの新プラットフォームのAndroid 3.1 Platformが発表された。これはまだタブレット専用のもので、タブレットとスマートフォンOSの統合は次期Icecream Sandwichリリースを待つ事になる模様。 一番注目すべきは外部デバイス向けのAPIが標準化されたことかな。ともあれこれとKeynoteで別途発表されたAndroid@Home構想(あとGoogle TVも?)を合わせると大まかなAndroid Platformの方向性が見えるということかも知れない。 情報元:Android 3.1 Platform, New SDK tools, Android 3.1 Platform Highlights ユーザ向け: UIの改善:最近使ったアプリ、リサイズ可能ウィジェットなど 入力システムの拡張:マウス、キーボード、ジョイスティック等からの入力サポート Wi-Fi接続の改善 アプリのアップデート:ブラウザ、ギャラリー、カレンダー、連絡先、メール エンタープライズ向け:Wi-Fi接続にHTTP Proxyの設定が可能に。“encrypted storage card”サポート 開発者向け: Open…