How to save on the development of a mobile application, getting a finished product, invaluable experience and an excellent solution for business

Preface:

The article describes the history of the search for successful solutions of one outsourcing American-Ukrainian company. Events are not fictional, coincidences are not accidental.

1. How we were looking for the best solution.

In the past few years, the market for mobile platforms has put developers and customers before a choice: to develop for any one platform, to focus on two popular platforms, or to try to cover all popular solutions for mobile devices. And, of course, customers themselves often want to cover the largest share of the mobile platform market. But in this case you will have to write at least four (!) Mobile applications for iOS, Android, Blackberry and Windows Phone.


')


And here it becomes necessary to find a compromise solution between cost, performance and functionality, since writing a separate native application for each of the platforms leads to a multiple development cost:

• porting or developing for each new platform requires a similar amount of time to write code;
• the number of developers involved in the development increases;
• As a result, the cost of development increases significantly.

Of course, there are situations when it is worth writing native applications:

• very high performance is required;
• the solution requires processing a large amount of data on the client side;
• when writing utilities for managing iron or an operating system;
• when creating solutions based on video or game scenarios, additional reality.

But, if there is no categorical reference to the management of iron, there is no need to process large amounts of data on the device, then you can try to find more economical solutions in the development.

Thus, we approach the problem of choosing a less laborious and expensive solution for implementing an ordinary application for all popular platforms without loss of quality and speed. Having conducted a small study on the illumination of this problem earlier, we found several publications that confirmed the correctness of the course of our thoughts in such authoritative sources as Mashable.com , Forbes.com . As one would expect, no one offered a quick, simple and universal solution, and we decided to conduct our analysis and find a solution that would not scare off the high cost of medium and small business representatives who are not always able to afford the development of several native applications at once.

For the standard, we took the best characteristics of native applications:

• better performance;
• access to hardware settings (camera, local data storage, microphone) opened by native APIs;
• no gulf between the imagination of developers and the capabilities of the platforms.

The following table summarizes the main factors that are important for determining the optimal option:

We faced a choice between other major popular solutions:

• clean cross-platform applications (for example, implemented using Phone Gap);
• hybrid cross-platform solutions (mobile site + wrapper for each of the platforms);
• HTML5 mobile site.

Since we already faced the development of diverse projects for our clients and accumulated vast experience, we already knew the advantages and disadvantages of each of the options. Net cross-platform applications implemented, for example, using Phone Gap, had serious performance problems when implementing complex customized solutions for the needs of the customer.

Problems in the development of such mobile applications using Phone Gap began at an early stage:

• initially the framework was complicated for a quick start;
• it had a high threshold of entry (developers had to spend a lot of time studying the documentation on introducing elementary changes to the settings);
• We observed the poor performance of the application at the output due to the heaviness of the functionality itself, the initial modules, which were difficult to customize for our needs;
• existing errors in the system can slow down the development process;
• Access to the operating system and hardware devices was not carried out through the native API, but through the API Phone Gap Framework, which also led to a drop in performance and in some cases limited the capabilities of applications.

