2012年2月6日月曜日

Are you looking for a way to learn how your users use you app, retention rate, error logging, etc?

This website introduce 7 different solutions. Personally, I only have experience with Flurry and Google Analytics. I'm very pleased with Flurry and even though some of the other services also look good, I feel no need to try them. (This is not a review, only a recommendation...)

http://support.flurry.com/images/logo.gif
Flurry Analytics
Flurry can be used in iOS, Android, Blackberry, Windows Phone, JavaME and HTML5.

The API is super easy to install and use and compared to Google Analytics which is originally made for webpages and not really adapted to mobile apps, Flurry is designed for mobile apps. For example, if you use a UITabBarController or UINavigationController, you can with one line of code in your app delegate track all "page" views controlled by that controller.

The free analytics package is all you need to get all plenty of feedback on how your app is doing out there.

Check the webpage by clicking the logo above for more information.

App Analytics

Are you looking for a way to learn how your users use you app, retention rate, error logging, etc?

This website introduce 7 different solutions. Personally, I only have experience with Flurry and Google Analytics. I'm very pleased with Flurry and even though some of the other services also look good, I feel no need to try them. (This is not a review, only a recommendation...)

http://support.flurry.com/images/logo.gif
Flurry Analytics
Flurry can be used in iOS, Android, Blackberry, Windows Phone, JavaME and HTML5.

The API is super easy to install and use and compared to Google Analytics which is originally made for webpages and not really adapted to mobile apps, Flurry is designed for mobile apps. For example, if you use a UITabBarController or UINavigationController, you can with one line of code in your app delegate track all "page" views controlled by that controller.

The free analytics package is all you need to get all plenty of feedback on how your app is doing out there.

Check the webpage by clicking the logo above for more information.

2012年2月1日水曜日

If you have some experience with objective oriented languages and want to learn Objective-C, or if you already started learning Objective-C but want to learn more from a great instructor, I have a tip for you.

Stanford University publishes their iOS App Development lectures on iTunes U, for anyone to download. Both HD videos and lecture notes are available.

There is material available from older quarters if you want to go for Xcode 3 and iOS 4. New material from 2011 is also available, which includes iOS 5, Xcode 4, Storyboard, iCloud and other new features of iOS 5.

The instructor is Paul Hegarty. He explains very well and makes the videos enjoyable to watch. You will learn not only the technical part of iOS and Objective-C but also how to create user friendly apps, what to avoid and best practices. One of the best instructors you can get.

I've watched all videos from both quarters below and even if you've seen Fall 2010 I highly recommend Fall 2011 because there is plenty of new information about the new features of iOS 5.

For iOS 4, please look at: Fall 2010

Developing Apps for iOS (HD)



For iOS 5, please look at: Fall 2011

iPad and iPhone Application Development (HD)


If you're looking for a good book, I can recommend this one. It explains in detail how Objective-C works and will give you a good insight into the language. -Link to Amazon-


Objective-C and iOS - Online learning resources

If you have some experience with objective oriented languages and want to learn Objective-C, or if you already started learning Objective-C but want to learn more from a great instructor, I have a tip for you.

Stanford University publishes their iOS App Development lectures on iTunes U, for anyone to download. Both HD videos and lecture notes are available.

There is material available from older quarters if you want to go for Xcode 3 and iOS 4. New material from 2011 is also available, which includes iOS 5, Xcode 4, Storyboard, iCloud and other new features of iOS 5.

The instructor is Paul Hegarty. He explains very well and makes the videos enjoyable to watch. You will learn not only the technical part of iOS and Objective-C but also how to create user friendly apps, what to avoid and best practices. One of the best instructors you can get.

I've watched all videos from both quarters below and even if you've seen Fall 2010 I highly recommend Fall 2011 because there is plenty of new information about the new features of iOS 5.

For iOS 4, please look at: Fall 2010

Developing Apps for iOS (HD)



For iOS 5, please look at: Fall 2011

iPad and iPhone Application Development (HD)


If you're looking for a good book, I can recommend this one. It explains in detail how Objective-C works and will give you a good insight into the language. -Link to Amazon-


2012年1月31日火曜日

Nexus SをAndroid 4.0.3にUpdateしました。
波形をとりながら動作確認中を行ったところ、面白い発見をしたので記事にしました。


キーガードロック画面のNFC動作
まずはAndroid2.3.6 GingerBread版Nexus Sの波形です。


電源キーによりスクリーンOFF → ONを行いキーガードロック画面を表示しました。
スクリーンON中はNFC電源ONになり、その波形が現れています。
約5秒後、再びスクリーンOFFになりました。


次はAndroid4.0.3 Ice Cream Sandwich版Nexus Sの波形です。


同じ操作でキーガードロック画面を表示しました。
しかし、スクリーンONになってもNFC電源ONの波形が現れません!

どうやら、ICSの変更でキーガードロック中はNFC電源が入らないように修正されているようです。


プログラムを確認してみましょう。
まずは、Android2.3.6 GingerBreadのプログラムです。
スクリーンON/OFFの動作処理を行っているのは以下のファイルです。
\packages\apps\Nfc\src\com\android\nfc
- NfcService.java

private class EnableDisableDiscoveryTask extends AsyncTask {
@Override
protected Void doInBackground(Boolean... enable) {
if (enable != null && enable.length > 0 && enable[0]) {
synchronized (NfcService.this) {
mScreenOn = true;
applyRouting();
}
} else {
:
}
return null;
}
}

private final BroadcastReceiver mReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
:
} else if (intent.getAction().equals(Intent.ACTION_SCREEN_ON)) {
:
new EnableDisableDiscoveryTask().execute(new Boolean(true));
} else if (intent.getAction().equals(Intent.ACTION_SCREEN_OFF)) {
:
}
}


以下の処理により、電源ONになりNFCタグ受信待ち状態となります。
  1. スクリーンONのIntentであるIntent.ACTION_SCREEN_ONを受信する
  2. EnableDisableDiscoveryTask().execute()をコール
  3. applyRouting()をコール
  4. mManager.enableDiscovery(DISCOVERY_MODE_READER)をコール



つぎは、Android4.0.3 Ice Cream Sandwichのプログラム確認。
\packages\apps\Nfc\src\com\android\nfc
- NfcService.java

/**
* Read mScreenState and apply NFC-C polling and NFC-EE routing
*/
void applyRouting(boolean force) {
synchronized (this) {
:
// configure NFC-C polling
if (mScreenState >= POLLING_MODE) {
if (force || !mNfcPollingEnabled) {
Log.d(TAG, "NFC-C ON");
mNfcPollingEnabled = true;
mDeviceHost.enableDiscovery();
}
} else {
if (force || mNfcPollingEnabled) {
Log.d(TAG, "NFC-C OFF");
mNfcPollingEnabled = false;
mDeviceHost.disableDiscovery();
}
}
}
}



class ApplyRoutingTask extends AsyncTask {
@Override
protected Void doInBackground(Integer... params) {
synchronized (NfcService.this) {
if (params == null || params.length != 1) {
// force apply current routing
applyRouting(true);
return null;
}
mScreenState = params[0].intValue();

boolean needWakelock = mScreenState == SCREEN_STATE_OFF;
if (needWakelock) {
mWakeLock.acquire();
}
applyRouting(false);
if (needWakelock) {
mWakeLock.release();
}
return null;
}
}
}

private final BroadcastReceiver mReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
:
} else if (action.equals(Intent.ACTION_SCREEN_ON)
|| action.equals(Intent.ACTION_SCREEN_OFF)
|| action.equals(Intent.ACTION_USER_PRESENT)) {
// Perform applyRouting() in AsyncTask to serialize blocking calls
int screenState = SCREEN_STATE_OFF;
if (action.equals(Intent.ACTION_SCREEN_OFF)) {
screenState = SCREEN_STATE_OFF;
} else if (action.equals(Intent.ACTION_SCREEN_ON)) {
screenState = mKeyguard.isKeyguardLocked() ?
SCREEN_STATE_ON_LOCKED : SCREEN_STATE_ON_UNLOCKED;
} else if (action.equals(Intent.ACTION_USER_PRESENT)) {
screenState = SCREEN_STATE_ON_UNLOCKED;
}
new ApplyRoutingTask().execute(Integer.valueOf(screenState));
} else if (action.equals(ACTION_MASTER_CLEAR_NOTIFICATION)) {
:
}
}


以下のように処理が変更され、スクリーンONでは電源ONとなりません。
  1. スクリーンONのIntentであるIntent.ACTION_SCREEN_ONを受信する
  2. mKeyguard.isKeyguardLocked()でキーガード状態かどうか確認する
  3. キーガード状態の場合、SCREEN_STATE_ON_LOCKEDを引数としてApplyRoutingTask().execute()をコール
  4. applyRouting(false)をコール
  5. mScreenStateがSCREEN_STATE_ON_LOCKEDなので、mDeviceHost.enableDiscovery()はコールしない

電源ONとなるタイミングはIntent.ACTION_USER_PRESENTを受信した時、
つまり、キーガードが解除された時に電源ONとなります。

キーガード中のNFC動作 GingerBread と Ice Cream Sandwichの違い

Nexus SをAndroid 4.0.3にUpdateしました。
波形をとりながら動作確認中を行ったところ、面白い発見をしたので記事にしました。


キーガードロック画面のNFC動作
まずはAndroid2.3.6 GingerBread版Nexus Sの波形です。


電源キーによりスクリーンOFF → ONを行いキーガードロック画面を表示しました。
スクリーンON中はNFC電源ONになり、その波形が現れています。
約5秒後、再びスクリーンOFFになりました。


次はAndroid4.0.3 Ice Cream Sandwich版Nexus Sの波形です。


同じ操作でキーガードロック画面を表示しました。
しかし、スクリーンONになってもNFC電源ONの波形が現れません!

どうやら、ICSの変更でキーガードロック中はNFC電源が入らないように修正されているようです。


プログラムを確認してみましょう。
まずは、Android2.3.6 GingerBreadのプログラムです。
スクリーンON/OFFの動作処理を行っているのは以下のファイルです。
\packages\apps\Nfc\src\com\android\nfc
- NfcService.java

private class EnableDisableDiscoveryTask extends AsyncTask {
@Override
protected Void doInBackground(Boolean... enable) {
if (enable != null && enable.length > 0 && enable[0]) {
synchronized (NfcService.this) {
mScreenOn = true;
applyRouting();
}
} else {
:
}
return null;
}
}

private final BroadcastReceiver mReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
:
} else if (intent.getAction().equals(Intent.ACTION_SCREEN_ON)) {
:
new EnableDisableDiscoveryTask().execute(new Boolean(true));
} else if (intent.getAction().equals(Intent.ACTION_SCREEN_OFF)) {
:
}
}


以下の処理により、電源ONになりNFCタグ受信待ち状態となります。
  1. スクリーンONのIntentであるIntent.ACTION_SCREEN_ONを受信する
  2. EnableDisableDiscoveryTask().execute()をコール
  3. applyRouting()をコール
  4. mManager.enableDiscovery(DISCOVERY_MODE_READER)をコール



つぎは、Android4.0.3 Ice Cream Sandwichのプログラム確認。
\packages\apps\Nfc\src\com\android\nfc
- NfcService.java

/**
* Read mScreenState and apply NFC-C polling and NFC-EE routing
*/
void applyRouting(boolean force) {
synchronized (this) {
:
// configure NFC-C polling
if (mScreenState >= POLLING_MODE) {
if (force || !mNfcPollingEnabled) {
Log.d(TAG, "NFC-C ON");
mNfcPollingEnabled = true;
mDeviceHost.enableDiscovery();
}
} else {
if (force || mNfcPollingEnabled) {
Log.d(TAG, "NFC-C OFF");
mNfcPollingEnabled = false;
mDeviceHost.disableDiscovery();
}
}
}
}



class ApplyRoutingTask extends AsyncTask {
@Override
protected Void doInBackground(Integer... params) {
synchronized (NfcService.this) {
if (params == null || params.length != 1) {
// force apply current routing
applyRouting(true);
return null;
}
mScreenState = params[0].intValue();

boolean needWakelock = mScreenState == SCREEN_STATE_OFF;
if (needWakelock) {
mWakeLock.acquire();
}
applyRouting(false);
if (needWakelock) {
mWakeLock.release();
}
return null;
}
}
}

