APP發版小知識


前言

最近在做APP端API修改,修改內容是要在APP畫面上多顯示一個欄位。當時想說:那我就多回傳欄位再請APP端地RD去接欄位。於是改完很開心想說可以直接發PR了,結果就被擋下來QQ
被擋下來的原因是:因為APP要接欄位很複雜

我聽到直接問號????????想說不就接個欄位是要多複雜?於是開啟了再次修改API的路,但今天沒有要討論後續怎麼修改xD是要來跟大家分享當時被擋下來真正的原因

一知半解,到底是多複雜?我就問

本身是寫網頁版,所以通常改完都可以興高采烈發PR,如果code review過了就可以上測試環境順便放鞭炮,待QA測試通過和PM宣布上版就可以直接上版,因為網頁版的server是自家公司自己建立的,所以只要公司內部通過審核就可以上版。

APP的server是綁google或apple,所以當內容有更新就要發版,如果只是上到測試環境,那就是公司內部自己審核過就好,但當要發版上PRD時就一定要讓google或是Apple審核!因為正式環境的server是掛在別人身上阿~為了自家品牌和APP品質就一定要花時間審核。原來這就是麻煩的地方啊啊啊!

所以根本不是什麼APP接欄位很複雜嘛,到底是誰在騙我(其實是你自己聽話聽一半,不然就是你誤解別人的意思!)

上面的資訊都是在詢(盧)問(小)負責ios RD才挖出來的秘辛(?!)

當然也順便問了一下APP端如果要接欄位要怎麼處理。其實跟我想得差不多,就是在model給對應的key跟value,和網頁版前端接後端資料很類似。

本來聽說如果後端API多回傳欄位可能會造成APP端報錯。(對沒錯又是聽說)
和ios RD確認之後果然跟我一開始推測一樣(你以為你是柯南?),API可以多回傳欄位,只是看APP端要不要接而已,如果沒接頂多沒有顯示。

結論

先感謝解答我的ios RD!以後如果要改APP使用的API可以先往用現有的欄位去做更改(增加或組合內容之類的),畢竟發版真的是偏麻煩阿xD

以上內容如果有誤,請協助指正! 感謝

#網頁 #APP






你可能感興趣的文章

[ 筆記 ] Fetch 與 Promise

[ 筆記 ] Fetch 與 Promise

七天帶你初探AR世界-Day 6

七天帶你初探AR世界-Day 6

[ Week 1 ] - Git

[ Week 1 ] - Git






留言討論