2012年2月28日火曜日

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

MWC(Mobile World Congress)2012が今年も開幕しました。

MWCは、毎年スペインのバルセロナで行われているモバイル界最大級の展示会で、今年は2/27~3/1の4日間行われています。

今回は、その初日の様子と、Androidブースとdocomoブースを紹介したいと思います。

■会場全体の様子

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

展示はスペイン広場付近の4つの展示会場で行われており、東京ビックサイトの西館、東館すべてを合わせた広さよりも広い会場でした。

4日かけても全部見て回れる気がしません。

来場される方は、ビジネスパートナーを探したりとビジネス寄りな目的の方が多く、スーツ姿の方が目立ちました。

展示内容も、すぐにビジネスに展開できるようなソリューションや、次年度に発売される製品の紹介が多く見受けられます。

■Androidブース

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

Androidのブースでは、ゲームコンテンツや、HMD、ロボット、UFOキャッチャー、滑り台など、ゲームセンターのような体感コンテンツが前面に押し出されており、他のブースと比べると、商談する場というよりは実際に体で感じて楽しめるブースになっていました。

f:id:bs-android:20120228130426j:image:w360:left
ブース内の様子

f:id:bs-android:20120228130427j:image:w360:left
Androidで操作するUFOキャッチャー

f:id:bs-android:20120228130428j:image:w360:left
ドロイド君がスマートフォンをデコってました。

f:id:bs-android:20120228130429j:image:w360:left
カフェでは本物のアイスクリームサンドウィッチなどが無料で振る舞われていました。

f:id:bs-android:20120228133840j:image:w360:left
ゴーグルの右下にAndroidの画面を映し出すHMD。スキー中など手が使えない時に便利。

■docomoブース

f:id:bs-android:20120228130430j:image:w360:left
docomoの展示ブースは、近々リリースされるサービスが展示されていました。

丁寧に一つ一つのサービスを紹介いただいたので、掲載させていただこうと思います。

f:id:bs-android:20120228130432j:image:w360:left
世界のNFC規格に準拠することで、海外でおサイフケータイが使えたり、日本で海外のサービスが使えたりするローミングサービス。

f:id:bs-android:20120228130433j:image:w360:left
リアルタイムなテレビ放送の配信や、音楽、ゲームなどのコンテンツ配信を行うサービス。ソーシャルとリンクして他人の意見などを同時に見ることができたりするそうです。

2012春サービス開始予定。

f:id:bs-android:20120228130434j:image:w360:left
10分でバッテリーを充電できるホルダー。

f:id:bs-android:20120228130431j:image:w360:left
音声で情報を検索したり、端末を操作したりできるアプリ。

日本語に対応。

f:id:bs-android:20120228130435j:image:w360:left
複数の通信規格を一つのチップに集約することで、チップをより小さくできる。

f:id:bs-android:20120228130436j:image:w360:left
クレイドル側にも加速度センサー付きGPSを搭載することで、クレイドル装着時はトンネルの中でも正確な位置を表示できるようになります。

f:id:bs-android:20120228130437j:image:w360:left
天気、交通渋滞、試合結果など、複数の情報を一つの絵の中に表現することで、待ち受け画面を楽しく、きれいに見せることができる。

アバターみたいにアイテム課金で自分らしさが表現できるといいかもしれません。

f:id:bs-android:20120228130438j:image:w360:left
センサー付きのジャケットに入れることで、スマートフォンを体脂肪計や、気圧計、口臭センサーなどに使える。

赤外線センサーを付ければリモコンにもなりそうですね。


本日のレポートは以上です。




文責:技術部 梶井祐介

『MWC2012』1日目レポート

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

MWC(Mobile World Congress)2012が今年も開幕しました。

MWCは、毎年スペインのバルセロナで行われているモバイル界最大級の展示会で、今年は2/27~3/1の4日間行われています。

今回は、その初日の様子と、Androidブースとdocomoブースを紹介したいと思います。

■会場全体の様子

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