private final BroadcastReceiver mReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
:
} else if (action.equals(Intent.ACTION_SCREEN_ON)
|| action.equals(Intent.ACTION_SCREEN_OFF)
|| action.equals(Intent.ACTION_USER_PRESENT)) {
// Perform applyRouting() in AsyncTask to serialize blocking calls
int screenState = SCREEN_STATE_OFF;
if (action.equals(Intent.ACTION_SCREEN_OFF)) {
screenState = SCREEN_STATE_OFF;
} else if (action.equals(Intent.ACTION_SCREEN_ON)) {
screenState = mKeyguard.isKeyguardLocked() ?
SCREEN_STATE_ON_LOCKED : SCREEN_STATE_ON_UNLOCKED;
} else if (action.equals(Intent.ACTION_USER_PRESENT)) {
screenState = SCREEN_STATE_ON_UNLOCKED;
}
new ApplyRoutingTask().execute(Integer.valueOf(screenState));
} else if (action.equals(ACTION_MASTER_CLEAR_NOTIFICATION)) {
:
}
}


以下のように処理が変更され、スクリーンONでは電源ONとなりません。
  1. スクリーンONのIntentであるIntent.ACTION_SCREEN_ONを受信する
  2. mKeyguard.isKeyguardLocked()でキーガード状態かどうか確認する
  3. キーガード状態の場合、SCREEN_STATE_ON_LOCKEDを引数としてApplyRoutingTask().execute()をコール
  4. applyRouting(false)をコール
  5. mScreenStateがSCREEN_STATE_ON_LOCKEDなので、mDeviceHost.enableDiscovery()はコールしない

電源ONとなるタイミングはIntent.ACTION_USER_PRESENTを受信した時、
つまり、キーガードが解除された時に電源ONとなります。
Kaspersky Endpoint Security, which claims to be compatible with Lion, apparently is not.

