snippets from shinichitomita’s journal RSSフィード Twitter

2011-12-19

■[node.js][javascript][salesforce] Node.js からSalesforceを使う

一応誰かがすでにやっていることですが、ちゃんとしたのが無いので作りました。

stomita/node-salesforce - GitHub


インストール

npm 登録済みです。

$ npm install node-salesforce

利用方法

接続
var sf = require('node-salesforce');
var conn = new sf.Connection({
  serverUrl : 'https://na1.salesforce.com',
  accessToken : '<your oauth2 access token is here>'
});

Connectionオブジェクトの引数に、OAuth2の認証フローで得られた情報をそのまま渡してやります。今のところOAuth2のトークンやりとりについてはモジュールに含まれていません。

テスト用にユーザ名／パスワードでログインすることも可能です。

var sf = require('node-salesforce');
var conn = new sf.Connection({
  loginUrl : 'https://login.salesforce.com'
});
conn.login(username, password, function(err) {
  if (!err) {
    // console.log(conn.accessToken);

    //
    // ... logics after authentication ...
    //
  }
});

本来ならこの loginメソッドの実装は OAuth2に則って Resource Owner Password Credential でやるべきかもしれませんが、SOAP APIからだとClient ID/Client Secretが必要ないので、そちらを利用しています。

余談ですが、Salesforce API においては OAuth2 Access Token ≒ Session IDです。SOAP API や埋め込みタブのURLから得たSession ID は、そのままOAuth2 Access Tokenとして利用できます（また逆に、scopeを指定しないで取得したOAuth2 Access Token は SOAP APIのSession IDとしても使えます）。

検索

SOQLでの検索。

検索結果のレコードをイベント駆動的に扱うオプションがあります。autoFetchオプションを渡せばレコード件数が多い場合は自動的にqueryMoreするので、結果セットの取得をアプリケーション側で意識しなくても大丈夫です。

conn.query("SELECT Id, Name FROM Account")
  .on("record", function(record) {
    records.push(record);
  })
  .on("end", function(query) {
    console.log("total in database : " + query.totalSize);
    console.log("total fetched : " + query.totalFetched);
  })
  .run({ autoFetch : true, maxFetch : 4000 });

通常のコールバックスタイルでも利用できます。

var records = [];
conn.query("SELECT Id, Name FROM Account", function(err, result) {
  if (!err) {
    console.log("total : " + result.totalSize);
    console.log("fetched : " + result.records.length);
  }
});

CRUD操作

対応してます。

conn.sobject("Account").retrieve("0017000000hOMChAAO", function(err, account) {
  if (!err) {
    console.log("Name : " + account.Name);
  }
});

conn.sobject("Account").create({ Name : 'My Account #1' }, function(err, ret) {
  if (!err && ret.success) {
    console.log("Created record id : " + ret.id);
  }
});

conn.sobject("Account").update({ 
  Id : '0017000000hOMChAAO',
  Name : 'Updated Account #1'
}, function(err, ret) {
  if (!err && ret.success) {
    console.log('Updated Successfully : ' + ret.id);
  }
});

conn.sobject("Account").del('0017000000hOMChAAO', function(err, ret) {
  if (!err && ret.success) {
    console.log('Deleted Successfully : ' + ret.id);
  }
});

配列指定で複数レコードの一括操作もありますが、SOAP APIと違いレコードごとに一つ一つAPIリクエストを投げるので、注意。


// Multiple records creation consumes one API request per record.
// Be careful for the API quota.
conn.sobject("Account").create([{
  Name : 'My Account #1'
}, {
  Name : 'My Account #2'
}], 
function(err, rets) {
  if (!err) {
    for (var i=0; i<rets.length; i++) {
      if (rets[i].success) {
        console.log("Created record id : " + rets[i].id);
      }
    }
  }
});

未対応

describe系はまだです。

参考

なお、githubにある既存のライブラリでは、以下のものがあります。

https://github.com/gidzone/sfdc-node

=> express依存＆あまり再利用考えてなさそうです。

https://github.com/durchblicker/SalesforceAPI