展示はスペイン広場付近の4つの展示会場で行われており、東京ビックサイトの西館、東館すべてを合わせた広さよりも広い会場でした。

4日かけても全部見て回れる気がしません。

来場される方は、ビジネスパートナーを探したりとビジネス寄りな目的の方が多く、スーツ姿の方が目立ちました。

展示内容も、すぐにビジネスに展開できるようなソリューションや、次年度に発売される製品の紹介が多く見受けられます。

■Androidブース

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

Androidのブースでは、ゲームコンテンツや、HMD、ロボット、UFOキャッチャー、滑り台など、ゲームセンターのような体感コンテンツが前面に押し出されており、他のブースと比べると、商談する場というよりは実際に体で感じて楽しめるブースになっていました。

f:id:bs-android:20120228130426j:image:w360:left
ブース内の様子

f:id:bs-android:20120228130427j:image:w360:left
Androidで操作するUFOキャッチャー

f:id:bs-android:20120228130428j:image:w360:left
ドロイド君がスマートフォンをデコってました。

f:id:bs-android:20120228130429j:image:w360:left
カフェでは本物のアイスクリームサンドウィッチなどが無料で振る舞われていました。

f:id:bs-android:20120228133840j:image:w360:left
ゴーグルの右下にAndroidの画面を映し出すHMD。スキー中など手が使えない時に便利。

■docomoブース

f:id:bs-android:20120228130430j:image:w360:left
docomoの展示ブースは、近々リリースされるサービスが展示されていました。

丁寧に一つ一つのサービスを紹介いただいたので、掲載させていただこうと思います。

f:id:bs-android:20120228130432j:image:w360:left
世界のNFC規格に準拠することで、海外でおサイフケータイが使えたり、日本で海外のサービスが使えたりするローミングサービス。

f:id:bs-android:20120228130433j:image:w360:left
リアルタイムなテレビ放送の配信や、音楽、ゲームなどのコンテンツ配信を行うサービス。ソーシャルとリンクして他人の意見などを同時に見ることができたりするそうです。

2012春サービス開始予定。

f:id:bs-android:20120228130434j:image:w360:left
10分でバッテリーを充電できるホルダー。

f:id:bs-android:20120228130431j:image:w360:left
音声で情報を検索したり、端末を操作したりできるアプリ。

日本語に対応。

f:id:bs-android:20120228130435j:image:w360:left
複数の通信規格を一つのチップに集約することで、チップをより小さくできる。

f:id:bs-android:20120228130436j:image:w360:left
クレイドル側にも加速度センサー付きGPSを搭載することで、クレイドル装着時はトンネルの中でも正確な位置を表示できるようになります。

f:id:bs-android:20120228130437j:image:w360:left
天気、交通渋滞、試合結果など、複数の情報を一つの絵の中に表現することで、待ち受け画面を楽しく、きれいに見せることができる。

アバターみたいにアイテム課金で自分らしさが表現できるといいかもしれません。

f:id:bs-android:20120228130438j:image:w360:left
センサー付きのジャケットに入れることで、スマートフォンを体脂肪計や、気圧計、口臭センサーなどに使える。

赤外線センサーを付ければリモコンにもなりそうですね。


本日のレポートは以上です。




文責:技術部 梶井祐介

2012年2月24日金曜日

Starting from now I will spend a few post talking about an app that I made shortly before starting at Brilliant Service, during my job search period. I think there are some implementations that might be interesting for other developers out there.

Take a look at iNippon in the iTunes Preview page here:  English  Japanese

In this post I'll share my experiences of implementing the UIPageViewController that is used in the new template Page-Based Application found in Xcode. For those of you who are not familiar with this, take a look at the iBooks app. The API for creating this beautiful and natural turning of pages is now made available using the UIPageViewController.

What the implementation in iNippon looks like can be seen in this screenshot.

iNippon, Today's view

Similar to UITableViewController, UIPageViewController takes a delegate and a datasource. Simply put, the datasource provide UIViewControllers for the UIPageViewController to display. The template in Xcode provides a fully functional implementation and it shouldn't be any problem to get ones head around how it works.

