Not sure where to start? Get going with our crush course for beginners and create your first project.
2012年2月27日から3月1日にかけてバルセロナで開催されたMobile World Congress 2012では、特に注目の集まったGoogleやFacebookのキーノート以外にも示唆に富んだ興味深いセッションが多数あった。その中の1つがコンサルティング会社frogのScott Jenson氏によるプレゼンテーションであった。同氏が各地で行っているというプレゼンテーションは“Mobile Apps Must Die”というラディカルなタイトルだが、筆者は大いに共感でき、多大なインスピレーションを受けた。本稿では、同氏の論旨に依拠しつつ、アプリ環境の今後を展望する。 「アプリの海」 現在、AppleのApp Storeでは50万以上、Google Play(旧Android Market)では40万以上のアプリが提供されており、この数は日々増加を続けている。これらに加え、Window
普通では考えられない優遇策--「Google提案」を振り返る 皆さんこんにちは、毎度おなじみ(?)文字コード漫談の時間がやってまいりました。前回が3月の掲載ですから3カ月ぶりですか。今まで3回にわたって絵文字をUnicode及びISO/IEC 10646(国際符号化文字集合)に収録しようという提案の動きについてご説明してきましたが、今回から2回に分けて完結編をお届けします。どうぞよろしくお付き合いください。 ひさしぶりですから、ここまでのポイントを整理しておきましょう。前述した「提案」とは、もともとはUnicodeに収録するためにGoogleがAppleと共同で作成したものです。以下、主唱者の名前をとり「Google提案」と呼ぶことにします。これはこの2月に開かれた最高議決機関、UTC会議で承認されてUnicodeコンソーシアムの総意となりました。ついでGoogle提案はISO/IEC 1
前回までを振り返る--Unicodeコンソーシアムの影響力 前回はどこまでお話ししましたっけ。世界中の文字の収録を目的とした文字コード規格、Unicodeは、米国のIT企業を中心に結成されたUnicodeコンソーシアムが制定するデファクト規格に過ぎないこと。しかし公的な国際機関が定めるデジュール規格ISO/IEC 10646と同期することで、WTO/TBT協定にもとづき世界中の国々に普及させられるメリットを得たこと。 また、Unicodeコンソーシアム自体はオープンな組織だけれど、意志決定を行うUTC(Unicode Technical Committee/Unicode技術委員会)で一票を投じる権利を持つのは一握りの団体に限られること。そしてUTCはISO/IEC 10646のアメリカ・ナショナルボディであるL2委員会と合同でしか開催されておらず、同時にL2委員会とUnicodeコンソー
じつはコメントを送っていたNTTドコモ 最初に前回のおさらいをしておきましょう。スタート当初の携帯電話の絵文字には、キャリア間でメールのやり取りの中で文字化けしてしまう欠点があったこと、それを解決する仕組みをキャリア各社が作ったものの、その場しのぎの欠点の多いものであったこと、そして絵文字のUnicode符号化というのはそうした欠点を一挙に解決するはずであること。ついでにGoogleが絵文字のUnicode符号化を進めることで、キャリア各社は今まで自分たちが育ててきた絵文字の主導権を奪われてしまうということも。 それから前回の最後では、キャリア各社に対してGoogleの提案についてどう思うか、パブリックレビューに参加する意向があるかを聞いてみました。そこでの回答は、各社そろって消極的と受け取れるものでした。 ところが前回の掲載後に、NTTドコモがGoogleの絵文字メーリングリストに投稿し
Unicodeが携帯電話の絵文字を収録へ 絵文字ってなに?そう聞かれても多くの人は、ああ、それはと答えられるはず。そう言えばちょっと前に『メールのハートマークにだまされるな! 8割の女性は「恋人以外にも使う」』(RBB NAVI)なんていうニュースもありました。携帯電話の個人普及率が9割を上回る(平成20年内閣府消費動向調査)この国において、絵文字はごくありふれたものになっている現実があります。 2008年の11月27日、Googleが携帯電話で使われる絵文字を国際的な文字コード規格、Unicodeに収録しようというプロジェクト進行中であることを発表しました。では、このニュースは何を意味するのでしょう。そして私たちに何をもたらすのでしょう。今回から3回に分けて考えてみようと思います。 まず歴史を振り返ってみましょう。じつは絵文字を使ったのは携帯電話が最初というわけでありません。先行するもの
FireMobileSimulatorはFirefox/Chrome版ともに配布・メンテナンスを終了しました。本ページの内容は記録のみの目的で残しています。 FireMobileSimulatorとは? FireMobileSimulatorは、主要3キャリア(DoCoMo/Au/SoftBank)の携帯端末ブラウザをシミュレートして、モバイルサイト開発を容易にするために作成されたGoogle Chrome/Firefoxの拡張機能です。携帯端末のHTTPリクエスト、絵文字表示、位置情報送信機能などの動作をシミュレートすることができます。 モバイルサイトをPCで閲覧するために、従来からある方法として、キャリア公式シミュレータの使用、Proxyの使用、Firefoxのuseragentswitcher+modify headersの組み合わせ等、色々と手段はありましたが、これらの方法はそれぞ
第1回 つらくないケータイWeb開発 設樂 洋爾 2008/10/20 何かと注文の多い日本の携帯電話向けWebサイト構築。jpmobileで、Ruby on Rails流の、つらくない携帯Webサイトを開発しよう(編集部) 本連載では、Ruby on Rails(Rails)をすでに利用されている方を対象に、Rails用プラグインjpmobileを使って携帯向けWebサイトを構築する方法を紹介します。 jpmobileは日本の携帯電話向けのサイトを構築するときに生じる厄介事を、Ruby on Rails流のやり方に倣って解決するためのプラグインです。 Mobile web development that doesn't hurt 日本の携帯電話は「ガラパゴス」と称され、時にやゆされもするように、良くも悪くも独自の進化・発展を遂げてきました。現代人の生活に密着して存在する携帯電話は、位置
馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する(閲覧者が望めば https:// でも閲覧できるようにする)のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。 (8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。) それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。 こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。 つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに
iチャネルはAdobe Systems Incorporatedが提供する「FlashCast」をベースにした、iモード対応携帯電話向けコンテンツ配信サービスです。
iモードコンテンツの仕様や作り方、技術情報、開発ツールなどのコンテンツ制作者向けの情報を公開しています。iモードコンテンツの制作の際にぜひご活用ください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く