=> 作りかけっぽいかんじ。なんでnpmに登録したかな…

https://github.com/joshbirk/FDC-NODEJS-HEROKU

=> 多分これが一番まともだけど、なぜわざわざHEROKUってつけてるかな？


※ このエントリーはForce.com Advent Calendarに参加しています http://atnd.org/events/22909

Permalink | コメント(0) | トラックバック(0) | 01:03 Node.js からSalesforceを使うを含むブックマーク Node.js からSalesforceを使うのブックマークコメント

2011-12-06

■[salesforce][force.com][javascript] Force.com ブックマークレット

Salesforceを使って多言語対応の開発をしていると、英語⇔日本語の設定を行き来することが多いですが、毎回設定画面に行って変更するのって結構めんどくさいですよね？

そんなとき、僕はブックマークレットで一発変更しています。

言語設定変更ブックマークレット

http://stomita-lab.s3.amazonaws.com/gist/1436661/toggle-language.html

説明

Ajax Toolkit経由でSOAP APIを使って現在のログインユーザの言語属性を変更しています（なので実行する組織のAPIが有効化されている必要があります）。

ソースはこちら

https://gist.github.com/1436661#file_toggle_language.js

英語⇔日本語のトグルですが、他の言語必要だったら適当にForkして増やしてください。


なおこのブックマークレットは拡張可能なLoaderを経由して実行しており、上記のスクリプトだけでなくGistに書いた任意のJavaScriptスニペットを簡単に呼び出し可能になっています。APIのデバッグは同梱のAjax Toolkit Shellで。うん、もうローカルPCにIDEなんて必要ないですね！

http://stomita-lab.s3.amazonaws.com/gist/1436661/sfdc-bookmarklet.html


注意事項

詳細は言いませんが、このブックマークレットはちょっと問題を抱えています。本稿執筆時現在は動きますが、将来にわたって動くことを保証はしません。詳しくはソースみてね。


※ このエントリーはForce.com Advent Calendarに参加しています http://atnd.org/events/22909

（とりあえず軽めにジャブ）

Permalink | コメント(0) | トラックバック(0) | 20:11 Force.com ブックマークレットを含むブックマーク Force.com ブックマークレットのブックマークコメント

2011-12-02

■[salesforce] SalesforceのWeb APIに対する意見

残念ながら個人的な意見なので殆どの人には響かないに違いないが、できるだけ一般の技術者にわかるように書く。なお実はそれほど現在の業務とは関係ない。


自分がやりたいこと

Salesforce（あるいはDatabase.com）のデータにアクセスするHTML5なAjaxアプリ（iPhone対応）を書きたい。なおVisualforceは管理者にセットアップさせるから×。外部サーバ経由は通信ポイントがいたずらに増えるから＆IP制限してたときに使えないから×。直接API EndpointにJavaScriptから通信するのが一番よろしい。

現状

REST APIがCORS (Cross-Origin Resource Sharing) に対応してない。SOAP APIの方は（CORSではなくcrossdomain.xmlだが）OKしてるのになんでなのかまったくよくわからない。せっかくImplicit Grant (User-Agent flow) も対応してるのにほぼ意味ないじゃない。SOAP APIでやるにはFlash Proxyを経由するしか無いので、PCブラウザならいいが、Flashの動かないモバイル用途だとこれも×。え、PhoneGap？アプリじゃなくてWebじゃないとだめなんですよ。

結論

Patのブログのコメントを見るかぎりCORS対応はロードマップには入っているっぽいが、いつになるのかわからない。Winter '12では入らなかった。Spring '12で対応しなかったら見限ろうかと思う。CORS対応を見据えてのDatabase.comに対するよいしょ記事を用意する予定だったがもう書かない。拗ねる。お蔵入り。なので中の人は調べてこっそりいつ頃になるのか教えてくれるとありがたい。

補遺：想定問答集

「セキュリティのことを考えてあえてCORSはOFFにしてるのでは？」