Problem
The template provided by Apple in Xcode creates new UIViewControllers on the fly when you start to turn the page. I started with this approach and it worked fine in the simulator and on the older generation iPod Touch and iPhone 3GS but on the iPhone 4 it was really slow and jerky. At first I thought this was weird but found the answer when removing the loading of the background image made it really fast and smooth. One might think that the iPhone 4 should be faster at loading images than the 3GS but in this case I used separate images sizes using the @2x suffix so the 3GS only loads an image that is 320x367 while the iPhone 4 uses an image that is 640x734 pixels, four times as much data as the lower resolution. Even though the iPhone 4 is faster it's not four times faster at this task, it seems.

Solution
So, have should we handle this? Some users might never turn the page while some users might use this functionality to flick through pages in a fast pace. Ten background images with different motives are used and loading them all into memory seems like a waste of valuable resources, especially considering most of them might not even be displayed. Remember memory is a valuable resource in mobile devices and by keeping our memory footprint low we keep other apps from being deallocated as well as improving our own loading time which will improve the overall user experience.

The solution came to be a compromise between fast page turning and memory usage. What I do is, in the datasource I keep an NSArray with 3 UIViewControllers, loaded and ready to be displayed. The one in the middle position is the one currently on screen, the others are the previous and the next page. If you turn a page the UIViewController at the next position is provided to the UIPageViewController and once the UIPageViewController has finished it's animations the next UIViewController is loaded and inserted into the array so that the array always contains three UIViewControllers. Of course, I have to keep the user from turning page again until the new UIViewController has loaded completely but this is easy done by deactivating the UIGestureRecognizers during this time. If the user takes the time to look through the content of the page, the new UIViewController will be loaded and ready well in time before the user turns page again. And as always, the edge case has to be handle separately when the user is on page zero and there are no more pages in back direction.

Utilize the UIPageViewController and create beautiful page-based applications you too. They provide a great user experience and make it fun to flick through pages.

iNippon Part 1

Starting from now I will spend a few post talking about an app that I made shortly before starting at Brilliant Service, during my job search period. I think there are some implementations that might be interesting for other developers out there.

Take a look at iNippon in the iTunes Preview page here:  English  Japanese

In this post I'll share my experiences of implementing the UIPageViewController that is used in the new template Page-Based Application found in Xcode. For those of you who are not familiar with this, take a look at the iBooks app. The API for creating this beautiful and natural turning of pages is now made available using the UIPageViewController.

What the implementation in iNippon looks like can be seen in this screenshot.

iNippon, Today's view

Similar to UITableViewController, UIPageViewController takes a delegate and a datasource. Simply put, the datasource provide UIViewControllers for the UIPageViewController to display. The template in Xcode provides a fully functional implementation and it shouldn't be any problem to get ones head around how it works.

Problem
The template provided by Apple in Xcode creates new UIViewControllers on the fly when you start to turn the page. I started with this approach and it worked fine in the simulator and on the older generation iPod Touch and iPhone 3GS but on the iPhone 4 it was really slow and jerky. At first I thought this was weird but found the answer when removing the loading of the background image made it really fast and smooth. One might think that the iPhone 4 should be faster at loading images than the 3GS but in this case I used separate images sizes using the @2x suffix so the 3GS only loads an image that is 320x367 while the iPhone 4 uses an image that is 640x734 pixels, four times as much data as the lower resolution. Even though the iPhone 4 is faster it's not four times faster at this task, it seems.

Solution
So, have should we handle this? Some users might never turn the page while some users might use this functionality to flick through pages in a fast pace. Ten background images with different motives are used and loading them all into memory seems like a waste of valuable resources, especially considering most of them might not even be displayed. Remember memory is a valuable resource in mobile devices and by keeping our memory footprint low we keep other apps from being deallocated as well as improving our own loading time which will improve the overall user experience.

