Building cross platform mobile app using Kony AppPlatform

In the last 48 hours, we built a fully functional production grade Android and iOS app using Kony AppPlatform. The rest of the blog talks about the experience. The app allows a user to get a real-time exchange rate for any two cryptocurrencies. It fetches the exchange information from ShapeShift APIs

Kony AppPlatfom primarily consists of two components:

1. Kony Visualizer: Kony Visualizer is an IDE that allows building mobile application interface using drag and drop – similar to Android Studio or Xcode. If you are developing an application, make sure you download Kony Visualizer Enterprise edition.

Kony Visualizer
Kony Visualizer Enterprise


2. Kony Fabric: This helps you build a server-side application for your mobile application on Kony’s cloud.

Kony Fabric
CryptoExchange App on Kony Fabric

Building application using Kony Visualizer:

The interface to build the application is very simple. Each screen is essentially a form. You create containers (flex containers) which are a logical group of various UI elements. In the screenshot below, frmDashboard represents the dashboard screen. It has lblTitle which represents ‘Choose Which Asset to Trade’ title. After that, there are three containers corresponding to three states in the UI – loading, loaded, error. In the example, below I have turned its visibility on for demo purpose.

You can control the size of the container by adjusting various properties under Look tab on right side. Notice that it is set to left as 24dp  and  right as 24dp . This essentially instructs the runtime to stretch the container width wise to occupy full width of the screen and keep at 24dp  to from both left and right edges.  Center X as 50%  tells the framework to center it horizontally and  Center Y as 50%  to center it vertically.

Screen Shot 2018-10-03 at 12.41.35 AM

You can similarly layout the rest of the components. In order to share the same style, you can create something call Skin (under Skin tab), very much like a CSS class in HTML.

Wiring up code

In order to add interaction to your user experience, you can directly invoke common actions (such as navigating to a form) by clicking under ‘Action’ tab and associated handler for the right event of the element. The below screenshot associates  onClick event handler for ‘Get Started’ button on the home screen to navigate to the dashboard page.

Screen Shot 2018-10-03 at 12.53.26 AM
onClick handler set to navigate to dashboard page

