Today we are closing out week three of the OST Alpha III hackathon. The focus this week with Helping Hands was getting set up with some app automation to ensure that I can hit the 1000 minimum in-app transactions. In addition, I’ve also implemented some new incentive-based transactions and re-worked the Send page to facilitate this. I attempted to implement QR-code scanning, but ran into some issues with the Firebase ML Kit and had to move on. Read on for a more details on the wins (and losses) from this last week!
App Automation
Since I am the only developer and tester for Helping Hands, I figured that I would need to employ a little bit of automation to achieve the minimum 1000 in-app transactions. To accomplish this, I’ve integrated the nifty nativesript-dev-appium project into Helping Hands. With this package, I’m able to stimulate most of the application’s features in the same way a real-life user would. I had a bit of trouble getting things set up initially, and continued to face difficulties with APIs missing from the web-driver implementations. However, with relatively minimal overall effort, I was able to implement some short-term workarounds that kept things moving forward. As of today, I have successfully automated the app login, token purchase, and token send operations. Check out the video below for a short demo of the automation. Note that everything in the video is being controlled by the testing script (cool!).
New Workflow For Sending Tokens
In order to support the new incentive-based token transfers (see below), the workflow for sending tokens needed to be refactored a bit. First, you enter the user’s handle, followed by an amount. This has been broken into two separate views (for now) with the intention of adding some auto-complete features in the future. The main new feature is that once a user and amount has been selected, the sending user is now presented with the option to sponsor an incentive in addition to sending the tokens immediately. This page needs to be cleaned up a bit, but the core functionality is all there.
 |
 |
| New User Handle View | New Amount View |
Incentives
The main new feature of the app this week is support for incentive-based token transfers. The idea here is that User A can send some tokens to User B, but the delivery of the tokens to User B is contingent on User B’s completion of some objective or goal. User A may choose which of User B’s incentives he would like to sponsor when the tokens are initially transfered.
The easiest way to understand the workflow is by a simple example. Let’s say that we have three users filling three distinct roles:
- John - Incentive sponsor
- Bobby - Incentive owner
- Susan - Incentive administrator
Incentive Creation
The first step in the process is to create the incentive. At this stage, the incentive owner, Bobby, and the incentive administrator, Susan, work together to craft the incentive title and a description. To prevent abuse, the incentive must be created using Susan’s device.
 |
 |
 |
| Incentive List | Creating Incentive | New Incentive |
Incentive Pledges
Once the incentive has been created, John will now be able to select it when he goes to send money to Bobby. John may choose to either send tokens immediately (user-to-user), or sponsor the new incentive (user-to-company). When John selects the incentive and approves the transaction, the tokens will be transfered from John’s account to the company account. The Helping Hands backend service records this (and all other) pledges associated with Bobby’s incentive. The value of Bobby’s incentive continue to grow as more users submit pledges. All users that sponsor Bobby’s incentive will see the transaction as an outgoing transaction to ‘Donation’ in their ledgers. In the future, this will be augmented with a footnote indicating that the tokens were pledged to Bobby, and the current status of the pledge.
 |
 |
 |
| Incentive List View | Incentive Pledge Confirm | Ledger After Sponsoring |
Incentive Approval
When Bobby completes the requirements of the incentive, it is Susan’s responsibility to confirm that he has done it. This is referred to as ‘Approving’ the incentive. Once she has approved the incentive the backend service aggregates all of the pledges for the incentive, totals up the pledged amount, and executes a company-to-user transaction to send the total amount to Bobby’s account. This transaction shows up in Bobby’s ledger as in incoming transaction from ‘Sponsors’. In the future, he will be able to select this transaction and see all of the donors that contributed.
 |
 |
| Approving Incentive | Pledges Released |
Coming Up
As we enter the final week of OST Alpha III, my primary focus will be on trying to finalize all of the currently implemented features and clean up the UI just a bit. I plan to begin executing automated tests early next week, and will probably start filming some of the video clips this weekend. As we are limited on time, I don’t plan to add any more major features to the app for this hackathon, but I’ve compiled a list of TODOs that I wasn’t able to complete but would still like to implement the next time around. Note that these features aren’t listed in any particular order:
- Barcode (QR) scanning for handles
- Text-based user handles (more like twitter)
- Incentives
- Better details for sponsor/owner of incentives
- Ability for the incentive administrator to deny an incentive, triggering a return of all tokens to donors
- Better UI for incentives
- Add ability to purchase HHT directly in app
- This is not currently supported by OST Kit, but hopefully will be in a future release
Developer Notes
Below is a list of the (mostly) unedited notes that I took over this last week. They capture the struggles that I faced and in some cases how I was able to resolve them. Others are just tidbits of information that I discovered or wanted to remember going forward.
- Barcode scanning seems to be a non-starter using the Firebase ML Kit for NS. Getting the component to load was relatively straightforward, but when pointing it at a QR code nothing seems to happen.
- My guess is this is an issue with the ML model not being downloaded properly. Unfortunately, I don’t have time to debug, as I need to move on to other things. Bummer…
- Getting Appium running was a bit harder than anticipated, but ultimately only took a few hours. Probably about 1 man day of work.
- Don’t forget to include the –devMode and/or –reuseDevice flags when running mocha
- It is possible to get everything running in VS code for debugging, but need to make sure that tsc is generating source maps (I chose inline maps)
- Getting code coverage in a TS/NS app seems to be elusive. This seems like it would make a good blog post, but I’d need to figure out how to make it work first. There does seem to be a github thread that describes how to use Istanbul with WebDriver, but it’s not for nativescript.
- Having some difficulties with the AppiumDriver missing a number of APIs that are supposedly supported. To name a few:
driver.back()driver.isKeyboardShown()driver.hideDeviceKeyboard()driver.waitFor***