The solution came to be a compromise between fast page turning and memory usage. What I do is, in the datasource I keep an NSArray with 3 UIViewControllers, loaded and ready to be displayed. The one in the middle position is the one currently on screen, the others are the previous and the next page. If you turn a page the UIViewController at the next position is provided to the UIPageViewController and once the UIPageViewController has finished it's animations the next UIViewController is loaded and inserted into the array so that the array always contains three UIViewControllers. Of course, I have to keep the user from turning page again until the new UIViewController has loaded completely but this is easy done by deactivating the UIGestureRecognizers during this time. If the user takes the time to look through the content of the page, the new UIViewController will be loaded and ready well in time before the user turns page again. And as always, the edge case has to be handle separately when the user is on page zero and there are no more pages in back direction.

Utilize the UIPageViewController and create beautiful page-based applications you too. They provide a great user experience and make it fun to flick through pages.

2012年2月14日火曜日

省電力評価
★★☆☆☆



アプリケーション概要
Google Chromeのモバイル版アプリです。
パソコン版Google Chrome と同期できる素敵なブラウザアプリです。




Android Market : https://market.android.com/details?id=com.android.chrome
Version : 0.16.4130.199



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



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



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



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



標準ブラウザと同じような波形でした。



Google検索の結果画面で上下に激しくスクロールを行いました。
標準ブラウザ(波形:白)とChrome Beta(波形:黄)の波形です。

  


上限値は同じぐらいですが、下限値がChrome Betaの方が高い値となりました。
安定化電源に表示された値は以下のようになりました。
標準ブラウザ … 約0.25A
Chrome Beta … 約0.30A

Chrome Betaの方が消費電流が高い!



次はGoogle画像検索の結果画面で上下に激しくスクロールを行いました。
標準ブラウザ(波形:白)とChrome Beta(波形:黄)の波形です。

  


Chrome Betaの波形(黄色)が被さって白い波形が見えずらくなってしまいました。
見えやすいように、色を逆転させました。


標準ブラウザ(波形:黄)とChrome Beta(波形:白)の波形です。



波形をみると、標準ブラウザの方が低いことがわかります。

安定化電源に表示された値は以下のようになりました。
標準ブラウザ … 約0.24A
Chrome Beta … 約0.30A

画像表示の画面でも、Chrome Betaの方が消費電流が高い結果となりました。



考察
Chrome Betaの方が消費電流が高い結果となりました。
Google社純正の2つのブラウザで、同じ端末上、同じwebkitを使用していても消費電流が異なることがわかりました。

アプリケーションの設計の違いが、消費電流の量に繋がってしまいます。
消費電流を意識した設計を心掛けるようにしたいものですね。

まだまだBeta版ということですので、消費電流の改善に期待します!

Chrome Beta

省電力評価
★★☆☆☆



アプリケーション概要
Google Chromeのモバイル版アプリです。
パソコン版Google Chrome と同期できる素敵なブラウザアプリです。




Android Market : https://market.android.com/details?id=com.android.chrome
Version : 0.16.4130.199



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



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



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



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



標準ブラウザと同じような波形でした。



Google検索の結果画面で上下に激しくスクロールを行いました。
標準ブラウザ(波形:白)とChrome Beta(波形:黄)の波形です。

  


上限値は同じぐらいですが、下限値がChrome Betaの方が高い値となりました。
安定化電源に表示された値は以下のようになりました。
標準ブラウザ … 約0.25A
Chrome Beta … 約0.30A

Chrome Betaの方が消費電流が高い!



次はGoogle画像検索の結果画面で上下に激しくスクロールを行いました。
標準ブラウザ(波形:白)とChrome Beta(波形:黄)の波形です。

  


Chrome Betaの波形(黄色)が被さって白い波形が見えずらくなってしまいました。
見えやすいように、色を逆転させました。


標準ブラウザ(波形:黄)とChrome Beta(波形:白)の波形です。



波形をみると、標準ブラウザの方が低いことがわかります。

安定化電源に表示された値は以下のようになりました。
標準ブラウザ … 約0.24A
Chrome Beta … 約0.30A

