どこかのPCで使ってたHDDを取り出して、新しいPCで使う場合に、旧HDDに入っているWindowsディレクトリなんかが削除できない場合があったり、なかったり。。。
所有権とかをイジっても削除できないので色々調べていたら、確実に削除できる方法を見つけた。
DOSプロンプトで・・・
takeown /r /f F:￥abc
と入力した後に・・・
icacls F:￥abc /grant Everyone:F /T
と入力すると、なんかダーっと表示された後に、ディレクトリが削除可能になる。
コマンドの意味は調べてないけど、これで削除できるようになったから良いや！
バージョン管理システム「git」サーバーを構築したので、その備忘録。
サーバー環境は外部公開用サーバー(OSはCentOS)で、固定IPにより運営しているサーバーとなります。
１．gitデーモンのインストール
yumを使ってgitデーモンをインストールする
yum -y install git git-daemon git-all git --version
２．/etc/xinetd.d/gitの編集
vi /etc/xinetd.d/git
でgitファイルを編集する。
編集内容は
disable = yes
を
disable = no
に変更するだけ。
３．Xinetdの再起動
/etc/rc.d/init.d/xinetd restart
４．リポジトリ作成
cd /var/lib/git/ mkdir 自由にgitの名称を付与する cd 上記で作成したgit名称のディレクトリ git --bare init --shared chown -R USERGROUP:USERNAME *
“git –bare init –shared”を実行することで、そのディレクトリにリポジトリを作成する
その後、作成されたファイルに権限を適切に付与してあげる。
と、これだけでリポジトリが作成されます。
ssh経由でgitとやりとししたいので、sshdがインストールされている事を確認してください。
インストールされていない場合は・・・
yum -y install openssh-server yum -y install openssh-clients vi /etc/ssh/sshd_config -> 適切に編集して /etc/rc.d/init.d/sshd restart
でsshdをインストールすること。
これで、”ssh://USERNAME@SERVER_IP:SSHD_PORT/var/lib/git/git名”でgitを公開することができます。
(ポートとかのセキュリティもチェックssh接続なので、ポート22を開放してください)
次にAndroidStudioからgitへの新規ソースコード登録と更新手順について。。
１．プロジェクトを作成したい場合は新規にプロジェクトを作成する。
２．プロジェクトディレクトリ直下に存在する.gitignoreを以下のように編集する
.DS_Store # built application files *.apk *.ap_ # files for the dex VM *.dex # Java class files *.class # generated files bin/ gen/ # Local configuration file (sdk path, etc) local.properties # Android Studio .idea/ .gradle /*/local.properties /*/out /*/*/build /*/*/production *.iml *.iws *.ipr *~ *.swp
３．AndroidStudioで以下の操作を行う。
VCS -> Import into Version Control -> Create git repository
(このとき、Projectツリーにして、プロジェクト名が選択されていることが望ましい)
ルートディレクトリを選択する画面になるので、プロジェクトのルートディレクトリが選択されていることを確認する。
(選択されていない場合は、プロジェクト名のディレクトリをしっかりと選択する)
次に
VCS -> Git -> Add
VCS -> Git -> Commit DIrectory
を立て続けに選択する
コメントを入れるダイアログが表示されるので、適当にコメントを入れてCommitボタンをクリック。
４．DOSプロンプトから以下の操作を実施する
cd /プロジェクトディレクトリへのパス git remote add origin ssh://USERNAME@SERVER_IP:SSHD_PORT/var/lib/git/git名 git push -u origin --all
これで、Gitサーバーにソースコードが登録される。
以降はAndroidStudioのAddとCommit DirectoryとPushを駆使すればソースコードをサーバーにアップすることができる。
アップされたソースコードから新規にAndroidStudioで開発を始めたい場合は以下の通り。
１．AndroidStudioを開き以下の操作を行う
Check out project from Version Control
(gitを選択)
２．Clone Repositoryというダイアログに以下のように入力する
Vcs Repository URL: ssh://USERNAME@SERVER_IP:SSHD_PORT/var/lib/git/git名
そのほかは自動で入力される
その状態でCloneボタンをクリック
途中でsshのパスワードを求められるので入力する
３．Checkout From Version Controlというダイアログが表示される
Yesボタンをクリック
４．Import Project from Gradleというダイアログが表示される
OKボタンをクリック
５．これで少し経つとソースコードをダウンロードし開発が始められるようになります。
とりあえず備忘録ということで。
これでソース管理が楽になる。。。はず？
外での作業でも使えるような、それなりのスペックのノートパソコンを持ってないので、仕方なくMacBookAirにMacOSとWindowsを混在させて、どんな作業にでも即座に対応できるようにしました。(VPN接続とか、使い込んでいるテキストエディタとかはMacでは使えず、Windowsを使いたくなるときがあるので。。。)
インストール作業はもの凄く簡単で、MacOSにbootcampというアイコンがあるので、それをクリックして、ドライバーCDを作成して、パーティションを切って、Windows7のCDを入れるだけで完了でした。
なお、パーティションを切るときに、いままで一度も使った事が無い領域でしか確保できない為、当初は45GBの容量を確保する予定でしたが、30GBしか切り出すことが出来ませんでした。(こうなってしまった場合は、TimeMachineを使ってデータのバックアップを取った後にOSのクリーンインストールを実施して、再度データを戻せば、その直後であれば空き領域から好きなだけWindowsに割り振ることが可能になります。・・・って、さらっと説明文が書いてあったけど、詳しい人じゃないと、そこまでやらんよなぁ・・・)
で、optionキーを押しながらMacを起動すると、いちいちカッコいいブートセレクターが表示されます。
ここで、Windowsを選択するだけで、憧れのWindowsがMacで動きます。
Windowsインストール後には、Apache＋PHPと、Java/Eclipse/Tomcatをインストールし、PHPかJavaなら即座に開発できるようにセットアップしておきました。
これで、30GBの容量のうち20GBを消費しましたが。。。
キー配置の違いから、一部使いにくい部分もありますが、ここまで動けば大助かりという感じで、これから重宝しそうです。
HTML5ではドラッグ＆ドロップでファイルをローカル環境にコピーすることができるようになりました。
既にネット上ではドラッグ＆ドロップのサンプルをよく見かけるようになりましたが、固定ファイルのダウンロードのサンプルのみで、テキスト等を入力し、それをそのままテキストファイルとしてダウンロードするというサンプルが見当たらなかったので、自分で作成してみました。
動作確認はChromeのみで行っており、Chromeは起動オプション(–allow-file-access-from-files)を付与してあげないと、ローカル環境への書き込みを行ってくれない点に注意してください。
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<script type="text/javascript">
function onSaveTest()
{
var sampleTextareaObj = document.getElementById("sampleTextarea");
var bb = new (window.BlobBuilder || window.WebKitBlobBuilder)();
bb.append(sampleTextareaObj.value);
var blob = bb.getBlob();
var blob_url = '';
if (window.createObjectURL)
{
blob_url = window.createObjectURL(blob);
}
else if (window.createBlobURL)
{
blob_url = window.createBlobURL(blob);
}
else if (window.webkitURL.createObjectURL)
{
blob_url = window.webkitURL.createObjectURL(blob);
}
document.getElementById('hoge').innerHTML = '<a id="file_download" href="' + blob_url + '" target="_blank">file</a>';
document.getElementById("file_download").addEventListener("dragstart", function (e)
{
e.dataTransfer.setData("DownloadURL", "text/plain:test.txt:" + blob_url);
}, false);
}
</script>
</head>
<body>
<textarea id="sampleTextarea" style="width:400px;height:200px;"></textarea><br>
<input type="button" value="保存" onclick="onSaveTest();"><br>
<div id="hoge"></div>
</body>
</html>
dragstartイベントの定義内で”test.txt”とファイル名を指定している部分を動的にしてあげることで、ダウンロードするファイルのファイル名も自由に設定できます。
これからはHTML5が主流になってくると思いますが、いまだにローカルPCとHTML間でのドラッグ＆ドロップという操作に違和感が・・・
自宅サーバ－で開発したアプリをレンタルサーバーにインストールしたところ、IEからjQuery.uploadで画像をアップロードする処理が正常に動作しないという現象に遭遇しました。
不思議なことに、ChromeやFirefoxでは全く問題なく動作し、自宅サーバーに接続している限りはIEでも正常に動作します。
アプリの概要としては、よくあるユーザー情報登録系の処理で、利用者の写真をアップロードする際に、画面を更新せずともアップした写真が反映される仕組みの為にjQuery.uploadを使っていました。
また、この部分はライブラリ化されており、過去にも同じ仕組みを使ってプログラムを開発していたので、何が原因なのか分かりませんでした。
早速IEのデバッガを使って調査してみると、handleData関数の最初の処理で躓いていることが分かりました。
if ($.isXMLDoc(contents) || contents.XMLDocument) {
return contents.XMLDocument || contents;
}
このような処理があり、正常時はここのreturnでサーバーから返却されたXMLがコールバック関数に戻されるようになっています。
しかし、あるサーバーとIEを組み合わせると、このif文の条件に合致せず、その後処理となる戻ってきた文字列をXMLにパースするという処理に流れてしまっていることが判明しました。
(このことから、jQuery.uploadでアップロード処理までは完了しており、その戻り値となるXMLが正常に取得できないということが判明)
ここでパースされる文字列は、単純にサーバーから戻されたXML値が文字列になっているだけかと思ったのですが、それならXMLパース処理で正常にXMLに変換されエラーになることもありません。
ということで調べてみると、ここに渡される文字列は、XMLをIEで表示した際にIEが自動的に加工してしまうHTML形式になっていることも分かりました。
もちろんHTML文字列なので、XMLパース処理は失敗となります。
対応策として、HTML文字列となってしまったXMLから不要なタグを取り除き、XMLに戻してあげるしかありません。
XMLに格納されてくる文字については、こちらが作成したサーバー側の処理で返却する文字列なので、特殊文字等は存在しないことが保障されているので、次のような対応を取りました。
(parseXml関数内のXMLパース処理後に追加)
if (xml.xml == "")
{
text = text.stripTags();
text = unescapeHTML(text);
text = replaceAll(text," ","");
text = replaceAll(text,"-<","<");
xml.loadXML(text);
}
また、上記処理で使うunescapeHTML関数も以下のように定義しました。
function unescapeHTML(text)
{
var div = document.createElement('div');
div.innerHTML = text;
return div.childNodes[0] ? (div.childNodes.length > 1 ?
$A(div.childNodes).inject('', function(memo, node) { return memo+node.nodeValue }) :
div.childNodes[0].nodeValue) : '';
}
これによって、IEによってHTML化されたXMLを素のXMLに戻し、この文字列をXMLパースすることでXMLとして扱うことが出来るようになりました。
結果は正常に動作しました・・・が、どうもしっくりこない結果に終わりました。
そもそも、サーバが違う(細かく言えばPHPのマイナーバージョンが少し違う程度)でここまで違う動作をするもんかと・・・
IE9に搭載されている非常に強力なデバッガのおかげで無事(?)解決することができましたが、いまだに少し疑問の残る結果とまりました。
これまで記事にしてきたセッションと「Android Open Accessory APIとADK」「HTML5とFLASHを比較する：Youtube動画を高速化するテクノロジー」に参加させて頂きました。
全てのセッションに参加すると、展示コーナー等は一切見る時間が無かったということは、全てのセッション終了後の気付いたという・・・
最後にイグナイトに参加。
初参加だったので、イグナイトって何だろう？って感じだったのですが、今までのマジメな内容で行われてきた内容から一転、笑いの起きる内容ばかりでとても楽しめました。
特に、DevQuizの回答では、「Google社員は全部解いてません」と普通に公表しちゃうあたりがとても面白かったです。
ということで、全体的に物凄く勉強になったイベントでした。
地方でしがないプログラマーをやってる自分にとって最新技術に触れる機会というのはとても大切で、「新しい技術を使ってなんかしてやろう！」という気持ちになりました。
でも、GDDの参加者の皆様は基本的に同じような事を考えていると思うので、ライバルがいっぱいという感じですね。
とりあえずHTML5とAndroid4.0をメインにこれから勉強していこうと思いました。
最後にGDDで貰えた「Zeemote JS1 H」ですが、前から欲しかったもので、開封してこれが出てきた時には内心で凄く喜びました。
このコントローラーをIS03に接続してみたら、うんともすんとも動かなかったので、結局MacBook Airのプレゼン時のマウスとして使っています。
これを有効利用する為にも、Androidタブレットが欲しい！！(笑)
今回のGDDで一番聞きたかったセッションが、このHTML5のオフライン機能でした。
ちょうどWebStrageのプログラムを作ったばかりだったので、他のセッションよりも理解しやすかった内容でしたが、内容がいっぱいあった為、ついていくのに必死だった部分もあります。
オフライン機能で動作しているサイトのデモ
・AngryBirds
・NewyorkTimes
オフライン機能とは？
・インターネット回線が繋がっていなくても起動できる
・インターネット回線が繋がっていなくても動く
・インターネット回線が繋がっていなくてもデータの保存ができる
・インターネット回線が繋がってもデータの矛盾が発生しない
ローカル環境へのデータ保持方法としてWebStrage(localStrage/sessionStrage)の紹介
・構造化されていないデータ(文字列データ)の保存しかできない
・構造化されているものを保存するのであればJSONで文字列に変換する
・同期型のAPIである(処理を行っている間は何もできない)
・localStrageはブラウザを閉じてもデータが残るが、sesionStrageは残らない
・sessionStrageは新しいウインドウやタブを開いた時点で異なるデータ領域となる(一時的なデータの退避として使う)
ローカル環境へのデータ保持方法としてIndexedDBの紹介
・構造化されたデータの保存に向いてる
・構造型データをそのまま保存できる
・スキーマがなくSQLも使用できない
・今のところ構造化データを保持したいならこの方法しかない
・インデックスを使って検索を行う
・現在はChrome/Firefoxのみ対応している
・非同期型のAPIである
・イテレータにも対応している
ローカル環境へのデータ保持方法としてWebSQLの紹介
・非推奨
・モバイル機器がターゲットの場合はその限りではない
(モバイルはwebKitベースのブラウザなのでIndexedDBが使えない)
・将来的にPC系のブラウザには実装されないだろう
静的リソースの保存について(HTMLとかJSとかCSSをローカルに保存する)
・AppCacheを使う
・アプリケーションをまるごとローカルにキャッシュできる
・マニフェストファイルを記述するだけで自動的にローカルに保存される
・サーバへのリクエストが飛ばなくなるので動作も高速化される
・モバイルでのサポート率が高い
・マニフェストはHTMLのタグに記述
・マニフェストファイルの構造はキャッシュ/フォールバック/ネットワークに分けられる
・本体となるHTMLはマニフェストファイルの内容に関係なく必ずキャッシュされる
・マニフェストファイルの文法が間違っているとキャッシュされないのでチェック(http://manifest-validator.com/)すること
・コンテントタイプはしっかり指定すること
・マニフェストファイルを１文字でも変更すればローカルに再取込される
・jsからマニフェストの状況が取得できる
・manifestRという生成ツールがある(http://westciv.com/tools/manifestR/)
バイナリデータの保存
・FileSystemAPI
・ディレクトリを持ったファイルシステム上にデータをファイルとして保存できる
・OSの持つファイルを操作できるわけではない
・サンドボックス化されている為、他のオリジンからは切り離されている
・画像/音声/動画などのバイナリデータ保存に最適
・URLを使って直接参照が可能
・非同期のAPI
・window.requestFileSystemでファイルサイズを指定するが、今のところChromeでは意味がない
ファイルURLを作る方法
・DataURLを使用する
・BlobURLを使用する
・FileSystemのURL(filesystem:)を使用する
データの同期について
・オンライン時/オフライン時のそれぞれのデータの同期を行う
・オンラインバージョン・オフラインバージョンの起動処理を分ける
・サーバサイドに機能を補完するファイルを用意しておき、オフライン時にフォールバックさせる
・テンプレートを使ってjsでパース・フィル
データの同期のSharedWorkerを使う
・接続状況を一元管理できる
・ウィンドウをまたいで使用してもデータの一貫性が保てる
・サーバー通信など、一部のコードを集中管理することで、複数ウィンドウにまたがったアプリのメモリ使用量を節約できる
・オンライン/オフライン状況の取得デモ
オフライン機能を使ってアプリのパフォーマンスアップ
・Cookieの代わりにWebStrageを使う
・サーバーの代わりにクライアント側のDBを使う
・オフラインアプリだけでなく、オンラインアプリでもAppCacheを使う
・バイナリファイルをブラウザで保存する
オフライン機能でのデバック
・chrome://appcache-internals/
・chrome://blob-internals/
・chrome://quota-internals/
ブラウザのサポート状況/Polyfillについて等、役立つ情報について
超人気のセッションだったらしく、立ち見(とは言っても通訳席の前の空きスペースに無理やり座ってました・・・)での参加となりました。
よって、このセッションのみ写真が一切ありません。
HTML5の機能を中心に様々なデモを織り交ぜた、今回参加した中で一番面白かったセッションでもあります。
モダンなWEBアプリとは？
・クラウドのデータ＋リッチなUI(ネイティブ＋デスクトップのリッチ環境)で構築する
・これを構築するにはHTML5が最適
・画面全体に背景を設定する等の見た目も大事
・既存のアプリのHTML5バージョンを作る気持ちで、UIなどは統一する
ここでIOReaderのデモを見せながら
・１つのアプリが様々なデバイスで動くように作ってある
・デスクトップPCならキーボードで操作/タブレットならタッチ操作/携帯端末ならジェスチャーで操作などを考慮
・画面スクロールに対応したURLの変更にも対応している
・デバイス別の動作の違いはJS・CSSのみで切り分けていて、メインとなる部分は全て共通化されている
フレームワークの紹介
[MVC Franeworks]
・SPROUTCORE
・Backbone.js
・ExtJS4
[CSS Frameworks]
・LESS
・Sass
優れたUIを作成するには？
・ユーザーはログイン等の操作も面倒だと思っているのOpenIDを使うのが良い
・Google Identity Toolkitの紹介
・画面サイズによる端末切り替えのデモ(様々な解像度のデバイスに対応する為にMediaQueryを使用する)
・formfactorの紹介(http://formfactorjs.com/)
複数ファイルアップロードのデモ(ディレクトリ単位でのファイルファイルアップロード等)
・以下の記述で実装可能
<input type="file" id="dir-select" webkitdirectory />
ブラウザからデスクトップ/デスクトップからブラウザへのファイルドラッグ＆ドロップ
・PDFファイルをブラウザからデスクトップにドロップするデモ
・オブジェクトに対してURLを生成することができる(createObjectURL)
・デスクトップからブラウザへのドロップするデモ
・ブラウザ上でターミナルを再現したデモ(これが凄かった・・・3Dでディレクトリ構造も表示可能)
local file systemへのファイル書き込みデモ
・BlobBuilderを使う
・ブラウザ上でURL「filesystem:・・・」でファイルの一覧が表示
オフラインWEBアプリ
・マニフェストファイルを用意するだけでWEBサイトがキャッシュされる
・localStrageを使ってユーザーデータをブラウザに保存する
音声入力
・以下の記述で実装可能
<input type="text" x-webkit-speech />
ChromeAPｐStoreの紹介など
デモの数が多く、ソースコード等を全て理解できなかったのが残念ですが、このような技術があるということで色々と勉強になりました。
早速、デスクトップとブラウザのファイルドラッグ＆ドロップを試してみたので、その結果はまた後日ブログにアップします。
Androidアプリは30万アプリ存在し、ダウンロード数の合計は80億を突破したという情報からセッションが開始しました。
Androidアプリで成功するには「クオリティ」の一言につきるとのことで、利用者からのレビューや不具合報告に誠実に対応→ファンを獲得→ランキングで上位→レーティングでも有利になる→売り上げも上がる→健全な成功という構図になるのが望ましいとのことでした。
一人でアプリを開発していると、このような基本的な事ですら実施できない事があったので、大いに反省させられる内容でした。。。
次にAndroidアプリは「速度が出ること」「使いやすいこと」「美しいこと」「Androidらしいこと」「ユーザーの声を聞くこと」に注意して製作すべきということで、それぞれの内容について説明がありました。
「速度が出ること」
・UIスレッドではIO処理は行わない
・時間が読めない処理はワーカースレッドで行う(StrictModeを使えばデバッガでチェック可能)
・AsyncTask/IntentService/Loader等の非同期系の利用
・処理時間はTraceViewを使って実際の時間を計測すること
・処理に時間が掛かる場合はウェイト表示などを使って利用者に分かりやすく伝えること
・0.2秒以上の処理にはプログレスバーやキャンセルボタンが必須
「使いやすいこと」
・少しでもマニュアルが必要だと思うならそれはおかしいアプリ
・マニュアルを見なくても使えるくらいでないと、利用者は去ってしまう
・ドナルド・ノーマンやヤコブ・ニールセンの本を参考に
「美しいこと」
・色使いやレイアウトを考慮すること
・第一印象が大事
・アニメーションをどこで使うか/色使いがアンバランスではないか/フォントの大きさは適切か等
・デザイナーに頼るのも良い
「Androidらしいこと」
・アクションバー等の実装はリファレンス通りに
・タイトル上にあるバックボタンと、ハードウェアのバックボタンで動作が違うなんてことが無いように
「ユーザーの声を聞くこと」
・メッセージを送ってもらうなど、必ずユーザーの声を聞くこと
・Analytics for Androidを使うとアプリの利用状況が判別できる
・アプリは早くリリースして早くアップデートしていく
・アップデートによりファンがついてくる
・クオリティが一緒でもアップデートしたアプリの方が印象が良い
Android 4.0(ICS)について
・タブレットや携帯等を統合するバージョンとして登場
・多くの機能は3.x系から継承されている
・システムバーの採用(3.x系からの採用)
・recent機能(3.x系からの採用)
・xhdpiの追加(アイコンは96ピクセルになる)
・端末にメニューボタンが無いものも登場するので、考慮すること
・アクションバーにメニューを表現する
・リソースの判定にsw600dpが追加
・アクションバーの左端はアプリのアイコンを設置
・アクションバーの中央は検索パーツやパンくずなどを設置
・アクションバーの右側は今の画面で利用できる機能のボタンなどを設定(メニュー含む)
・アクションバーは画面サイズにしたがって色々と変化できる
(スタックアクションバー・スプリットアクションバー)
フラグメントについて
広い画面(タブレットなど)・狭い画面(携帯)で同じ画面デザインを走らせる仕組み。
広い画面では１つで表示されていたものが、狭い画面だと多画面となって表示される。
画面の定義についてはアクティビティ単位で作るのではなく、フラグメントを利用することで移植性を高める。
(タブレット対応を予定していなくても、フラグメントの仕組みは勉強しておくべき)
よってアクティビティにソースコードは記述しないようにする。
AppNavigation
今までのAndroidは「戻る」機能しか存在しなかった。
これは単純に時間順にどの画面を表示していたかを辿る機能でしかなかった。
しかし、この仕組みのままでは複雑なアプリでは混乱してしまうことがあった。
それを解消する為にAppNavigationを採用し、階層構造の上に移動できるような仕組みを提供した。
その他、技術的なお話し
・apkファイルはなるべき１つで提供すべき
・レイアウトファイルは１つのまま長さを抽象化できる
・レイアウトにはpxを使わないでdpを使う
・プラットフォーム別に一番美しく見えるビットマップを採用する(NinePatchBitmapがお勧め)
・画面サイズに対応したアプリの開発をしてください
ということで、Android 4.0(ICS)は機能も増えたし対応機器も増えたけど、開発者はやることが多くなったなぁ・・・という印象でした。
特にフラグメントは使いこなせれば便利な機能っぽいけど、実際に複数デバイスに対応した時のどんな感じになるのか不安もあります。
はやく実機で開発できる程に4.0の端末が増えてくれると良いんだけどなぁ・・・
Android 4.0となるICE CREAM SANDWICH(ICS)の話しが中心でした。
私自身がAndroid 3.0にすら触れたことが無いという状態だった為、一部の話しについては理解できなかった部分もありますが、ICSは非常に大きなバージョンアップということ位は理解できました。
しかし、2.x時代と比べてメニューボタンの扱いが変更になる等、現在はAndroidの成長段階であり、今のところ当たり前と思っている機能についてもスッパリと切り捨てられてしまう危険性もあると思いました。
ここらへんは、Windows3.1～WindowsXP位までの色々と変化があった状況に似ているかと思います。
さて、ICSの大きな機能追加は以下の通りです。
・フォントの変更(但し、いまのところ日本語は対応していない)
・入力フォームなどが洗練されたデザインになった
・履歴機能の追加
・アクションバーの機能が洗練された
・フラグメント
・ソーシャルAPI
・カレンダーAPIの正式提供
・各種マルチメディア処理に対応
・カメラAPIに顔認識機能の追加
・Android Beam
・VPNのサポート
この中で特に凄いと思ったものは「フラグメント」と「Android Beam」になります。
フラグメントについては、この後のセッション「Androidの優れたユーザーエクスペリエンス」で分かりやすく紹介されましたので、後日このブログでも紹介したいと思います。
Android Beamは近くにあるAndroid端末同士が簡単に通信を行える仕組みで、デモとして、現在閲覧しているWEBページを、もう一台の端末にコピー(WEBページを紹介)するというものを紹介していました。
(デモでは端末同士をくっつけていましたが、実際には数メートル程度であれば通信できるとのこと。色々と応用できそうな技術だと思います。)
どちらも魅力的な機能追加だったのですが、ICS搭載機って今のところDocomoの「GALAXY Nexus」しか予定が無いんですよね・・・
そもそも、Android 3.0もよく理解していなかったので、3.0搭載のタブレットを開発機として購入しないとなぁ・・・という感じになりました。
ここらへんって、個人でアプリを開発してる人たちってどーしてるんだろうか・・・