Blog

Beyond the exciting news surrounding the Apple Watch and iPhone 6, Apple’s announcement of their new Apple Pay platform is arguably one of most revolutionary changes out of this year’s iOS 8 event. Apple’s push into the mobile payment space will not only be a huge benefit for iPhone users but will also help bring NFC and mobile payments into the mainstream.

Here are the top 3 things you need to know about this new and and very exciting platform from Apple:

1. NFC Payments

Apple Pay opens up the world of NFC contact-less payments to iPhone 6 and iPhone 6 Plus users. It’s going to be very easy for people to get started with Apple Pay. Here’s how it will work:

  • Users can simply opt to use the primary credit card Apple already has on file for them in iTunes. If a user wants to add a different card, all they have to do is take a photo of that card and add it to the Passbook app.
  • Once a credit card is added to the device, the information used to make a payment is stored in the iPhone 6’s secure element. This ensures the integrity of the card information as Apple does not store your card or payment history to keep your data private.
  • Once the cards are set up, the user can simply scan their finger using the TouchID sensor and tap the phone or Apple Watch to the payment terminal to pay for items in-store.

Apple is also supporting NFC payments for users with iPhone 5 and 5s that purchase the new Apple watch, allowing users with older devices to join the NFC payment world. If your device is ever lost or stolen, Apple has also provided a method to remotely disable purchasing power of a device to keep your payment information safe.

2. In-app Payments

As part of the Apple Pay release, Apple is providing developers the ability to roll out support in their…

Continue Reading Article

Tuesday’s iOS 8 event included some of the most substantial announcements in years from Apple. The changes to phone size, the payment platform and Apple’s smartwatch are all mobile game changers. This was the most significant launch event since the iPad — and if you remember, the iPad was met with similar criticism as the watch is being subjected to today. Four years later, it is clear the iPad changed mobile computing (and in fact computing overall) – we believe that four years from now we’ll all see the Apple watch in the same light. Let’s look at how Tuesday’s announcements impact mobile strategy and apps currently in the marketplace or under development: 1. The Big Screen x 2 (iPhone 6 & iPhone 6 Plus)  To the surprise of almost no one, yesterday Apple revealed two brand new iPhones, the iPhone 6 and the iPhone 6 Plus. As pre-event rumors suggested, the new iPhone models are sized at 4.7-inches and 5.5-inches respectively and greatly increase the amount of real estate that developers can utilize in apps. Interestingly, the iPhone 6 Plus allows for different and varied layouts compared to the iPhone 6 and iPhone 5. The iPhone 6 Plus allows more content to be visible and supports iPad-style layouts in landscape mode. These layouts are made available via “size classes” that allow developers to provide unique layouts for variations in screen size and orientation.  The iPhone 6 (like previous iPhones), will support the “compact” size in landscape mode, whereas the iPhone 6 Plus supports the “regular” size class which allows it to display more content. In order to support multiple screen sizes and size classes, Apple has made “auto layout” available in previous OS versions; however until now, the benefits of using “auto layout” have not been fully realized. To Do:

  • Immediately run all existing apps on the new screen sizes in iOS 8 using the simulator to test how your apps will appear and behave, given the new combination of OS and devices. Many older apps will not…
Continue Reading Article

Apple fans across the world were treated to a number of exciting announcements at today’s iOS 8 event. Our team is excited by all of Apple’s news too and we’ll be covering all things iOS 8 on the blog for the remainder of the week. Without further ado, here are our first iOS 8 impressions:

iPhone 6 

Apple is going big this year with two new iPhone sizes, the iPhone 6 and the iPhone 6 Plus.  These new sizes greatly increase the amount of real estate that developers can utilize in their apps.  Interestingly, the iPhone 6 Plus will allow for different and varied layouts as compared to the iPhone 6 and iPhone 5.  For our clients, this change means more opportunity to create compelling interfaces that match the form and factor of devices they use. Not only will apps be able to take advantage of the larger iPhone 6 Plus screen sizes, but they will also scale down elegantly to fit  iPhone 6 and iPhone 5 screens.

As developers, these new screen sizes mean we need to take advantage the new iOS 8 APIs (e.g. size classes and auto-layout) in order to continue building our clients elegant apps. Fortunately, Apple also revealed that existing apps can be scaled automatically to fill the screens of the new iPhones. That said, taking full advantage of all the new functionality of these devices will require deliberate thought around how to best leverage the newly available screen space.

Apple Pay