With clean mobile sites for smartphones, the problem was a bit different: according to statistics, users spend a quarter more time working in applications, mobile sites, unlike applications, are not so interactive in their interface, are not available offline, and often have limited functionality ( for example, access to the user's location data).

It should also indicate the existence of a global advantage of native applications: speaking of the development of each platform of a native application, we mean that the application caches as much information as possible on the client side by default. When we talk about a solution based on any web interface (be it a website or a mobile web application), often the development does not pay enough attention to the level of data caching, and consequently, performance can suffer.

Also, for the operation of the application based on the web interface, in any case, you will need access to the Internet. But, if we make an application on the basis of a client-server solution, which on the server side produces huge amounts of computation, and the client already gives their results, the need to connect to the global network will rather be connected with the need to give the client the most relevant information every second.

After analyzing all the options, the team came to the conclusion that in some cases of developing cross-platform mobile applications you can get virtually all the advantages of using a native application using a hybrid website and applications:

• for a client-server application, in any case, access to the Internet is needed (since the Web API is being accessed);
• there is access to location data;
• the application will be available immediately after installation (without the need to go into the native browser and type the address in the line);

And provided that the client connects the device through a provider that provides high data transfer speeds, it will be possible to get such a performance that will compete with the performance of native solutions. Of course, if the client connects to networks with a low data transfer rate, any client-server application will show less high performance regardless of how it is implemented.

2. How we came to Google Closure

With the growing share of mobile traffic, there was a need to implement a mobile solution for the convenience of users on Pikaba.com.
In early 2012, a cross-platform mobile application was implemented on our base on the jQuery Mobile Framework. In this case, a hybrid site with a browser-based wrapper has been used: custom templates, styles, and transitions between screens.

But already at the implementation stage, it became clear that this framework is not suitable for solutions that operate with large amounts of data and with the implementation of a large number of customized functions:

• jQuery Mobile has made too many changes in structure (DOM);
• too many API requests were made on the server side;
• double serialization and deserialization of data occurred due to data transfer between the server and ASP.NET web application;
• on the server side there was no compression and code optimization;
• on the client, the main manifestation of problems in the application was “thoughtfulness” during transitions between screens.

All this led to the fact that the speed of the application on the end device left much to be desired and had to find a more elegant and productive solution that would be less expensive than writing native applications for each of the platforms. And the development team found it: a SPA website in JavaScript, which was supposed to be loaded into an application based on a browser with reduced browser functionality.

In this case, we got an application site, which:

• had a DOM that was incomparably smaller than the previous one;
• performed calculations on the server side, while not loading the client device;
• tracked hashtag changes and loaded content asynchronously;
• actually had full access to the software and hardware of the device, in contrast to the usual site, downloadable, through a full browser;
• it was worth less in development, since for the platforms it was necessary to write only an wrapper.

The most interesting thing remained: choose a framework for working with JavaScript. Among the most likely candidates are Backbone.JS Framework and Google Closure Tools . You can think about the choice of a particular stack of technologies for a long time and, rather, this is a matter of taste, habits and affection in deciding in favor of a framework, but we chose Google Closure Tools. The following parameters have become decisive:

• the team already had experience with this framework, and this lowered the threshold for entering the productive stage of application development;
• Google has its own compiler, which, among other things, makes it possible to optimize and compile the entire code into one file;
• the possibility of writing unit tests directly on the basis of Google Closure and the absence of the need to use additional tools (for example, the same Jasmine );
• the possibility of implementing your own MVC ( Model – view – controller ) framework.

Moreover, despite the fact that Google’s JavaScript compiler was in principle omnivorous and could work with any framework (for example, the same Backbone.JS), the development team decided to stay on the tandem of two products from one company, because a bunch of Google Closure and the compiler promised to have long-term support from the Corporation of Good and the first-priority implementation of the newest technologies.

3. How we implemented the Pikaba Mobile project

Having decided on the technology stack, by the end of 2012 we began to develop a cross-platform hybrid mobile application with a minimum amount of functionality that would allow users to:

• log in and create accounts;
• create, edit and save applications;
• view applications, products and services and search by them;
• browse by profiles, grids.

Thus, the primary task was to create all the necessary functionality for buyers. The functionality for sellers should be implemented later.

Also, developers had the task to develop their MVC Framework for interaction with Google Closure. Of course, no one forgot about the existence of such frameworks as AngularJS , EmberJS , KnockoutJS , in which the MVC model was implemented initially and the interaction with the UI would be simpler and reduced to a minimum. But Google Closure Tools “buns” in the form of an omnivorous compiler, support and tools for writing unit tests have become a decent price for these minor inconveniences.

As a result, the above functionality was written and tested much faster than the previous solution, since TDD was used.

4. Marketing Bonus

Of course, there are no universal solutions for all customer requests, but our team has found one of the solutions for itself, which, with its relative financial efficiency, is a good substitute for implementing a native application for several platforms and covers a fairly large share of potential development orders applications.

A hybrid solution using a wrapped mobile site nevertheless remains a mobile site with all its advantages: we can connect Google Analytics and explore user behavior in the application, segment the audience, its movement within our application site and perform many analytical operations.

A positive point will also be the lack of urgent need to release updates on Google Play, iTunes and other markets. In order for the user to receive in his application an updated version of the site with corrected faults or improved functionality, it will be enough for him to simply go into the application again.

In addition, it will help customers save on support in the event of new versions of mobile platforms, simply by implementing a new wrapper and focusing on improving the basic functionality and adding a new one, without splashing on multiple revisions for different platforms.



PS The application with the conditional name Pikaba Mobile 2.0 is already preparing to be published on iTunes and on Google Play, with plans to write wrappers and test the application on Windows Phone and Blackberry OS.

PSS The acquired experience and the ready-made bundle were successfully applied within a couple of months, when a small Social Commerce project appeared for development with similar functionality. We accelerated development by using the MVC Framework from Pikaba Mobile.