Mobile devices started out as web access devices but quickly evolved elegant apps such as Facebook that are rapidly displacing web pages like Facebook.com. But development for mobile devices produces a new set of issues we did not ever have to consider during the past decade of building web apps. These issues form the main case for ODBC on Apple iOS, including:
- Unlike a web page, app binaries must be downloaded ahead of time (via the AppStore), not upon each desired use. This has an important ramification in that any change made to an app's server has to maintain backwards compatibility with all prior releases of the app's binary or negative feedback will likely appear in the AppStore from prior consumers. Over time, we must make many changes for support of fixes, new iOS releases, database structure and additional functionality to remain competitive, but if we spent hundreds of hours writing our own server-side scripts to provide our database interface and each of those scripts maintained backwards compatibility with previous releases of our app binary to maintain customer satisfaction, then our scripts would become exponentially more complex, less secure and less reliable as they mature.
Web Database Integration
- While Apple does supply a built-in library for parsing XML documents (even though XML was designed for batch processing with power cords and air conditioning), it is best used for infrequent processing of one-off "config files" and "feeds", not actions occurring in real-time response to user interface events.
CALL, SELECT, INSERT, UPDATE and DELETE. Because the SDK implements the ODBC industry standard, it has compatibility with almost any database server ever produced and because it is designed for iOS, the low-level industry-standard API calls in C-Language are supplemented by easier high-level calls in Objective C that return query results as native iOS objects (NSStrings, UIImages, NSNumbers, ...) that may be passed directly into the Apple iOS SDK (UITableView, ...) eliminating client and server side JSON-string processing yielding more-users-per-server and longer mobile device battery life.
Because virtually every database system supports Windows in every past, present and future release, the ODBC ROUTER is designed to run exclusively on Windows, either in a virtual machine on top of Linux (using a free VMware Server) or Mac (using VMWare Fusion) or other (potentially free) hypervisors such as VMware VSphere, RedHat KVM, Citrix Xen or Parallels Bare Metal. Installation of ODBC ROUTER on Windows is trivial and works along side ODBC drivers supplied by the database vendors themselves (not obscure third-parties), for example, MySQL 5.1 ODBC/Connector, ORACLE ODBC and IBM DB/2 Connector.
Although not required, Microsoft's new, highly-secure and inexpensive "Windows Web Edition" may be used to host the ODBC ROUTER and the database system's official ODBC drivers for as little as a $10/month premium above Linux (or on your own server for free with a 180 day evaluation) and is typically configured with only port 6110 (and perhaps Remote Desktop port 3389) open on the built-in Windows Firewall.
The database server itself (eg, MySQL, SQLServer, DB/2, Excel, Firebird, Visual FoxPro, Access, ...) may either be installed on the same Windows instance as ODBC ROUTER (but perhaps only accessible to applications running on that same instance via shared-memory/named-pipes) or elsewhere in the back-end network or VPN/extranet on Linux, Unix, Mac, Windows or a legacy mini or mainframe.