画像表示の画面でも、Chrome Betaの方が消費電流が高い結果となりました。



考察
Chrome Betaの方が消費電流が高い結果となりました。
Google社純正の2つのブラウザで、同じ端末上、同じwebkitを使用していても消費電流が異なることがわかりました。

アプリケーションの設計の違いが、消費電流の量に繋がってしまいます。
消費電流を意識した設計を心掛けるようにしたいものですね。

まだまだBeta版ということですので、消費電流の改善に期待します!

2012年2月13日月曜日

省電力評価
★★★☆☆



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





Android Market : 登録なし
Version : 4.0.3-239410



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



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



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





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



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



Google検索の結果画面で上下に激しくスクロールを行いました。
白い波形がGB版、黄色い波形がICS版です。
なんと、ICSの方が消費電流が低いことが解りました。







次はGoogle画像検索の結果画面で上下に激しくスクロールを行いました。
白い波形がGB版、黄色い波形がICS版です。
なんとなんと、さらにICSの方が消費電流が低いことが解りました。





波形をみると何となく画像検索結果画面(=画像が多い画面)の方が消費電流が低いように見えたので、波形を重ねてみました。
白い波形が文字列の多いGoogle検索の結果画面、黄色い波形が画像の多いGoogle検索画像の結果画面です。




Google検索結果画面よりGoogle画像検索結果画面の方が若干、消費電流が低いようです。




考察
GB版よりICS版の方が消費電流が低いことが解りました。
さらに画像表示の消費電流が大きく下がっています。
ドラッグ中の画像再描画に関する処理に改善対策が行われていると思います。
これは注目すべき改善点です。

標準ブラウザ Android4.0.3版

省電力評価
★★★☆☆



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





Android Market : 登録なし
Version : 4.0.3-239410



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



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



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





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



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



Google検索の結果画面で上下に激しくスクロールを行いました。
白い波形がGB版、黄色い波形がICS版です。
なんと、ICSの方が消費電流が低いことが解りました。







次はGoogle画像検索の結果画面で上下に激しくスクロールを行いました。
白い波形がGB版、黄色い波形がICS版です。
なんとなんと、さらにICSの方が消費電流が低いことが解りました。





波形をみると何となく画像検索結果画面(=画像が多い画面)の方が消費電流が低いように見えたので、波形を重ねてみました。
白い波形が文字列の多いGoogle検索の結果画面、黄色い波形が画像の多いGoogle検索画像の結果画面です。




Google検索結果画面よりGoogle画像検索結果画面の方が若干、消費電流が低いようです。




考察
GB版よりICS版の方が消費電流が低いことが解りました。
さらに画像表示の消費電流が大きく下がっています。
ドラッグ中の画像再描画に関する処理に改善対策が行われていると思います。
これは注目すべき改善点です。
Nexus Sにて再度、明るさ設定の確認を行いました。
GingerBreadとIce Cream Sandwichで消費電流の違いがあるか確認します。

条件:
・壁紙設定:壁紙
・Wifi設定:OFF
・bluetooth設定:OFF
・GPS設定:OFF
・バックグラウンドシンク設定:OFF

「画面の明るさ」の変更方法:
・電源管理ウィジェットによる変更


1.「画面の明るさ」設定:レベル1

電源管理ウィジェットにて一番暗い設定にしました。




2.「画面の明るさ」設定:レベル2

電源管理ウィジェットにて1段階目の明るさ。




3.「画面の明るさ」設定:レベル3

電源管理ウィジェットにて2段階目の明るさ。






まとめ

各レベルと電流値を表にしました。

画面の明るさ電流値
レベル10.12A
レベル20.15A
レベル30.25A


以前、GingerBread版で計測した結果と比べると、ほぼ同じ値となりました。
画面設定「画面の明るさ」の違いを確認する - オシロスコープの波形
http://bs-power-save-project.blogspot.com/2011/10/blog-post.html


「画面の明るさ」に関しては、OSによる違いはありませんでした。