⇒ セキュリティというのが「IPアドレスによるAPIのアクセス制御が難しいからクロスドメインでの直接アクセスを禁じたい」という主旨であるとして、それは現在Flashアプリが(AIRでなくWeb埋め込みでも)SOAP API経由でクロスドメインで直接APIコールが送れるようになっている実態と矛盾する。

「Herokuでやったらいいじゃない」

⇒ サーバを介することは不必要な通信ノードを増やす。クラウドとはいえサービス提供者が運用を気にする必要ができてしまい面倒。あとIPアドレス帯域の制限は結構よくある話なのでサービスの展開に影響する。ユーザの管理者に頼んで許可IPアドレスに入れてもらうくらいならVisualforceで作っても似たようなもん。

「PhoneGapでやったらいいじゃない」

⇒ PhoneGapだと結局iPhoneアプリ作って配布することになる。AppStore？エンタープライズ配布？それもいいが、そうじゃない選択肢としてHTML5はあるのだ。

「Visualforceで（以下同文）」

⇒ 管理者にセットアップ（インストール）してもらうようなことを想定したアプリ・サービスならそれでもよいが、そうでない、バイラル的・ボトムアップ的に利用者が広がるようなものについては提供が不可能。

「管理者が認めたアプリからしかアクセスさせない、のが普通では？」

⇒ もし本当に管理外のアプリからのアクセスを禁じたいなら、現状それは「アクセス可能なIPアドレス帯の制限」「ネットワーク内PC/スマートフォンへのインストールアプリの制限」などと同時に実施されなければ意味がない。前者はSalesforceの設定の話だが、後者はそれ以上の全社的な運用ポリシーの話になるので、徹底してやってるところは稀。あるいは「APIアクセスの禁止」も選択肢となりえるが、それは同時に認可したい他のアプリ／サービスからのアクセスも禁ずることになる。

さらに、先ほど述べたとおり、現状Flash Webアプリが直接APIコールできるため、単なるアプリケーションのインストール規制というのはそれほど意味をもたない。

なお、管理者による利用アプリを制限を真っ向から否定するほどラジカルな意見を持っているわけではない。ただ、それを実現するために、低レベルなレイヤーで境界を設けるのは時代遅れだと言いたい。実際 Chuck もそういう意見でしょ（参考：Cloud Identity Summit でのcmortのプレゼン資料）

「SalesforceのOAuth Implicit Grant (User-Agent flow) はAndroid/iOSアプリのためにあるのでは」

⇒ そうだとするなら、なぜOAuthクライアントの登録時に https:// ではじまるリダイレクトURIの登録を許しているのか。

Permalink | コメント(0) | トラックバック(0) | 12:38 SalesforceのWeb APIに対する意見を含むブックマーク SalesforceのWeb APIに対する意見のブックマークコメント

2011-08-23

■[iphone][udid][ad] スマフォのリワード広告におけるUDIDに依存しない設計案

前回のまとめ

前エントリで触れたとおり、スマートフォンのUDIDの問題点というのは、自分の把握する限り３つあった。

1. サーバとのセッションを管理するための認証に使われてしまっている

2. アプリケーションをまたがっての行動トラッキングに使われてしまっている

3. スマフォにおけるリワード広告がUDIDが取れることに依存した実装になっている。

このうち、1. に関しては代替案があり、ほぼ既存のユーザビリティを損なわない形に実装できるものなので、単に実装側の怠慢か知識不足に帰結されると感じている。今の時点でこれほど安易に使われてしまっているのは残念なことではあるかもしれないが、今後改善できる余地がある。

2. に関しては、実はデバイス固有IDであることについてはそれほどこの時点では問題ではなく、単にトラッキングされることに対してユーザの同意も拒否も介在する余地が無い、というところを問題にしている。たとえば、もしAdNetwork固有のIDを生成して割り振れたとしても（実際にはそれは無理なのだが）ユーザがそのトラッキングについて受入の許認可ができない時点でアウトと宣告される。つまりは、3rd Party Cookie的なオプトイン・アウトの仕組みが提供され無い限り、そもそも無理筋のビジネスモデルではないか、というのが自分の感想だ。