Before upgrading to Lion I had no problems with Xcode or other application freezing and becoming "not responding". After upgrading, Xcode, which I use all day in my work, often freezes, sometimes other applications too. Usually it returns to normal state if I wait 1-5 minutes, but sometimes not and unsaved data is lost when I have to force quit Xcode (before I discovered how to quit Kaspersky's process). The really bad thing is that it's when saving that Kaspersky locks up the saving application so the chances of loosing valuable work is high.

If you are required to run Kaspersky on your Mac, I recommend that you do not upgrade to Lion until Kaspersky has fixed to support Lion's Autosave and Versions.

If Xcode or any other application locks up, open "Activity Monitor" and quit the process "kav". This will release the lock on the frozen application but (it looks like) Kaspersky will automatically restart so you have to repeat this every time an application freezes when saving data.

I'm not alone:
Cocoabuilder.com: Xcode4 and Lion causes freezes when saving
Stackoverflow.com: Xcode is very slow to save a file frequently beach balls

Waiting for a fix...

Lion + Kaspersky + Xcode = Trouble...

Kaspersky Endpoint Security, which claims to be compatible with Lion, apparently is not.

Before upgrading to Lion I had no problems with Xcode or other application freezing and becoming "not responding". After upgrading, Xcode, which I use all day in my work, often freezes, sometimes other applications too. Usually it returns to normal state if I wait 1-5 minutes, but sometimes not and unsaved data is lost when I have to force quit Xcode (before I discovered how to quit Kaspersky's process). The really bad thing is that it's when saving that Kaspersky locks up the saving application so the chances of loosing valuable work is high.

If you are required to run Kaspersky on your Mac, I recommend that you do not upgrade to Lion until Kaspersky has fixed to support Lion's Autosave and Versions.

If Xcode or any other application locks up, open "Activity Monitor" and quit the process "kav". This will release the lock on the frozen application but (it looks like) Kaspersky will automatically restart so you have to repeat this every time an application freezes when saving data.

I'm not alone:
Cocoabuilder.com: Xcode4 and Lion causes freezes when saving
Stackoverflow.com: Xcode is very slow to save a file frequently beach balls

Waiting for a fix...

2012年1月25日水曜日

In one of my apps I have data as csv files in the bundle and at when the app is run for the first time I parse these files and create a database using Core Data. During development I often added more data to the csv files, adjusted the Core Data classes and so on, so I needed a smooth way of telling whether the app was run for the first time or not since the last build so I can reconstruct the database.

I first tried another solution that didn't require the target name "MYTARGET" in the script which means you don't have to customize the script for every project but I couldn't get that to work in Xcode 4.2 but here is a script that works great for me. I will link to the source if I remember it later.

In the project navigator, select your project and then your target to the right.
In the "Info"-tab, create a new "Custom iOS Target Property" called "BuildNumber" and let it be a string.
Select the tab "Build Phases" and "Add Build Phase" down to the right.
Select "Add Run Script" and set the shell to "/bin/bash"
Paste in this script: (replace MYTARGET with the name of your target (usually same as name of project)

#!/bin/bash
buildNumber=$(/usr/libexec/PlistBuddy -c "Print BuildNumber" MYTARGET/MYTARGET-Info.plist)
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :BuildNumber $buildNumber" MYTARGET/MYTARGET-Info.plist

bundleShortVersion=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" MYTARGET/MYTARGET-Info.plist)
bundleVersion=$bundleShortVersion"."$buildNumber
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $bundleVersion" MYTARGET/MYTARGET-Info.plist

Now, each time you build your app the variable "BuildNumber" will be increased by 1 and your bundle version will be set to Version.BuildNumber. That is, if your app version is 1.0 and your on build number 8, the bundle version will be 1.0.8.

If you, in your app delegate or elsewhere, want to check if the "BuildNumber" has changed since the last run by comparing it with the last value, stored in NSUserDefaults, do something like:

int thisVersion = [[[[NSBundle mainBundle] infoDictionary] objectForKey:@"BuildNumber"] intValue];
int lastVersion = [[NSUserDefaults standardUserDefaults] integerForKey:@"lastVersion"];
[[NSUserDefaults standardUserDefaults] setInteger:thisVersion forKey:@"lastVersion"];
BOOL appIsNewVersion = lastVersion != thisVersion;

And there, you have a smooth, automated way of telling if you're on a new build and do the proper initializing, etc.

Auto incrementing build number in Xcode

In one of my apps I have data as csv files in the bundle and at when the app is run for the first time I parse these files and create a database using Core Data. During development I often added more data to the csv files, adjusted the Core Data classes and so on, so I needed a smooth way of telling whether the app was run for the first time or not since the last build so I can reconstruct the database.

I first tried another solution that didn't require the target name "MYTARGET" in the script which means you don't have to customize the script for every project but I couldn't get that to work in Xcode 4.2 but here is a script that works great for me. I will link to the source if I remember it later.

In the project navigator, select your project and then your target to the right.
In the "Info"-tab, create a new "Custom iOS Target Property" called "BuildNumber" and let it be a string.
Select the tab "Build Phases" and "Add Build Phase" down to the right.
Select "Add Run Script" and set the shell to "/bin/bash"
Paste in this script: (replace MYTARGET with the name of your target (usually same as name of project)

#!/bin/bash
buildNumber=$(/usr/libexec/PlistBuddy -c "Print BuildNumber" MYTARGET/MYTARGET-Info.plist)
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :BuildNumber $buildNumber" MYTARGET/MYTARGET-Info.plist

bundleShortVersion=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" MYTARGET/MYTARGET-Info.plist)
bundleVersion=$bundleShortVersion"."$buildNumber
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $bundleVersion" MYTARGET/MYTARGET-Info.plist

Now, each time you build your app the variable "BuildNumber" will be increased by 1 and your bundle version will be set to Version.BuildNumber. That is, if your app version is 1.0 and your on build number 8, the bundle version will be 1.0.8.

If you, in your app delegate or elsewhere, want to check if the "BuildNumber" has changed since the last run by comparing it with the last value, stored in NSUserDefaults, do something like:

int thisVersion = [[[[NSBundle mainBundle] infoDictionary] objectForKey:@"BuildNumber"] intValue];
int lastVersion = [[NSUserDefaults standardUserDefaults] integerForKey:@"lastVersion"];
[[NSUserDefaults standardUserDefaults] setInteger:thisVersion forKey:@"lastVersion"];
BOOL appIsNewVersion = lastVersion != thisVersion;

And there, you have a smooth, automated way of telling if you're on a new build and do the proper initializing, etc.

2012年1月23日月曜日

My first post. I guess it would be a good a idea to share what I do whenever I start a new project in Xcode.

It has kind of become a habit of mine to log to console at almost every method for easy bug tracking. However, using NSLog doesn't show you what method unless you do something like:

NSLog(@"MyViewController:viewDidLoad");

Which is rather cumbersome when you add logging to many methods. This is where my savior comes into the picture.

By adding the following to your "MyApp-Prefix.pch" file in the "Supporting Files"-group

// DLog is almost a drop-in replacement for NSLog
// DLog();
// DLog(@"here");
// DLog(@"value: %d", x);
// Unfortunately this doesn't work DLog(aStringVariable); you have to do this instead DLog(@"%@", aStringVariable);
#ifdef DEBUG
# define DLog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);
#else
# define DLog(...)
#endif

// ALog always displays output regardless of the DEBUG setting
#define ALog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);

you can use ALog (always log) and DLog (debug log) for a rich debug logging.
Simply putting DLog(); in your viewDidAppear method will output something like:

[MainViewController viewDidAppear:] [Line 169]

Even showing the line number where in your source code the line was executed. And don't worry about performance or similar, when compiling for release DLog(); is defined to nothing so there will be no logging going on.

The blog post where I found this information is >>here

First post, logging.

My first post. I guess it would be a good a idea to share what I do whenever I start a new project in Xcode.

It has kind of become a habit of mine to log to console at almost every method for easy bug tracking. However, using NSLog doesn't show you what method unless you do something like:

NSLog(@"MyViewController:viewDidLoad");

Which is rather cumbersome when you add logging to many methods. This is where my savior comes into the picture.

By adding the following to your "MyApp-Prefix.pch" file in the "Supporting Files"-group

// DLog is almost a drop-in replacement for NSLog
// DLog();
// DLog(@"here");
// DLog(@"value: %d", x);
// Unfortunately this doesn't work DLog(aStringVariable); you have to do this instead DLog(@"%@", aStringVariable);
#ifdef DEBUG
# define DLog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);
#else
# define DLog(...)
#endif

// ALog always displays output regardless of the DEBUG setting
#define ALog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);

you can use ALog (always log) and DLog (debug log) for a rich debug logging.
Simply putting DLog(); in your viewDidAppear method will output something like:

[MainViewController viewDidAppear:] [Line 169]

Even showing the line number where in your source code the line was executed. And don't worry about performance or similar, when compiling for release DLog(); is defined to nothing so there will be no logging going on.

The blog post where I found this information is >>here

2011年12月5日月曜日

省電力評価
★★☆☆☆



アプリケーション概要
Android端末に標準に搭載されているブラウザアプリです。



Android Market : 登録なし
Version : 2.3.6



計測条件
・SIMカード:なし (3G通信なし)
・壁紙設定:壁紙
・Wi-Fi設定:ON
・Bluetooth設定:OFF
・GPS設定:OFF
・NFC設定:OFF
・バックグラウンドシンク設定:OFF
・現在地情報:無線ネットワークを使用 ON、GPS機能を使用 OFF



プロセスとサービスの使用数
プロセス?
サービス?
※(別途、調査します)


アプリケーション起動中の使用機能
機能使用
ネットワーク通信○
GPS○
WIFI制御×
バッテリー情報取得×
Bluetooth×
カメラ起動×
NFC×
WakeLock使用○



アプリケーション起動時の電力測定
ブラウザ起動後、通信を行っていない状態の波形です。



ブラウザ起動後、スクリーンOFF状態の波形です。




ブラウザ起動後、無通信状態ではHome画面表示中とあまり変わりませんでした。


次はブリリアントサービスのHPを表示させたときの波形です。
(※WiFi通信)
通信を行い画面更新が完了するまでの約3秒間、消費電量が上昇していることがわかります。





Google検索の結果画面で上下に激しくスクロールを行いました。



 




次はGoogle画像検索の結果画面で上下に激しくスクロールを行いました。

 
 


Google検索結果画面は 約0.2~0.4A、
Google画像検索結果画面は 約0.3~0.45A、
と、画像表示あり/なしで消費電力に差異がありました。



考察
スクロールを行う際、画像の有無で省電力に差異があることがわかりました。
標準ブラウザの計測データを基に、他のブラウザアプリと消費電力の比較を行います。

標準ブラウザ

省電力評価
★★☆☆☆



アプリケーション概要
Android端末に標準に搭載されているブラウザアプリです。



Android Market : 登録なし
Version : 2.3.6



計測条件
・SIMカード:なし (3G通信なし)
・壁紙設定:壁紙
・Wi-Fi設定:ON
・Bluetooth設定:OFF
・GPS設定:OFF
・NFC設定:OFF
・バックグラウンドシンク設定:OFF
・現在地情報:無線ネットワークを使用 ON、GPS機能を使用 OFF



プロセスとサービスの使用数
プロセス?
サービス?
※(別途、調査します)


アプリケーション起動中の使用機能
機能使用
ネットワーク通信○
GPS○
WIFI制御×
バッテリー情報取得×
Bluetooth×
カメラ起動×
NFC×
WakeLock使用○



アプリケーション起動時の電力測定
ブラウザ起動後、通信を行っていない状態の波形です。



ブラウザ起動後、スクリーンOFF状態の波形です。




ブラウザ起動後、無通信状態ではHome画面表示中とあまり変わりませんでした。


次はブリリアントサービスのHPを表示させたときの波形です。
(※WiFi通信)
通信を行い画面更新が完了するまでの約3秒間、消費電量が上昇していることがわかります。





Google検索の結果画面で上下に激しくスクロールを行いました。



 




次はGoogle画像検索の結果画面で上下に激しくスクロールを行いました。

 
 


Google検索結果画面は 約0.2~0.4A、
Google画像検索結果画面は 約0.3~0.45A、
と、画像表示あり/なしで消費電力に差異がありました。



考察
スクロールを行う際、画像の有無で省電力に差異があることがわかりました。
標準ブラウザの計測データを基に、他のブラウザアプリと消費電力の比較を行います。

2011年11月28日月曜日

省電力評価
★☆☆☆☆



アプリケーション概要
スマートフォンといえば、Googleマップ。このアプリのお陰で迷子にならなくなりました。
家に居ても、3Dマップ表示で世界中旅するのも楽しいです。
ただ、外出中に使用することが多く、どうしても電池の消費が気になりますね。



Android Market : http://market.android.com/details?id=com.google.android.apps.maps
Version : 5.12.0



計測条件
・SIMカード:なし (3G通信なし)
・壁紙設定:壁紙
・Wi-Fi設定:ON
・Bluetooth設定:OFF
・GPS設定:OFF
・NFC設定:OFF
・バックグラウンドシンク設定:OFF
・現在地情報:無線ネットワークを使用 ON、GPS機能を使用 OFF



プロセスとサービスの使用数
プロセス1
サービス2



アプリケーション起動中の使用機能
機能使用
ネットワーク通信○
GPS○
WIFI制御○
バッテリー情報取得×
Bluetooth×
カメラ起動×
NFC○
WakeLock使用○



アプリケーション起動時の電力測定
Google マップ起動中の波形です。
WiFi設定ON中の待ち受け画面 よりも波形が乱れ、一定間隔で0.300Aを超えていることがわかります。





現在地表示中の波形です。
通常マップ表示中とあまり変わりませんでした。





現在地でかつ3D表示中の波形です。
常に0.300Aを超え、明らかに消費電力が上がっていることがわかります。
端末を持つ手が少しでも揺れると、画面も揺れてしまいます。
3D表示を行うために、センサー系がフル稼働していることも原因の一つだと考えられます。




スクリーンOFF時の電力測定
Googleマップ起動中にスクリーンOFFした波形です。
通常マップ表示、現在地表示、現在地3D表示ともに以下のような波形でした。




考察
オシロスコープの波形をみると、マップの現在地3D表示中の消費電力が明らかに高いことがわかりました。
XYZの3軸の値からマップ表示を行う際、計算量が増加するのに加え、頻繁に画面更新しているのが原因の1つだと考えられます。
ただ、スクリーンOFFになるとWiFi設定ON中の波形と変わらないことから、無駄な電力消費を行っていないのはさすがGoogle純正アプリだと思いました。

外出中の「3D表示」には気をつけよう。

モバイルGoogleマップ

省電力評価
★☆☆☆☆



アプリケーション概要
スマートフォンといえば、Googleマップ。このアプリのお陰で迷子にならなくなりました。
家に居ても、3Dマップ表示で世界中旅するのも楽しいです。
ただ、外出中に使用することが多く、どうしても電池の消費が気になりますね。



Android Market : http://market.android.com/details?id=com.google.android.apps.maps
Version : 5.12.0



計測条件
・SIMカード:なし (3G通信なし)
・壁紙設定:壁紙
・Wi-Fi設定:ON
・Bluetooth設定:OFF
・GPS設定:OFF
・NFC設定:OFF
・バックグラウンドシンク設定:OFF
・現在地情報:無線ネットワークを使用 ON、GPS機能を使用 OFF



プロセスとサービスの使用数
プロセス1
サービス2



アプリケーション起動中の使用機能
機能使用
ネットワーク通信○
GPS○
WIFI制御○
バッテリー情報取得×
Bluetooth×
カメラ起動×
NFC○
WakeLock使用○



アプリケーション起動時の電力測定
Google マップ起動中の波形です。
WiFi設定ON中の待ち受け画面 よりも波形が乱れ、一定間隔で0.300Aを超えていることがわかります。





現在地表示中の波形です。
通常マップ表示中とあまり変わりませんでした。





現在地でかつ3D表示中の波形です。
常に0.300Aを超え、明らかに消費電力が上がっていることがわかります。
端末を持つ手が少しでも揺れると、画面も揺れてしまいます。
3D表示を行うために、センサー系がフル稼働していることも原因の一つだと考えられます。




スクリーンOFF時の電力測定
Googleマップ起動中にスクリーンOFFした波形です。
通常マップ表示、現在地表示、現在地3D表示ともに以下のような波形でした。




考察
オシロスコープの波形をみると、マップの現在地3D表示中の消費電力が明らかに高いことがわかりました。
XYZの3軸の値からマップ表示を行う際、計算量が増加するのに加え、頻繁に画面更新しているのが原因の1つだと考えられます。
ただ、スクリーンOFFになるとWiFi設定ON中の波形と変わらないことから、無駄な電力消費を行っていないのはさすがGoogle純正アプリだと思いました。

外出中の「3D表示」には気をつけよう。

2011年11月12日土曜日




http://twitter.com/#!/nfc_quest


魔王、またblog執筆。




NFC QUEST 広報兼魔王の、魔王です。


そうです また私です。なんだか魔王業よりも広報の方が本業なんじゃないか?


とじっと掌を見つめるような気持ちにもなっていました が ところがどっこいですよ!


2011/11/11(金)-12(土)に福岡で開催されるAndroidとモノづくりの祭典『Android Make Days』に「NFC QUEST」を出展することになりました!


そうです 再び皆様と 滅ぼし滅ぼされることができるのです!


福岡の皆様 わたし心を込めて豪腕を振るい 皆様を滅ぼします。


皆様もわたしをたくさん滅ぼしてくださいね!魔王との約束です。








そしてそして ついでと言っては何ですが


なんとNFC QUESTのyoutube動画ができました!



D


誰ですか?こんな素敵な動画をつくったのは?…ふふふ なんてね そうです。わたしです。


思わず自作自演をしてしまいましたが、わたしの勇姿(時に滅ぼし時に滅ぼされ…)


がばっちり写っていますので、是非みなさん見てみてください。





以上 魔王でした。





(*NFC QUESTスタッフ注)


『Android Make Days』当日はカードとGoogleアカウントの連動登録と


魔王と戦えるバトルゲームのみの縮小DEMO出展となります。


会場内でのチェックポイントを探してのレベルアップシステムは今回は用意しておりませんので


あらかじめご了承下さい。


職業毎に用意したスタッフカードと組み合わせゲームクリアができるように調整しておりますので


組み合わせパターンでの変化をお楽しみ下さい。






魔王再臨『Android Make Days』にNFC QUESTを出展します




http://twitter.com/#!/nfc_quest


魔王、またblog執筆。




NFC QUEST 広報兼魔王の、魔王です。


そうです また私です。なんだか魔王業よりも広報の方が本業なんじゃないか?


とじっと掌を見つめるような気持ちにもなっていました が ところがどっこいですよ!


2011/11/11(金)-12(土)に福岡で開催されるAndroidとモノづくりの祭典『Android Make Days』に「NFC QUEST」を出展することになりました!


そうです 再び皆様と 滅ぼし滅ぼされることができるのです!


福岡の皆様 わたし心を込めて豪腕を振るい 皆様を滅ぼします。


皆様もわたしをたくさん滅ぼしてくださいね!魔王との約束です。








そしてそして ついでと言っては何ですが


なんとNFC QUESTのyoutube動画ができました!



D


誰ですか?こんな素敵な動画をつくったのは?…ふふふ なんてね そうです。わたしです。


思わず自作自演をしてしまいましたが、わたしの勇姿(時に滅ぼし時に滅ぼされ…)


がばっちり写っていますので、是非みなさん見てみてください。





以上 魔王でした。





(*NFC QUESTスタッフ注)


『Android Make Days』当日はカードとGoogleアカウントの連動登録と


魔王と戦えるバトルゲームのみの縮小DEMO出展となります。


会場内でのチェックポイントを探してのレベルアップシステムは今回は用意しておりませんので


あらかじめご了承下さい。


職業毎に用意したスタッフカードと組み合わせゲームクリアができるように調整しておりますので


組み合わせパターンでの変化をお楽しみ下さい。






2011年11月9日水曜日

NFC設定を切り替えて、Home画面とスクリーンOFF中の計測を行いました。

条件:
・壁紙設定:壁紙
・Wi-Fi設定:OFF
・Bluetooth設定:OFF
・GPS設定:OFF
・NFC設定:ON/OFF
・バックグラウンドシンク設定:OFF



1.Home画面

NFC設定OFFの波形です。
約0.10Aでした。





NFC設定ONの波形です。






一定間隔で約0.15Aを超えていることがわかりました。



2.スクリーンOFF中

Home画面で電源キー短押下しスクリーンOFFした状態で計測しました
NFC設定OFFの波形です。
約2秒間隔で0.05Aを超えていますが、ほぼ0Aまで落ちています。






NFC設定ONの波形です。







設定OFFの波形と変化が見られませんでした。
(※少しノイズが混じっているようにも見えますが誤差の範囲だと思います)




3.まとめ

NFC設定をONにしていると、スクリーンON中はNFCチップの電源が入りっぱなしのため、消費電力が上がっているようです。
ただ、スクリーンOFF中はNFC設定ON/OFFどちらも消費電力に違いが見えませんでした。
スクリーンOFF中は誤作動防止&省エネのため、NFCのチップの電源をOFFに切り替えていると考えられます。

NFC利用時のみ、設定をONにすれば電池持ちが良くなると思います。
NFC設定切り替えウェイジェットがあれば便利かも!!

NFC設定ON/OFFの違いを確認する

NFC設定を切り替えて、Home画面とスクリーンOFF中の計測を行いました。

条件:
・壁紙設定:壁紙
・Wi-Fi設定:OFF
・Bluetooth設定:OFF
・GPS設定:OFF
・NFC設定:ON/OFF
・バックグラウンドシンク設定:OFF



1.Home画面

NFC設定OFFの波形です。
約0.10Aでした。





NFC設定ONの波形です。






一定間隔で約0.15Aを超えていることがわかりました。



2.スクリーンOFF中

Home画面で電源キー短押下しスクリーンOFFした状態で計測しました
NFC設定OFFの波形です。
約2秒間隔で0.05Aを超えていますが、ほぼ0Aまで落ちています。






NFC設定ONの波形です。







設定OFFの波形と変化が見られませんでした。
(※少しノイズが混じっているようにも見えますが誤差の範囲だと思います)




3.まとめ

NFC設定をONにしていると、スクリーンON中はNFCチップの電源が入りっぱなしのため、消費電力が上がっているようです。
ただ、スクリーンOFF中はNFC設定ON/OFFどちらも消費電力に違いが見えませんでした。
スクリーンOFF中は誤作動防止&省エネのため、NFCのチップの電源をOFFに切り替えていると考えられます。

NFC利用時のみ、設定をONにすれば電池持ちが良くなると思います。
NFC設定切り替えウェイジェットがあれば便利かも!!

2011年11月3日木曜日




f:id:bs-android:20111102205033j:image




http://twitter.com/#!/nfc_quest


魔王、blogデビューです。


NFC QUEST 広報兼魔王の、魔王です。


役目を終えてきえる…などと言っておきながらまた現れてしまいました。


ごめんなさい。きえるきえる詐欺してしまいました。


まさかのblogに召喚されてしまい…いや、違いますね。


再びみなさんと会えた事を素直に喜びましょう!ここは!


ヤッホー!みなさんこんにちは。魔王です!はじめましての方ははじめまして。


私、ふだんは人々を滅ぼしたり逆に勇者に滅ぼされたりすることを生業にしています。


しかし今日は、私が降臨したGoogle Developer Day 2011(以下GDD)でのNFC QUESTの様子をリポートしたいと思います。




f:id:bs-android:20111102162407j:image:w360:left


当日は私の下僕が、朝8時から設営に入りました。


画面を見てお判りの通り、私はAndroid界を征服しております。


具体的にはシャープ様のNFC搭載タブレット「RW-T107」を使用させて頂きました。




f:id:bs-android:20111102162414p:image:w360:left


これらがGDDの会場に散りばめられたチェックポイントです。


これをタッチしていくと、みなさんのレベルが上がり、そして私は滅ぼされる。


と、こういう寸法なわけですね。


さて、みなさんはどれぐらいレベルをあげてくれるのでしょう?


果たしてわたしは滅ぼされるのか?


私、滅ぼされなかったらどうしよう。


空気読めずに勝ち続けちゃったらどうしよう…などと思っていました。


この時は、まだ。




f:id:bs-android:20111102162408j:image:w360:left


そして、設営完了!ついにみなさんとの対面です。


わたしはロゴの裏に待機していますよ。


チラリと見えますね。


しかし今だから言いますが、魔王ドキドキし過ぎてて足が震えていました。




f:id:bs-android:20111102162409j:image:w360:left


これがゲーム中の私です。どうですか?強そうでしょうか。


普段とは違い、かなり相当かんじの悪いセリフをみなさんに浴びせていましたよね。


「見積もりが甘い!」とか。


でも、みなさんはひどいセリフほど喜んでました。


なぜでしょう?人格者過ぎます。




f:id:bs-android:20111102162410j:image:w360:left


GDDの休み時間には、大勢の方が私に会いに来てくれました。


今だから言いますが、正直私やスタッフ達の予想を大幅にこえる盛況ぶりだったのです!


こんなに遊んでもらえるなんて、魔王感無量です。


みなさんのレベルも想定よりずっとずっと高く、私あっというまに滅ぼされてしまいました。


いささかカンタンにやられ過ぎの感も否めませんでしたが…


歯ごたえのない魔王で申し訳ありませんでした。精進します。




最終的には580人の方に登録いただけました。


3桁いけたらいいほう、などと言っていたのは誰ですか?…私ですね。


なめてました。


勇者なめてました。


見積もり甘いのはどっちだ!って話ですよね。


ともかく、皆さんたくさん私と戦ってくれて、ほんとうにほんとうにありがとうございました!




f:id:bs-android:20111102162412j:image:w360:left


いかがでしたでしょうか『NFC QUEST』楽しめていただけましたでしょうか?


平和に退屈した民たちの魔王・待望コールの高まりいかんによっては、再び召喚される日もあるやもしれません。


その時はまた私を滅ぼしてくださいね。


魔王も大魔王ぐらいにはなれるよう、がんばります。




http://twitter.com/#!/nfc_quest


以上、魔王が報告いたしました。


@nfc_quest






『NFC QUEST』 @ Google Developer Day 2011Japan リポート




f:id:bs-android:20111102205033j:image




http://twitter.com/#!/nfc_quest


魔王、blogデビューです。


NFC QUEST 広報兼魔王の、魔王です。


役目を終えてきえる…などと言っておきながらまた現れてしまいました。


ごめんなさい。きえるきえる詐欺してしまいました。


まさかのblogに召喚されてしまい…いや、違いますね。


再びみなさんと会えた事を素直に喜びましょう!ここは!


ヤッホー!みなさんこんにちは。魔王です!はじめましての方ははじめまして。


私、ふだんは人々を滅ぼしたり逆に勇者に滅ぼされたりすることを生業にしています。


しかし今日は、私が降臨したGoogle Developer Day 2011(以下GDD)でのNFC QUESTの様子をリポートしたいと思います。




f:id:bs-android:20111102162407j:image:w360:left


当日は私の下僕が、朝8時から設営に入りました。


画面を見てお判りの通り、私はAndroid界を征服しております。


具体的にはシャープ様のNFC搭載タブレット「RW-T107」を使用させて頂きました。




f:id:bs-android:20111102162414p:image:w360:left


これらがGDDの会場に散りばめられたチェックポイントです。


これをタッチしていくと、みなさんのレベルが上がり、そして私は滅ぼされる。


と、こういう寸法なわけですね。


さて、みなさんはどれぐらいレベルをあげてくれるのでしょう?


果たしてわたしは滅ぼされるのか?


私、滅ぼされなかったらどうしよう。


空気読めずに勝ち続けちゃったらどうしよう…などと思っていました。


この時は、まだ。




f:id:bs-android:20111102162408j:image:w360:left


そして、設営完了!ついにみなさんとの対面です。


わたしはロゴの裏に待機していますよ。


チラリと見えますね。


しかし今だから言いますが、魔王ドキドキし過ぎてて足が震えていました。




f:id:bs-android:20111102162409j:image:w360:left


これがゲーム中の私です。どうですか?強そうでしょうか。


普段とは違い、かなり相当かんじの悪いセリフをみなさんに浴びせていましたよね。


「見積もりが甘い!」とか。


でも、みなさんはひどいセリフほど喜んでました。


なぜでしょう?人格者過ぎます。




f:id:bs-android:20111102162410j:image:w360:left


GDDの休み時間には、大勢の方が私に会いに来てくれました。


今だから言いますが、正直私やスタッフ達の予想を大幅にこえる盛況ぶりだったのです!


こんなに遊んでもらえるなんて、魔王感無量です。


みなさんのレベルも想定よりずっとずっと高く、私あっというまに滅ぼされてしまいました。


いささかカンタンにやられ過ぎの感も否めませんでしたが…


歯ごたえのない魔王で申し訳ありませんでした。精進します。




最終的には580人の方に登録いただけました。


3桁いけたらいいほう、などと言っていたのは誰ですか?…私ですね。


なめてました。


勇者なめてました。


見積もり甘いのはどっちだ!って話ですよね。


ともかく、皆さんたくさん私と戦ってくれて、ほんとうにほんとうにありがとうございました!




f:id:bs-android:20111102162412j:image:w360:left


いかがでしたでしょうか『NFC QUEST』楽しめていただけましたでしょうか?


平和に退屈した民たちの魔王・待望コールの高まりいかんによっては、再び召喚される日もあるやもしれません。


その時はまた私を滅ぼしてくださいね。


魔王も大魔王ぐらいにはなれるよう、がんばります。




http://twitter.com/#!/nfc_quest


以上、魔王が報告いたしました。


@nfc_quest






2011年10月31日月曜日



f:id:bs-android:20111024131559j:image:w360


11/1(火)にパシフィコ横浜で開催される『Google Developer Day 2011 Japan』に出展予定の「NFC QUEST」公式ページを公開しました!


「NFC QUEST公式ページ」


現在公式ページではイベント概要資料などを公開していますが


イベント当日には登録ゲームキャラクターなどを確認できるゲームサイトも公開されます!


当日の実況や攻略情報など見逃せない情報も流れますので


参加を予定されている方は是非ブックマークしてください。


明日は皆様と会場でお会いすることを楽しみにしています!


 ~NFC QUEST制作チームより~


公式twitterアカウントNFC QUEST の 魔王も随時更新しています。フォローよろしく!





【お願い】


「NFC QUEST」では、キャラクターの名前とアイコンを『Google+』のプロフィールから取得します。


もしくはgoogleアカウントの 公開プロフィール からの取得も可能です。


当日は会場内の混雑が予想されますので、事前の設定をお願いします(公開情報ですので、お気をつけて!)。





いよいよ明日!「NFC QUEST 公式ページ」を公開しました



f:id:bs-android:20111024131559j:image:w360


11/1(火)にパシフィコ横浜で開催される『Google Developer Day 2011 Japan』に出展予定の「NFC QUEST」公式ページを公開しました!


「NFC QUEST公式ページ」


現在公式ページではイベント概要資料などを公開していますが


イベント当日には登録ゲームキャラクターなどを確認できるゲームサイトも公開されます!


当日の実況や攻略情報など見逃せない情報も流れますので


参加を予定されている方は是非ブックマークしてください。


明日は皆様と会場でお会いすることを楽しみにしています!


 ~NFC QUEST制作チームより~


公式twitterアカウントNFC QUEST の 魔王も随時更新しています。フォローよろしく!





【お願い】


「NFC QUEST」では、キャラクターの名前とアイコンを『Google+』のプロフィールから取得します。


もしくはgoogleアカウントの 公開プロフィール からの取得も可能です。


当日は会場内の混雑が予想されますので、事前の設定をお願いします(公開情報ですので、お気をつけて!)。





2011年10月25日火曜日



f:id:bs-android:20111024185035g:image:w360













おやおや?ブリリアントサービスのようすが・・・?














f:id:bs-android:20111024131558g:image:w360















f:id:bs-android:20111024131559j:image:w360

カードタッチでLVアップ!

君の持ってるICカードがゲームキャラクターになるぞ!

会場に隠されたチェックポイントを見つけ出し己を鍛えよ!

ゲームブースに待ち構える魔王に、君は勝てるか?




11/1(火)にパシフィコ横浜(横浜市西区)で開催される『Google Developer Day 2011 Japan』に、NFCを使ったゲーム「NFC QUEST」を出展します。




f:id:bs-android:20111024131557j:image:w240:right

「NFC QUEST」はNFCとクラウドを使った全く新しいイベント参加型ゲームです。

会場ではオリジナルのICカードを2000枚無償配布します。

また、皆さんが既に持っているSuica・PASMOやEdyカード、Taspoなどのカードや、おさいふケータイでも参加頂けます。







【会場内のチェックポイントにカードをタッチしてレベルアップ!】

会場内にはICカードでのタッチが可能なチェックポイントが多数設置されています。

スタンプラリーのように数多くのチェックポイントを探し、レベルを十分に上げて、魔王に挑戦して下さい。




【チームを作ろう!】

バトルブースでは3人1組のチームでゲームにチャレンジすることなります。

参加者同士でチームを組んで、ゲームブースに来て下さい




ランキング上位チームには豪華景品をご用意しております!(参加賞もあります)

皆様の挑戦をお待ちしております!




詳細は「NFC QUEST公式ページ」でご覧下さい。




『Google Developer Day 2011 Japan』でNFCを使ったスタンプラリーゲームを実施します!



f:id:bs-android:20111024185035g:image:w360













おやおや?ブリリアントサービスのようすが・・・?














f:id:bs-android:20111024131558g:image:w360















f:id:bs-android:20111024131559j:image:w360

カードタッチでLVアップ!

君の持ってるICカードがゲームキャラクターになるぞ!

会場に隠されたチェックポイントを見つけ出し己を鍛えよ!

ゲームブースに待ち構える魔王に、君は勝てるか?




11/1(火)にパシフィコ横浜(横浜市西区)で開催される『Google Developer Day 2011 Japan』に、NFCを使ったゲーム「NFC QUEST」を出展します。




f:id:bs-android:20111024131557j:image:w240:right

「NFC QUEST」はNFCとクラウドを使った全く新しいイベント参加型ゲームです。

会場ではオリジナルのICカードを2000枚無償配布します。

また、皆さんが既に持っているSuica・PASMOやEdyカード、Taspoなどのカードや、おさいふケータイでも参加頂けます。







【会場内のチェックポイントにカードをタッチしてレベルアップ!】

会場内にはICカードでのタッチが可能なチェックポイントが多数設置されています。

スタンプラリーのように数多くのチェックポイントを探し、レベルを十分に上げて、魔王に挑戦して下さい。




【チームを作ろう!】

バトルブースでは3人1組のチームでゲームにチャレンジすることなります。

参加者同士でチームを組んで、ゲームブースに来て下さい




ランキング上位チームには豪華景品をご用意しております!(参加賞もあります)

皆様の挑戦をお待ちしております!




詳細は「NFC QUEST公式ページ」でご覧下さい。




2011年10月21日金曜日



この記事は Android Developers サイトの Support Package,r14 の翻訳です。


v4 サポートライブラリの変更点:




  • アクセシビリティ API のサポート:


    • View.AccessibilityDelegate をサポートする AccessibilityDelegateCompat が追加されました。

    • AccessibilityEvent をサポートする AccessibilityEventCompat が追加されました。

    • AccessibilityManager をサポートする AccessibilityManagerCompat が追加されました。

    • AccessibilityNodeInfo をサポートする AccessibilityNodeInfoCompat が追加されました。

    • AccessibilityRecord をサポートする AccessibilityRecordCompat が追加されました。

    • AccessibilityServiceInfo をサポートする AccessibilityServiceInfoCompat が追加されました。

    • ViewGroup のアクセシビリティ機能をサポートする ViewGroupCompat が追加されました。

    • View のアクセシビリティ機能をサポートする ViewCompat が変更されました。



  • EdgeEffect をサポートする EdgeEffectCompat が追加されました。

  • グローバルにブロードキャストせず、単一アプリケーション中で容易に登録と受信が行える LocalBroadcastManager を追加しました。

  • Android 2.3 以降のビュー用のオーバースクロールモードの確認と設定のための ViewCompat サポートを追加しました。

  • フラグメントAPIの変更:


    • 新しいメニューの可視性制御を行う新しい API を追加しました。

    • カスタムアニメーション API を追加しました。

    • カスタム, 非設定インスタンスデータを保持するため、FragmentActivity に API を追加しました。

    • 様々なバグの修正。



  • ViewPager の変更:


    • ページ間のマージンのサポートを追加しました。オプションの Drawable はマージンを埋めるようにすることができます。

    • EdgeEffect のサポートを追加しました。

    • キーボードナビゲーションのサポートを追加しました。

    • 現在のページの両側にどれくらいのページを保持するかを制御する、サポートを追加しました。

    • touch physics の改良。



  • Froyo より以前のバージョンで動作している AsyncTasks のキャンセルで不具合が発生するローダーのバグを修正しました。サポートコードは、全てのプラットフォームで同じ振る舞いをする 自身の AsyncTask のバージョンを使用しています。



文責:技術部 瀬戸 直喜 





Support Package (for Android 4.0) の変更点



この記事は Android Developers サイトの Support Package,r14 の翻訳です。


v4 サポートライブラリの変更点:




  • アクセシビリティ API のサポート:


    • View.AccessibilityDelegate をサポートする AccessibilityDelegateCompat が追加されました。

    • AccessibilityEvent をサポートする AccessibilityEventCompat が追加されました。

    • AccessibilityManager をサポートする AccessibilityManagerCompat が追加されました。

    • AccessibilityNodeInfo をサポートする AccessibilityNodeInfoCompat が追加されました。

    • AccessibilityRecord をサポートする AccessibilityRecordCompat が追加されました。

    • AccessibilityServiceInfo をサポートする AccessibilityServiceInfoCompat が追加されました。

    • ViewGroup のアクセシビリティ機能をサポートする ViewGroupCompat が追加されました。

    • View のアクセシビリティ機能をサポートする ViewCompat が変更されました。



  • EdgeEffect をサポートする EdgeEffectCompat が追加されました。

  • グローバルにブロードキャストせず、単一アプリケーション中で容易に登録と受信が行える LocalBroadcastManager を追加しました。

  • Android 2.3 以降のビュー用のオーバースクロールモードの確認と設定のための ViewCompat サポートを追加しました。

  • フラグメントAPIの変更:


    • 新しいメニューの可視性制御を行う新しい API を追加しました。

    • カスタムアニメーション API を追加しました。

    • カスタム, 非設定インスタンスデータを保持するため、FragmentActivity に API を追加しました。

    • 様々なバグの修正。



  • ViewPager の変更:


    • ページ間のマージンのサポートを追加しました。オプションの Drawable はマージンを埋めるようにすることができます。

    • EdgeEffect のサポートを追加しました。

    • キーボードナビゲーションのサポートを追加しました。

    • 現在のページの両側にどれくらいのページを保持するかを制御する、サポートを追加しました。

    • touch physics の改良。



  • Froyo より以前のバージョンで動作している AsyncTasks のキャンセルで不具合が発生するローダーのバグを修正しました。サポートコードは、全てのプラットフォームで同じ振る舞いをする 自身の AsyncTask のバージョンを使用しています。



文責:技術部 瀬戸 直喜 







f:id:bs-android:20111020142159j:image:w201:right


この記事は Android Developers サイトの Android 4.0 Platform の一部及び NFC Basics/Beaming NDEF Messages to Other Devices の翻訳をまとめたものです。


Android Beam とは


Android Beam は NFC ベースの機能で、NFC が利用可能な携帯端末を重ねることによって、ユーザが使用しているアプリに関する情報を即座に共有する機能です。範囲内にデバイスが存在する時ー数センチメートル以内でーシステムは NFC 接続を準備し、共有のための UI を表示します。見ている何かを他のデバイスと共有するには、ユーザはスクリーンをただタッチするだけです。


開発者にとって、Android Beam は殆ど全てのタイプの、接近に基づいたインタラクションを引き起こす新しい方法です。例えば、ユーザは連絡帳を即座に交換、マルチプレイヤーのゲームのセットアップ、チャットやテレビ電話への参加、写真やビデオの共有、などを行うことができます。システムは低レベルの NFC サポートと 共有のUI を提供する一方、フォアグラウンドのアプリは他のデバイスに転送するための軽量のデータを提供します。開発者は共有されるデータとそれがどのように取り扱われるかについて、完全に制御しているため、殆どのインタラクションが可能です。


もっと大きなペイロードについては、Android Beam を初回の接続として利用し、ユーザがペアリングを意識する必要なくBluetooth経由でデータを転送することができます。


開発者が Android Beam に基づくインタラクションに手を加えなくても、Android の中に深く統合された利益を享受することができる場合があります。デフォルトではシステムは アプリケーションの Android Market のURL を共有します。そのため、ユーザはすぐにアプリケーションのダウンロードまたは購入することが簡単にできます。


Android Beam (NDEF Push with NFC)の仕組み


Android Beam は あるデバイスから他へ NDEF メッセージを送信すること(この処理は "NDEFプッシュ" としても知られています)を可能とする新しい NFC の機能です。Android Beam をサポートする2台の Android デバイスが隣接(約4cm)し、通常は背面同士がタッチしている時、データ転送は初期化されます。NDEF メッセージの中のデータは、デバイス間で共有したいデータを含むことができます。例えば、連絡帳の共有、YouTubeの共有ビデオ、ブラウザによるURLの共有を行うアプリは Android Beam を使えます。




Android Beam を使ったデバイス間のデータの送信には、アクティビティがフォアグラウンドにある間に、共有したい情報を含む NdefMessage を生成する必要があります。次の2つの方法のうちのいずれかでシステムに対して NdefMessage を渡す必要があります:




  • アクティビティ中でプッシュする 単一の NdefMessage の定義:


    • メッセージを送りたい時に都度 setNdefPushMessage() を呼び出します。例えば、おそらく、アクティビティの onCreate() メソッドでこのメソッドを呼び出して、NdefMessage を渡すことでしょう。アクティビティがフォアグラウンドにいる間、 Android Beam が他のデバイスから活性化される場合は常に、システムは NdefMessage を他のデバイスに送信します。



  • Android Beam の初期化と同時にプッシュする NdefMessage の定義:


    • 送りたい NdefMessage を返す createNdefMessage() メソッドの実装中に、NfcAdapter.CreateNdefMessageCallback を実装する。その時、NfcAdapter.CreateNdefMessageCallback を setNdefPushMessageCallback() の実装へ渡します。

    • このケースではアクティビティがフォアグラウンドにある間、他のデバイスから活性化された時、システムは送りたい NdefMessage を引き出すために createNdefMessage() を呼び出します。これは、メッセージのコンテンツがアクティビティの存在中に終始変化するかもしれないケースにおいて、初期化された Android Beam を一度だけ配信するために NdefMessage を定義することを許します。




システムによって他のデバイスへの NDEF メッセージの送信に成功した際に、特定のコードを処理したい場合は、NfcAdapter.OnNdefPushCompleteCallback を実装し、setNdefPushCompleteCallback() でセットすることができます。メッセージが配信された時、システムは onNdefPushComplete() を呼び出すでしょう。


デバイスの受信時、通常の NFC タグと同等の方法で NDEF プッシュメッセージを処理します。


システムはアクティビティを開始するために、ACTION_NDEF_DISCOVERED アクションとNdefMessage の 最初の NdefRecord に従って URL か MIME タイプのいずれかを設定して、インテントを起動します。アクティビティで反応させるために、対応したい URL か MIME タイプのインテントフィルタを定義することができます。詳細は NFC 開発者ガイドの Tag の処理についてを参照して下さい。


URL を NdefMessage で送りたい場合、文字列か Uri オブジェクトを元とした新しい NdefRecord を作成する createUri という便利なメソッドを使うことができます。URI が、Android Beam のイベント中受信するアプリケーションが特別なフォーマットであるという場合、送られてくる NDEF メッセージを受信するために、同一の URI スキームを使用するアクティビティのためのインテントフィルタを生成すべきです。


例え他のアプリケーションが同じインテントアクションをフィルタを処理するとしても、入ってくる NDEF メッセージをアプリケーションが処理することを保証するためには、NdefMessage と共に“Android アプリケーションレコード" も渡すようにすべきです。createApplicationRecord() を呼び出すことで Android アプリケーションレコード を生成することができ、アプリケーションのパッケージ名を渡すことができます。アプリケーションレコードと、特定のインテントを処理するアクティビティを含む複数のアプリケーションを伴う NDEF メッセージを他のデバイスで他のデバイスが受信した時、システムはいつも(アプリケーションレコードにマッチしたものに基づいた)アプリケーション中のアクティビティにメッセージを配信します。その際、ターゲットのデバイスにアプリケーションがインストールされていない場合、システムは Android マーケットを起動してユーザにアプリケーションをインストールさせるために Android application record を用います。


アプリケーションが NDEF プッシュメッセージを行うのに NFC API を使わない場合、その時は Android は標準の振る舞いを行います:あるデバイスのアプリケーションがフォアグラウンドにあり、他の Android デバイスから Android Beam が起動される時、他のデバイスは Android アプリケーションレコードとアプリケーションのID を含む NDEF メッセージを受信します。受信したデバイスにアプリケーションが既にインストールされている場合、システムはそれを起動します。インストールされていない場合は、Android マーケットが開き、インストールするためにユーザを案内します。


Android Beam と その他の NFC の機能について、NFC 基本 開発者ガイドを読むことができます。Android Beam を使ったサンプルコードは Android Beam デモを御覧ください。


Android Beam の詳細


Android Beam は、2つのAndroidデバイス間でシンプルなピア・ツー・ピアデータ交換を可能にします。他のデバイスへデータを送りたいアプリケーションは、フォアグラウンドにいて、且つ、データを受信するデバイスがロックされていないことが必要です。受信側のデバイスに接触するぐらい十分に送信するデバイスを近づけると、送信側のディスプレイに "Touch to Beam" UIが表示されます。ユーザーは受信側のデバイスにメッセージを受信するかどうかを選択することができます。


注意:フォアグラウンド NDEF プッシングは API レベル10から使用可能で、Android Beam と同様の機能を有します。これらの API 群は非推奨となりましたが、旧デバイスをサポートすることが可能です。詳細はenableForegroundNdefPush() をご覧下さい。


アプリケーションで Android Beam を有効にするために、次の2つのメソッドのうちいずれかを使用できます:




  • setNdefPushMessage(): 送信するメッセージをセットするためのNdefMessage を受け入れます。2つのデバイスが十分近くに隣接すると自動的にメッセージを送信します。

  • setNdefPushMessageCallback():送信範囲内にデバイスが存在する時に呼び出されるcreateNdefMessage() を含むコールバックを受け入れます。コールバックは必要な時に限って、NDEF メッセージを生成させます。


アクティビティは、1度に1つの NDEF メッセージのみをプッシュすることが可能です。そのため、両方がセットされている時は、setNdefPushMessageCallback() は setNdefPushMessage() よりも優先されます。


Android Beam を使うためには、下記の一般的なガイドラインに従う必要があります:




  • データを送信するアクティビティはフォアグラウンドにある必要があります。両デバイス共にスクリーンはアンロック状態である必要があります。

  • NdefMessage オブジェクトに送信したいデータをカプセル化する必要があります。

  • 送信されたデータを受信するNFC デバイスは、com.android.npp NDEF push protocol か、NFC フォーラムの SNEP(Simple NDEF Exchange Protocol) のいずれかをサポートする必要があります。com.android.npp プロトコルは API レベル9 (Android 2.3) から API レベル13 (Android 3.2) のデバイスが必要です。com.android.npp と SNEP の両方は API レベル14 (Android 4.0) 以降が必要です。



注意:Android Beam が使用可能なアクティビティがフォアグラウンドにある場合、標準的なインテントの処理は無効となります。しかし、アクティビティがフォアグラウンドで処理することもまた有効である場合、フォアグラウンド処理中にインテントフィルタにマッチするタグを引き続きスキャンする事ができます。



Android Beam を有効にするために:




  1. 他のデバイスへプッシュしたい NdefRecords を含んだ NdefMessage を生成します。

  2. NdefMessage を含む setNdefPushMessage() を呼び出すか、アクティビティ中の onCreate() メソッドの中で NfcAdapter.CreateNdefMessageCallback オブジェクトが渡された setNdefPushMessageCallback を呼び出します。これらのメソッドは、活性化したい他のアクティビティのオプションのリストと共に、 Android Beam で有効にしたいアクティビティが少なくとも1つは必要です。


一般に、2つのデバイスがコミュニケーションする範囲内にある場合、アクティビティがいつも同じ NDEF メッセージをプッシュする必要があるだけである場合は、通常 setNdefPushMessage() を使います。アプリケーションが現在のアプリケーションのコンテキストを扱いたい時やユーザがアプリケーションに対して行っていることに依存する NDEF メッセージをプッシュしたい時は、setNdefPushMessageCallback を使います。


以下は アクティビティの onCreate() メソッド中で、NfcAdapter.CreateNdefMessageCallback を呼び出す単純なアクティビティをどのように実装するかの例です(完全なサンプルを御覧ください)。この例はまた MIME レコードの作り方も示しています:



package com.example.android.beam;

import android.app.Activity;
import android.content.Intent;
import android.nfc.NdefMessage;
import android.nfc.NdefRecord;
import android.nfc.NfcAdapter;
import android.nfc.NfcAdapter.CreateNdefMessageCallback;
import android.nfc.NfcEvent;
import android.os.Bundle;
import android.os.Parcelable;
import android.widget.TextView;
import android.widget.Toast;
import java.nio.charset.Charset;


public class Beam extends Activity implements CreateNdefMessageCallback {
NfcAdapter mNfcAdapter;
TextView textView;

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TextView textView = (TextView) findViewById(R.id.textView);
// 利用可能なNFC アダプタのチェック
mNfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (mNfcAdapter == null) {
Toast.makeText(this, "NFC is not available", Toast.LENGTH_LONG).show();
finish();
return;
}
// コールバックを登録する
mNfcAdapter.setNdefPushMessageCallback(this, this);
}

@Override
public NdefMessage createNdefMessage(NfcEvent event) {
String text = ("Beam me up, Android!\n\n" +
"Beam Time: " + System.currentTimeMillis());
NdefMessage msg = new NdefMessage(
new NdefRecord[] { createMimeRecord(
"application/com.example.android.beam", text.getBytes())
/**
* Android Application Record(AAR)はコメントアウトされています。
* デバイスがAARを含むプッシュを受信した時、アプリケーションは
* 実行を保証するためにAARを指定します。AARはタグの処理システムをオーバーライドします。
* メッセージを受信した時にこのアクティビティが開始されることを保証するために、
* 後ろに追加することができます。今のところ、このコードはタグ処理
* システムを使っています。
*/
//,NdefRecord.createApplicationRecord("com.example.android.beam")
});
return msg;
}

@Override
public void onResume() {
super.onResume();
// アクティビティがAndroid Beamによって開始されたことをチェックする
if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction())) {
processIntent(getIntent());
}
}

@Override
public void onNewIntent(Intent intent) {
// インテントを処理するために、この後でonResumeが呼ばれる
setIntent(intent);
}

/**
* インテントからのNDEFメッセージのパースとTextViewへの表示
*/
void processIntent(Intent intent) {
textView = (TextView) findViewById(R.id.textView);
Parcelable[] rawMsgs = intent.getParcelableArrayExtra(
NfcAdapter.EXTRA_NDEF_MESSAGES);
// ビームの送信中は一つだけのメッセージ
NdefMessage msg = (NdefMessage) rawMsgs[0];
// 現在は、レコード0はMIMEタイプを含む、レコード1はAARを含む
textView.setText(new String(msg.getRecords()[0].getPayload()));
}

/**
* NDEFレコード内にカスタムMIMEタイプをカプセル化して生成する
*/
public NdefRecord createMimeRecord(String mimeType, byte[] payload) {
byte[] mimeBytes = mimeType.getBytes(Charset.forName("US-ASCII"));
NdefRecord mimeRecord = new NdefRecord(
NdefRecord.TNF_MIME_MEDIA, mimeBytes, new byte[0], payload);
return mimeRecord;
}
}


このコードはAARをコメントアウトしていますが、除去できることに注意して下さい。AARを有効にした場合、AAR中の特定のアプリケーションは常にAndroid Beam メッセージを受信します。アプリケーションが存在しない場合、Android Market がアプリケーションをダウンロードするために起動します。したがって、AAR が使われる場合、下記のインテントフィルタは Android 4.0 以降のデバイスでは技術的に必要ありません:



<intent-filter>
<action android:name="android.nfc.action.NDEF_DISCOVERED"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:mimeType="application/com.example.android.beam"/>
</intent-filter>


このインテントフィルタにより、 com.example.android.beam アプリケーションが NFC タグをスキャンした時やcom.example.android.beam 型のAARを伴うAndroid Beamを受信した時、または、NDEF フォーマットのメッセージが application/com.example.android.beam 型の MIME レコードを含んでいる時に、開始することができます。


例え AAR がアプリケーションの開始とダウンロードを保証していても、インテントフィルタは推奨されます。何故なら、AAR によって特定されたパッケージの範囲内にあるメインのアクティビティを常に開始する代わりに、アプリケーション中の開始するアクティビティを選択する余地を与えるためです。AAR はアクティビティレベルの保証は行いません。また、いくつかの Android 端末は AAR をサポートしないため、万が一のために、NDEF メッセージの最初の NDEF レコードに、IDの情報を埋め込み、同様にフィルターすべきです。レコードの生成方法に関する詳しい情報は、NDEF レコードの共通タイプの作成を御覧ください。



文責:技術部 瀬戸 直喜 





Android Beam の基本



f:id:bs-android:20111020142159j:image:w201:right


この記事は Android Developers サイトの Android 4.0 Platform の一部及び NFC Basics/Beaming NDEF Messages to Other Devices の翻訳をまとめたものです。


Android Beam とは


Android Beam は NFC ベースの機能で、NFC が利用可能な携帯端末を重ねることによって、ユーザが使用しているアプリに関する情報を即座に共有する機能です。範囲内にデバイスが存在する時ー数センチメートル以内でーシステムは NFC 接続を準備し、共有のための UI を表示します。見ている何かを他のデバイスと共有するには、ユーザはスクリーンをただタッチするだけです。


開発者にとって、Android Beam は殆ど全てのタイプの、接近に基づいたインタラクションを引き起こす新しい方法です。例えば、ユーザは連絡帳を即座に交換、マルチプレイヤーのゲームのセットアップ、チャットやテレビ電話への参加、写真やビデオの共有、などを行うことができます。システムは低レベルの NFC サポートと 共有のUI を提供する一方、フォアグラウンドのアプリは他のデバイスに転送するための軽量のデータを提供します。開発者は共有されるデータとそれがどのように取り扱われるかについて、完全に制御しているため、殆どのインタラクションが可能です。


もっと大きなペイロードについては、Android Beam を初回の接続として利用し、ユーザがペアリングを意識する必要なくBluetooth経由でデータを転送することができます。


開発者が Android Beam に基づくインタラクションに手を加えなくても、Android の中に深く統合された利益を享受することができる場合があります。デフォルトではシステムは アプリケーションの Android Market のURL を共有します。そのため、ユーザはすぐにアプリケーションのダウンロードまたは購入することが簡単にできます。


Android Beam (NDEF Push with NFC)の仕組み


Android Beam は あるデバイスから他へ NDEF メッセージを送信すること(この処理は "NDEFプッシュ" としても知られています)を可能とする新しい NFC の機能です。Android Beam をサポートする2台の Android デバイスが隣接(約4cm)し、通常は背面同士がタッチしている時、データ転送は初期化されます。NDEF メッセージの中のデータは、デバイス間で共有したいデータを含むことができます。例えば、連絡帳の共有、YouTubeの共有ビデオ、ブラウザによるURLの共有を行うアプリは Android Beam を使えます。




Android Beam を使ったデバイス間のデータの送信には、アクティビティがフォアグラウンドにある間に、共有したい情報を含む NdefMessage を生成する必要があります。次の2つの方法のうちのいずれかでシステムに対して NdefMessage を渡す必要があります:




  • アクティビティ中でプッシュする 単一の NdefMessage の定義:


    • メッセージを送りたい時に都度 setNdefPushMessage() を呼び出します。例えば、おそらく、アクティビティの onCreate() メソッドでこのメソッドを呼び出して、NdefMessage を渡すことでしょう。アクティビティがフォアグラウンドにいる間、 Android Beam が他のデバイスから活性化される場合は常に、システムは NdefMessage を他のデバイスに送信します。



  • Android Beam の初期化と同時にプッシュする NdefMessage の定義:


    • 送りたい NdefMessage を返す createNdefMessage() メソッドの実装中に、NfcAdapter.CreateNdefMessageCallback を実装する。その時、NfcAdapter.CreateNdefMessageCallback を setNdefPushMessageCallback() の実装へ渡します。

    • このケースではアクティビティがフォアグラウンドにある間、他のデバイスから活性化された時、システムは送りたい NdefMessage を引き出すために createNdefMessage() を呼び出します。これは、メッセージのコンテンツがアクティビティの存在中に終始変化するかもしれないケースにおいて、初期化された Android Beam を一度だけ配信するために NdefMessage を定義することを許します。




システムによって他のデバイスへの NDEF メッセージの送信に成功した際に、特定のコードを処理したい場合は、NfcAdapter.OnNdefPushCompleteCallback を実装し、setNdefPushCompleteCallback() でセットすることができます。メッセージが配信された時、システムは onNdefPushComplete() を呼び出すでしょう。


デバイスの受信時、通常の NFC タグと同等の方法で NDEF プッシュメッセージを処理します。


システムはアクティビティを開始するために、ACTION_NDEF_DISCOVERED アクションとNdefMessage の 最初の NdefRecord に従って URL か MIME タイプのいずれかを設定して、インテントを起動します。アクティビティで反応させるために、対応したい URL か MIME タイプのインテントフィルタを定義することができます。詳細は NFC 開発者ガイドの Tag の処理についてを参照して下さい。


URL を NdefMessage で送りたい場合、文字列か Uri オブジェクトを元とした新しい NdefRecord を作成する createUri という便利なメソッドを使うことができます。URI が、Android Beam のイベント中受信するアプリケーションが特別なフォーマットであるという場合、送られてくる NDEF メッセージを受信するために、同一の URI スキームを使用するアクティビティのためのインテントフィルタを生成すべきです。


例え他のアプリケーションが同じインテントアクションをフィルタを処理するとしても、入ってくる NDEF メッセージをアプリケーションが処理することを保証するためには、NdefMessage と共に“Android アプリケーションレコード" も渡すようにすべきです。createApplicationRecord() を呼び出すことで Android アプリケーションレコード を生成することができ、アプリケーションのパッケージ名を渡すことができます。アプリケーションレコードと、特定のインテントを処理するアクティビティを含む複数のアプリケーションを伴う NDEF メッセージを他のデバイスで他のデバイスが受信した時、システムはいつも(アプリケーションレコードにマッチしたものに基づいた)アプリケーション中のアクティビティにメッセージを配信します。その際、ターゲットのデバイスにアプリケーションがインストールされていない場合、システムは Android マーケットを起動してユーザにアプリケーションをインストールさせるために Android application record を用います。


アプリケーションが NDEF プッシュメッセージを行うのに NFC API を使わない場合、その時は Android は標準の振る舞いを行います:あるデバイスのアプリケーションがフォアグラウンドにあり、他の Android デバイスから Android Beam が起動される時、他のデバイスは Android アプリケーションレコードとアプリケーションのID を含む NDEF メッセージを受信します。受信したデバイスにアプリケーションが既にインストールされている場合、システムはそれを起動します。インストールされていない場合は、Android マーケットが開き、インストールするためにユーザを案内します。


Android Beam と その他の NFC の機能について、NFC 基本 開発者ガイドを読むことができます。Android Beam を使ったサンプルコードは Android Beam デモを御覧ください。


Android Beam の詳細


Android Beam は、2つのAndroidデバイス間でシンプルなピア・ツー・ピアデータ交換を可能にします。他のデバイスへデータを送りたいアプリケーションは、フォアグラウンドにいて、且つ、データを受信するデバイスがロックされていないことが必要です。受信側のデバイスに接触するぐらい十分に送信するデバイスを近づけると、送信側のディスプレイに "Touch to Beam" UIが表示されます。ユーザーは受信側のデバイスにメッセージを受信するかどうかを選択することができます。


注意:フォアグラウンド NDEF プッシングは API レベル10から使用可能で、Android Beam と同様の機能を有します。これらの API 群は非推奨となりましたが、旧デバイスをサポートすることが可能です。詳細はenableForegroundNdefPush() をご覧下さい。


アプリケーションで Android Beam を有効にするために、次の2つのメソッドのうちいずれかを使用できます:




  • setNdefPushMessage(): 送信するメッセージをセットするためのNdefMessage を受け入れます。2つのデバイスが十分近くに隣接すると自動的にメッセージを送信します。

  • setNdefPushMessageCallback():送信範囲内にデバイスが存在する時に呼び出されるcreateNdefMessage() を含むコールバックを受け入れます。コールバックは必要な時に限って、NDEF メッセージを生成させます。


アクティビティは、1度に1つの NDEF メッセージのみをプッシュすることが可能です。そのため、両方がセットされている時は、setNdefPushMessageCallback() は setNdefPushMessage() よりも優先されます。


Android Beam を使うためには、下記の一般的なガイドラインに従う必要があります:




  • データを送信するアクティビティはフォアグラウンドにある必要があります。両デバイス共にスクリーンはアンロック状態である必要があります。

  • NdefMessage オブジェクトに送信したいデータをカプセル化する必要があります。

  • 送信されたデータを受信するNFC デバイスは、com.android.npp NDEF push protocol か、NFC フォーラムの SNEP(Simple NDEF Exchange Protocol) のいずれかをサポートする必要があります。com.android.npp プロトコルは API レベル9 (Android 2.3) から API レベル13 (Android 3.2) のデバイスが必要です。com.android.npp と SNEP の両方は API レベル14 (Android 4.0) 以降が必要です。



注意:Android Beam が使用可能なアクティビティがフォアグラウンドにある場合、標準的なインテントの処理は無効となります。しかし、アクティビティがフォアグラウンドで処理することもまた有効である場合、フォアグラウンド処理中にインテントフィルタにマッチするタグを引き続きスキャンする事ができます。



Android Beam を有効にするために:




  1. 他のデバイスへプッシュしたい NdefRecords を含んだ NdefMessage を生成します。

  2. NdefMessage を含む setNdefPushMessage() を呼び出すか、アクティビティ中の onCreate() メソッドの中で NfcAdapter.CreateNdefMessageCallback オブジェクトが渡された setNdefPushMessageCallback を呼び出します。これらのメソッドは、活性化したい他のアクティビティのオプションのリストと共に、 Android Beam で有効にしたいアクティビティが少なくとも1つは必要です。


一般に、2つのデバイスがコミュニケーションする範囲内にある場合、アクティビティがいつも同じ NDEF メッセージをプッシュする必要があるだけである場合は、通常 setNdefPushMessage() を使います。アプリケーションが現在のアプリケーションのコンテキストを扱いたい時やユーザがアプリケーションに対して行っていることに依存する NDEF メッセージをプッシュしたい時は、setNdefPushMessageCallback を使います。


以下は アクティビティの onCreate() メソッド中で、NfcAdapter.CreateNdefMessageCallback を呼び出す単純なアクティビティをどのように実装するかの例です(完全なサンプルを御覧ください)。この例はまた MIME レコードの作り方も示しています:



package com.example.android.beam;

import android.app.Activity;
import android.content.Intent;
import android.nfc.NdefMessage;
import android.nfc.NdefRecord;
import android.nfc.NfcAdapter;
import android.nfc.NfcAdapter.CreateNdefMessageCallback;
import android.nfc.NfcEvent;
import android.os.Bundle;
import android.os.Parcelable;
import android.widget.TextView;
import android.widget.Toast;
import java.nio.charset.Charset;


public class Beam extends Activity implements CreateNdefMessageCallback {
NfcAdapter mNfcAdapter;
TextView textView;

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TextView textView = (TextView) findViewById(R.id.textView);
// 利用可能なNFC アダプタのチェック
mNfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (mNfcAdapter == null) {
Toast.makeText(this, "NFC is not available", Toast.LENGTH_LONG).show();
finish();
return;
}
// コールバックを登録する
mNfcAdapter.setNdefPushMessageCallback(this, this);
}

@Override
public NdefMessage createNdefMessage(NfcEvent event) {
String text = ("Beam me up, Android!\n\n" +
"Beam Time: " + System.currentTimeMillis());
NdefMessage msg = new NdefMessage(
new NdefRecord[] { createMimeRecord(
"application/com.example.android.beam", text.getBytes())
/**
* Android Application Record(AAR)はコメントアウトされています。
* デバイスがAARを含むプッシュを受信した時、アプリケーションは
* 実行を保証するためにAARを指定します。AARはタグの処理システムをオーバーライドします。
* メッセージを受信した時にこのアクティビティが開始されることを保証するために、
* 後ろに追加することができます。今のところ、このコードはタグ処理
* システムを使っています。
*/
//,NdefRecord.createApplicationRecord("com.example.android.beam")
});
return msg;
}

@Override
public void onResume() {
super.onResume();
// アクティビティがAndroid Beamによって開始されたことをチェックする
if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction())) {
processIntent(getIntent());
}
}

