In this article, we will go through what’s inside Playbasis iOS SDK along with its sample apps that were created to give developers guidelines on developing their own applications.
Playbasis iOS SDK consists of the SDK itself, and sample apps. The sample apps are as the following list.
All of the sample applications are designed in the way that you can use them to render information of any application (API_KEY & API_SECRET) created with Playbasis Dashboard. This article also helps explaining how to switch between application as well.
The SDK comes with a pre-defined application that you can test it out immediately. The following information is for such an application.
Make sure that file “apikeys-config.txt” are filled with above API_KEY, and API_SECRET.
Also for a file “demoAppSettings.h”, make sure it is filled with such player-id.
We will use such player-id across the demos. So we define it in one place.
You can change those application information to use your own application. Just update it on those two files.
API_KEY & API_SECRET are sensitive information thus we try to minimize the chance that hackers would be able to break through. This means increasing time and effort on the attacking side.
After those two information are filled in apikeys-config.txt, that configuration file will be encrypted and copied into application bundle. It won’t be copied in clear text, only after encrypted.
During run-time, whenever developers call one of secure authentication related method calls (see below), Playbasis SDK will decrypt the file and read in API_KEY and store it in memory. For API_SECRET, the SDK will decrypt the file and read in on-demand only when it needs to. As API_KEY is use frequently across the API request, it’s better to cache such information in memory. But for API_SECRET, it’s only used when we need to authenticate the application to get token. Thus on-demand decryption to get such information is not regarded as expensive.
The SDK provides the following API calls for authenticating the application that applies what we mentioned above.
But also, developers can call ones of following to directly specify API_KEY, and API_SECRET.
*We recommend to use the former instead of the latter.
Whenever you start the application, you will see the status update of caching complete for certain data.
It was caching data in the background for quests, and reward store. Those cached data will be used to render information to users whenever network is not reachable at the time of making a request. As SDK relies heavily on json-response class, user can cache it very easily whenever response from corresponding request comes back.
Take a look at “globalCaching.m” file for an example on how to do some caching on json-response got back from Playbasis system.
The following is the list of sample apps provided in the SDK.
Go to the “demoApp” folder, and double click to open the project file “demoApp.xcodeproj”.
Then run the project by pressing Cmd + R.
The application will try to authenticate the application, and logging in user. Then finally, you will see a main-menu screen letting you select which sample to play around with.
This demo allows you to make a simple request to Playbasis server, and see the response back. It demonstrates both blocking call, and non-blocking call requests.
The response is parsed by the SDK and showed on screen.
You can modify the demo to show raw json-format response by accessing parseLevelJsonResponse property of response object.
This demo demonstrates how users join a quest, and follow through its mission thus complete it one by one.
Firstly, user need to join the quest, then each quest will present subsequent mission to complete. Each mission has its own required actions for user to do. Whenever you’re in a mission screen (on the right side), touch on action with cross symbol indicated in front of it. Then touch on “Do Selected Action” to do such an action. The application will give feedback indicating that such action is performed, and such action is accomplish as part of the mission.
The quest / mission demo is designed to be able to render multiple quests, and multiple missions by utilizing UIPageViewController. So it will work with all possible of quest / mission data as set in your own application too.
Badge demo demonstrates how such a rule setting up in Playbasis Dashboard works with user’s application. The rule is to do “like” in consecutive of 3 times, then user will get a badge reward. This demo demonstrates the use of showing feedback back to user via status update, and popup which can be called from the SDK directly.
There are 3 questions to complete a quiz. Select an which option to answer, then click on “Next” button to proceed to a next question. Finally after answered all questions, user will be notified about the rewards via status update.
Reward store consists of rewards that can be redeemed. It will send the redeemed code back to user either via SMS or E-mail. For the one who tests these such features, he/she needs to update the phone number, or e-mail via API call of one of the following.
This demo demonstrates sending phone events back to Playbasis system. The basics are button clicking and gesture.
In order to check whether the application successfully sends those phone events, you can check it at the messages on console, or logging in to Playbasis Dashboard for such application then go to “Engine” to see whether such rules have been executed.