で、問題は 3. だ。


スマフォのリワード広告はevilなのか？

リワード広告について、ビジネスモデルの健全性を疑う声もあるようだが、僕はそこは今回とは分けて考えるべきである、という意見である。少なくとも個人的には、アコギなことをしている、という印象までは抱かない。もっと言うと、そのシステムがはたして世界にどういう結末をもたらすのか、という点で、第三者的な興味がある。もし、広告ビジネス自体を卑下して、そんなものはだめだ、という立場を取る人がいたとしたら、あさはかだな、とは思う。

ビジネス自体をやめろ、というのは簡単だ。もし無断かつ回避できない行動追跡のようにevilであるというコンセンサスが確立している場合には、正直そういうしかない。でも、リワード広告については、そこまでevilとは思わなかった。これは、先日の調査の結果、いままでの自身の価値観に照らし合わせて判断したもののため、いやそうじゃないよ、という意見もあるかもしれない。もしそうなら是非その点についてコメントなりで教えていただきたい。

ただし、ビジネス自体はありとしても、あたりまえながら実装においてはルールが存在し、 UDIDの収集によってそれを実現するのは、ルール違反といえる。また、起こりうるプライバシー問題についての想像力がない、という意味で、センスがない。

しかしながら、世の中はルール以外のところで動いているようだ。このままだとUDIDがとれなくなるんだったらMACアドレス（のハッシュ値）でやっちゃえばいいじゃん、という流れになるかもしれない。これは避けるべきところだ。


スマフォにおけるリワード広告のフロー（推定）

今回、正直に告白すると、自分はiOSネイティブのまともなアプリを作ったことは全くない。なので、実際とかけ離れた推測になっていた場合はご容赦いただきたい。

スマフォアプリのリワード広告で、肝となるのは、ユーザが該当アプリをダウンロードしたかどうかをどうやって把握するのか、ということだ。これさえできるのであれば、別にUDIDというのは必ずしも必要ではない。

今、リワード広告を掲載するアプリをA（ソーシャルゲームのようなものを想定すると良い）、広告主のアプリをBとしてみる。おそらく現在は以下のフローになっている。これはもちろん推測。

1) ユーザは、アプリAのゲームを楽しんでいる。

2) ユーザは、アプリA内のゲーム内での仮想通貨ポイントが欲しくなった。

3) ユーザは、アプリA内に表示されている広告をクリックする。

4) アプリAは、ユーザのスマフォのUDIDを取得し、サーバ上でユーザ情報に紐付けた後、App Storeを起動してアプリBのページへ遷移させる。

5) ユーザは、アプリBをスマフォにダウンロードする。

6) アプリBは、初回起動時にスマフォのUDIDを取得し、ゲームAのサーバに送信する

7) アプリAは、サーバ側でUDIDを照らし合わせて、そのユーザに対してポイントを付与する

8) ユーザは、アプリAにおいて、仮想通貨ポイントをゲットできた！

ここで、アプリAとアプリBで、ユーザのセッションを突き合わせるという目的のためにUDIDが使われているのがわかる。つまり、アプリ間でセッションの連携さえ出来るのならばこれは解決される。


スマフォアプリ間でセッションを共有する方法

今回、iPhoneアプリ間で連携する方法には、一般的に以下の方法がある、ということを教えいていただいた。

iOSの中で、アプリケーション同士が連携するためのしくみ - The iPhone Development Playground

URLによるアプリの起動

Pasteboardによるデータ共有

UIDocumentInteractionControllerによるファイルの受渡し

このうち、URLによるアプリ起動によって解決できる可能性があるのではないかと考え、以下のようなフローを考えてみた。（４以降が変更点）

1) ユーザは、アプリAのゲームを楽しんでいる。

2) ユーザは、アプリA内のゲーム内での仮想通貨ポイントが欲しくなった。

3) ユーザは、アプリA内に表示されている広告をクリックする。

4) アプリAは、アプリA内で一時的にUUIDを生成し、ユーザ情報に紐付けた上で、ユーザをApp StoreのアプリBのページへ遷移させる。