画面設定「画面の明るさ」の違いを確認する - Android4.0.3版

Nexus Sにて再度、明るさ設定の確認を行いました。
GingerBreadとIce Cream Sandwichで消費電流の違いがあるか確認します。

条件:
・壁紙設定:壁紙
・Wifi設定:OFF
・bluetooth設定:OFF
・GPS設定:OFF
・バックグラウンドシンク設定:OFF

「画面の明るさ」の変更方法:
・電源管理ウィジェットによる変更


1.「画面の明るさ」設定:レベル1

電源管理ウィジェットにて一番暗い設定にしました。




2.「画面の明るさ」設定:レベル2

電源管理ウィジェットにて1段階目の明るさ。




3.「画面の明るさ」設定:レベル3

電源管理ウィジェットにて2段階目の明るさ。






まとめ

各レベルと電流値を表にしました。

画面の明るさ電流値
レベル10.12A
レベル20.15A
レベル30.25A


以前、GingerBread版で計測した結果と比べると、ほぼ同じ値となりました。
画面設定「画面の明るさ」の違いを確認する - オシロスコープの波形
http://bs-power-save-project.blogspot.com/2011/10/blog-post.html


「画面の明るさ」に関しては、OSによる違いはありませんでした。

http://upload.wikimedia.org/wikipedia/en/0/0c/Xcode_icon.pngXcode has great code-completion (or auto-completion) and by utilizing this wisely we can save ourselves lots of trouble. A good thing to do at the beginning of every app development is to create an global.h file to hold all constants, strings, etc, and include this in all the classes where needed. Even though it might not feel necessary at the start of a small project, as new functionality is added the amount of constants, strings, etc, needed quickly grows and it becomes difficult to remember them all. By collecting them all in one place, we make configuration, updates and changes very easy to do.


My Global.h can look something like this:

// NSUserDefaults
#define kUDMusicState           @"MusicState"           // BOOL
#define kUDSoundState           @"SoundState"           // BOOL
#define kUDNrOfPlayers          @"NrOfPlayers"          // int
#define ...

// Notification Center
#define kNCFacebookLogin        @"FacebookDidLogin"
#define kNCFacebookLogout       @"FacebookDidLogout"
#define ...

// Images
#define kImageHelpGamePhone     @"helppageGame"        
#define kImageHelpGamePad       @"helppageGame~pad"
#define ...

Now, when somewhere in my code I need to access NSUserDefaults. I know that all my NSUserDefault keys start with kUD... so when I type kUD all the keys are presented to me and I can easily choose from the menu the one I need.
