Apple Pay is arguably one of the biggest announcements of iOS 8 and marks the arrival of seamless mobile payments for iPhone 6 and iPhone 6 Plus users. Those who purchase one of the new devices will now be able to easily scan their existing cards into the iOS and make mobile payments anywhere NFC transactions are accepted. Additionally, users with stored cards can now make seamless payments online, and possibly within apps too. Apple’s jump into the payment space means big things for…

Continue Reading Article

A never-ending and often emotional debate in mobile development circles remains whether to use a deep cross-platform tool such as Xamarin, or develop apps natively? It’s almost impossible to find impartial analysis as nearly every reviewer comes in with an underlying bias. At WillowTree, however, we use both approaches, and in the end it all depends on the project and your organization. Here are some things to think about when we tackle this all-important platform problem for a client:

Upsides of Xamarin

C#: One of the major upsides of using Xamarin is the ability to use C# as your development language on all platforms. While both Objective-C and Java are great languages, C# has evolved considerably over the years. It allows for incredibly rapid development and iteration with strong type safety. Newer patterns in C#, including generics, LINQ, implicit typing, extension methods, async methods, and closures make what would be incredibly long boilerplate code in other languages completely unnecessary, which helps create cleaner, more readable and more reliable code.

Shared Core Code: While we have had some portability issues (they’ll be mentioned later), sharing code between Android and iOS is fairly clean and simple, thanks in part to constraints imposed on us by MVVMCross. Our models, view models, networking and parsing logic (including error handling), and navigation logic are often shared between both versions of the app. This means there are no differences in functionality between the two, simplifying bug hunting and ensuring similar operation between both apps. Of all bugs reported in Xamarin apps, a very small number are usually platform-specific, meaning fixes can be applied to both platforms easily.