5) ユーザは、アプリBをスマフォにダウンロードする。

6) アプリAは、4)で生成したUUIDをURLにパラメータとしてつけて、アプリBを起動する。

7) アプリBは、パラメータでもらったUUIDをアプリAのサーバへ送信する

8) アプリAは、サーバ側でUUIDを照らし合わせて、そのユーザに対してポイントを付与する

9) ユーザは、アプリAにおいて、仮想通貨ポイントをゲットできた！

こちらのフローだと、一旦6)でアプリAからアプリBを明示的に起動する、というフローが発生してしまうが、目的は達成されている。受け渡しされるのはアプリケーションの橋渡しをするための一時的なIDであるため、漏えいしても悪用されることはない。

UDIDを用いたフローが、即座にポイントが獲得できるのに対し、この提案はアプリケーションの確認となる 6)の ユーザインタラクションが入ってしまうため「ユーザビリティが損なわれる！」と憤慨するかもしれない。実際、ターゲットユーザ層を考えると、そのあたりのわかりにくさによる離脱は十分考えられるため、そんな要素は極力無くしたいというのが、ビジネスを企画する側の本音だろう。

ただ、申し訳ないのだが、今回の件でUDIDなど端末固有IDを利用することによるビジネス上のリスクというのは十分にわかったはずだ。デバイスIDを広く収集させてしまうことについての忌避感は、まともなベンダーならかならず感じていることだ。iOSでAppleがやったことは、世間的に見てむしろ常識的な対応なのだ。さてじゃあAndroidではそんなことはないと誰がいっているか？ そのようなリスクをとってまで最初のフローに固執するのはなぜだ？ もしスマフォアプリのリワード広告というビジネスを継続させたいなら、今のところこれしかありえない、というのが自分の結論になる。

もちろん、まだ他の実装方法もあるかもしれない。その中には、ユーザインタラクションを損なわない妙案もあるかもしれない。残念ながら自分には見つけられなかったが、まあそこまで頑張る義理というのもない。

＃ちなみにもしかしたらAndroidだったらIntentによってユーザのインタラクションを介さずにバックグラウンドでパラメータ渡しができるのかもしれない。そうすれば既存のユーザビリティを著しく損なうということはない。

Permalink | コメント(0) | トラックバック(1) | 15:16 スマフォのリワード広告におけるUDIDに依存しない設計案を含むブックマーク スマフォのリワード広告におけるUDIDに依存しない設計案のブックマークコメント

2011-08-22

■[iphone] なぜiOSでUDIDが必要とされていたのか、メモ

iOSやその開発事情に詳しいと言える状態にはないので、調査を兼ねて書く。

Apple Sneaks A Big Change Into iOS 5: Phasing Out Developer Access To The UDID | TechCrunch

アップル、iOS端末ユーザーのプライバシー保護で方針変更 - 「iOS 5」ではUDIDの利用を推奨せず - WirelessWire News（ワイヤレスワイヤーニュース）

上記の「iOSでUDIDの利用が禁止」というニュースを聞いた時、正直TL上にこんなにいっぱい反応が貼り出されるとは思っていなかった。さすがにUDIDをいじるのはまずいよね、っていうコンセンサスは開発者の間では常識的部類に入ってくるのだろうと楽観的に捉えていたのかもしれない。

以下、なぜUDIDがそのようにスマートフォン開発者に利用されてきたのかについて、調べた限りでまとめてみた。


アプリケーションのサーバとのセッション保持

いわゆるかんたんログインの実現のために利用する、というもの。

たぶんほとんどのUDID批判者はこの点について最初に批判していたと思われる。

UDIDがこのような用途に向かないことは、すぐに分かる。

iOSの開発トレーニングでUDIDを利用していたことが伺えるツイート。

ということで、UDIDの利用は半ば常識化していたことが読み取れる。

ただし、これには以下のツイートもあったので、そもそもAppleが勧めてるようにみえたんじゃないのどうなの？という疑問もちょっとは残る。