In order to handle more complicated scenarios, you can write custom Javascript. Each form has an associated controller where you can write the functions specific to the form. As an example, when the form is initiated, we invokegetAllCoins  function to fetch all the available cryptocurrencies from our backend.

  getAllCoins: function() {
    var self = this;
    CryptoExchangeServices.getAllCoins(function (err, response) {
      if (response && response.coins) {
        self._coins = response.coins;
        self._setDepositToken(self._coins.length > 0 ? self._coins[0] : null);
        self._setReceiveToken(self._coins.length > 1 ? self._coins[1] : null);
        // Get exchange info
      } else {

It relies on CryptoExchangeServices  module to fetch all the coins. Any functionality that is non-UI specific can be written in a separate module that is available to all controllers. In our case, I createdappServices.js and added it under Modules folder.

CryptoExchangeServices = {};

CryptoExchangeServices.getAllCoins = function (done) {
  var serviceName = "Shapeshift";
  var integrationObj = KNYMobileFabric.getIntegrationService(serviceName);
  var operationName =  "getcoins";
  var data = {};
  var headers = {};
  integrationObj.invokeOperation(operationName, headers, data, function (res) {
    done(null, res);
  }, function (res) {

As you can see, this makes a call to Kony Mobile Fabric. The app on Kony Fabric talks to ShapeShift and returns back the response.

Kony Fabric

In order to talk to an external service, you first need to create a new service:

Screen Shot 2018-10-03 at 1.08.58 AM
Add new service to your app on Kony Fabric

Once you have done that, you can define basic details about the service you are going to integrate to and expose various operations to it. Most of the fields are pretty self-explanatory. For Shapeshift integration, this is how the service definition looks like:

Screen Shot 2018-10-03 at 1.10.41 AM
Shapeshift service definition on Kony Fabric

I will talk more about building a marketInfo endpoint on this service:

In order to get the exchange info between two coins, a call to Shapeshit looks like:

In order to accept the currency pair, we first define front end url exposed to mobile app (or any other client) in general as follows. It accepts pair variable in url.

Screen Shot 2018-10-03 at 1.12.56 AM

We also define it as part of Request input

Screen Shot 2018-10-03 at 1.13.12 AM

Once it’s done, we tell Kony Fabric to pass this variable to Shapeshift endpoint as follows:

Screen Shot 2018-10-03 at 1.12.36 AM

Now, the call to Kony Fabric can be made from the app as follows:

CryptoExchangeServices.getExchangeInfo = function (pair, done) {
  var serviceName = "Shapeshift";
  var integrationObj = KNYMobileFabric.getIntegrationService(serviceName);
  var operationName =  "marketinfo";
  var data = {
    pair: pair
  var headers = {};
  integrationObj.invokeOperation(operationName, headers, data, function (res) {
    done(null, res);
  }, function (res) {

In the next blog, we will talk about how to set up your environment to enable debugging and hence faster development.

Overall, the platform seems pretty straightforward and can be used to build cross-platform quickly.  Questions? Drop in the comments.

Why ERC721 is better than ERC20 to represent a real estate property on ETH blockchain

We recently built a solution to help real estate professionals to record a sale of property and title ownership on the blockchain. See: Using blockchain for title registration in real estate industry

We represented each property via an ERC20 token. Note that each ERC20 token is exactly the same just like how each $1 bill are same – same value, same look, and feel. In order to maintain which token represents which property, we maintained a mapping of address to the owner who currently owns the token:

propertyTransferDetails[_propertyAddress].push(PropertyTransferInfo(Owner(_ownerName, _ownerEmailAddress, _to), ""));

The PropertyTranferInfo is a struct as follows:

struct PropertyTransferInfo {
Owner owner;
string deedURL;


struct Owner {
string name;
string email;
address walletAddress;

Every time a user wants to transfer a property, we would look for the current owner and transfer 1 token out of his wallet and update the information in our contract.

This has two issues –

  1. In the real world, every property is different – shape, size, address, value. ERC20 does not allow to associate properties with a token.
  2. If a user uses a system other than our engine to transfer token, we would lose track of which token belongs to which property.

Enter ERC721. Its a specification to create a token that can have properties associated with it. See technical specifications for ERC721:

We can now associate address (and eventually other properties) with the address itself and each token is unique to a property. The DApp built previously still works as is. If you are interested to see all this in action and like to get a custom software solution built, please reach out to us at


Logging in NodeJS using Papertrail


Recently, I was implementing a 3rd party service in our project and was facing some issue in implementing, I wanted to check what’s missing, what data is being sent and received.

console.log() somehow helps in this, but it’s not a good solution for production, it becomes difficult if you want to see the last week logs, also I wanted handle application errors too. I needed a good log management that helps me in solving these issues.

I was looking for a logger that shows all my requests at a single place and also give alerts whenever an error occurred in my application, so after spending some time on the internet, I found Papertrail very useful for my need.
So along with log management, Papertrail provides a lot of other useful tools like text log, Real-time events, Alerts etc.

We’ll now integrate Papertrail to our NodeJS Application, So let’s get started.

Step 1

First, we need to install the required  modules
npm install winston express-winston winston-papertrail —- save

winston is a logging library with support for multiple transports, in winstona transport is essentially a storage device for your logs, you can read more about it here
express-winston is a middleware for request and error logging of your ExpressJS application
winston-papertrail is Papertrail transport for winston

Step 2

So, After installing modules, create a file logger.js and paste this code

Step 3

Now in your app.js file, use the following code. The expressWinston will add our logger as a middleware, after this, you can see all your request in Papertrail account

Here’s an example of how requests are shown in Papertrail

also if you want to use this as the alternative of console.log, you can you this

logger.log(‘info’,’some demo message’);

Step 6

Now we will create a Papertrail Alert which will notify us whenever an error occurred, we will be receiving notification in our slack channel, also there are other available options which you can use

  1. Enter a search string in the search bar, we are looking for errors only, so will write error and hit enter, you can see all errors now (if any)
  2. Now hit Create Alert button which is at bottom right side
  3. Now you will see lots of integration methods email etc, we will choose slack for now
  4. On next page, add details like how you want error reports and at the bottom add slack Integration’s Webhook URL (you can create a new integration to Papertrail and obtain a new webhook URL )
  5. And hit Create Alert, Now you will be receiving Error notifications to your slack whenever an error has occurred


I hope this approach helps you to integrate log management into your app. Please leave comments or suggestions for improvements!


Code Pal – Best coding practices delivered every day

In our day to day job, we often get busy implementing application logic that we sometimes get to keep up to date with best or latest practices. To us, learning is such a crucial thing that if ignored, it can significantly reduce individual as well as overall team productivity.

We discussed a few alternatives within our team and their pros and cons. We ended up building Code Pal (still in beta). Code Pal is a slack app that sends articles describing best/latest practices to your slack workspace once a day. These articles are picked by our algorithm and vetted by our experts.


It has the following advantages:

1. It saves your team members time and energy. They no longer have to spend time searching on the web.
2. It encourages continuous learning. They spend a few minutes daily to keep upto date rather than sit through online training which can be expensive, time-consuming and may get out of date.
3. Since these articles are written by the domain expert, they often contain knowledge not readily available in books or online training.

If you are interested to try it out, go to It may not contain the technology stack that you currently use in your organization. If that is the case, please drop in the comment section and we will try to get to them as soon as we can.

Software development process at JTC

In this blog, I want to share how we approach software development. JTC is an engineering company where each product engineer takes complete ownership of the feature from development to deployment and monitoring and take great pride in building great software products.

Before we start the actual development,  one of our engineer (usually tech lead) gets together with the project owner (usually the customer) to understand the problems that need to be solved and solution that needs to be built. Once those are finalized, the work is converted into user stories (we follow behavior driven development) and entered into JIRA. We then begin to start executing them.

STEP 1: Sprint Planning
We follow the agile methodology. It all starts with sprint planning. Team members get together on a particular day of a week (Monday in our case), talks about new user scenarios that need to be enabled as well bugs, if any, that needs to be addressed. The work is estimated in story points and planned (factoring any upcoming time offs) for the sprint. Our sprint is usually a week long. All the work is managed in JIRA.

STEP 2: Development and testing:
We use Gitflow branching model and Github for source control. For every task, bug, or story, we create a feature branch. Ex: Consider a story in JIRA:  SEQP-10 – User should see an error message if they entered wrong username or password.

git hf feature start SEQP-10/error_message_wrong_username_password

We use Hubflow (a set of helper scripts) that does all plumbing work to enforce Gitflow branching model. Once all the changes are made and automated tests are written, changes are committed.

STEP 3: Committing changes
Before a commit can be made locally, our bot ensure that changes follow coding standards and run all automated tests to ensure the changes do not break existing scenarios. In case it breaks, our system does not allow the commit.

At this stage, the engineer who made the change goes to Github and raise a pull request (PR). With each PR, they write a detailed description of the changes made, document manual test cases ran, automated tests cases added, and various devices the changes were tested. S/he then assigns relevant engineers to review the code. Our system automatically deploys just those changes to a new endpoint (for web-based projects). Each PR goes through a detailed code review. Here are a few things a reviewer looks for:

1. Reviewer tests the changes on the endpoint to make sure it does what it was supposed to do.
2. Proper comments have been added to the code.
3. Variables and functions are named correctly.
4. Proper validations and null checks are in place.
5. Relevant automated test cases have been added to cover new code path.
6. Proper error logging is done to ensure we can debug the issue in production in case an issue occurs.
7. The code is architected correctly and follows SOLID design principles.
8. Think about all various scenarios these changes might affect.
9. Does user experience make sense? Is it responsive? Does it render well when user zoom in  or zoom out?
10. Performance implications (time and memory)

Once the reviewer approves the changes, the PR is merged and developer moves on to next tasks. Note that we do not have a separate QA team and our engineers own everything from building the feature to testing and monitoring.

STEP 4: Release
As soon the changes are merged, our system auto deploys them to a staging server. At the end of the sprint, the product owner (often our customer) verifies the changes. Once the changes are verified, we release them to production. We have set up monitors on our servers and if there are any errors, bug or crashes that happens, our team gets immediately notified on a Slack channel. Yes, we use Slack for our team communication.

The project team members do a daily standup to talks about the progress they have made yesterday, what they plan to work on today as well as any blocking issues. This makes sure that everyone is on the same page and any blocking issues are surfaced early on.

If you any suggestions, questions or comments about how we do things or ways we can improve, please leave a comment.

Using blockchain for title registration in real estate industry

Update: This demo has been updated by representing a property using ERC721 token. See why ERC721 is better than ERC20 to represent a real estate property

Blockchain is a useful technology to bring efficiency while closing a real estate transaction. If you are new to blockchain, please refer this link.

In this blog, we will cover how it can be used to digitize title registration which then helps to do a thorough search with confidence on title history by eliminating any chances of forgeries in the chain of title. The rest of the blog talks about a proof of concept developed by blockchains experts at JTC for title registration. We use Ethereum public blockchain to record the transactions.

It starts by representing each property as an ERC20 token. A company (or maybe county) can launch a custom ERC20 token to represent a property. In the example below, Title Co. is launching token named JTC to represent a property.

Screen Shot 2018-06-27 at 6.05.39 PM
Title Co. is prompted to sign and submit the transaction


Behind the scene, it deploys a smart contract and creates JTC token. Title Co. wallet now has all the JTC tokens

Screen Shot 2018-06-27 at 6.10.30 PM
JTC Token on ETH blockchain


Now, consider the scenario where Ap #867-859 Sit Rd. Azusa New York 39531 is up for sell and a buyer wants to buy the property.

At this stage, by verifying the ownership documents manually for the very first time, Title Co. will issue a JTC token to the existing owner. This will be recorded on blockchain. Once the transaction is signed and submitted by Title Co., one JTC token is assigned to Theodore Lower wallet.


Screen Shot 2018-06-27 at 6.12.37 PM
Title Co. issues a JTC token to Theodore Lowe who is the existing owner of the property.
Screen Shot 2018-06-27 at 6.14.09 PM
Metamask account screenshot for Theodore Lower after a JTC token is sent to his account










We also built a title history viewer which queries all the transactions about this property from blockchain. At this stage, it only shows one owner.

Screen Shot 2018-06-27 at 6.16.14 PM
Property history viewer after a token is assigned to Theodore Lowe.

Now consider Iris Watson is interested to buy this property. Title Co. will use the ‘Sell property’ function. The form will auto-populate the latest owner of the property from blockchain. It also allow to nominate a notary who will sign the deed along with grantor (seller) and grantee (buyer).

Screen Shot 2018-06-27 at 6.20.56 PM

Once Title Co. will submit this form, it will create a deed and send it for e-signature to existing owner, buyer, and notary.

Screen Shot 2018-06-27 at 6.25.22 PM
Sample deed document received and signed by Theodore

Once everyone signs the document, the token related to property Ap #867-859 Sit Rd. Azusa New York 39531 is transferred to new owner. The deed is recorded on blockchain as well. Property owner explorer now shows Iris as the new owner along with the ability to see the signed deed.

Screen Shot 2018-06-27 at 6.30.37 PM
History explorer shows Iris as the new owner along with the ability to see the signed deed


Screen Shot 2018-06-27 at 6.31.59 PM
Iris Metamask account showing he has one JTC token now.

Since blockchain guarantees that transaction once recorded cannot be tampered with, the software we built demonstrates how it can now be used to transfer and record the title history and quickly scan through all previous titles as well.






The system is also capable to send a physical copy of the signed deed automatically to local county. If you are interested for a demo or see how we can build similar solutions for your organization, please reach out to us at


Return on investment on residential solar energy system in top 20 US cities

We recently built a tool (using SAM model in the backend) to understand if one was to install a solar energy system at their residence on the rooftop, how much time would it take them to recover their investment.

For our research, we picked the top 20+ most populous cities in USA and picked most populous zip code in that city (from here). We made following assumptions:

  1. 12,000 kWh annual electricity consumption.
  2. Customer wants to deploy a solar energy system to replace 100% (or closer) of grid electricity.
  3. Consumption of electricity increases by 3.5% annually while the solar system performance degrades by 0.5% annually.
  4. EPC (Engineering, Procurement, and Construction) cost is 3$/W.

Here are the results:


Please note that break-even point time is in years it will take to recover the system cost with the savings in the utility bill.

So, if you are in California or Hawaii, you should definitely invest in a residential solar energy system with break-even point less than 5 years.

BTW, if we missed your city but you want to know the return on investment in solar energy system in your city, please drop in a comment and we will update this table.

About us:

JTC is a technology consulting firm based out of India and USA. Our Solar practice team works with solar companies across the globe to help them gain business efficiencies by leveraging the best of technology.

If you are a solar company and see how technology can help your business, please reach out to Jai at