在iOS上獲取GCM推送通知的注冊令牌的正確順序? GCM不可靠嗎?

[英]Proper sequence to get registration token for GCM push notification on iOS? Is GCM unreliable?


Hi I've followed the tutorial for using GCM on iOS. It has been working intermittently(which means all the certificates, permissions and stuff is okay). However of late, I have been getting the two error messages repeatedly:

嗨,我已經按照教程在iOS上使用GCM。它一直在間歇性地工作(這意味着所有的證書,權限和東西都沒問題)。但是最近,我一直在反復收到兩條錯誤消息:

GCM | GCM registration is not ready with auth credentials.

GCM | GCM注冊尚未准備好使用身份驗證憑據。

Also, reconnection to GCM fails with:

此外,重新連接到GCM失敗:

Error Domain=com.google.gcm Code=501 "(null)"

錯誤域= com.google.gcm代碼= 501“(null)”

This co-relates,in part, to the device not getting a GCM registration ID. Has anyone else come across these issues more frequently of late? Or is it because I'm calling the GCM API in an incorrect sequence (especially the connectWithHandler:, startWithConfig: and tokenWithAuthorizedEntity methods)? I suspect that the reason is the latter since I do get a GCM ID after some delay.

這部分地與未獲得GCM注冊ID的設備相關。有沒有其他人最近經常遇到這些問題?或者是因為我以不正確的順序調用GCM API(特別是connectWithHandler:,startWithConfig:和tokenWithAuthorizedEntity方法)?我懷疑原因是后者,因為我在延遲一段時間后得到了GCM ID。

I do not always receive a GCM ID either. When I don't receive one, I usually have to run the app once or twice more via Xcode. (Or by force-closing the app). Clearly this is not something that my users should have to do.

我也不總是收到GCM ID。當我沒有收到一個,我通常需要通過Xcode運行應用程序一次或兩次。 (或通過強制關閉應用程序)。顯然,這不是我的用戶應該做的事情。

This is the sequence of my GCM API calls:

這是我的GCM API調用的序列:

  1. The device gets an APNS token
  2. 設備獲取APNS令牌

  3. I then call tokenWithAuthorizedEntity: by using my APNS token
  4. 然后我通過使用我的APNS令牌調用tokenWithAuthorizedEntity:

  5. ^ This usually results in one of those two errors mentioned above.
  6. ^這通常會導致上述兩個錯誤之一。

  7. Whenever I actually need a GCM token, I force a refetch of the GCM token by calling tokenWithAuthorizedEntity again.
  8. 每當我真正需要GCM令牌時,我再次通過調用tokenWithAuthorizedEntity強制重新獲取GCM令牌。

Also, I have the connectWithHandler: call written inside my applicationDidBecomeActive: method also.

另外,我還在我的applicationDidBecomeActive:方法中編寫了connectWithHandler:調用。

A couple of questions:

幾個問題:

  1. Is the call to connectWithHandler: in applicationDidBecomeActive: necessary if I am only interested in receiving GCM push messages and not send them upstream?
  2. 調用connectWithHandler:在applicationDidBecomeActive:如果我只對接收GCM推送消息感興趣而不向上游發送它們是必要的嗎?

  3. If answer to (1) is yes, in the completion handler of that method, if an error occurs, and I do not have the GCM token at that point, should I try to get a token again? (i.e. call tokenWithAuthorizedEntity?)
  4. 如果對(1)的回答是肯定的,那么在該方法的完成處理程序中,如果發生錯誤,並且我在那時沒有GCM令牌,我應該再次嘗試獲取令牌嗎? (即調用tokenWithAuthorizedEntity?)

  5. When should the startWithConfig be called? Before getting a GCM token or after?
  6. 什么時候應該調用startWithConfig?在獲得GCM令牌之前或之后?

EDIT: Limited testing revealed that the following appears to work:

