Posts

---

Field access restriction inquiry
• P Paul Winterhalder

  Then just call GetSessionForSessionIdAndProfileId() again.

  The check your are doing requires the retrieval of the session from memcached. Retaining a copy of the session and then checking that field later will not solve your use case...

  i.e. if the players session was valid at the time the system calls GetSessionForSessionIdAndProfileId() -- and then becomes invalid while you've got the session cached --- you can't just check the "isLoggedOut" field - because even if you COULD access it - you would be accessing a STALE copy of it.

  So just re-call GetSessionForSessionIdAndProfileId() and if that call is non-null - the session is STILL good - and you are gold.

---

Suggestions based on usage patterns.
• J johnh

  Regarding #1, It looks like this can be implemented within the current functionality as follows:

  When the client is viewing the chat channel, have the client write a user entity saying, in this channel I have read messages up to (the date of the most recent message they have seen). Next, when the app loads the next time, call “getRecentChatMessages” and count up the messages since (the date of the most recent message they have seen). This will give you your count to show for that channel.

  Limitations:
  The chat queue for a channel has a limit of 250.
  Messages have max days and max history (settable by the developer) so if the players been away a long time, some of those messages wont be around to be counted up.
  Go to Messaging Chat to view the settings for these.

---

Suggestions based on usage patterns.
• J johnh

  Regarding #3, The app can store the GroupOwner information in the GroupSummary data which comes back with ListGroups anyway. For existing groups, on login, have the client call GetMyGroups and UpdateGroupSummaryData for any owned groups. The GroupSummary data area is super useful, you could also put say, a group vibe “Casual”, faction alignment or other group descriptor as well.

  Regarding #5 we discussed this idea. The devs emphasized that the description text block can be stored in the GroupSummary or GroupEntities areas. This keeps the system as broadly compatible and efficient as possible for all customers.

---

Field access restriction inquiry
• P Paul Winterhalder

  Hi @noah ,

  That call only returns the session if the user if it's valid and the user is still logged in - so you shouldn't need to check that field. If it's non-null you are good.

  Paul.

---

Are there plans to support Storekit 2 receipt verification?
• M Michael Costa

  Hello @peter.

  That's correct, you get the TransactionID from deserializing PendingOrder.Info.Receipt (at least that is the method I'm using ). The reason why you want the TransactionID and NOT the OriginalTransactionID is because renewed subscription purchases will have two different values for this.

  Just a couple questions so we have more context:

  1. Do you have the Bundle Id field filled on the Apple Platforms page on brainCloud? This is still a requirement for validating purchases. You'll need to make sure to have one set up for your app on Certificates, Identifiers & Profiles and that it matches the Bundle Identifier in your Unity Player Settings.

  2. Are you running CachePurchasePayloadContext() (docs) before VerifyPurchase()? This is also a requirement for purchases of itunes type.

  Please let me know so we can look deeper into this! Thanks

---

Are there plans to support Storekit 2 receipt verification?
• M Michael Costa

  Hello @peter. Thank you for letting us know, we are currently looking into it.

  As a work around, if you ENABLE "Use App Store Server API for legacy receipts (optional)", and the other fields are filled, you should be able to save. Afterwards you can DISABLE the optional value and it will still be able to save.

---

Are there plans to support Storekit 2 receipt verification?
• M Michael Costa

  Hello @LEE-JONG-GUN!

  In order to fill out these values, you will first need to go your app on App Store Connect, then go to App Information. Under General Information you will see the app's Apple ID (this number should also appear in the URL for your app, FYI).

  Next you will need to go to the Users and Access > Integrations > In-App Purchases page in App Store Connect.

  From there you can find the Issuer ID. Next you'll want to click on the + button to Generate In-App Purchase Key. Give it whatever name you think suitable and it should add it to the page. You will then need to download this IAP subscription key; this should reveal the Key ID for that subscription.

  The downloaded IAP subscription key file should be in a .p8 file format. You can open it with a text editor in order to view the Encoded Key. Ctrl + A then Ctrl + C to copy the entire file to the Encoded Key field. Also keep this file somewhere safe, you can only download it once!

  That should be all that's required in order to make use of brainCloud's StoreKit 2 integration .

  Finally the option for Use App Store Server API for legacy receipts (optional) is there to have apps with older integrations of the brainCloud client to make use of the new implementation with the old StoreKit 1 receipt system.

---

Improving inventory inefficiencies
• J JasonL

  Thank you for the feedback. We’ll take a look and follow up if needed.

---

Are there plans to support Storekit 2 receipt verification?
• P Paul Winterhalder

  Hi folks,

  brainCloud 5.9 is now live - with StoreKit2 support. Go to it!

  Paul.

---

Anonymous Login Cumulative Reasons
• P Paul Winterhalder

  Note - the system allows a maximum of 15 anonymous ids. If you exceed that, it will delete the oldest ids to keep you at 15.

  [Background - this used to be totally unlimited - but they really added up for some apps - so we implemented this behaviour and set the max of 15 as being "more than reasonable enough to handle all use cases!"

  Paul.