@Override
public void onNewIntent(Intent intent) {
// インテントを処理するために、この後でonResumeが呼ばれる
setIntent(intent);
}

/**
* インテントからのNDEFメッセージのパースとTextViewへの表示
*/
void processIntent(Intent intent) {
textView = (TextView) findViewById(R.id.textView);
Parcelable[] rawMsgs = intent.getParcelableArrayExtra(
NfcAdapter.EXTRA_NDEF_MESSAGES);
// ビームの送信中は一つだけのメッセージ
NdefMessage msg = (NdefMessage) rawMsgs[0];
// 現在は、レコード0はMIMEタイプを含む、レコード1はAARを含む
textView.setText(new String(msg.getRecords()[0].getPayload()));
}

/**
* NDEFレコード内にカスタムMIMEタイプをカプセル化して生成する
*/
public NdefRecord createMimeRecord(String mimeType, byte[] payload) {
byte[] mimeBytes = mimeType.getBytes(Charset.forName("US-ASCII"));
NdefRecord mimeRecord = new NdefRecord(
NdefRecord.TNF_MIME_MEDIA, mimeBytes, new byte[0], payload);
return mimeRecord;
}
}


このコードはAARをコメントアウトしていますが、除去できることに注意して下さい。AARを有効にした場合、AAR中の特定のアプリケーションは常にAndroid Beam メッセージを受信します。アプリケーションが存在しない場合、Android Market がアプリケーションをダウンロードするために起動します。したがって、AAR が使われる場合、下記のインテントフィルタは Android 4.0 以降のデバイスでは技術的に必要ありません:



