13

Google チームが Android Developer API をアップグレードしたことを発見した後、すべてのアプリ データを一度に複数の言語で自動的に更新するスクリプトを作成しました。

ただし、次のワークフローに従うと、次のことに気付きました。

  1. 編集IDを聞いて、
  2. すべての変更を行います
  3. すべての変更をコミットします

ある時点で、SocketTimeoutException変更を更新しようとすると が表示されます。うーん、これは私の接続に問題がある可能性があります。

それで、それを解決するために、ワークフローを変更しました：

  1. 編集IDを聞いて、
  2. 変更を 1 つ行う
  3. 1 つの変更をコミットする
  4. 変更が完了するまで 1 から繰り返します

ただし、このプロセスに従って、いくつかの変更後にコミットしようとすると、これで終了します。

{
  "code" : 403,
  "errors" : [ {
    "domain" : "androidpublisher",
    "message" : "Daily save quota exceeded.",
    "reason" : "publishingDailySaveQuotaExceeded"
  } ],
  "message" : "Daily save quota exceeded."
}

この API の保存クォータについての説明がないため、私には奇妙に見えます。

また、集中的に使用した後、何もしていないかのように、現在のクォータ制限が 0/200k に固定されたままになります。私はこの API の v1 を使用していないので、これについては何も知りません。

それが正しい振る舞いかどうか知っていますか？

4

2 に答える 2

6

残念ながら、API の使用ページの「推奨事項」がルールのようです。

アルファ版またはベータ版の更新を 1 日に 1 回以上公開しないでください。(本番アプリはそれよりもさらに少ない頻度で更新する必要があります。) 更新ごとにユーザーの時間と、場合によってはお金がかかります。頻繁に更新すると、ユーザーは更新を無視したり、製品をアンインストールしたりするようになります。

しかし、彼らがこのようにそれを厳しく制限していることは私には奇妙に思えます。少なくとも明示的であるべきです。

アップデート

補足として、試みられたアップロードが何らかの理由 (401 無許可など) で拒否されない限り、実際には 1 日に複数回公開できます。上限が何であるかを確認するためにテストしていませんが、1回の試行でレート制限が大きくなると、これをテストするのが面倒になります。

于 2014-11-12T23:03:38.873 に答える