Hello readers!

My name is John Wu, Miso’s newest addition to the engineering (specifically iphone) team. For my first blog post, I want to start with something light and talk briefly about who I am and how I came to work at Miso.

I majored in Mathematics as an undergraduate. I chose math for a couple reasons. First, I thought it was easy. Like many of you, math was the one class I never had to prepare for in high school. Math period became synonymous to nap time. I was the kid the teacher never wanted to call on because I’ll deprive others of their opportunity to learn.  Second, I was “good” at it, and by that I mean I felt comfortable manipulating formulas and performing complicated computations, it made “sense”, and I understood the logic. Finally, I believed Math would open the doors to just about anything one could aspire to do — my reasoning was simple: math exists in almost everything, even haikus.

Looking back, I had no idea what I was getting myself into. I was lost during day one of Calculus I. Cryptic concepts such as epsilon-delta, proof by contradiction, theorems, corollaries, and “if and only if” had me dropping classes faster than I could sell my useless TI-89 (did not use this a single time in college). At first, I hated it. I learned proof after proof of theorems that seemed useless. I worked out examples that were so contrived I had a hard time seeing how any of it modeled real life. By the time I graduated with a B.S., I was only comparable in knowledge to mathematicians 200 years ago. My degree felt useless.

But math isn’t pure evil. While extremely difficult to appreciate, crafting proofs, often compared to poetry and painting, is a true art form in and of itself. I distinctively remember showing my professor my one page proof on a fundamental vector space theorem, to which he responded with his version that was exactly 5 lines. This experience led me to my first realization about math beyond calculus: finding the simplest version of a proof for any given theorem, only then will you have understood the theorem in its rawest form. Want some perspective? The popular Pythagorean theorem (a^2+b^2=c^2) has been proven (through distinctive ways) well over 300+ times. My second realization came to me after taking a course in number theory, a sub-discipline studying the positive integers (0,1,2,3,…): not all math is meant to be applicable or even useful, there are numerous theorems out there that well documented and proven, but lack any real world application, they are, in essence, math purely for math’s sake. The mathematicians who engage in this are the picassos and michelangelos of the math world, and who says they won’t offer unexpected insight in the (far) future?

The remainder of my mathematical journey came to an end in graduate school after a tragic realization of myself: that I simply wasn’t bright enough for math, not even to contribute on a microscopic level. I knew this to be true as I found myself begging child prodigies in my classes to help me with my homework. I gave up on a PhD. Rejection was difficult, but not without its lessons. I swallowed my pride, and began searching for something that would allow me to cause a dent. Trusting in my haiku-logic, I eventually found my place in application development.

I found many analogous counterparts of math in development work. Code design is similar to crafting proofs, except I now had the help of my coworkers, and the end goal of creating the simplest version is still sought after. Reading code is like trying to understand proofs, though in a different context, navigating logic turns out to be one and the same. Moreover, my degree accelerated my learning process, my background allowed me look beyond the complexities of the underlying math, such as floating point arithmetic, and focus on creating reusable and scalable code. The differences? Even an average Joe such as myself can contribute, even my code will manage to see the light of day, and be ran thousands of times a day. All along, this is where I belonged.

So I am glad to say, while my choices earlier on in life were based on erroneous assumptions, I do not regret it one bit! And as I continue to work at Miso, I’ll be sure to offer my experiences and help you, the reader, to leverage what we do at Miso to help make your app better. So please look forward to my next post, which will be on styling UINavigationBars in your iphone app. Thanks for reading!

Part 3 is here! Yes, I’m back to writing more about hybrid framework goodness. Today I want to talk a bit about performance optimizations using a hybrid framework.

At Miso, we hold EJS templates on the device and combine it with JSON responses from the server to produce html rendered by a UIWebview. What we learned at F8 is that Facebook delivers the entire html from the server to the device directly. There’s some pros and cons to both approaches.

Miso’s EJS + JSON approach minimizes the payload coming back from the server by just asking for the JSON data. As long as you’re not freely including anything and everything in your JSON response, it should be a fairly small package. The downside however, is that your device would have to handle the process of combining the JSON data with the EJS template. This, in our benchmarks have shown to be fairly costly. Depending on the complexity, in the hundreds of milliseconds.

Facebook’s approach on the other hand leaves the processing all to the server so the device just needs to render the HTML response. This is beneficial especially for slower devices, but the payload coming back from the server is also much larger in comparison.

Both approaches are fine, I just wanted to point out the differences in them. Picking one over the other, like many other engineering decisions, depends on your use case.

Backgrounding EJS Processing

Everyone loves UIWebviews except for one thing. It’s SLOW. Rendering HTML blocks the foreground thread, and there’s simply nothing you can do about it. It was even worse for Miso because we did EJS processing on the foreground as well. Why not just background it? Well, long story short you can’t. The iOS javascript library is invoked from UIWebview (eg. [_webview stringByEvaluatingJavaScriptFromString:@"..."]). Even if you don’t perform any code that affects UI, iOS doesn’t allow you to background that process. To give you a taste of the distribution of processing time involved from start to finish:

EJS Processing – 50%
InnerHTML rendering – 40%
JSON data parsing – 10%

As you can see, backgrounding EJS processing would be a big big win for us. After a few hours of googling around for solutions, it became apparent that in order to accomplish this we will have to import our own javascript library to run in parallel with what iOS provides us. Fortunately, someone has already compiled a JavascriptCore library for iOS for their own purposes here. After successfully importing the library into the project, I wrote a lightweight singleton wrapper in combination with another interfacing class written by this fine gentlemen for you to background javascript by passing it a string.

I’ve open sourced the relevant code on github.

I was able to successfully background EJS processing this way, and boy was it worth it. The pause from foreground thread blocking became a lot more bearable for the cost of adding ~2MB to your binary size.

Making your UIWebviews faster

One of the biggest advantages of using UIWebviews is that you can use all the javascript/css goodness to make your views look tasty. However, as you may soon find out, the more css styling you add, performance starts to slow to a crawl. The most common symptom is that scrolling starts to feel very clunky and jerky. This is especially apparent on older iPhones such as the 3G. To figure out what is the biggest offender here, I went through and removed CSS stylings here and there to get a feel for performance impacts. What I found is that removing corner-radius and box-shadows makes the scrolling much smoother. This is not new as other sources have pointed out similar performance issues related to these new CSS3 features. Until they are addressed, use these sparingly and always try to benchmark with an older device.

If you’ve already stripped down your CSS and it’s still clunky, another factor to consider is sizing down image assets you are using on your page. During my performance tuning journey, to my embarrassment, I observed that Miso image assets were anywhere between 100% to a staggering 2000% larger than Facebook counterparts. We used a tool called Smusher and sized down all of our PNG images significantly. This was the last optimization I did that pushed performance across the finish line.

What I’ve learned through all this is that every bit of processing power should not be taken for granted on a mobile device. The motivation for making the app perform better came from trying to use it on my older iPhone 3G. Any mobile developer should have a base benchmark device to keep them honest. Until next time. Happy coding! :)

PS: If you have suggestions for topics that you want me to cover please feel free to share them in the comments section.