Jonathan Bender, Author at The Contactually Blog | For Relationship-Based Businesses
Contactually’s API v2: Easier Development and Integration

Contactually’s API v2: Easier Development and Integration

Last week we introduced The Contactually Marketplace — a freshly designed and formatted directory of every integration built on top of Contactually’s framework. It allows you to quickly access to all the tools needed to leverage your network and build authentic relationships that make a meaningful, fruitful impact on your business. For anyone who’s already listed on our marketplace, or wants to build an app that plays nicely with Contactually, we’re pleased to announce our all-new API v2. This API is developer-friendly and well documented, with sample code in four popular programming languages. Introducing Contactually’s API v2… Ease of integration for developers Understanding the process to integrate and create a partnership is one thing, but to follow through is another. In days past developers would find themselves sifting through copious amounts of data — only left to parse and structure for later use. A heavy burden left to the partner to allocate resources and address the issues. If it’s meant to be a partnership, then where’s the helping hand? Contactually’s API v2 is updated with new endpoints and OAuth2 allowing for quick and seamless sign-on. It is redesigned and refactored groupings upgrade speed and legibility for simple integration. Even more apps that work seamlessly with Contactually We’re building the Marketplace by partnering with the best apps and companies to offer the greatest solutions for all of your business problems. This means a robust selection of better quality apps that complement the way Contactually works with your business and processes. Writing on the new API From the planning stages of our v2 API, we concentrated on how it would feel...
Building Contactually’s iOS App 3.0

Building Contactually’s iOS App 3.0

A few months ago, our team decided to revisit our mobile experience, and to evaluate alternative means of developing the next version. In the end, we decided to build our app in RubyMotion! We did this for a variety of reasons, but they largely boiled down to familiarity with the language and available libraries (both Ruby and Cocoapods). After a few months of busily writing code, we thought we’d take some time to talk about how that decision worked out. To start out: we’ve shipped iOS v3.0! It’s in the App Store, and if you haven’t already grabbed it, go do that now, it should provide some context to the rest of this article. Technical highlights of the new app: Customized table views with “cards” Gestures tied to swipe movements on the cards Progressively-loaded lists Detail views with nested tables 400% faster than the previous version (2.4) iPad-friendly through constraints How We Approached Development Building an iOS app on a “blank slate” was both a blessing and a curse. We had no technical debts from a previous API or architecture holding us back, but we were also starting from nothing and needed to build it all back up again. We started with the API (v2 will be published soon!), and took an outside-in approach to its development. From there, we built out a Ruby client that allowed us to interact with the API as though it were our persistence layer (database). With the foundation of these models, we were able to concentrate on the views and interactions. Everything else was table stakes. Everyone expects an app to be able...
Picking a Mobile App Framework

Picking a Mobile App Framework

Note: This is part two in a series.  Part one is here. There’s no shortage of ways to build a mobile app these days. HTML5 is on the upswing (again), and quasi-native frameworks are popping up almost as often as Javascript libraries. Here at Contactually, we wanted to take the time to re-evaluate all of the current leaders in the mobile app framework space to give us the most bang for our buck. We were looking for the framework that gave us: Longevity – we don’t want to have to write from scratch again Interoperability – we have a dev team of very talented Ruby and web developers that we’d like to use across teams if possible. This also ensures that the mobile devs would be able to troubleshoot anything that goes wrong with our API Hirability – we want to make sure that we don’t pick a language that’s too specialized, which would make it hard to make any experienced hires (or experienced hires prohibitively expensive) Developer Happiness – writing for mobile shouldn’t be a burden; we want to pick a language and framework that makes the most sense to the most developers In this search we looked at several mobile app frameworks, but ended up prototyping with three frameworks based on our initial research: Swift 2.0 – The truly native choice. It’s the only one that we looked at that’s sponsored (and actively promoted) by Apple ReactNative 0.12.0 – Facebook’s newly-published framework that brings React to the native environment, complete with bindings RubyMotion 4.4 – Commercial product that allows you to write in Ruby and compile down to App/Play Store...
Lessons Learned: Four Years of Startup Mobile App Development

Lessons Learned: Four Years of Startup Mobile App Development

Here at Contactually we are reinvesting in our mobile apps.  Four years after our founding, we finally have the ability to build mobile applications that live up to the standard of our core web experience. To make that a reality, we’ve taken a step back to plan out our vision and framework for the future. In doing so, we wanted to document how we got here, and hopefully help any other startups who find themselves pulled in a million directions to develop products across all the platforms available today (just kidding about that last one). In part one, we’re going to give a history of our mobile app development — the choices we made at the time and lessons learned. Lessons Learned from 4 Years of Startup Mobile App Development 2012 Our founders were web developers (Ruby on Rails) who naturally focused on building out our app for the web. We specialized in scaffolding things out quickly and seeing how users reacted. After gaining traction, by 2012 the demand for an iOS app had grown to the level where we knew we had to do something. HTML5 apps were gaining in popularity (though not without some major detractors later that year), and it was a technology we already understood, so we went for it. We built our first iOS application using Appcelerator Titanium, and covered all the basics of Contactually. You could create contacts, bucket them, and make notes about them. Because we understood the core of the technology before building it, it only took a month to go from first commit to initial release. During that development, we also built out the first version of our...