What if finding a new job was just as easy as finding the perfect spouse? OK, so maybe my elevator pitch needs work… But this didn’t stop Adam Brodzinski from finding inspiration for his job search app Blonk in an unexpected place: Tinder, the popular dating app.

It seems like Blonk hit a nerve when it launched: the various Reddit and Hacker News threads totaled hundreds of comments. So when I heard that not only was Blonk built with Meteor, but that Adam had also read Discover Meteor, I knew I had to get in touch.

So read on to learn more about:

  • Using Meteor to build cross-platform mobile apps.
  • The common pitfalls of Meteor mobile development.
  • The open-source tools Adam created to help with the process.

The Beginning

Sacha: First of all, can you introduce yourself? Can you briefly tell us about your background?

Adam Brodzinski

Adam: Sure, my name is Adam Brodzinski. I’m 28 years old and I work in Silicon Valley as a software developer. I went to college for computer network security but decided that I really liked building software. I started out making static websites and worked on the front end of WordPress sites.

In the last few years I’ve been doing full-stack work with Backbone & Node. Now I’m working 100% with Meteor and loving the ecosystem!

What does Blonk do? How did you come up with the idea? And how did you come up with the name?

Blonk is a mobile app that helps you find a job quickly by introducing you to the founders or department heads of a company. You just enter in your skills (or import them from LinkedIn), swipe through jobs and tap “Yes” or “No” to indicate you’re interested in that job.

Blonk

The companies swipe through candidates and do the same. When you both say yes, we create a match and open up a chat room to get the discussions flowing quickly.

[Blonk co-founder] Tom came up with the idea after talking to a co-founder of Swell about how mobile interfaces are changing. Then while using Tinder, the inspiration for jobs came to mind. The name… well… I don’t have a great answer but I bet you won’t forget it!

How many people are in the Blonk team? Are there other developers?

We have 3 co-founders including myself, Tom Page, and Patrick Landreman. James Liao recently joined the Blonk team. We’re currently in the process of adding two more to the team and will be looking for another full stack Meteor developer as well!

Swiping through job listings

I’m full-time on development, Patrick splits his time between development and user acquisition, and Tom handles the business development and CEO things. They’re great people to have on the team. I couldn’t do it without them!

Meteor For Mobile

How did you first hear about Meteor? Was it difficult to get started? Did the book help?

I think I first read about it on Hacker News when it was around 0.4 or so. I played around with it a bit, but at that time the auth wasn’t finished.

I picked up the Discover Meteor book around October and couldn’t put it down! It was so well written that I was able to go through it in a couple of days and actually retain it. I built another Reddit clone on my own right after to solidify what I had just read as well as expose any areas I didn’t fully understand. I recommend it to everyone who’s starting with Meteor!

What are your impressions of Meteor for mobile development? Which wrapper did you use?

Well, the Meteor part is really great! It’s a breath of fresh air as we finally have a JS framework that has the same productivity force multiplier as Rails (or even better).

[Meteor] is a breath of fresh air

The PhoneGap part… well… not so much. The PhoneGap project itself has horrible docs and a lot of things still have “catches” across devices. If I knew the iOS framework already it wouldn’t be faster to go this route, but since we’re solid in web development it was a great fit. With Meteor’s flexibility and DDP we can easily integrate with a native app anytime in the future.

Phonegap

Mobile browsers are still very inconsistent across the board. The largest issue was how each browser handled text inputs and the keyboard, CSS rendering in Android, and a lot of small things that shouldn’t really be an issue but are. Not everything is the standards compliant way to do things.

Stumbling Blocks

Building all the UI was a chore as well. When we started there wasn’t a UI framework that felt native and was fast. So I just built one from scratch as we grew. We’re open sourcing a vanilla iOS Meteor boilerplate on GitHub.

Blonk’s in-app tutorial

Dealing with memory, DOM node count, and data bandwidth is a real issue. Everything has to be lean (which I guess is great for learning how to build fast Meteor apps!).

You really have to be careful how much data gets rendered and how many dom nodes need to be rendered. For example you can’t render 100 listings in a linear fashion, even with Blaze. You have to render 3 cards at a time and orchestrate the data and slider in less than 16 ms to get the slider to swipe smoothly.

You really have to be careful how much data gets rendered

We started out with the iframe wrapper method but I had so many text input bugs with iOS7. We’re now using the MeteorRider hijacking method which is working rather well. The only downside is that you need to fetch the JS & CSS before using the app for the first time.