<intent-filter>
<action android:name="android.nfc.action.NDEF_DISCOVERED"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:mimeType="application/com.example.android.beam"/>
</intent-filter>


このインテントフィルタにより、 com.example.android.beam アプリケーションが NFC タグをスキャンした時やcom.example.android.beam 型のAARを伴うAndroid Beamを受信した時、または、NDEF フォーマットのメッセージが application/com.example.android.beam 型の MIME レコードを含んでいる時に、開始することができます。


例え AAR がアプリケーションの開始とダウンロードを保証していても、インテントフィルタは推奨されます。何故なら、AAR によって特定されたパッケージの範囲内にあるメインのアクティビティを常に開始する代わりに、アプリケーション中の開始するアクティビティを選択する余地を与えるためです。AAR はアクティビティレベルの保証は行いません。また、いくつかの Android 端末は AAR をサポートしないため、万が一のために、NDEF メッセージの最初の NDEF レコードに、IDの情報を埋め込み、同様にフィルターすべきです。レコードの生成方法に関する詳しい情報は、NDEF レコードの共通タイプの作成を御覧ください。



文責:技術部 瀬戸 直喜 





2011年10月20日木曜日

GPS設定を切り替えて、Home画面とスクリーンOFF中の計測を行いました。

条件:
・壁紙設定:壁紙
・Wi-Fi設定:OFF
・Bluetooth設定:OFF
・GPS設定:ON/OFF
・バックグラウンドシンク設定:OFF



