Mamba.Ruアプリケーションプラットフォームでの作業の印象

この投稿では、Mambaアプリケーションプラットフォームで作業するときに遭遇した経験と問題を共有します。



プラットフォームの説明


Mambaアプリケーションプラットフォームはかなり新しい製品です。 昨年末に、アプリケーションの作成を開始しました。 私には権利がないので、財政、具体例、数字の詳細を伝えることはできません。 主にプログラマーに役立つ技術的な詳細についてのみお話しします。



ゲームとアプリケーション


Mambaは、アプリケーションとゲームの間に特定のラインを作成しようとしていますが、ここの状況は非常に興味深いものです。 私の意見では、2012年の初め頃、ゲームは一般的に禁止されていました。 アプリケーションは、 配置規則 (デートを目的としない場合)に応じて、何らかの方法でユーザーの親しみを促進する必要があります。 FAQのパラグラフ4には、彼らがゲームポータルを行いたくないという条項がありますが、状況によってはゲームアプリケーションが許可される場合があります。



ゲームセクションは非常に「突然」出現し、すぐに多くのゲームが登場しました。 さらに、ほとんどのゲームアプリケーションは、ユーザーを紹介することすら考えていません。 どうやら、これはゲームメーカーとマンバの間の何らかの合意であり、これらのトリックを他の方法で説明することはできません。



APIとMambaとの相互作用


いくつかの例外を除き、提示されたAPIに満足しました。 すべてが非常に論理的で理解しやすいものです。



ユーザーがアプリケーションに入る最初の要求は、GETパラメーター内の対応する変数の存在によって決定されます。 すべてのセッションをセッションに保存することをお勧めします。将来、ページをナビゲートするとき(フラッシュアプ​​リケーションを使用しなかった)、mambaの一意のユーザーIDであるsid(セッション識別子とoid)が必要になるためです。 最初のものがないと、ほとんどのAPI関数にアクセスできません。



セッションが期限切れにならないように、少なくとも時折、アプリケーションをajaxで「プル」するようにしてください。 すべてがセッションの設定に依存することは明らかですが、ユーザーを失った場合は、F5キーを押すようにユーザーを招待することによってのみ、「復活」できます。



最初の呼び出しの後、sidキーは4時間有効です。 ただし、コツは、ドキュメントに「SIDキーはサーバーへの最後の要求から最大4時間後です!」と書かれていることです。 だから-これはすべて真実ではありません。 生成の瞬間から4時間に相当します。 つまり、ユーザーがアプリケーションにログインすると、最大4時間そのアプリケーションにとどまることができます。 さらに、すべてのapi呼び出しは誓います。別の方法で新しいキーを取得することは不可能であるため、ユーザーにF5を押すように要求する必要があります。



APIの一部が互いに完全に独立して機能しなくなる可能性があるという事実に備えてください。 時々それらが落ち、5枚中1枚のリクエストで写真が提供されない場合がありました。F5を押すと、空のデータを定期的に受け取ります。 人の写真がないかのように。



次の問題は、ユーザーがデータを変更することです。 APIを頻繁にプルしないために、何らかの情報(写真へのリンク、名前、年齢)を自宅に保存することを強制されます。 しかし、残念ながら、最後の呼び出し以降に変更されたかどうかを調べることは不可能です。 アドバイスはしません-各アプリケーションごとに個別です。 しかし、私は、特に女の子の場合、写真が十分頻繁に変わるとしか言えません。



フラグを立てることは非常に便利です。アプリケーションがユーザーにインストールされているかどうか、定期的に(夜間に)ユーザーが削除したかどうかを確認するためです。 そのようなユーザーに通知を送信することは意味がないためです。



このページで説明されている署名生成は、原則として機能します。 ただし、 $ request_paramsに空の値を含めることはできません。 APIへのすべてのアクセスは、リクエストパラメータというフィールドを持つクラスの形式で行われただけです。 また、サーバー間リクエスト(たとえば、通知を送信するためのコンソールクラウンタスク)では、sigフィールドはNULLでした。これは入力されていないため、署名を作成するときに他のすべてのフィールドと同様に実際に反復されました。 これが私たちのカントであることは明らかですが、私は長い間エラーの場所を探しました。



アプリのURLに注意してください。 誤って通常のドメインからwwwへのリダイレクトを残したため、アプリケーション設定にwwwのないアドレスがあったため、JS-APIは機能しませんでした。



支払い用のシークレットURLは「課金プロセッサURL」です。 これは本当に魔法です。 ドキュメントのどこにも、支払いの受領時にmambaからの着信要求にスクリプトが正確にどのように応答するかがわかりません。 そのため、これは「 サーバー応答フォーマット」セクションで説明されていることに注意してください。 はい、これはサーバーに関するものです。 さらに、スクリプトが何を返したとしても、お金はまだクレジットされます(常に持っているとは思いませんが、それが起こったのです)-これは悪いことです。なぜなら、ユーザーはあなたのアプリケーションに自分のお金を見ず、動揺するからです。



