AppCoins News Update, or ANU for short, is a regular bi-weekly update by the AppCoins team. As usual we are going to cover dev updates, market reports, team members and upcoming events. This week’s focus is on IAP Flow, Advertising, ASF Wallet, ASF SDK and Smart Contract Development. You may expect the next ANU on the 23rd May.
After the Gosling release — which we’ve been calling Alpha 3 — we’re back to another news update about the current state of development. We’ll cover what we are doing now and will be doing for the next couple of weeks.
This ANU will cover changes to the IAP and Advertising flows, developments in the ASF Wallet and ASF SDK, and improvements to smart contracts development that are important for the protocol.
Athough they are still in an alpha stage, we are doing some small improvements to the two flows that have already been released: In-App Purchases (IAP) and Advertising.
This flow enables developers to accept APPC as payment for in-app items. It is composed by the interaction between the developer’s app, the ASF SDK integrated into that app, and the ASF Wallet (or any AppCoins compliant wallet in the future).
Regarding the Blockchain part of the flow, it consists of two transactions:
- An approve call to the AppCoins token contract that enables the IAP smart contract to spend APPC from the user
- A buy call to the IAP contract that performs the action of buying an item, which executes the transfers from the user to the developer, app store and OEM
For the flow to be seamless for the user buying the in-app item, the wallet should check if there are enough funds of ETH (to pay for transaction fees) and APPC (to pay for the item itself) to perform both transactions before starting the flow of payment. We will publish an update of the ASF Wallet in Google Play and Aptoide with this fix.
The Advertising flow enables users to earn APPC from using and giving attention to apps that are implemented in active campaigns. These campaigns are created by the app developers, which can be done in the Create Campaign page and then seen in the Offer Wall.
As for the IAP flow, the Advertising flow is also composed by interactions between the developer’s app, the ASF SDK integrated into that app, and the ASF Wallet (or any AppCoins compliant wallet in the future). In this case, the SDK is responsible for checking if the app is being used and for triggering the ASF Wallet to compute the Proof-of-Attention (PoA) components that in the end will form a full PoA, which is sent to the Blockchain. We will publish a fix in the new version of the SDK, related to the PoA submission to the Advertising smart contract in the Blockchain. The SDK should check if the wallet is prepared for the PoA submission before starting the PoA computation process. The wallet should have an account already configured with the necessary amount of ETH to submit the PoA. Otherwise, after the 2 minutes that the computation of the PoA takes, the wallet will simply state there isn’t enough ETH to submit the PoA to the Blockchain, and this translates into a bad user experience.
In addition, the wallet should give feedback about the progress of the PoA computation instead of just stating it is being computed. This is also an improvement we’ll publish in a new version of the ASF Wallet.
As we’ve said in the Gosling release post, we are starting to redesign the ASF Wallet to improve the user experience and the easiness of the interaction with the AppCoins Protocol. We are starting this redesign with the transactions screen and with the individual transaction view, and we aim to have the transactions related to the AppCoins Protocol flows more understandable.
Below are the current statuses of the transactions screen and individual transaction view, and what we want to achieve when we finish redesigning them.
For each flow in the AppCoins Protocol, all transactions are composed by a division between either the developer (IAP) or the user (Advertising), the app store and the OEM. The ASF SDK is responsible for sending data regarding the app store and OEM wallets to the ASF Wallet to make the division possible.
For each transaction made, the SDK needs to be able to know the wallet account of both the app store and the OEM that should be receiving the respective amount of APPC. The protocol defines three possible attribution mechanisms:
- During installation of a given app, the app store informs the operating system (OS) that it has installed that app, and the ASF Wallet is able to get this data from the OS and map it to the app store’s wallet address.
- During the installation of a given app, the app store broadcasts that it has installed that app and the SDK catches that broadcast. The broadcast should include the app store and the OEM that preloaded that app store (if applicable) and the identifiers, which is sufficient for the wallet to map them to the respective wallet addresses.
- If there’s no data regarding which app store and OEM should receive their respective share of a given transaction, those shares go to default wallets addresses configured in the wallet.
We’ll start developing these mechanisms that will allow app stores and OEMs to start monetising using the AppCoins Protocol.
Smart Contract Development
Smart contract development is still in its early stage, with several platforms aiming to take the lead. As of now, Ethereum is still the most mature platform where developers can build their Apps. One important aspect of smart contract development in Ethereum is that when a smart contract is deployed to the network, it is unchangeable. If there’s a bug or if more features should be included in the contract, a new deployment has to take place, and the address that should be used changes as well.
In regards to the AppCoins Protocol, we are building several products (ASF SDK, ASF Wallet, webpages) that interact with our smart contracts. Since we’re in the early stages of development of the protocol, there are several changes that need to be done every day or every week. As pointed above, every time we deploy a new version of a smart contract, all the products that interact with it need to be updated to point to the new address. This can become troublesome to manage and it increases the probability of compatibility errors during development because of lack of communication. When it comes to the ASF SDK, it becomes very difficult to ask developers to keep updating the version of the SDK they’re using simply because of a new smart contract deployment.
Therefore, we’ve decided that we need to decouple the deployments of the smart contract from the other products development. We’ll create a new layer between the smart contracts deployed and the products that use them that serve as a proxy. In addition, we’ll also implement a solution to avoid losing all of the data in a smart contract when we deploy a new version of it. One can think of it as a version of an Eternal Storage.