編輯:有限的測試顯示以下似乎工作:

  1. Get the GGLInstance ID first (i.e. call getIDWithHandler:)
  2. 首先獲取GGLInstance ID(即調用getIDWithHandler :)

  3. If the above GGLInstance ID was received without any error, ask for a GCM token (i.e. call tokenWithAuthorizedEntity:)
  4. 如果收到上述GGLInstance ID沒有任何錯誤,請求GCM令牌(即調用tokenWithAuthorizedEntity :)

  5. Doing this generally gives the following error, but at least in a short while(~3-10 seconds), the token is received:
  6. 這樣做通常會產生以下錯誤,但至少在短時間內(~3-10秒),會收到令牌:

Unable to find token in cache Error Domain=com.google.iid Code=-25300 "(null)"

無法在緩存中找到令牌錯誤域= com.google.iid代碼= -25300“(null)”

2 个解决方案

#1


4  

Is the call to connectWithHandler: in applicationDidBecomeActive: necessary if I am only interested in receiving GCM push messages and not send them upstream?

調用connectWithHandler:在applicationDidBecomeActive:如果我只對接收GCM推送消息感興趣而不向上游發送它們是必要的嗎?

Yes, connectWithHandler is necessary regardless as its prime purpose is to make connection with GCM endpoint.

是的,connectWithHandler是必要的,因為它的主要目的是與GCM端點建立連接。

If answer to (1) is yes, in the completion handler of that method, if an error occurs, and I do not have the GCM token at that point, should I try to get a token again? (i.e. call tokenWithAuthorizedEntity?)

如果對(1)的回答是肯定的,那么在該方法的完成處理程序中,如果發生錯誤,並且我在那時沒有GCM令牌,我應該再次嘗試獲取令牌嗎? (即調用tokenWithAuthorizedEntity?)

So the way it should work is you check for errors while you are requesting the token itself and retry with exponential back-off if the request fails. More info here. Also, read the note here. Now, if you still want to re-invoke the GGLInstanceIDTokenHandler at any point you should also implement deleteTokenWithAuthorizedEntity before getting a new token.

因此它應該工作的方式是在請求令牌本身時檢查錯誤,如果請求失敗則重試指數后退。更多信息在這里。另外,請閱讀此處的說明。現在,如果您仍想在任何時候重新調用GGLInstanceIDTokenHandler,您還應該在獲取新令牌之前實現deleteTokenWithAuthorizedEntity。

When should the startWithConfig be called? Before getting a GCM token or after?

什么時候應該調用startWithConfig?在獲得GCM令牌之前或之后?

In your AppDelegate.m you should invoke the GGLInstanceID shared instance using startWithConfig method. Essentially in GGLINstanceID.h class, it should first get an Instance ID; then authorize the project as Authorized Entity and then get a Registration Token through the iid service. See the detailed implementation for GGLInstanceID.h class here.

在AppDelegate.m中,您應該使用startWithConfig方法調用GGLInstanceID共享實例。基本上在GGLINstanceID.h類中,它應該首先獲得一個實例ID;然后將項目授權為授權實體,然后通過iid服務獲取注冊令牌。請在此處查看GGLInstanceID.h類的詳細實現。

Hope this answers help!

希望這個答案有幫助!

EDIT

Does this answer your question? Gist of it is, make sure the Bundle Identifier for your target is the same as the BUNDLE_ID in the info.plist file.

這回答了你的問題了嗎?要點是,確保目標的Bundle Identifier與info.plist文件中的BUNDLE_ID相同。

Hopefully this resolves the error, if not post what happened when you test it and we can go from there. :)

希望這可以解決錯誤,如果不發布測試時發生的事情,我們可以從那里開始。 :)

#2


1  

Try move the connectWithHandler block to didFinishLaunchingWithOptions method, after you get the gcmConfig block.(for official's example, after the [END start_gcm_service])

在獲得gcmConfig塊之后,嘗試將connectWithHandler塊移動到didFinishLaunchingWithOptions方法。(對於官方的示例,在[END start_gcm_service]之后)


注意!

本站翻译的文章,版权归属于本站,未经许可禁止转摘,转摘请注明本文地址:https://www.itdaan.com/blog/2015/11/25/7298a5258e55c12e04663f1a8cd27423.html



 
粤ICP备14056181号  © 2014-2020 ITdaan.com