参照元(翻訳): Purchasing In-app Billing Products | Android Developers アプリがGoogle Playと接続すると、アプリ内商品の購入リクエストが行える。Google Playによってユーザーが支払い方法を入力するためのチェックアウトのインターフェイスが提供されるので、アプリケーション側で直接支払いの処理を扱う必要はない。 アイテムが購入されると、Google Playはユーザーが所有していることを認識し、アイテムが消費されるまでは同じユーザーが同じ商品IDのアイテムを購入できないようにする。あなたはアプリ内でのアイテムの消費をコントロールでき、再び購入可能にするようGoogle Playに通知することができる。 また、あなたはGoogle Playに問い合せて、すぐにユーザーの購入したリストを検索することができる。これは例えば、ア
Android アプリケーションの作成 への移動 アプリ内決済サービスを利用すると、アプリケーション内でデジタル コンテンツを直接販売することができます。 Google Play のアプリ内課金は、Google の Android 向けアプリ内決済サービスです。このトピックでは、FireMonkey アプリケーション プラットフォーム を使ってアプリケーションで Google Play のアプリ内課金にアクセスする方法を説明します。 メモ: 以下の情報は、Android 向け開発についての主要なドキュメント トピックを補完するものです。続行する前に、「Android モバイル アプリケーション開発」に目を通してください。 サポートされているデバイス FireMonkey では、Android 2.2 以降が動作しているデバイスと、最新バージョンの Google Play ストアに関して、G
はじめに 最近リリースされたUnity 4.3とPhoton Cloudを使って何か出来ないかな・・と思ったので実験してみました。 前編ではPhoton Coundの準備からゲームの下地作り、ゲームサーバーへ接続するところまでを簡単に説明したいと思います。 Photon Cloudを準備する Photon Cloudを使うにはまずアカウント作成が必要です。PhotonCloud公式サイトでExit Games Photonアカウントを作成しましょう。Emailアドレスだけで作ることができます。 アカウントを作成したらログインし、MyPhoton>アプリケーションを確認します。ここに表示されている「AppID」はアプリケーション毎に発行される固有の識別子で、クライアントからサーバーへ接続する際に必要となります。今回はデフォルトで発行済みのAppIDを利用するのでメモっておきましょう。 Uni
リアルタイムクラウド Photon Realtime を利用したゲームはグローバルに分散されたPhotonCloud内にてホストされており、世界中のプレイヤーに対して低レイテンシー、短いRTTを保証しています。 マルチプレイ 接続し、マッチングして、対戦する: PUNは、Unity3Dで作成したあらゆる種類のルームベースマルチプレイゲームにとって強固な基盤となります。ゲームのバックエンドには弊社が注意を配りますので、あなたはゲーム開発に専念できます。 クロスプラットフォーム モバイル、デスクトップ、ウェブ、コンソールへエキスポート可能: Photonは標準的なクロスプラットフォームマルチプレイヤーサービスであり、UnityアセットストアでNo.1のサービスです。 スケーラビリティ PUNを利用したゲームは、CCU数に応じて自動的かつシームレスにスケールされます。また明瞭な価格で提供されます
ここのところずっと要件定義をやっています。要件定義はUSDM/RDRA/ICONIXからエッセンスをもらって自分なりに組み合わせて使っています。そんなわけで、最近考えたことを少し整理してみる。 要求とは? なんか、以前にも書いたような気がしますが、現状の理解を書いてみます。 要求とは、顧客が提供するサービスまたはシステムに対して実現したいと思っていること、と言えます。そして、この要求はRFPに書かれていたりするわけですが、この要求にはレベルがあります。 Lv1 サービスレベルの要求 これは、もっとも抽象度が高く顧客がエンドユーザに提供したいサービスに対する要求です。新規サービスにおいては、顧客自身もその最終形は見えていない状況から始まることもあります。このレベルではサービスがどのようなシステムによって実現されているのかは関係がありません。 Lv2 システムレベルの要求 実際には顧客は既にサ
実は.. 事業運用をオペレーションレベルに展開しないままに、 システム開発をしてしまうことにあります。 入力画面や出力を決めても.. それを使って、いかに日々の仕事をこなすのか? オペレーションレベルまで突き詰めた創りこみをしないで、 専門家だから、プロだからと... コンピュータの専門家に、業務運用の仕組みまで 丸投げにしてしまうことが問題なのです。 要求定義と要件定義の違いを考える どの会社でも、コンピュータのシステムを導入しています。 実績のあるパッケージソフトの導入なら問題ありませんが、 自社のシステムを開発するとなると失敗もあります。 特に、経験の少ないSEが担当した場合や無理な要求をした場合に失敗する可能性が高まります。 その原因は何でしょうか? そこで重要となるのが、システム化の「要求」を 正しくSEに伝えるということです。 SEは、エンドユー
システム設計の世界では、他のエンジニアリングの世界とは異なり、用語があいまいな部分がある。要件と仕様という言葉もその一例である。この2つを同じ意味で使う人もいる。が、私は厳密に区別している。仕様はシステム開発者の側から出すべきものである。しかし、要件はユーザーから出てくるものである。 ■仕様を中心に進められるシステム開発 たとえば、「申込書はこういうように集めてくるので、それを一気に入力したい」というのが要件である。それならばと、「グリッド形式で複数レコードを一挙に入力し、更新ボタンで入力された全レコードを一度にコミットするというように画面を作ろう」というのが仕様である。前者がユーザーから出てきて、後者がシステム開発者から出てくる。 この区別はふつう思われている以上に重要である。 私も情シス部門の人間として繰り返し経験してきたが、システム開発はふつう仕様を中心に進む。開発プロジェクトの会議
補足:p87で指摘しているDefaultBloomKernelですが、完全にパッケージから除外したい場合はブラックリスト機能をご活用ください。 http://api.unrealengine.com/JPN/Platforms/Android/ReducingAPKSize/#%E3%83%96%E3%83%A9%E3%83%83%E3%82%AF%E3%83%AA%E3%82%B9%E3%83%88%E3%82%92%E3%83%91%E3%83%83%E3%82%B1%E3%83%BC%E3%82%B8%E5%8C%96%E3%81%99%E3%82%8B 2018年8月5日に行われた「GTMF 2018 TOKYO」で登壇した際に使用した資料です。 https://atnd.org/events/98232
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く