1.Home画面

GPS設定OFFの波形です。
約0.10Aでした。





GPS設定ONの波形です。



設定OFFよりも値が跳ね上がっている回数が多いですが、
思った以上に上昇していません。




2.スクリーンOFF中

Home画面で電源キー短押下しスクリーンOFFした状態で計測しました
GPS設定OFFの波形です。
約2秒間隔で0.05Aを超えていますが、ほぼ0Aまで落ちています。






GPS設定ONの波形です。




設定OFFの波形と変化が見られませんでした。


3.まとめ

GPS設定ONの状態では、消費電流はあまり上昇しないことがわかりました。
ただし、これは一定の場所にとどまって計測を行ったためかもしれません。
移動中に計測すると、結果は異なると思います。

GPS設定ON/OFFの違いを確認する

GPS設定を切り替えて、Home画面とスクリーンOFF中の計測を行いました。

条件:
・壁紙設定:壁紙
・Wi-Fi設定:OFF
・Bluetooth設定:OFF
・GPS設定:ON/OFF
・バックグラウンドシンク設定:OFF



1.Home画面

GPS設定OFFの波形です。
約0.10Aでした。





GPS設定ONの波形です。



設定OFFよりも値が跳ね上がっている回数が多いですが、
思った以上に上昇していません。




