Sunday, March 31, 2019

We Are Hiring!

We Are Hiring! Yep, you head me. We Are Hiring!

If I had to describe my entire journey at Makkajai in one word, it would be "FUN". Every single day has so much to offer, new challenges, newer and bigger problems to tackle, lots and lots of learning and above have lots of fun!

It's a company that I co-founded, so I am programmed to like it. However, here are some data points that might help you decide for yourself. Here is a small list of achievements from the past year

  • We have written code in about 8 different programming languages.
  • Build lots of tools and services to enable our marketing team drive organic growth
  • Built and released 3 new games, with a very thin DEV team.
  • Did numerous hours of play testing of our games with actual kids. Incorporated play testing feedback into our apps.
  • Our Content team built 60 books worth of printables which is available to print from our apps

We are growing, we want to do even more awesome stuff.

If you are bored doing routine stuff, if you are in your comfort zone and that scares you, here is your opportunity. 

Click Here to see all our open positions, apply only if you don't fear challenges and are ready to make a real impact on learning outcomes for millions of kids worldwide!

Wednesday, February 27, 2019

How To Pass User Defined Properties To Android APK

We were looking around for ways to pass additional information to our Android app at run time. Main intent behind this was, to effectively test certain flow in the app - one such example would be the In-App Purchase flow.

One way of achieving this is by setting properties via ADB and reading their values from within the app via code. This post is about documenting the steps needed to achieve this.

There are two main parts to the solution
  • Setting the properties via ADB on the command line
  • Reading the property value from within the app via code and using its value to alter the app behaviour.

Without further ado, let's look at the actual code needed to achieve both parts.

The Solution

Setting the properties via ADB is pretty straightforward and we can easily do it with one line of code as follows

Here we are setting the property "log.tag.GITIAP" to value "DEBUG"

Reading the property value from within the app via code, needs a little bit of work. Here is the full code that will let you read the property "log.tag.GITIAP".

That should do it! When you call the method "PropertyHelper.initializeProperty()" it will set the value of "gitIAPValue" to the value that was passed via ADB.

Thursday, January 31, 2019

The EMI on Card Scam

It's pretty common practice to convert big spends on EMI. The EMI is sometimes marketed as "No Cost EMI" and sometimes it comes at a declared interest rate. Whether we purchased the goods online or from physical stores, option to convert the transaction to EMI is available.

This post describes, how Customers are scammed into paying more by the Card companies by hiding an important detail related to the EMI conversion.

Recently, I bought a Mac Mini for Rs. 100605. Because of its high cost, I decided to convert the transaction to a 24 month EMI. At the time of purchase the sales people explained me that, I will be charged 15% annual interest on the EMI transaction.

They told me, the total Interest charged over 24 months would be Rs. 16467. Hence at the end of 24 months, I would be paying Rs 100605 + Rs 16467 ~ Rs 117072.

This was perfectly fine with me as I knew exactly what I was getting into and how much extra I am paying.

After the transaction was over they even gave me a charge slip which had the details of the transaction such as

  • Tenure : 24 Months
  • Base Amount: INR 100605.00
  • Applicable Interest Rate (P.A.): 15%
  • EMI Amount: INR 4877.99
  • Total Amount (with interest): INR 117072

All of the above details were clearly mentioned on it. Below is the picture of the actual charge slip I received. Focus on the Red box for now, which highlights the above details.

Charge Slip

Notice how the "Total Amount (with interest)" matches the exacted total amount we calculated above. Till this point, I was super happy, transaction was done with transparency. I knew exactly how much am I paying. I even told my friends that these EMI transaction are great and now they have become pretty transparent.

Little did I know, I am in for a big surprise. After a few days, I was sent an Amortization Schedule from the bank. Out of curiosity, I checked the schedule to see if the totals are matching up. To my surprise, bank was charging 18% GST on top of the interest! 

On the interest amount of Rs 16467 they are charging 18% GST. This was over and above the marketed 15% annual interest.

This meant that, I am paying Rs. 2964 extra on top of Rs 16467 interest. It translates to extra outflow of Rs 16467 + Rs. 2964 = Rs 19431. Total outflow = Rs 100605 + Rs. 19431 = Rs. 120036! 

Here is the Amortization Schedule sent to me by the bank.

Amortization Schedule

Whats the scam here? 

Card company choose to conveniently hide the fact that GST will be charged over and above the marketed interest payout. No where on the charge slip do they mention the total outflow as Rs 120036. In fact they scam the customers by mentioning the Total Amount (with interest) = Rs. 117071.

Now sift your focus to the Green rectangle of the charge slip, bank simply mentions that "GST applicable on Interest and Processing fees" now thats convenient!

I was never told about this before the transaction. In fact, I had failed to notice this line even after the transaction. Only when I checked the Amortization Schedule and checked the charge slip again, I realised how I was scammed!

Please, please beware of what you are getting into and how much extra are you going to pay for any EMI transaction! Generally speaking customers end up paying 2.5-3% extra interest over and above the marketed annual interest rate!

Monday, December 31, 2018

How To Reorder cells in UICollectionView using Swift

While building out a feature, in one of our Apps, I was faced with a need to reorder the cells in UICollectionView using Swift.

I looked around and found many ways of doing it, some of them work and some of them didn't. Heres an implementation that we ended up using and which is working for sure.

The Solution

