Hoiio Developer Blog

Over the last 2 months, we have launched 3 apps on our portal:

• Main Line: a virtual PBX or a main number of any business
• Conference: a convenient way to setup conference call
• Fax: online fax system for business

As we launch more apps on Hoiio Platform over the next few weeks, we want to make sure our users will experience the highest quality of apps.

Today, we have completed testing a new version of Conference app that’s much faster, and more reliable than ever before. To understand how we achieved this, let’s take a look at how Hoiio has evolved on web application development.

Google Web Toolkit (GWT)
We have been using GWT in most of our products, from the user portal to our internal admin dashboard. We have built arrays of custom components that can be reused in any GWT project, making GWT the framework that every web project would start with in Hoiio. Our Apps are no exception. We started developing our apps using GWT and reused a number of major components to speed up the development process. However, we started to feel long in the tooth when feature creep sets in. We also felt the sluggishness of GWT. And as GWT is improved, some of our components and plugins were less relevant in new projects. In light of this, our new Conference app marks our first release without GWT.

Spring + jQuery
Our topmost priority is to ensure that regardless of device, platform or region, Hoiio users will have the best experience in accesing and using our Apps. For each app, we aim for simplicity, ease of use, reliability as well as efficiency of the apps. Yet, the very critical problem that we want to solve is speed. We know that it’s certainly not nice to let our users wait for more than 5 seconds to load an app. At that point, we believed native Javascript is the way to go, and we made a bold move, switching from GWT to a different stack: jQuery on client side and Spring framework on server side.

GWT tightly couples the server side and client side, which means any changes on the client side technology results in a complete rewrite of our app; adopting jQuery and Spring makes client and server side loosely coupled. This means if we, for some reasons, want to adopt another technology in server side, we can easily modify the server side’s code, expose the same sets of APIs to client side, and that’s it.

Main Line was the first app to use this architecture. The result was very positive: app loads faster, our users are happier, and our developers feel that’s the right way to craft our apps. Now, as our apps are gaining more users, and we are receiving positive feedbacks, our next focus are speedy maintenance and upgrade. And that is when we faced an issue that many Javascript developers considered a nightmare: managing Javascript.

Managing Javascript: The issues we are facing
The first problem we got with handcoding Javascript is maintaining states of the views. Right now, it’s rather easy to create great web applications with jQuery. However, our apps are constantly growing, making jQuery declarations and callbacks more complex, and are distributed all over the place. The code becomes more cluttered and hard to read.

The second problem is managing events for DOM elements. In fact, we already experienced the frustration on binding events to the spaghetti code mess that we had created at earlier time. For example, the first version of Conference app has around 15 events, 4 different types of data objects that interact with each other, and many DOM elements that depend on each other in certain ways like CSS effects. We feel that without a proper structure, we will soon face a lot of issues while maintaining our app.

Another problem we are experiencing is mixing HTML code inside Javascript. A good example is when retrieving data to fill a table, there are a lot of append() calls inside javascript. We think this is not a good approach.

BackboneJS, HandlebarsJS and RequireJS
We consider ourselves latecomer in adopting BackboneJS’s great technology. At a glance, BackboneJS gives us a tool to structure our client side code, allowing us to modularly organize our Javascript code so that it’s much easier to maintain and upgrade. It also provides an event-driven communication between views and models, in which events can be attached to any attribute of a model that gives us control over what we change in the view. BackboneJS alone solved most of our problems, and with HandlebarsJS templating engine, most, if not all, of our Javascript problems are solved.

RequireJS, on another hand, helps us further split BackboneJS’s module into separate Javascript files for ease in development. Now, for example, a User model will be located at user.js file, a Phonebook model will be located at phonebook.js file. This is very important to us as we can finally structure our client code in a very nice way.

The disadvantage in our approach is multiple Javascript files, which leads to multiple requests needed when serving our apps’ contents. Therefore, we further optimize our app using r.js: an optimizer for RequireJS which combine all our javacript into 1 javascript file and minified it, allowing for even faster response time. Now, whenever we develop, all modules are clearly defined and separated in many javascript files. Once we’re ready for deployment, our users will see only 1 highly optimized and minified javascript.

The fact: Speed comparison
We measure the speed of our app to demonstrate the performance gain we have achieved. Test machine is in Vietnam, server is in US. Same app is used during testing

Using GWT
First request (no cache) takes 13.6 seconds to complete.
Second request (with cache) takes 2 seconds to complete.

Using BackboneJS + RequireJS
First request (no cache) takes 3.6 second to complete.
Second request (with cache) takes 1 seconds to complete.

The results say it all. BackboneJS and RequireJS beat GWT in every ways: 4x faster without cache and 2x with cache.

Coming soon. For all apps.
We are committed to deliver quality apps. That’s why at Hoiio, we never stop to research the latest technologies that helps to create the best user experience. Conference app is now ready to deploy, and we are starting to make all other apps faster. Stay tuned.

In the last 10 days, developers worked together to create travel apps for THack 2012.

Hoiio is an API provider for the competition. So is Wego, a travel search portal.

As well as being API providers, Hoiio and Wego also jumped into the fun of hacking!

