Apache Cordova and Server-Side Technologies
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Many developers are looking to mobilize existing web applications, and they see Apache Cordova as a useful way to do so. They're right. Apache Cordova provides a great way to use web development skills and web technologies to deliver native mobile (and desktop) applications.
For many years now, I've been trolling the PhoneGap Google Groups and Stack Overflow Cordova sites (trolling as in fishing, not in the Internet sense), trying to answer any questions I can. A common question is, "How can I get my [technology_name]-based app to work in Cordova/PhoneGap?" replacing [technology_name] with server-side scripting technologies such as ASP.NET, JSP, node JS, and PHP.
Unfortunately, the short answer to the question above is, "You can't." Also, as React Native (Facebook), NativeScript (Telerik), tabris.js (EclipseSource), and other options gain popularity with developers, it's important to be clear that the same answer applies for those frameworks as well.
The long answer consumes the remainder of this article. Spoiler alert: You'll have to create a new web application to run in the Apache Cordova container, plus rework your existing back-end server app to accommodate this new approach. The good news is that you'll be able to do this using code from the existing app as a starting point, leveraging much of the HTML, JavaScript, CSS, and server-side scripting code your app uses today.
A Quick Intro to Apache Cordova
It's clear to me that developers asking about server-side scripting technologies and Apache Cordova don't really understand what Apache Cordova is. So, before we go any further, I'll provide a quick background on Apache Cordova. For much more detail, please take a look at Apache Cordova 4 Programming.
Apache Cordova is an open source framework that allows web developers to create native mobile (and desktop) applications. Developers code a web application that provides the UI and business logic the app requires and then uses tools provided by the Cordova team, along with the native SDKs for each target platform, to package the web application into a native application container that simply renders the web app (like the browser does today). When the app launches, the native app displays a full-screen WebView (basically a browser window without any chrome) and then loads the web app into the WebView. At this point, the WebView takes over, and the users interact directly with the web content, just as they would in a browser. The initial benefit here is that the app is now a native app that can be deployed through app stores and shows up as an app icon on the device's home screen.
At this point, you're probably asking, "Then why would I need Cordova? Users can put an icon for a web app on their home screen today in just a few simple steps."
The answer comes down to accessing native APIs. One of the things that makes native mobile applications more engaging than web applications is that native applications have access to more local capabilities than a browser app has. Native applications have access to all of the capabilities exposed through the mobile operating system APIs and applications. Mobile web browsers added capabilities that allow web applications to access the camera, geolocation or file system, and more, and those capabilities will continue to grow over time. For now, though, only native applications can access native capabilities; for example, the contacts database, calendar, or near field communications (NFC).
Apache Cordova bridges that gap by providing a JavaScript-to-native bridge that enables web applications to make calls to native APIs. With that in place, Cordova delivered an open plug-in architecture plus a core set of plug-ins that enable developers to access some common APIs from their web applications running in the Cordova container. Where the Cordova team doesn't publish a plug-in exposing the native capabilities that a developer needs, it's easy to find a plug-in that does, or to build a custom plug-in. The result is a native mobile application executing web content that has access to native capabilities.
Developers like Cordova because they can get more use out of their existing web apps. They simply need to transform the web app into a format that can run in the Cordova container.
What Are the Issues with Server-Side Scripting Languages and Cordova?
With that background on Apache Cordova in mind, let's consider why web apps written using server-side scripting languages can't run in an Apache Cordova container. If you're reading this article, I have to assume that you know more about server-side scripting technologies than you do about Apache Cordova. In case I'm wrong, though, I'll use this section to highlight how server-side scripting languages work, and then wrap up by explaining why they're unsuitable for use with Apache Cordova.
Server-side scripting languages are used to build dynamic or data-driven websites. A developer embeds script code within a web page; the code, which can do almost anything, is used to create or change content on the page depending on conditions embedded in the code. Special software deployed on a web server processes pages before they're delivered to user agents (typically a web browser). The server process parses the script code and then executes it, replacing the embedded code with the results of the code execution.
To demonstrate this process, take a look at some sample code from the PHP developer guide:
<html>
<head>
<title>PHP Test</title>
</head>
<body>
<?php echo '<p>Hello World</p>'; ?>
</body>
</html>
In this example, as the web server gets ready to deliver the page, the php server task parses the PHP code within the body tag (the boldfaced code in the example) and replaces it with the result of executing the code. In this case, the PHP server returns the text <p>Hello World</p>. The server then returns the following page script to the requesting browser:
<html>
<head>
<title>PHP Test</title>
</head>
<body>
<p>Hello World</p>'
</body>
</html>
As I mentioned previously, the embedded server-side code can do almost anything. Typically, it's used to retrieve data from a database or application server, customize a page to the user's preferences, and so on. The web server delivers only HTML pages, customized for each request as shown in Figure 1. Web developers create static web pages using the necessary HTML, JavaScript, and CSS code, and then the PHP code embedded within the page gets just-in-time custom content based on the business logic embedded in the PHP code.
)
Figure 1 Serving dynamic web pages.
This approach won't work in an Apache Cordova app because it relies on a server process to parse the server-side scripting code and update the page before passing it to the rendering engine (the browser). In the Apache Cordova use case, the web application is prepackaged within the Cordova container, not retrieved from a web server. There simply are no available implementations of the server-side scripting engines that would run within the Cordova container.
If you think about it, the scenario described in the previous paragraph is the reason why the Web 2.0 approach was created. It allows developers to deliver dynamic apps from a static app, but the data is retrieved from the app server, not from web pages.
Leveraging Existing Dynamic Web Pages in an Apache Cordova App
Now, you may be thinking, "Couldn't I create a Cordova app that simply displays the remote web content within the native container?" Yes, you can. By default, an Apache Cordova app opens the local index.html file at launch. The developer can point that startup page to a different file packaged within the application, myapp.html for example, or it could point to a remote server URL such as http://myapp.mydomain.com. When the app launches, the user would see a blank screen while the remote content is retrieved, parsed, and rendered.
This approach would work, but with problems; for example, Apple isn't fond of publishing apps like this in the App Store. Also, your existing app running in the Cordova container wouldn't make use of any of the native APIs that Cordova exposes to the app through plug-ins. You could rework the app so that it detects whether it's running in a Cordova app, and then enable the native capabilities in that case, but that technique adds a level of complexity to your app that may be difficult to maintain. Ultimately you would be maintaining two versions of your app in the same code base.
Another problem is what happens when the device running the app doesn't have a network connection: The app won't be able to display anything. A Cordova app doesn't cache content like the browser does; it loads everything dynamically at startup. A Cordova app typically has all or most of its web content packaged within the app, allowing it to operate with or without a network connection. Not the best user experience when the app loads to a blank screen and an error dialog.
Reworking an Existing App into Apache Cordova
The solution to these scenarios? Rework the app in the Web 2.0 style, and it will fit well into the Cordova architecture. The app has to be rewritten so that the web application content can be packaged into the Cordova container without needing server-side components to manage the content. To use this design, you'll have to create some way for the web app to obtain the data it needs from the server. The difference is that the server will no longer be delivering web pages crafted in HTML; instead, it merely delivers data and lets the app handle rendering it (as shown in Figure 2).
)
Figure 2 Serving the Web 2.0 approach.
Migrating an existing dynamic web app built with server-side scripting languages to Apache Cordova requires the following:
- Create one or more web services that expose the data used by the existing dynamic web app. In every place where the dynamic web app reaches out to a database or app server for data using the server-side scripting language, replace that code with a call to a web service.
- Rework the existing web app into the Web 2.0 style. Here the app's HTML pages (or page, in a single-page app) are self-contained and can easily be packaged into a Cordova container. The app still uses the network to retrieve data as needed, but at least the app will run (and display something) when the device is outside network coverage.
As a bonus, you'll be able to reuse much of your existing code:
- You don't have to throw away the web application code. What you have today still works; all you have to change is the areas in the app where the code reaches out to an external data source to obtain data that's rendered within the app. Replace server-side scripting code with AJAX requests and some code that renders the results when they come back from the server, and you're done.
- You may be able to keep your server-side scripting code. Server-side scripting technologies can usually be used to create web services as well, so all you'll need to do is wrap the existing code into web services, and you're all set.
The only real challenge you'll face is replicating any security required by the application, which is easily addressed by adding a login page to the app that validates the user's credentials against the organization's identity-management system. If the user can't log in, display an error page instead of any protected data. Additionally, be sure to encrypt any data that is cached on the device, to protect it from prying eyes if the device is lost or stolen.
With this approach, you'll also be able to leverage the work you've done in the desktop and native mobile-app versions of your app. The desktop browser doesn't have to use the dynamic web pages from the old approach; simply point the desktop browsers to the same web app content. Any services you create can be used just as easily, if you ever decide to deliver a native version of the app.
Conclusion
With the information provided in this article, you have the basic background needed to understand how to leverage existing dynamic web applications with Apache Cordova. You'll have work to do if you want to migrate your apps to the Cordova framework, but it shouldn't be too hard. As a bonus, you can easily leverage the work you've done across other channels, such as desktop web and native mobile apps, so this exertion is worth the effort.