Here are the steps to get the reorder feature working using drag and drop

  • We need to implement the method collectionView(_ collectionView: UICollectionView, canMoveItemAt indexPath: IndexPath) -> Bool from the UICollectionViewDelegate protocol, to indicate that the cells in UICollectionView can be moved around.
  • Next, we need to implement the UILongPressGestureRecognizer for the UICollectionView so that we can better handle the long press gesture
  • We are adding the gesture recognizer to the UICollectionView and setting up the callback method to handleLongGesture(gesture: UILongPressGestureRecognizer)
  • In the callback method we are letting the UICollectionView know about the interactions. 
  • Most of the work is already done, only thing left is to handle what should happen when the items are moved around. This can be achieved by implementing the method collectionView(_ collectionView: UICollectionView, moveItemAt sourceIndexPath: IndexPath, to destinationIndexPath: IndexPath) from the UICollectionViewDelegate.
Thats about all the code thats needed to achieve reordering of cells in UICollectionView using Swift!

Friday, November 30, 2018

How to use a Git Submodule's https url without username

We were starting on a new project and we had a git repository for it (no surprises here :)). This repository was hosted on bitbucket. We were using it over HTTPS because of various reasons.

The Problem

Soon enough we wanted to add a submodule to it. This submodule was hosted on bitbucket as well. This posted a tricky situation, because the HTTPS url looks like


Notice that it embeds the username i.e. deep into the URL itself. This URL is used in the .gitmodules file that is tracked in the parent repository.

This wouldn't have been a problem if, I was the only one working on the project. However, there were other developers wanting to work on this repository and check out the submodules. Unless I get rid of the username from the submodule URL, other developers would not be able to pull/push the submodules and contribute to the repository.

The Solution

I looked around and finally found a very simple solution to this problem. The solution works very well, as long as the main repository and submodules reside on the same server i.e. bitbucket in our case. Lets say that the parent repository URL was 

  • As you can see both the parent and the submodule are hosted on the same server.
  • We need to edit the .gitmodules file located at the root of the parent repository. This is a text file and can be opened in any text editor.
  • Locate the Submodule and its HTTPS URL there. It would look something like this
  • Next, we need to edit the submodule URL and make it relative to the parent repository URL
  • In this case, the relative url would look like "../module.git"
  • Updated .gitmodules looks like this
  • After this all we need to do is push the updated .gitmodules.
  • Thats it, now other developers will be able to pull and push changes to the parent repository and its submodules like any other repository!

Tuesday, October 30, 2018

How to debug a web page on iOS - Part 2

In this post we will continue our pursuit to debug a web page on iOS. Wont it be nice, if we had Chrome Developer Tools kind of interface even for the iOS?

The second way to investigate webpage errors on iOS is going to achieve exactly that, but using Safari!

The Solution

Apple natively supports remote debugging of webpages on  iOS since iOS6. Here are the steps that are necessary to enabled it.
  • Open Settings app on iOS device
  • Click on Safari

  • Here, click on Advanced

  • Next, enable the Web Inspector switch.
  • Now, head over to your Mac and open Safari.
  • Click on Safari --> Preferences

  • Click on Advanced tab and enable Show Develop menu in menu bar 

  • This will Show a new menu item called Develop right next to the Window menu item.
  • Now, Connect your iOS device with the Mac using a cable.
  • Next, Open the Safari browser on the iOS device and open the webpage that you want to investigate.
  • Click on Develop and you should see your iOS device listed there.
  • Clicking on your iOS device name under the Develop menu, should show up all the web pages opened on the iOS safari browser.

  • Click on the webpage that you want to debug, this opens up the Safari Web Inspector 
  • Here, you can select elements, manipulate CSS, investigate console errors, look at all the network calls, profile your app and more. 
  • Notice when we inspect a div in the Web Inspector, it automatically gets highlighted on the iOS device

    Nice isn't it?

    Sunday, September 30, 2018

    How to debug a web page on iOS - Part 1

    One of our customer, recently wrote an email to our support team about a problem they were facing. They were not able to view the "Printables" section of Monster Math Games. This section shows list of free and paid Printable activities. This page is designed as a web page instead of a native screen and loads in a web view on the app. The customer was only getting a blank white page.

    I started investigating the issue, initially I thought it might be some sort of network latency issue or  something related to HTTP vs HTTPS. But it turned out, the problem was with one of Javascript API we were using.

    The Problem

    Debugging a web page on iOS device, is not as straightforward as I had initially thought. I learned two very interesting ways of debugging webpage errors on iOS. This post is an attempt at documenting these two approaches so that it could help someone who is facing a similar problem.

    The Solution

    The first thing I wanted to check was the actual source code of the web page. Here are the steps we need to follow to view HTML source of a web page.

    • Open this post on the iOS safari browser
    • Click the upload icon button on the menu bar, then click the "Add Bookmark" button.
    • Change the Title field to "View Source" and hit "Save"
    • Next we need to edit this bookmark and change the Address field to the following javascript code. Copy all the text from the following gist.

    • It needs to be done this way because, iOS Safari doesn't let us edit the Address field while creating the bookmark.
    • Click on the "Book Icon" in the menu bar to bring up your bookmarks. 
    • Click on "Favorites", you should see the newly created book mark "View Source".
    • Click the "Edit" and then tap on "View Source" bookmark.

    • Now select the Address field and paste the copied code.
    • Hit the "Done" to save the bookmark.
    • Visit the web page whose HTML source you want to view.
    • Once the page opens, click the newly created bookmark "View Source". 
    • This will open up a popup with details of the web page

    • This Popup has a "View Source" tab that shows the HTML source of the web page.

    Pretty cool, huh!
    Have some Fun!