Review: Alpha Anywhere aces offline mobile apps

One of the defining characteristics of mobile devices is that you can't count on them being online all the time, but you still need them and want to use them when they are offline. Native mobile apps can often deal with offline operation gracefully; for mobile Web and hybrid mobile apps, offline operation can be a bit more difficult. Things get even hairier when the app connects to a remote database, which is often the case with business apps. Triple the hairiness if the user needs to edit data offline and later synch with the remote database, opening up the potential for data update conflicts.

Along with going offline at unpredictable times, mobile devices run on batteries, which can run low without much in the way of warning. Mobile devices can also reboot unexpectedly -- often at the worst possible time. If the device is a phone, an incoming call can interrupt the user's data entry session, potentially causing a browser-based app to refresh its page and lose unsaved data when the user returns from the call.

Not too many mobile development tools have dealt with these problems well. All too often, the tool vendors will tell you that it's the programmer's responsibility to deal with all of those issues. Considering what mobile developers in businesses already have on their plate -- way too many apps wanted for way too little budget in way too little time -- I have to think that it would be much better for the vendor to offer a solution.

Alpha Anywhere 3 does in fact address all of these issues for mobile Web and hybrid mobile apps. And it does this in the context of a RAD (rapid application development) tool that allows developers to build good apps quickly, with surprisingly good performance and native-like look and feel.

A bit of background

Alpha Anywhere evolved from Alpha Five, which was a Web and desktop application development tool with an application and Web server, a PDF report generator, and strong support for dozens of SQL and desktop databases. Alpha Five in turn evolved from Alpha Four, which was an easy-to-use dBase clone. (The Alpha Web and application servers were originally unified, and then later split, so that the Web server could be replaced by IIS.)

Alpha Anywhere added mobile Web and then hybrid mobile app development to Alpha Five's bag of tricks, but didn't really address offline operation until version 3. But, true to form, when it finally addressed offline operation, it covered all the bases.

In later versions of Alpha Five, a data-bound Grid component and a Tabbed User Interface component were the workhorses for Web developers. With a little experience, a developer could go from a database to an initial Grid-based Web application in minutes. As mobile Web became more important, a lighter-weight Dialog component started to replace the monolithic Grid for many Web apps. The Dialog was eventually renamed the UX component in Alpha Anywhere as its functionality expanded to include navigation (panels) and search.

To substitute for the tabular view in the Grid, Alpha added a very lightweight List control to the UX component. The List control is the building block of Alpha's offline strategy. It uses JSON internally, which makes it compatible with REST APIs and NoSQL databases as well as SQL databases. The typed data returned from a SQL database query is easy to convert to JSON, and the List control does that for you automatically.

How offline operation works

To design a mobile UI with Alpha Anywhere, you typically drag panels, containers, and controls onto the tree view of a UX component and set the properties of each element on a property sheet. This methodology is rapid, although not quite as intuitive as a WYSIWYG designer. You can see a working or live preview at any time, however, and see it simultaneously with the designer if you have enough screen space. The server-side Xbasic (and other languages) of an Alpha Web or mobile component generates HTML5 and JavaScript for rendering by a browser.

The properties of the UX component, and any other Alpha component, define its overall behavior and appearance. Switching styles changes the CSS, and therefore the appearance, without changing the behavior.

The UX control can automatically emit the proper logic for persistent local storage in a browser or mobile device. You can control the local storage behaviors on the Local Storage section of the property sheet.

Working Preview allows you to see how your component will look in a browser or mobile device, using either Chrome or IE as the browser. Working Preview makes it easier to debug your code than Live Preview, which runs in a separate browser process with the included application and Web server. The server is restricted to development use unless you buy a server license, which unlocks it.

The UX component includes many controls in addition to the List. For example, you can pick a row from a list and bring up a Google map of its location. Defining the row binding, the map display, and the addition of the marker is a matter of a few mouse clicks. Alpha generates the appropriate JavaScript and HTML automatically. The UX can even bring up HTML reports.

Alpha Anywhere has a robust templating language that can turn JSON data into formatted HTML pages. The template tester allows you to refine the template interactively until the output looks as desired.

The UX component and the List control implement what you need for offline/online data synchronization. There are multiple UIs for controlling the behavior. The List Builder, for instance, allows you to manage data binding, list behavior, and list layout.

The figure below shows what happens when we have saved an edit to a database record locally on the simulated mobile device, but have not synchronized the change with the remote database. You can tell this by the button states at the bottom and the isDirty flag in the debugging block. Note that the ContactName is now Anita Trujillo (diminutive of Ana), whereas the original ContactName seen in the blue debugging block is Ana Trujillo.

The next figure shows the timings and SQL for the UPDATE operation generated to synchronize the new local field value with the remote database. If the value in the database is no longer the same as the saved old value, a conflict occurs, the SQL will fail, and Alpha will generate error messages with action buttons so that the user can decide on the correct resolution to the conflict and then resubmit the operation, if desired. You can test this functionality by opening the same record in two browsers and changing it in one before changing it in the other.

Database integration

Alpha started as a dBase-compatible tool, then added SQL database support. One thing led to another, and it currently supports more than 20 databases, ranging from DBF files to Oracle, and supporting advanced features of the major databases, such as spatial data types and Oracle sequences.