2.スクリーンOFF中

Home画面で電源キー短押下しスクリーンOFFした状態で計測しました
GPS設定OFFの波形です。
約2秒間隔で0.05Aを超えていますが、ほぼ0Aまで落ちています。






GPS設定ONの波形です。




設定OFFの波形と変化が見られませんでした。


3.まとめ

GPS設定ONの状態では、消費電流はあまり上昇しないことがわかりました。
ただし、これは一定の場所にとどまって計測を行ったためかもしれません。
移動中に計測すると、結果は異なると思います。


f:id:bs-android:20111019221458j:image:w450


この記事は Android Developers サイトの SDK Tools,r14 の翻訳です。



重要: Android SDK マネージャから 新しい Android 4.0 のシステムコンポーネントをダウンロードするためには、初めに SDK ツールをリビジョン14にアップデートして、Android SDK マネージャを再起動する必要があります。これらを実施していない場合、Android 4.0 システムコンポーネントをダウンロードすることができません。



依存関係:




  • Android SDK Platform-tools リビジョン8以降が必要です。

  • Eclipse で ADT を使って開発している場合、SDK ツール r14は ADT 14.0.0以降を使用するようにデザインされていることに注意してください。ADT 14.0.0 を使用していないのであれば、ADT プラグインを 14.0.0 へアップデートすることを強く推奨します。

  • Eclipse以外で開発している場合、Apache Ant 1.8以降が必要です。


一般的な注意点:




  • Android 4.0 以降のプラットフォームで、1つの webcam がある場合は背面カメラ、2つの webcam がある場合は背面と全面の両方のカメラをシミュレートする webcam サポートが追加されました。webcam は Windows と Linux のみでサポートされています。Mac のサポートは今後のリリースでサポートされる予定です。

  • default.properties は project.properties へ、build.properties は ant.propertiesへ変更されました。Ant でビルドした既存のプロジェクトは、android update project コマンドで更新する必要があります。

  • ビルドシステムの改良をサポートするために build.xml が変更されました。また、Ant コマンドが追加、変更されました。Ant コマンドのリストは、Ant コマンドリファレンスを参照してください。

  • ライブラリプロジェクトのビルド方法が変更されました。

  • リソースのコンパイルが頻発しないようにインクリメンタルビルドが改善されました。文字列やレイアウトを編集した際(新しいidの追加が伴わない限り)に、もはやビルドする必要はなく、個々のライブラリプロジェクトを先にビルドする必要もありません。

  • 常に存在する全てのPNGファイルのcrunch(PNGの圧縮)を行う代わりに、編集されたPNGに対してだけ動作する"PNG crunch cache"を導入しました。

  • SDK マネージャの UI が改良されました(詳細)。


ビルドシステムの変更点の完全な概要とサポートが必要な場合は、Android Tools Project サイトをご覧下さい。



文責:技術部 瀬戸 直喜 





SDK Tools (for Android 4.0) の変更点



f:id:bs-android:20111019221458j:image:w450


この記事は Android Developers サイトの SDK Tools,r14 の翻訳です。



重要: Android SDK マネージャから 新しい Android 4.0 のシステムコンポーネントをダウンロードするためには、初めに SDK ツールをリビジョン14にアップデートして、Android SDK マネージャを再起動する必要があります。これらを実施していない場合、Android 4.0 システムコンポーネントをダウンロードすることができません。