以前は、JS-APIでは、補充ダイアログの原因となるjs-scriptの本文にapp_idを直接記述する必要がありました。 さて、これはそこにありませんが、その瞬間まで気になりました。なぜなら、1つのテストともう1つの戦闘という2つのアプリケーションがあり、時にはこの数字を変更するのを忘れていたからです。



mambaが開発者向けに確保しているもう1つの楽しい瞬間:すべてのテスト(未公開)アプリケーションがプロファイルに完全に表示されることに注意してください。 アチーブメントボードには、これらのアプリケーションからのエントリも含まれます。 彼らが言うように、些細なことですが、不快です。



サーバー間(つまり、ユーザーのセッション外)を要求するときは、secure = 1を設定することを忘れないでください。そうしないと、何も機能しません。



ユーザーへのメッセージの送信-明確にするだけです。 メッセージは、アクティブセッションで送信することも、アクティブセッションなしで送信することもできます。 前者の場合、メッセージは現在のユーザーに代わって、連絡先リストに登録されているユーザーにのみ送信できます。 これを行うには、contacts.sendMessageメソッドを使用します。 2番目のケースでは、 notify.sendMessageを使用する必要があります。 しかし、2つのポイントがあります。残りのメッセージを返すdaily_balanceは 、私の記憶では決して変更されておらず、ほとんどの場合は単なる定数です。 たぶん、彼らはそれを修正します。 また、通知はすぐに届かず、すべてに届くことはありません。



マンバアンケートのデータを(完全に保存する必要がある場合)Mongoに保存することをお勧めします。 ネストされた巨大な配列を保存するのに最適です。



ブラウザ


IEはいつものようにフリークアウトします。 特に、セッションはフレームで動作しない場合があり、常にではなく、特定の時点でのみ動作する場合があります。 素晴らしい見出しが役立ちます。



my-app.localのようなドメインで実行するテストアプリケーションがある場合、オペラで「Allow Cross Network Navigation」を有効にする必要があります。



積極的に設定されたadblockは、フレームのコンテンツをブロックし、表示しない場合があるため、アプリケーションのあるページのアドレスを例外に追加します。



iOSおよびiPadでのサファリ問題の準備をします。 デフォルトでは、Cookieはフレーム内に保存されません。 これは実際にはプライバシーポリシーであり、回避することはできません。 唯一の解決策は、Cookieが設定されていないことを確認し、ユーザーをセキュリティポリシーの変更方法を説明する特別なページにリダイレクトすることです。 この質問は、アプリケーションでセッションが必要な場合にのみ適用されます。



総論


モデレートは十分に高速です。 しかし、申請が生きている人で満たされていないという理由で、節度が拒否される場合があります。 つまり、モデレートの前に少なくとも10個のプロファイルを入力する必要がありますが、SIMカードの入手先は誰もわかりません。 開発者アカウントはありません。 彼らは原則としてクラスに欠席しています。 困難なのは、電話に結び付ける必要のないタイプのアカウントを作成することですが、特定のアプリケーションにしかアクセスできませんでした-わかりません。 どうやらマンバはまだ成熟していないようです。



しかし同時に、一部の国では、電話による確認なしでプロファイルを登録することが可能です。 彼らが外国地域でいくつかの制限を持っていることは明らかですが、そのような国のリストを知っていれば、あなたのアプリケーションがこれを許可していれば簡単にプロファイルを登録し、さまざまな種類のチートを作成できます(招待された友人へのボーナス、無料の定期的なボーナスなど)。 そのようなことに注意してください。 必要に応じて、アプリケーションから電話を確認していないユーザーを完全に遮断できます(anketa.getFlagsメソッドのis_realフラグは0になります)。



技術的な支援を得るのは非常に難しいことに留意してください。 自分で間違いや理解不足を掘り下げる必要があります。質問できる最も簡単なフォーラムすらありません。 開発者に連絡することはできますが、それは非常に長い時間であり、答えがあなたに合っているという事実ではありません。



最近、さらに興味深いことが起こりました。 アンケートの一部とその中の情報の構造が完全に変更されました。 ブロック「Interests」が登場しました。 そして、これらすべてにより、APIを介して新しいデータを取得することは不可能です。 それらは単にそこにありません。



まあ、最初に最も重要なことはインストールの数であることを忘れないでください。 したがって、最初の段階では、収益を忘れて、新しいユーザーの数を増やすことさえできます。 これを行うには、アプリケーションにリストされている友人にさまざまなボーナスを使用します。 忘れられないように、アチーブメントボードとボーナスを使用して、アプリケーションをお気に入りに追加します(これはAPIを使用して簡単に確認できます)。 さて、すべてを記録します。 さまざまなログ用のタブレットで個別のデータベースを取得し、すべてのユーザーアクションを記録します。 将来、何が起こったのか、どうすればこれを回避できるのかを把握するのが容易になるでしょう。



UPD:投票したすべての人に感謝しますが、この投稿はアプリケーション開発マニュアルではありません。 最も簡単なアプリケーションは、ドキュメンテーションを注意深く読むことで、ある夜に行うことができます。 ここで落とし穴について説明します。落とし穴は、これに直接遭遇した場合にのみ学習します。 そして、この投稿がこれらの石の回避に役立つことを願っています。



ZaiSLと共同執筆した投稿



All Articles