欧美成人精品高清在线观看,99热国产在线观看,亚洲精品免费观看

需要注意的是，配置應(yīng)用內(nèi)購買和 Game Center 還是需要通過App Store Connect 網(wǎng)站進(jìn)行配置。

現(xiàn)有的解決方案

Fastlane 已經(jīng)是一個完善的自動化工具，它提供了如 produce 等工具用于更新元數(shù)據(jù)。為啥還要關(guān)心 App Store Connect API 呢？

首先 App Store Connect API 是蘋果官方提供的，適用于所有環(huán)境。Fastlane 基于 ruby 的，限制適用的技術(shù)棧。

其次 Fastlane 是通過 Spaceship 來訪問 Apple Developer Center 和 App Store Connect 的。目前 Spaceship 是通過解析網(wǎng)頁來實(shí)現(xiàn)自動處理的，會有以下幾個問題：

Apple Developer Center 和 App Store Connect 是兩個不同的網(wǎng)站，因此需要兩次認(rèn)證，存兩份cookie。
現(xiàn)在 Apple ID 強(qiáng)制開啟了雙重認(rèn)證，每次登錄需要驗(yàn)證碼，無法完全自動化。cookie 也只能保持 1 個月。
Apple Developer Center 和 App Store Connect 如果有頁面更新，Spaceship 就需要升級來適應(yīng)變化。

如果都能夠用 App Store Connect API 來實(shí)現(xiàn)，則這些問題就不存在了。

App Store Connect API 也有一些不完善的地方，例如其 token 有效期只有 20 分鐘，固然增強(qiáng)了安全性，但是如何簽名產(chǎn)生這個 token，還需要總結(jié)出一個最佳實(shí)踐。

瑕不掩瑜，業(yè)界對 App Store Connect API 還是蠻期待的。Fastlane 在 2.150.0 的分支中已經(jīng)添加對新的 App Store Connect API 的支持。相關(guān)討論 issue：Fastlane: Support new App Store Connect APIs^[1]

App Store Connect API 的新內(nèi)容

文檔

這次新增了 200+ 的 RESTful endpoint，和原來相比翻了一倍。蘋果爸爸還將提供一個 openAPI 規(guī)范文件供您下載（OpenAPI Specification^[2]?是流行的swagger格式的開放標(biāo)準(zhǔn)第三版）。可以在 swagger UI 中查看它，以獲取快速的 API 參考。或者更好的方法是將其輸入代碼生成器中，以更快，更輕松地引導(dǎo)幾乎所有語言的 API 集成。蘋果爸爸還聲稱會添加了一些有關(guān)速率限制和文件上傳等主題的新說明文章，提供可下載的示例代碼，以演示重要的 API 概念，例如創(chuàng)建和簽名身份驗(yàn)證令牌，與API響應(yīng)進(jìn)行交互以及使用新的資產(chǎn)上傳 API。

。詳情可以參考：App Store Connect API Resources^[3]

應(yīng)用元數(shù)據(jù)API （app metadata API）

Session?Expanding automation with the App Store Connect API^[4]?中 Geoff Coffey 是通過一個例子，貫穿講解了相關(guān)的 API，包括以下?5 個步驟：創(chuàng)建一個新版本，設(shè)置定價以更新應(yīng)用程序元數(shù)據(jù)，將構(gòu)建與該版本相關(guān)聯(lián)，然后將該新版本提交給App Review 。本文就做一個簡要的總結(jié)，不再一一列舉了。

新API遵守原有的 App Store Connect API 的認(rèn)證方式。可以參考文章?App Store Connect的新特性(WWDC 2018 session 301 & 303)^[5]，?App Store Connect API^[6]

基本規(guī)則

應(yīng)用元數(shù)據(jù)的相關(guān)資源以及它們的關(guān)系如下圖所示。

圖中每個節(jié)點(diǎn)代表 restful api 中的一個資源，例如 /v1/apps。圖中聯(lián)線代表資源之間的關(guān)聯(lián)，例如：一個 App 可以有多個 App Store Versions。每個資源的數(shù)據(jù)結(jié)構(gòu)如下

data: {

    "type": 資源名,

    "id": 資源ID，

    "attributes": {

        資源自己的屬性

    },

    relationship: {

        "關(guān)聯(lián)資源名": {

            "data" : { "type": 資源名, "id": 資源ID }

        }

    }

}

查詢資源

通過 GET 方法請求資源路徑就可以獲得對應(yīng)資源的元數(shù)據(jù)。

可以通過添加形如 filter[key]=value 的 query string 來過濾返回的結(jié)果。例如：

GET /v1/apps?filter[bundleID]=org.forestexplorer.ForestExplorer

GET /v1/builds?filter[app]=appid&filter[perReleaseVersion.version]=1.1&fileter[version]=3

此時返回結(jié)果 data 是一個數(shù)組。

可以通過指定資源的 ID，來確定的獲得一個資源的數(shù)據(jù)。例如：

GET /v1/apps/資源ID

此時返回結(jié)果 data 是一個對象。

當(dāng)然也可以獲取一個確定資源的關(guān)聯(lián)資源。例如：

GET /v1/appStoreVersions/資源ID/appStoreVersionLocalizations