じゃあ、かんたんログインできないし、ユーザ登録してもらわなきゃいけなくて、スマフォの画面でそれやらせる？むりだろ、という話になってしまうかもしれないが、そもそもそんなデバイス固有のIDを使う理由がない。

アプリ内でのサーバとのセッション管理に関して、UDIDを用いずに利用する方法について

これでいい。UUIDの生成さえセキュアであれば永続化Cookieによるセッション管理と同等だ。

つまり、ガラケーIDの時と違い（当時はCookieサポートしていない端末が数多くあった）、回避策はすぐあるわけだ。ログインさせるのが嫌だ、という理由にはならない。トレーニングという点ではUDIDを使った方が簡単に見えるかもしれんけど、非セキュアな方法をあたりまえのものとしてトレーニングしてよいわけがない。


なお、上記の方法ではKeychainを使っており、Keychainはアプリ間では情報の共有ができない（正確には同一のプロビジョニングIDをもっていればできるが、他社のアプリの情報を読めたりはしない）。つまり、アプリをまたがってセッションを共有したいという用途には用いることはできない。


行動トラッキングによるターゲティング広告

でもアプリをまたがってセッションを特定したいってのはどういう時なんだ？

最初に思いつくのは、行動トラッキングによるターゲティング広告になる。

現在スマートフォンのアプリ向けにいろいろベンチャー・大手含めてアドネットワークが参入している。TLの反応を見ても、このへんの商売への影響を心配している声が強かったようだ。

一見、3rd Party Cookieによるトラッキングの話と似ているじゃないのか、と思う。しかしながら、通常ブラウザは3rd party Cookieの受け入れはオプトアウトできるようになっている。だがUDIDの場合はそれができない。アプリケーションレベルで開発者の倫理により同意ダイアログを出すことは可能だろうけど、アプリに入り込んでいるターゲット広告がそれを出すわけがない。だから、この目的（行動トラッキング）によるUDIDの利用の正当性にはプライバシー保護上明確にNOと言われる可能性が高いし、歴史上そのような試みはほとんど糾弾されて来ている。スマフォは例外で特別であるという理由が存在しない。

つまりこのような行動トラッキングによる広告は、そもそもビジネスモデル自体が危うい。それが今回、Appleの（とりあえずは健全な）判断により現れたとすれば、そいつはまあ自己責任でないかといえる。

なおこの記事には正直びっくりした。いやこれくらい想定してないといかんのだろうが。

アプリがあなたを監視中─スマートフォン・アプリがプライバシーを侵害 - WSJ日本版 - jp.WSJ.com

携帯アプリへと事業を拡大しつつある、エピック・メディア・グループ傘下のネット広告ネットワーク、トラフィック・マーケットプレイスのメガン・オホレラン氏は、「携帯の素晴らしいところは、ＵＤＩＤをクッキーのようには削除できないことだ。われわれは、ＵＤＩＤを通じて、すべてを追跡する」と語る。


リワード広告

ただし、ことはそう単純でもないことが、調べているうちにわかってきた。

どちらかというと、影響があるのは行動トラッキングによる広告などではなく、違う広告分類のものらしい。

「リワード広告」というキーワードで調査した。

こちらはiPhone上でリワード広告を行っているTapjoy。

Has Tapjoy solved monetization of free apps on the iPhone and Android? | TechCrunch

They track the sale using the device owner’s Unique Device Identifier (UDID) so there is no confusion on whether the app is downloaded or not.

その他にも、スマートフォン上でリワード広告を提供している国内サービス。

グリー株式会社 | ニュースリリース | プレスリリース 2011年 | グリー、スマートフォン向けリワード広告商品「GREEリワード広告」の提供を開始

CAリワード、スマートフォン向けのリワード広告商品を販売開始 :ベンチャーニュース：Venture Now（ベンチャーナウ）

（訂正：こちらはスマフォ向けではなかった。が、エンジニア向けにリワード広告について分かりやすい図が書いてある）

リワード広告システムPoncanの仕組みと実例／ソーシャルアプリ勉強会（第2回）