Myself and Choon Kee from Wego teamed up to create FareHound – an SMS application to monitor airfare prices.

You can SMS flight search such as “SIN to SFO on Dec 25 with $1000″ to +65 8537 2489 (up for a limited time only).

For Developers:

FareHound is fully open source on github. It uses Typesafe Stack (Scala + Akka + Play! web framework).

Last year, Hoiio API is one of the API providers for THack, a travel hackathon.

This year, the annual event is back to Singapore, with a change in the competition format. Instead of a 24-hour code-without-any-sleep hackathon, you now have around 8 days to create your travel app.

If you are developer, come and show what you’re made of in Singapore.

Perhaps another winner will find Hoiio API useful.

Hey friends in Singapore,

Ever wish for a way to skip the queue during the busy lunch hour? Well, Hastify FastPass promises just that.

http://www.hastify.com

Hastify is a Singapore based Tech Startup focusing on F&B innovations. Their first product, FastPass, is e-ordering solutions for restaurants to grow their lunch time sales. For users, the main appeal of the service is to skip the lunch queue and save time.

Here’s how it works.

Yup. Simple and cool service created by a brilliant team with communications powered using Hoiio API.

My sister loves shopping and works in the town area. Often, she will have sandwiches for lunch so that she can skip the lunch queue and spend the time shopping instead. I am introducing her to Hastify so that she can have both a hot meal and lunch-time shopping. Cheers =)

Zapier is a service that connects web services easily (similar to ifttt).

For example, when you receive a new email on Gmail, you can send yourself an SMS using Hoiio. The 2 web services in this case are Gmail and Hoiio.

For a web service to work in Zapier, it must have an API. Of course, Hoiio API is good to integrate :)

It turns out Zapier is very easy to integrate. I spent less than an hour to get Hoiio SMS API working.

The rest of this post will cover how I add Hoiio as an app on Zapier platform, so if you simply want to use the service, head over to their website.

1) Setup

Register an account, go to their developer portal, and create a new app.

2) Authentication

Tell Zapier how Hoiio API authenticates.

• Add app_id field
• Add access_token field
• Use API Key (Query String)
• Set the Auth Mapping to

  {"access_token": "{{access_token}}", "app_id": "{{app_id}}"}

3) Actions

Tell Zapier what Hoiio API can do.

• We provide SMS as an action
• Add Message (msg)
• Add Phone Numbers (dest)
• Set URL route to

  https://secure.hoiio.com/open/sms/bulk_send?dest={{dest}}&msg={{msg}}

Note that we use Bulk SMS API so that we can accept sending to multiple phone numbers, separated by commas.

4) Touch Up with Scripting API

Up till this point, Hoiio should work in Zapier, except that Zapier only support Actions with POSTing JSON. For Hoiio API, we POST with query strings (not JSON), therefore it does not work.

Some APIs might not work with Zapier due to slight differences in API design. To solve that, Zapier creates a ingenious scripting API to manipulate the requests. It’s unexpectedly easy. Since Hoiio supports GET with the query string, I simply change the request method to GET.

var Zap = {
  sms_pre_write: function(bundle) {
    bundle.request.method = "GET";
    return bundle.request;
  }
};

That’s it!

Good news!

Hoiio scored a double at SiTF Awards 2012, clinching a gold medal for the category of Cloud Solution, and is also overall Judges’ Choice!

After winning  DEMO Asia People’s Choice 5 months ago, we are extremely proud to have won the Judges’ Choice this time round.

Hoiio API, it’s your choice :) Cheers!

We have added a new API to record the whole phone conversation!

Monitor is a new middle block that we have introduced to accomplish this. Once you have used the Monitor API in your call flow, you can continue with using other IVR APIs. When the call finally ends, you will get a notification, which will provide you the MP3 recording in “monitor_url”.

Following is the classic Customer Helpline example which we have extended.

PS: Don’t be confused by Record API, which is used for a one-off recording, like a voicemail.

New Zealand’s local numbers is now available for developers.

This add our local numbers availability to 6 countries.

1. US: $1
2. Singapore: $4
3. Hong Kong: $4
4. Vietnam: $4
5. Australia: $4
6. New Zealand: $4

All prices is for per month subscription, denoted in USD.

We have open sourced the chrome extension that was released last month.

SMS-to-Phone is a convenient chrome extension to share a website link via SMS. The technology used are Javascript, HTML, and Hoiio API. It was also ProgrammableWeb Mashup of the Day!

If you interested in the source code, head over to github.

We have improved the Transfer API so that you can continue to control the call if the transfer is unsuccessful.

Some of you are using the Transfer API end block to transfer an IVR call to a phone number. However, in the event that the line is busy or the recipient does not answer, there is nothing else you can do.

You have told us that you would like to have control of the call after an unsuccessful transfer, such as sending the call to a voicemail. Now we provide you a way to re-wire the call flow to any middle or  end block! You can use Record API for voicemail, Gather API to ask for another number, or Transfer API to transfer to another number.. It’s up to you!

How to do that?

There is a new request parameter “on_failure” added to Transfer API. You can specify “hangup” (the default) or “continue”. If you choose to continue, you can issue another Middle or End block eg. Play, Gather.