Same when I need an images, simply typing kImage... and code-completion gives my a list of all my defined image names. No more going back to check what the filename was or looking for bugs that are caused by wrong spelling in the key string (maybe I'm the only one who get this kind of bug *_* )

If Xcode doesn't show the auto-completion list, try hitting ESC. If still no suggestion comes up, the needed file is not included or you're trying write something that doesn't belong there. On rare occasions the auto-completion systems fails to work properly but building the project should solve that.

If you have any good tip on how to make the most of Xcode, please let me know!

Utilize Auto-Completion in Xcode


http://upload.wikimedia.org/wikipedia/en/0/0c/Xcode_icon.pngXcode has great code-completion (or auto-completion) and by utilizing this wisely we can save ourselves lots of trouble. A good thing to do at the beginning of every app development is to create an global.h file to hold all constants, strings, etc, and include this in all the classes where needed. Even though it might not feel necessary at the start of a small project, as new functionality is added the amount of constants, strings, etc, needed quickly grows and it becomes difficult to remember them all. By collecting them all in one place, we make configuration, updates and changes very easy to do.


My Global.h can look something like this:

// NSUserDefaults
#define kUDMusicState           @"MusicState"           // BOOL
#define kUDSoundState           @"SoundState"           // BOOL
#define kUDNrOfPlayers          @"NrOfPlayers"          // int
#define ...

// Notification Center
#define kNCFacebookLogin        @"FacebookDidLogin"
#define kNCFacebookLogout       @"FacebookDidLogout"
#define ...

// Images
#define kImageHelpGamePhone     @"helppageGame"        
#define kImageHelpGamePad       @"helppageGame~pad"
#define ...

Now, when somewhere in my code I need to access NSUserDefaults. I know that all my NSUserDefault keys start with kUD... so when I type kUD all the keys are presented to me and I can easily choose from the menu the one I need.
















Same when I need an images, simply typing kImage... and code-completion gives my a list of all my defined image names. No more going back to check what the filename was or looking for bugs that are caused by wrong spelling in the key string (maybe I'm the only one who get this kind of bug *_* )

If Xcode doesn't show the auto-completion list, try hitting ESC. If still no suggestion comes up, the needed file is not included or you're trying write something that doesn't belong there. On rare occasions the auto-completion systems fails to work properly but building the project should solve that.

If you have any good tip on how to make the most of Xcode, please let me know!

2012年2月7日火曜日



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


Androidアプリケーション、デザイナーとプログラマーのハッカソン vol2 が開催されました。


前回に引き続き第二弾です。


従来のハッカソンではプログラマーがメインとなるイベントですが、デザイナーさんも交えてAndroidアプリを作りました。


チーム分け


事前に用意したネタごとにチームを作りました。


時計やライブウォールペーパーなど、デザイナーさんの力が光りそうなアプリがあります。


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


ハッカソンの様子


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


各チーム席をくっつけ、ハッカソンスタートです


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


ライブウォールペーパーを作るチームは、すでにあるライブウォールペーパーを参考にしているようです


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


ノートにはラフ画が書かれています


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


ガシガシ画像作ってます


こういうソフト使える人に憧れます!


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


デザイナーと意思を疎通させるためには、手書きも便利ですね


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


発表資料を作っているようです


発表


チーム DQN 「DQN Clock」

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


メンバー




f:id:bs-android:20120204171510j:image:h400


カラフルでユニークな時計を作られていました。


マスコットキャラクターのDQNちゃん(ドキュンちゃん)がかわいく手を振ります




チーム 小学3年生 「電卓アプリ」

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


メンバー




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


見た目は普通だけど、なんと占いまでできてしまう電卓を作られていました。


占い機能と見た目はできたけど、ハプニングにつき完成には至りませんでした。


発表者曰く、「電卓は鬼門だから次からは辞めとけ」だそうですw




チーム MemoPad「MemoPad」

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


メンバー




  • @zaki50(プログラマー)

  • @b0ner_jp(プログラマー)

  • @mstssk(プログラマー)

  • 匿名希望(デザイナー)


このチームは@zaki50 さんがAndroidMarketで公開されている


MemoPadのデザインを、より良くしようと集結しました。


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


色を選ぶUIが、より分かりやすくなりました。


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


さらに描いた絵をNFCを利用してSmartTagに書きこむ機能まで追加!


すごい!




チーム La battle 「La 合戦」

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


メンバー




チーム内に歴史が好きな人がいた事と、フランス人と仲良くなりたいという人がいたので


フランス人と仲良くなるための合戦ゲームを作っていました。


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


こんな感じで手裏剣を投げ合って


敵の大将を倒すと…


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


うちとったりーと表示されます


私もフランス人と仲良くなれるよう、遊んでみたいです。




チーム 左官「ライブウォールペーパー -天気-」

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


メンバー




チーム左官は天気を表示するライブウォールペーパーを作りました。


和風テイストでとても綺麗です。


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


さらに画面をタッチすると、なぜか手裏剣が空を舞います


某合戦チームの影響だそうですw




チーム オレオレ詐欺 「oreoreゲーム」

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


メンバー




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


チームオレオレ詐欺は、さめがめというゲームを作っていました。


この短時間で基本的なゲームの部分が完成していました。素晴らしい!


石を消すと気持ちいい音が鳴るのも特徴でした。音はなかなか気づかないですが重要ですよね。


投票


全員に一人5票で投票してもらいました。


結果は…




  • 1位 オレオレ詐欺 oreoreゲーム 41票

  • 2位 La battle La合戦 30票

  • 3位 MemoPad 27票


おめでとうございます!


その他


Androidアプリ デザイナーとプログラマーのハッカソン vol.2 - Togetter


http://togetter.com/li/253227


参加者リスト


https://twitter.com/#!/bs_android/dpthon2




文責:技術部 山下 智樹





Androidアプリケーション、デザイナーとプログラマーのハッカソン vol2が開催されました。



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


Androidアプリケーション、デザイナーとプログラマーのハッカソン vol2 が開催されました。


前回に引き続き第二弾です。


従来のハッカソンではプログラマーがメインとなるイベントですが、デザイナーさんも交えてAndroidアプリを作りました。


チーム分け


事前に用意したネタごとにチームを作りました。


時計やライブウォールペーパーなど、デザイナーさんの力が光りそうなアプリがあります。


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


ハッカソンの様子


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


各チーム席をくっつけ、ハッカソンスタートです


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


ライブウォールペーパーを作るチームは、すでにあるライブウォールペーパーを参考にしているようです


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


ノートにはラフ画が書かれています


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


ガシガシ画像作ってます


こういうソフト使える人に憧れます!


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


デザイナーと意思を疎通させるためには、手書きも便利ですね


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


発表資料を作っているようです


発表


チーム DQN 「DQN Clock」

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


メンバー




f:id:bs-android:20120204171510j:image:h400


カラフルでユニークな時計を作られていました。


マスコットキャラクターのDQNちゃん(ドキュンちゃん)がかわいく手を振ります




チーム 小学3年生 「電卓アプリ」

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


メンバー




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


見た目は普通だけど、なんと占いまでできてしまう電卓を作られていました。


占い機能と見た目はできたけど、ハプニングにつき完成には至りませんでした。


発表者曰く、「電卓は鬼門だから次からは辞めとけ」だそうですw




チーム MemoPad「MemoPad」

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


メンバー




  • @zaki50(プログラマー)

  • @b0ner_jp(プログラマー)

  • @mstssk(プログラマー)

  • 匿名希望(デザイナー)


このチームは@zaki50 さんがAndroidMarketで公開されている


MemoPadのデザインを、より良くしようと集結しました。


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


色を選ぶUIが、より分かりやすくなりました。


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


さらに描いた絵をNFCを利用してSmartTagに書きこむ機能まで追加!


すごい!




チーム La battle 「La 合戦」

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


メンバー




チーム内に歴史が好きな人がいた事と、フランス人と仲良くなりたいという人がいたので


フランス人と仲良くなるための合戦ゲームを作っていました。


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


こんな感じで手裏剣を投げ合って


敵の大将を倒すと…


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


うちとったりーと表示されます


私もフランス人と仲良くなれるよう、遊んでみたいです。




チーム 左官「ライブウォールペーパー -天気-」

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


メンバー




チーム左官は天気を表示するライブウォールペーパーを作りました。


和風テイストでとても綺麗です。


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


さらに画面をタッチすると、なぜか手裏剣が空を舞います


某合戦チームの影響だそうですw




チーム オレオレ詐欺 「oreoreゲーム」

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


メンバー




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


チームオレオレ詐欺は、さめがめというゲームを作っていました。


この短時間で基本的なゲームの部分が完成していました。素晴らしい!


石を消すと気持ちいい音が鳴るのも特徴でした。音はなかなか気づかないですが重要ですよね。


投票


全員に一人5票で投票してもらいました。


結果は…




  • 1位 オレオレ詐欺 oreoreゲーム 41票

  • 2位 La battle La合戦 30票

  • 3位 MemoPad 27票


おめでとうございます!


その他


Androidアプリ デザイナーとプログラマーのハッカソン vol.2 - Togetter


http://togetter.com/li/253227


参加者リスト


https://twitter.com/#!/bs_android/dpthon2




文責:技術部 山下 智樹





Related Posts Plugin for WordPress, Blogger...