Does the app connect to your server for all its content, or did you bundle the HTML/CSS/JS in it?

Yes, unfortunately it has to connect to the server for the first page load. This is really a bummer but the alternative is to use something like PackMeteor which loads everything locally from the phone.

However, the 5-8 day delay on the App Store was a deal breaker. We’re deploying several times a day and the quick feedback is really nice. It would be really nice to have the ability load from the app locally first and then any new releases are pulled in from the server and cached with AppCache.

We’re deploying several times a day and the quick feedback is really nice

Mobile Matters

Did you make use of any native functionality/APIs?

Currently we’re using the native splash screen, vibrate, device info, connection (data signal info), push notifications, as well as event listeners for ‘pause’ and 'resume’ events.

We also use the Phonegap connection plug-in to determine if you’re on WiFi or 3G and fetch more/less aggressively.

We’re currently serving all of the HTML/CSS/JS for the first page load from Meteor but are looking into using a CDN soon (our other static files are served on the CDN).

How do you handle loss of connection issues?

I’m using a package that I open sourced called cordova-status that listens for online/offline events and calls Meteor.reconnect() & Meteor.disconnect() when needed. This is especially important when the app goes into the background because the app would normally crash when it was brought back up again (due to garbage collection clean up). It also updates a “cordovaStatus” session variable, which helps allows you to reactively handle connection state.

Do you have any tips for using complex transitions inside your Meteor app?

Not really… let me know if you have any! I’ve deferred some of the animations until I can get some more time to perfect them. I want to try out Tom’s Iron-Transitioner or create my own system to do iOS7 transitions. Currently the Blonk app is not really getting the animation details right.

Contributing Back

I’ve heard you’re planning on open-sourcing parts of the app. Can you talk more about this?

Blonk’s chat room

I’ve open sourced a few repos that will eventually allow users to clone down a Cordova iOS shell, mobile app boilerplate, and a few essential packages so you can be ready to upload to the App Store in a few mins. The boilerplate will have basic building blocks like table views, buttons, header, tray, scroll views, etc…

When I started building a mobile web app, there was a lot of UI boilerplate that had to be made. I created a repo called meteor-mobile-boilerplate that has a basic iOS7 mobile app with some basic essential components. This is still a work in progress and needs to be updated to use the new Blaze UI.

Getting OAuth working on mobile was really tough

My repo meteor-cordova-shell has a basic phonegap 3.3 app, a few essential plugins, and sets up MeteorRider. The idea is that you can download it, open in XCode, paste in your meteor server url, and click build.

Getting OAuth working on mobile was really tough. Meteor uses pop-ups in their OAuth flow, which is nice on the desktop. However with Phonegap and its InAppBrowser plugin the flow is broken. I created a package called phonegap-oauth that mokeypatches the OAuth flow for phonegap apps. I haven’t had a chance to test all of the providers yet but it works great with LinkedIn and Google.

I’ve also created a file generator called Meteor-Generate that isn’t quite finished. It’s based on the Rails generator and loosely with MVC (Models are a bit fuzzy). It really helps save time if the file structure works for you.

How would you like to see Meteor evolve in the future? Any specific features you’re looking for?

Oh good question!

  1. I would really like to see an amazing test framework with the same elegance that Meteor brings to app building. Laika and RTD are great build they’re not as complete and fluid as Rspec, Capybara and Rails.
  2. I would really like to see official support for the aggregation framework and full text searching in Mongo. Complex queries are a bit rough in Meteor at this time.
  3. Separate the Meteor core code from my app code so it can be cached easier.

How was the app received so far? Are you seeing a lot of activity?

It’s been received rather well. A lot of people seem to like the idea of swiping through one job at a time and talking directly to the co-founders of a company.

We recently received a ton of attention from Hacker News and Reddit. In fact it happened so quick that it caused a few performance issues. I didn’t limit the number of tags being sent to the client very well and it was crashing certain pages by the end of the night.

We received a ton of attention from Hacker News and Reddit

One tip I can’t recommend enough is make sure your test/development data has tens of thousands of documents. You want to be sure you’re not going to bog down the client with excess data.

We’ve been getting a steady stream of traffic after that first big bump, mostly from word of mouth at the moment. We’ve got some pretty exciting stuff coming down the pipeline, can’t wait to release it!


Thanks so much to Adam for such an informative chat. Mobile Meteor apps is definitely an area worth keeping a close eye on, and something we intend to cover more on this blog!