Alpha's SQL database support is especially strong because it allows you to use the native SQL dialects of each database if you wish, or use Alpha's Portable SQL facility, which will emit the appropriate native SQL for the current database connection. To make things even easier, Alpha will generate most of your SQL for you, and help you to design your SELECT statements with a graphical builder. If you just want to use existing tables or views, you don't even have to type anything once the database connection has been set up.

The database connection in Alpha is a useful abstraction that is made even more useful by Portable SQL. It's not unusual for Alpha developers to work with an Access database on their own computers, and then publish to a server running a scalable SQL database such as SQL Server, Postgres, MySQL, or Oracle. Everything remains the same, except that you create a different value for the named connection string in the server publication profile.

A few years ago, some independent Alpha developers had trouble using stored procedures for data creation, retrieval, updates, and deletions from Grid components, which are inherently data-bound. That was fixed by adding some server events that allow the programmer to override the Grid's built-in SQL queries and execute the programmer's own SQL, which might be a stored procedure call. With that experience in mind, the UX component was created as inherently unbound, with easy ways to activate the binding mechanism.

Servers and languages

That inherently unbound architecture, and the support of JSON, made adding integration of the UX component and List control with NoSQL databases possible. One other change allowed for direct support of MongoDB and CouchDB: integration between Alpha's Xbasic language and Node.js, so that Alpha could take advantage of the Node.js drivers for MongoDB and CouchDB. Of course, you program Node in JavaScript, so you can also write JavaScript Node services and use them in Alpha applications.

Even before that, Xbasic was integrated with the .Net Framework. That made it easy to call JSON and XML Web services, and to use C# code in Alpha applications. In fact, a significant percentage of Alpha Five Version 11 was written in C#, building on the existing C++, Antlr, and Xbasic code.

Alpha Anywhere is undergoing two large transitions in its application servers. One effort is to integrate an IIS server with Alpha plug-ins, and this is currently in an open beta test period. The other is an effort to offer hosted Alpha cloud servers, and this is currently in a closed early beta test period, running on Amazon Web Services. The two efforts may eventually be combined, and the servers will probably be made available for other clouds besides Amazon.

The IIS server with Alpha plug-ins, which I have not personally tested, is supposedly faster and more scalable than Alpha's existing server. It should also be easier to certify for government use, since IIS itself has already been vetted for FIPS security.

RAD and skill level

Alpha Anywhere is a "low-code" development product. There are people who use Alpha without writing much more code than the occasional relational or logical expression where necessary, and who spend the bulk of their development time using the IDE. On the other hand, there are "real" programmers who add large chunks of functionality to what Alpha already offers by writing code in Xbasic, JavaScript, C#, HTML, or CSS.

I've seen junior programmers -- basically, kids right out of college -- become productive Alpha developers in a week or two. I have also seen experienced Alpha programmers throw together sophisticated websites and hybrid mobile apps in a matter of days. At the other end of the spectrum, I have seen complicated corporate Web applications developed by two programmers in nine months, less than half the time it would have taken to create the same sites in Java Server Pages or ASP.Net -- and then never need any maintenance to speak of.

Weighing Alpha's cons

There are some significant downsides to Alpha, although they may not be stoppers for many companies. One issue is that the Alpha IDE and application servers currently run only on Windows. That didn't used to matter, as most people ran their businesses on Windows anyway, but there are now good reasons for many developers to use Macs -- the biggest of which is that they need to use Xcode on a Mac to develop iPhone and iPad apps. As a workaround, running Windows in a Parallels or VMware Fusion virtual machine on a Mac works, and the Alpha Anywhere IDE runs well in either of those configurations.

Another downside is Alpha's proprietary application server. While large HIPAA- and PCI-compliant applications have been deployed on Alpha, so far no U.S. government agency has been able to use Alpha for websites because the application server hasn't been FIPS-certified. The company hopes that its upcoming IIS integration will solve that problem.

A third downside is Alpha's lack of a scalable cloud service. Again, this is in development; meanwhile, it's easy to build out an Alpha server farm on IBM SoftLayer, Amazon, or Rackspace, and SoftLayer reseller ZebraHost has become expert in doing just that.

The fourth downside is Alpha's lack of native mobile client support. Interestingly enough, people often can't tell that Alpha hybrid applications are not native, because the Alpha Anywhere mobile components and controls have been crafted to look and feel native.

The verdict? Overall, I rate Alpha Anywhere 3 very good as a Web, mobile Web, and mobile hybrid development system. The IDE is powerful and easy to use, although it has so many features that it's easy to forget where to find the one you need. The capabilities and integrations are very good.

Alpha has its own JavaScript client framework, which includes support for jQuery, but not for some of the newer frameworks such as Angular and Backbone. On the other hand, Alpha's templating language has a distinctly Angular-like feel to it, and you can't really complain about the framework when the system generates almost all of the code for you. What made me reduce the score for client support to 8 wasn't any of these, but the lack of native app support. As I mentioned above, however, this often doesn't matter, because Alpha Anywhere/PhoneGap apps usually look and feel native, even if they aren't.