GET /v1/appStoreVersionLocalizations/資源ID/appPreviewSets

可以通過添加include=關(guān)聯(lián)資源名的 query string 來讓返回結(jié)果同時包含關(guān)聯(lián)資源，例如：

GET /v1/apps/資源ID/prices?include=priceTier

修改資源

修改資源通過 http 的 patch 方法。路徑需要指定對應(yīng)的資源 ID。有意思的是，如果想要用一個原子操作，修改資源的同時為資源添加關(guān)聯(lián)資源。而此時由于新添加的資源還沒有創(chuàng)建，沒有一個正式的資源 ID。可以通過 ${臨時資源ID} 的方式由創(chuàng)建者臨時指定一個資源 ID，并在 data 的同級添加一個 included 其中包含臨時資源 id。只要臨時資源 ID 相同，就會關(guān)聯(lián)并創(chuàng)建。在返回結(jié)果中會更正為真正的資源 ID。例如

PATCH /v1/apps/資源ID/

{

    "data": {

        "type": "apps",

        "id": 資源ID,

        "relationships": {

            "prices": {

                "data" : [{ "type": "appPrices", "id": "${tmpid}" }]

            }

        }

    },

    "included": [{

        "type": "appPrices",

        "id": "${tmpid}",

        "attributes": {

        },

        "relationships": {

            "priceTier": {

                "data": { "type": "priceTiers", "id": "0" }

            }

        }

}

當(dāng)然也可以直接修改一個資源的關(guān)聯(lián)資源，例如修改一個appStoreVersion 關(guān)聯(lián)的build

PATCH /v1/appStoreVersions/資源ID/relationships/build

創(chuàng)建資源

一個典型的例子是在 AppStore 添加一個新的版本：

POST /v1/appStoreVersions



{

    "data": {

        "type": "appStoreVersions",

        "attributes": {

            "platform": "IOS",

            "versionString": "1.1"

        },

        "relationships": {

            "app": {

                "data": {"type" : "apps", "id" : "資源ID" }

            }

        }

    }

}

創(chuàng)建新資源不用添加”id”屬性，創(chuàng)建成功后，ID會自動生成，并在結(jié)果中返回

appPreviews 和 appScreenshots 不僅僅包含元數(shù)據(jù)，還包含具體的圖片、視頻文件，這些怎么上傳呢？圖片、視頻文件被統(tǒng)一叫做 asset，代表大數(shù)據(jù)文件。在創(chuàng)建 appPreviews 和 appScreenshots 的元數(shù)據(jù)成功后，服務(wù)端會返回一個屬性字段 "uploadOperations" 其中包含了上傳 asset 的相關(guān)信息。例如 url、method、offset、length，以及請求的headers。使用者還需要通過這些信息上傳asset。

需要注意的是，?"uploadOperations"?可能返回一個數(shù)組，這樣可以將大文件分段上傳。上傳的順序可以打亂，也可以并發(fā)上傳，其中一塊失敗了只需要重傳失敗的塊就行了。

當(dāng)所有塊都上傳成功后，還需要更新一下 appPreviews 元數(shù)據(jù)的狀態(tài)。標(biāo)記 uploaded 為 true 并且附上 sourceFileChecksum。app store connect 會對上傳的asset再做處理。這個處理是異步的。需要通過查詢 appPreview 的元數(shù)據(jù)來確認(rèn)處理狀態(tài)。

診斷數(shù)據(jù)API （Power and Performance Metrics and Diagnostics API）

診斷數(shù)據(jù)API獲取的數(shù)據(jù)是顯示在Xcode中的功能和性能視圖（上圖）中的數(shù)據(jù)。有另外一個session:?Identify trends with the Power and Performance API^[7]?詳細(xì)講解其中的具體數(shù)據(jù)內(nèi)容。

診斷數(shù)據(jù)可以通過 app 或者 build 維度獲取，具體路徑形如：

GET /v1/apps/資源ID/perfPowerMetrics

GET /v1/builds/資源ID/perfPowerMetrics

這里由于返回的數(shù)據(jù)是蘋果定制的格式，因此需要在請求頭中添加accept類型如下：

accept: application/vnd.apple.xcode-metrics+json

特別指出，在磁盤寫入時，會包含一些堆棧信息，因此還有一個diagnosticSignature的資源節(jié)點(diǎn)以及關(guān)聯(lián)的logs資源節(jié)點(diǎn)

GET /v1/builds/資源ID/diagnosticSignatures

GET /v1/diagnosticSignatures/資源ID/logs

總結(jié)

新的 app metadata API 提供了一種官方支持的自動化發(fā)布app的方案。大家可以開動想象力，發(fā)揮它的潛力。例如，通過這些 API 一些面向企業(yè)的 APP 都可以高效的自動生成定制化版本。再結(jié)合蘋果正在推廣的 Apple Business Manager ，定向?yàn)槠髽I(yè)發(fā)布定制化版本的app。或者未來會涌現(xiàn)出一些簡化開發(fā)的平臺，提供模板和上線服務(wù)。只要你有創(chuàng)意和資源，就可以一鍵在AppStore 上發(fā)布一個應(yīng)用了。

本文章轉(zhuǎn)載微信公眾號@老司機(jī)技術(shù)