Hotwire Tech Blog

Scribes from Hotwire Engineering

Goal

Currently at Hotwire, when developing new mobile features, the business logic and UI is written separately for the Android and iOS app. This is especially time-consuming when developing features that have a lot of overlap. Not only does this take more development time, but also both platforms end up having their own bugs. We felt that it was an interesting time to try out a cross-development tool to build features in a more unified way. One of the promising tools we decided to try out is React Native, a mobile, JavaScript Framework. In this post, I will be discussing the basics and advantages of React Native. In Part 2, I will be going into more detail regarding integrating…

Read more...

Overview


Our Android application originally started out using AsyncTask to make our api calls. This tightly coupled the networking calls to our Activity lifecycle. Any configuration change would force the Activity to be restarted, and by extension the AsyncTask would be restarted. At Hotwire we wanted to change how we were making and handling our api calls and decouple this from the Activity lifecycle. During the change to a more robust and thought-out architecture for handling our data we wanted to ensure that we built in client-side caching, made the new framework easily expandable to new requirements, abstract away where the source of data was originating, and…

Read more...

Introduction

Typically, when users search for content using Google Search on their mobile devices, they are directed to the corresponding mobile web page or in some cases the actual web page itself.

This often leads to a sub-optimal user experience mainly because mobile users are limited by screen size and processing power. Also web pages have multiple scripts executing on load which sometimes render the screen inactive for intermittent periods of time.

App indexing on the other hand, gets the app into search results. If the app is already installed on the user’s phone, the app is directly launched from the search results or in cases where the user does not have the app,…

Read more...

Overview

 

Our Android app had grown at a rapid pace, and more growth was on the way. Our UI widgets were defined in the same classes as our API response handlers. Some of our activities were over two thousand lines of code. Activities and Fragments that had originally seemed short, succinct, and well organized had grown into an unrecognizable thicket of Java. We needed to tame this wild growth before our code base became another spaghetti code behemoth. Enter MVP.

As anyone involved in the Android development community is likely aware, the Model View Presenter (MVP) architecture has gained a lot of traction in the past few years…

Read more...

The purchase path in any m-commerce app needs least resistance and must be devoid of errors. Credit card entry is a very important component of the purchase path, and in our initial versions of the app this particular component was powered by a third-party open source library. The decision to use that library was purely based on time-to-market.

Why write our own?

Throughout the months that the Hotwire android app was in the play store, there were a significant numbers of errors attributed to this library which exposed deficiencies, especially in the following areas.

Read more...

Our partners give us access to their unsold inventory – empty seats on flights, empty hotel rooms, and extra cars on the lot – at big savings. By showing the name of our travel partner after customers book, Hotwire can get travel deals that are significantly below published prices.

Because we can’t disclose a lot of detailed information about the hotel, showing the general location of the hotel via neighborhood polygons on a map becomes a very important feature for our app.

The initial versions of our Android application had only…

Read more...