.NET (and other C#) Libraries: .NET has some great libraries (including HTTPClient), and with the increased support of PCLS and Microsoft’s recent re-licensing of some of its libraries, using these libraries makes doing certain complex tasks on the platform incredibly easy.

Native APIs: Xamarin’s bindings on any given platform mirror the native calls so…

Continue Reading Article

If you’re reading this post, it’s likely you’re in one of two camps of thought:

Camp 1: “I don’t know what Google Tag Manager is, but I want it.
Camp 2: “I love Google Tag Manager for web, and mobile will be just as easy.”

To each of these camps I reply: not so fast. Like all things tech, there are ins and outs that require careful consideration. In this post, I’ll explain to you what Google Tag Manager is, where it came from, and how it applies to mobile.

Beyond the marketing buzz words like “IT-friendly,” “quick and easy,” and “multi-platform,” deciphering what exactly Google Tag Manager is can be a challenge. Most people come around to the idea that Google Tag Manager is “souped-up Google Analytics.” But what does that really mean? What does Google Tag Manager actually give you? We’ve got to look at the web’s evolution to answer these questions.

Once-upon-a-time, there was only the Web (I like to refer to this time as, “before the mobile era,” or “BME” for short). During this time, web development teams implemented “tags” (snippets of JavaScript), which fed usage information to data-hungry marketers. Marketers would constantly request tagging tweaks in their quest to increase conversions and reach performance goals. The result was massive amounts of wasted time both coordinating teams to modify event tracking tags, and waiting on test-release cycles to complete. To stay ahead of the competition, marketers needed more agility and more flexibility.

Google Tag Manager is built on a promise that marketers won’t need to rely so heavily on development teams. It places power in their hands by letting them decide for themselves what tags should be defined. Rather than developers sprinkling snippets throughout their otherwise pristine code to explicitly tag events, a single Tag Manager snippet replaces them all.

The Nitty Gritty of How Google Tag Manger Works:

Tag Manager uses the concept of a “container.” It contains the following types of configuration:

  • Tags – what to see in your report (e.g. “User Logged In”)
  • Rules – when a tag should be “fired” (e.g. “href clicked containing /login”)
  • Macros – which name-value…
Continue Reading Article

We’re proud to announce that WillowTree has been recognized for the third-consecutive year as one of America’s fastest-growing private companies on the 2014 Inc. 5000 List. This year we jumped ahead 524 positions to grab the 454th position, placing us among the top 10 percent of all companies on Inc.’s exclusive annual list.

Our rapid growth over the previous 12 months is a testament to the fact that organizations across industries like healthcare, sports, media and entertainment, as well as enterprises with specific field sales and field services functions, recognize the huge efficiency gains and return on investment from mobile. These companies are truly engaging their customers and workforces in meaningful and value adding ways through apps and connected devices, and making peoples lives easier. 

We’d like to thank our partners and clients for the continued trust they place in WillowTree. We are proud of our team, and this third-time honor from Inc. Magazine. Check out the Inc. 5000 List to read more about this year’s honored companies, and learn more about WillowTree’s ranking here.

Continue Reading Article

A common problem you will face when developing Backbone applications is deciding where to put shared logic. At first blush, inheritance (via extend) can solve most of your problems. When you have a group of similar classes, simply make a common ancestor and have them all inherit from it. But what happens when you have a group of *unrelated* classes that need a similar feature? This is where the Mixin pattern becomes incredibly useful.

For the use of this article, we will be making a simple mixin that shows a pop-up alert message with some text when a method is called.

First Attempt

Our first foray into mixing functionality into our views will be quite simple. First, we will create an object to house our grouped functions, and then we will attach it to our Backbone view:

Continue Reading Article

Integration challenges and solutions come in a wide range of scope and complexity–from multi-year, multi-million dollar engineering engagements to scripts that scrape a screen every hour on a cron job. Likewise, enterprises have historically taken on integration initiatives for a variety of reasons, most often to allow siloed legacy applications to share data without a complete rewrite.

Screen Shot 2014-07-23 at 4.06.41 PM

The Problem

Today, mobile initiatives are a huge driver of integration projects. Enterprise workforces increasingly demand access to the internal tools they use in the office on their phones and tablets.

For an Enterprise Integration solution targeting mobile, the architecture usually involves tying into existing tools and data stores, often transforming and caching some data before exposing a subset of the internal systems’ functionality via REST resources. It’s more like a specialized piece of middleware that also integrates systems than a full-blown Enterprise Integration project in the traditional sense.

The Challenges

Allowing access to mission-critical systems from smartphones is different from, for example, a business intelligence tool reporting on data from several legacy data stores. Security concerns are much more acute when access to the company’s revenue data is in a user’s pocket, accessible over the Internet rather than on an IT-managed workstation in corporate headquarters behind a firewall. Limiting access to only the necessary subset of data and guaranteeing industrial-strength security safeguards are two concerns of any mobile enterprise integration solution.

Network connectivity in the mobile world is reliably unreliable. Mobile APIs need to optimize payload size through compression, paging and properly designed data representations. It’s usually not enough to simply expose existing systems, even in organizations that have service-oriented architectures in place. Mobile solutions require an integration layer to pull data from several data sources and tailor the response to the app’s specific requirements.

Those internal systems you’re trying to connect to mobile apps themselves have a variety of protocols and interfaces. In a…

Continue Reading Article

This is our first installation of WillowTree Labs, a recurring blog post series in which we will discuss the details of our quarterly internal research projects. Each project is voted on by our team, and designers and developers share updates at our weekly Research & Development meetings. We conduct these research projects in an effort to stay on top of the latest technology trends, continue learning, and contribute new innovative mobile solutions for our clients.


Good startups grow fast. While WillowTree is outgrowing its ‘startup’ moniker, we still have our share of growing pains. We have moved and renovated several times over the past few years, all to make room for new hires. As a rapidly growing company, our biggest problem is not the struggling wifi network or the contractors bustling around….it is the ever-growing bathroom line. Since last year, we have doubled our staff without adding any new bathrooms. Renovations plans are in the works, but we were not willing to wait. Since bathrooms can’t be built overnight, we built a tool to tell us if one is available. Enter: “Bathroom Monitor”.

Our primary goal was to detect and broadcast the bathroom status throughout the office, using whatever technology was available. After several iterations, we elected to use magnetic contact switches and a Raspberry Pi. Each contact switch would be mounted on a bathroom door and wired to a central RPi. The RPi would then broadcast the switch values through an API. The end goal is to have desktop/mobile clients that consume the API and report the status in real-time.

Here is how we built it.

Parts List

  • Raspberry Pi, Amazon
  • 3 Magnetic contact switches, Amazon
  • Prototyping board, Amazon
  • Adafruit PermaProto Pi Breadboard, Amazon
  • Wire strippers
  • 16-18 gauge wire (10-30 ft.)
  • Banana connectors, Wikipedia
  • USB Wi-Fi dongle, ModMyPi.com
  • 5V 2A micro-usb power supply (optional, to power the wifi dongle), Amazon

Assembly

Configuring Raspberry Pi

If this is your first exercise with a Raspberry Pi, use this guide to…

Continue Reading Article

An important announcement for Android developers from this year’s Google I/O was the full rollout of the Android runtime (ART).  ART significantly improves Android’s performance, increasing application speed and reducing “jank” across the board.  It provides the “performance boosting thing” that users have long been waiting for.

ART was announced last year as an alpha runtime with the release of KitKat, and with the L developer preview, it is now the standard, fully replacing the Dalvik runtime.  Let’s take a look at what ART offers and why it is one of the most important steps in a long-running effort to improve Android’s smoothness.

Explaining runtimes

First, let’s define what a runtime does.  A runtime is a library used by a compiler to implement language functions during the execution of a program.  It’s essentially the framework or platform on which your code runs.  The C++ runtime, for example, is simply a collection of functions, but other runtimes, like .NET, package in a garbage collector and other language tools.

Up to this point, Android apps have used the Dalvik virtual machine to execute code.  Java programs are compiled to Java bytecode, which is then translated to Dalvik bytecode by the “dx” tool. The Dalvik bytecode is then packaged as a Dalvik executable file (hence “dexing”), which is designed for constrained systems like you’d traditionally find on mobile devices.

With the L release, which is anticipated to arrive this fall, Dalvik will be replaced by ART.

ART over Dalvik

ART introduces ahead-of-time (AOT) compilation, which can be beneficial for mobile applications as opposed to Dalvik’s just-in-time (JIT) compiler. For apps running on Dalvik, the JIT will compile your DEX files to machine code when your application is launched and as your app is running. Performing this step at launch can slow down app start times, especially on resource-starved devices. AOT compilation eliminates compiling bytecode to machine code at launch and instead performs this step at installation time. When the app…

Continue Reading Article

Android Notifications

One of the biggest takeaways from Google I/O was how much Android is evolving as an ecosystem.  It’s no longer just an operating system for phones and tablets–you’ll now be able to wear it on your wrist, use it in your car, and watch it on your television.  Android is very quickly going to be everywhere, and it’s important that developers take advantage of this by displaying their app notifications in sensible places.  If you’ve been using stock Android notification APIs, you’re already in a great spot when it comes to the future of Android.  You may need a couple of easy tweaks here or there, but for the most part things should work great.  Let’s take a look at some of those tweaks and the new notification APIs exposed by the L developer preview and Android Wear.

Form and Function

In L, notifications have been given a material-inspired styling rendered as cards.  Gone are the days of dark notification backgrounds, as the new notifications have a shadow-casting light background.  The foreground contains dark text and action icons, and across the board, icons are treated as silhouettes.  There are **no** new icon guidelines, so you don’t need to do anything with your assets so long as you did them right in the first place.  L will treat icons as masks, and draw them in the correct color.  This means that it’s imperative that you remove any opacity you have in your notification icons.

L exposes a new API that allows you to provide color branding by setting a notification asset color.   Notification.Builder.setColor()  will fill a circle behind your notification’s small icon.

Music Player

L also brings a new notification template for media…

Continue Reading Article

notifications2

Google I/O preview of Android L has created a great deal of excitement for mobile app designers everywhere. The changes seen in the preview of Android L (I’m rooting for the L to stand for “Life Saver”) are quite extensive. The dark flat design of KitKat will be overhauled and changed to become more alive through depth and fluidity of animations. Google’s new interface, “Material Design,” adds real-time shadows, realistic animations, and smart interactions dependent on the user’s actions. There are changes beyond the UI as well: apps are interlinked, notifications are more intuitive, and adaptive design allows for apps to be consistent and easy to use across devices.

1. App Indexing

Android L will allow users to search through Chrome and display results from the apps downloaded on the phone.  When a user searches in Chrome for the score of the Ohio State basketball game for instance, the results will include the search results for the NCAA app if it’s installed on the device, where the user can tap to launch the app.  This allows web apps and native apps to be interlinked, allowing for a more streamlined user experience.

2. Interactive Notifications

Notifications are now going to be smarter and more interactive.  Android L notifications will no longer be locked to the notifications bar. Instead, they will be a key part of the lock screen, with the most urgent or relevant notifications displaying first. Through Visibility Controls, the user has the ability to manage the type of notifications that display on the lockscreen in order to protect their privacy.  The notifications will also be more interactive; users can perform common tasks from the notification itself or even swipe the notification away to be removed from the list.  When an app is in use, “Heads-up” high-priority notifications appear in on top of the app with actions revealed for quick interaction. Not only do notifications work on…

Continue Reading Article