リワード広告自体は一般的な広告提供の仕組みであると言えるけれども、これがスマートフォンの場合は、アプリのインストールに対して、アフィリエイトのような形で、ポイントなどを付与する。広告主はアプリのダウンロードが増えて満足、広告を掲載したアプリは広告料が入ってニコニコ、ユーザはポイントがもらえてラッキー、という仕組み。

この際に、ユーザにポイントを付与するためにアプリをダウンロードしたクライアントを特定する必要があるのだが、これにUDIDを用いている（少なくともTapjoyはそうしている、と書いてある）。

これを上記の行動トラッキングの場合と比較すると、ユーザのインタラクションが介在しているだけに、プライバシーの面からアドネットワークのプロバイダーの不誠実を訴えるのは難しいケースなのではないかと、個人的に感じた。このサービス自体がデバイスにアプリをインストールしたかどうかでポイントがもらえることを明確に宣言しており、ユーザはそれを認識しているのだから、それにまつわるデバイス情報を取得するのは当然だろ、という理論武装はそれなりにありえるからだ。

しかしながらそれにおいても、本来なら、ユーザとアプリの紐付けを行うのをUDIDというデバイス固有IDで行う必要はないはずだ。実際Webサイトのリワード広告はサイト間のセッションのやりとりだけで固有IDなどは用いていない。

しかしながら、どうもiOS上でアプリ間でスマートにセッションを共有する仕組みがなさそうなのである。

これについては、ただ単に自分の知識が足りないだけかもしれない。わからない。

これができない以上、スマフォアプリのリワード広告のシステムは作ることができない、ということになる。

じゃあUDID使っていいじゃん、っていう結論には、どう考えても落ちるはずはないのだけど、はてさて、だからといってこのようなビジネスモデル自体にダメだしするには、さすがに根拠がない。一番いいのはAppleがアプリ間でセッションを共有するための仕組みを整えてくれることだろうけど、それがiOS5およびその後可能になるのかどうかは、これまたわからない。


まとめ

なお、今回は、もともと興味を持っていた分野であったので、ちょっと時間を取ったけど、まだ浅い調査だけのメモ程度で、だからどうすべきか、までには至っていない。

ただし、今回わかったのは、ただ単にかんたんログインなどの技術者の知識レベルの話ではなく、すでにスマートフォンのアプリという成長市場で、一つのエコシステムができ上がりつつある中での廃止のニュースだったのが、各方面に波紋を巻き起こしているということだった。

リワード広告のエコシステム自体は、市場の活性化に必要なのは理解できるが、UDIDに依存した実装に関しては可能ならば早急に対策をしなければいけないだろう。で、Appleはそれを強制した。それは実はリワード広告というビジネス自体を潰したいという意図があるのかどうか知らない。またiAdがUDIDをトラッキングのために独占して利用するのか、そしてどれほど悪意を持ち得るのかもわからない。知らないわからないことだらけだったな、というのしかわからなかった、という、まとめにならないまとめ。


追記

Appleがリワード広告自体を締め出そうとしているのではないか？というのが伺える記事について、コメントしていただいた。

Appleが景品付きアプリダウンロードを締め付けへ

追記２

スマフォのリワード広告の実装について、UDIDを利用する以外の代替案について考えてみた。

スマフォのリワード広告におけるUDIDに依存しない設計案 - snippets from shinichitomita’s journal

まあ、上記のようにAppleというプラットフォーマーがそのビジネス自体を禁止したい意図がある場合は、こんなことをしても意味がないが、もしこれがAndroidなどでも同じような状況なのだとしたら、少しは役に立つかもしれない

Permalink | コメント(0) | トラックバック(3) | 20:42 なぜiOSでUDIDが必要とされていたのか、メモを含むブックマーク なぜiOSでUDIDが必要とされていたのか、メモのブックマークコメント

プロフィール

shinichitomita

shinichitomita

Shinichi Tomita / Azabujuban

カレンダー
<< 2012/02 >>
日 月 火 水 木 金 土
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29
人気のエントリ
最新タイトル
最近のコメント
最近のトラックバック
カテゴリー