依存関係:




  • Android SDK Platform-tools リビジョン8以降が必要です。

  • Eclipse で ADT を使って開発している場合、SDK ツール r14は ADT 14.0.0以降を使用するようにデザインされていることに注意してください。ADT 14.0.0 を使用していないのであれば、ADT プラグインを 14.0.0 へアップデートすることを強く推奨します。

  • Eclipse以外で開発している場合、Apache Ant 1.8以降が必要です。


一般的な注意点:




  • Android 4.0 以降のプラットフォームで、1つの webcam がある場合は背面カメラ、2つの webcam がある場合は背面と全面の両方のカメラをシミュレートする webcam サポートが追加されました。webcam は Windows と Linux のみでサポートされています。Mac のサポートは今後のリリースでサポートされる予定です。

  • default.properties は project.properties へ、build.properties は ant.propertiesへ変更されました。Ant でビルドした既存のプロジェクトは、android update project コマンドで更新する必要があります。

  • ビルドシステムの改良をサポートするために build.xml が変更されました。また、Ant コマンドが追加、変更されました。Ant コマンドのリストは、Ant コマンドリファレンスを参照してください。

  • ライブラリプロジェクトのビルド方法が変更されました。

  • リソースのコンパイルが頻発しないようにインクリメンタルビルドが改善されました。文字列やレイアウトを編集した際(新しいidの追加が伴わない限り)に、もはやビルドする必要はなく、個々のライブラリプロジェクトを先にビルドする必要もありません。

  • 常に存在する全てのPNGファイルのcrunch(PNGの圧縮)を行う代わりに、編集されたPNGに対してだけ動作する"PNG crunch cache"を導入しました。

  • SDK マネージャの UI が改良されました(詳細)。


ビルドシステムの変更点の完全な概要とサポートが必要な場合は、Android Tools Project サイトをご覧下さい。



文責:技術部 瀬戸 直喜 







f:id:bs-android:20111019143535j:image:w400


この記事は Android Developers サイトの ADT Plugin for Eclipse の翻訳です。


依存性




  • ADT 14.0.0 は SDK Tools r14用にデザインされています。まだ SDK Tools r14をインストールしていない場合は、Android SDK と AVD マネージャを使用して下さい。


ビルドシステム




  • default.properties は project.properties に、build.properties は ant.properties に変更されました。Eclipse のプロジェクトが開かれた時に、必要があればADT は自動的にこれらのファイルをリネームします。

  • Eclipse で、ライブラリプロジェクトのビルド方法が変更されました。

  • Eclipseで、javacの出力先が bin/ から bin/classes に変更されました。

  • リソースのコンパイルが頻発しないようにインクリメンタルビルドが改善されました。文字列やレイアウトを編集した際(新しいidの追加が伴わない限り)に、もはやビルドする必要はなく、個々のライブラリプロジェクトを先にビルドする必要もありません。

  • 常に、存在する全てのPNGファイルのcrunch(PNGの圧縮)を行う代わりに、編集されたPNGに対してだけ動作する"PNG crunch cache"を導入しました。

  • 通常の保存によってリソースのコンパイルが起こらないように修正しました。これらは実行時またはデバッグ時のみに発生します。(ADT12 によって導入されたパッケージングステップを無効にするビルドオプションは、現在はデフォルトになっています。)


ビルドシステムの変更点の完全な概要とサポートが必要な場合は、Android Tools Project サイトをご覧下さい。


一般的な改善




  • Android 開発環境の初期セットアップを助けるために ウェルカムウィザードを追加しました(詳細)。

  • ランチャーやメニューやタブのようなアイコンを作成を手助けする Android Asset Studio が統合されました(詳細)。

  • Logcat ビューが改良され、PIDと同様にアプリケーション名でログの表示とフィルタリングがサポートされました(詳細)。

  • SDK マネージャの UI が改良されました(詳細)。

  • 新しいプロジェクトと新しいXMLファイルウィザードが複数のページを持つように改良されました。サンプルプロジェクトはワークスペース内にコピーされるようになり、マスターコピーに影響を及ぼすことなく編集や削除が可能となりました(詳細)。

  • Eclipse GEFの依存性を改善しました。


XML と Java エディタ




  • Android のコーディングスタイルに準拠した全ての XML ファイルを整形する、新しい XML フォーマッターが追加されました。このフォーマッターは属性を推奨される順番で並び替えができ、レイアウトエディタで変更されたものを処理することが可能です。

  • XMLファイルの開いたタグと閉じたタグの間をジャンプすることができる、"Go to Matching"(CTRL+SHIFT+P) 機能を追加しました。

  • Macで "エンクロージング要素の選択" をサポートしました。

  • 文字列の中にキャレットが入っている時、文字列を抽出するクイックフィックスを追加しました(詳細)。

  • XML エディタのリターンキーを押す時に、自動インデント・アンインデントを自動的に行うことができる "スマートインデント" を改良しました(詳細)。


レイアウトエディタ




  • ドラッグとリサイズ操作のツールチップフィードバックを追加しました。例えば、relative レイアウト中をドラッグする時に、提案された制約が表示されます。リサイズの際は新しい範囲が表示されます(詳細)。

  • 厳密な警告を抑制する機能を追加しました(詳細)。

  • 子供のコンテナを削除してトップレベルまで移動し、ネームスペースとレイアウトの属性を必要に応じて変換する "Remove Container"(コンテナの削除)と呼ばれる視覚的なリファクタリングツールを追加しました。(詳細)

  • 子供が親を完全に覆ってしまい選択することが難しい場合に、親のプロパティにアクセスするためのコンテキストメニューをプル-ライトメニューに追加しました。

  • コンテキストメニューのプロパティ操作を改善しました。それぞれのビューの属性でよく設定されるものをメニューのトップにリストします。プロパティのメニューは最も最近設定された属性へのアクセスを提供し、属性は定義されたビューやレイアウトの属性のみ、または、全ての属性がアルファベット順で構成されます(詳細)。


バグ修正




  • 多くのバグの修正とマイナーな改善を行いました、特にいくつかのクリティカルなLinuxのバグを修正しました。






文責:技術部 瀬戸 直喜 





ADT 14.0.0 (for Android4.0) の変更点 [ADT Plugin for Eclipse 翻訳]



f:id:bs-android:20111019143535j:image:w400


この記事は Android Developers サイトの ADT Plugin for Eclipse の翻訳です。


依存性




  • ADT 14.0.0 は SDK Tools r14用にデザインされています。まだ SDK Tools r14をインストールしていない場合は、Android SDK と AVD マネージャを使用して下さい。


ビルドシステム




  • default.properties は project.properties に、build.properties は ant.properties に変更されました。Eclipse のプロジェクトが開かれた時に、必要があればADT は自動的にこれらのファイルをリネームします。

  • Eclipse で、ライブラリプロジェクトのビルド方法が変更されました。

  • Eclipseで、javacの出力先が bin/ から bin/classes に変更されました。

  • リソースのコンパイルが頻発しないようにインクリメンタルビルドが改善されました。文字列やレイアウトを編集した際(新しいidの追加が伴わない限り)に、もはやビルドする必要はなく、個々のライブラリプロジェクトを先にビルドする必要もありません。

  • 常に、存在する全てのPNGファイルのcrunch(PNGの圧縮)を行う代わりに、編集されたPNGに対してだけ動作する"PNG crunch cache"を導入しました。

  • 通常の保存によってリソースのコンパイルが起こらないように修正しました。これらは実行時またはデバッグ時のみに発生します。(ADT12 によって導入されたパッケージングステップを無効にするビルドオプションは、現在はデフォルトになっています。)


ビルドシステムの変更点の完全な概要とサポートが必要な場合は、Android Tools Project サイトをご覧下さい。


一般的な改善




  • Android 開発環境の初期セットアップを助けるために ウェルカムウィザードを追加しました(詳細)。

  • ランチャーやメニューやタブのようなアイコンを作成を手助けする Android Asset Studio が統合されました(詳細)。

  • Logcat ビューが改良され、PIDと同様にアプリケーション名でログの表示とフィルタリングがサポートされました(詳細)。

  • SDK マネージャの UI が改良されました(詳細)。

  • 新しいプロジェクトと新しいXMLファイルウィザードが複数のページを持つように改良されました。サンプルプロジェクトはワークスペース内にコピーされるようになり、マスターコピーに影響を及ぼすことなく編集や削除が可能となりました(詳細)。

  • Eclipse GEFの依存性を改善しました。


XML と Java エディタ




  • Android のコーディングスタイルに準拠した全ての XML ファイルを整形する、新しい XML フォーマッターが追加されました。このフォーマッターは属性を推奨される順番で並び替えができ、レイアウトエディタで変更されたものを処理することが可能です。

  • XMLファイルの開いたタグと閉じたタグの間をジャンプすることができる、"Go to Matching"(CTRL+SHIFT+P) 機能を追加しました。

  • Macで "エンクロージング要素の選択" をサポートしました。

  • 文字列の中にキャレットが入っている時、文字列を抽出するクイックフィックスを追加しました(詳細)。

  • XML エディタのリターンキーを押す時に、自動インデント・アンインデントを自動的に行うことができる "スマートインデント" を改良しました(詳細)。


レイアウトエディタ




  • ドラッグとリサイズ操作のツールチップフィードバックを追加しました。例えば、relative レイアウト中をドラッグする時に、提案された制約が表示されます。リサイズの際は新しい範囲が表示されます(詳細)。

  • 厳密な警告を抑制する機能を追加しました(詳細)。

  • 子供のコンテナを削除してトップレベルまで移動し、ネームスペースとレイアウトの属性を必要に応じて変換する "Remove Container"(コンテナの削除)と呼ばれる視覚的なリファクタリングツールを追加しました。(詳細)

  • 子供が親を完全に覆ってしまい選択することが難しい場合に、親のプロパティにアクセスするためのコンテキストメニューをプル-ライトメニューに追加しました。

  • コンテキストメニューのプロパティ操作を改善しました。それぞれのビューの属性でよく設定されるものをメニューのトップにリストします。プロパティのメニューは最も最近設定された属性へのアクセスを提供し、属性は定義されたビューやレイアウトの属性のみ、または、全ての属性がアルファベット順で構成されます(詳細)。


バグ修正




  • 多くのバグの修正とマイナーな改善を行いました、特にいくつかのクリティカルなLinuxのバグを修正しました。






文責:技術部 瀬戸 直喜 





2011年10月13日木曜日

Bluetooth設定を切り替えて、Home画面とスクリーンOFF中の計測を行いました。

条件:
・壁紙設定:壁紙
・Wi-Fi設定:OFF
・Bluetooth設定:ON/OFF
・GPS設定:OFF
・バックグラウンドシンク設定:OFF
・Bluetooth設定"ON"の場合は、ペアリング確立後に計測



1.Home画面

Bluetooth設定OFFの波形です。
約0.10Aでした。







Bluetooth設定ONの波形です。
OFFの波形とあまり変わりませんでした。









2.スクリーンOFF中

Home画面で電源キー短押下しスクリーンOFFした状態で計測しました
Bluetooth設定OFFの波形です。
約2秒間隔で0.05Aを超えていますが、ほぼ0Aまで落ちています。








Bluetooth設定ONの波形です。
一定間隔で約0.02Aの波形が現れました。









3.まとめ

Bluetoothデバイスのスキャンが動いていない状態では、消費電流はあまり上昇しないことがわかりました。
スクリーンOFF中は一定間隔で約0.02Aの波形が現れました。
CPUもしくはBluetoothチップがスリープモードで動作中かもしれません。

Bluetooth設定ON/OFFの違いを確認する

Bluetooth設定を切り替えて、Home画面とスクリーンOFF中の計測を行いました。

条件:
・壁紙設定:壁紙
・Wi-Fi設定:OFF
・Bluetooth設定:ON/OFF
・GPS設定:OFF
・バックグラウンドシンク設定:OFF
・Bluetooth設定"ON"の場合は、ペアリング確立後に計測



1.Home画面

Bluetooth設定OFFの波形です。
約0.10Aでした。







Bluetooth設定ONの波形です。
OFFの波形とあまり変わりませんでした。









2.スクリーンOFF中

Home画面で電源キー短押下しスクリーンOFFした状態で計測しました
Bluetooth設定OFFの波形です。
約2秒間隔で0.05Aを超えていますが、ほぼ0Aまで落ちています。








Bluetooth設定ONの波形です。
一定間隔で約0.02Aの波形が現れました。









3.まとめ

Bluetoothデバイスのスキャンが動いていない状態では、消費電流はあまり上昇しないことがわかりました。
スクリーンOFF中は一定間隔で約0.02Aの波形が現れました。
CPUもしくはBluetoothチップがスリープモードで動作中かもしれません。
Related Posts Plugin for WordPress, Blogger...