Showing posts with label ios. Show all posts
Showing posts with label ios. Show all posts

Wednesday, December 26, 2012

Starting JSONBus: towards a replacement for Cordova/PhoneGap

Security warning 2015


The Cordova project has been fixing security issues in its external domain whitelist plugin over time, and has also dealt with security issues in its internal bridging mechanism. It is very strongly advised NOT to release an app with a custom-built web view bridging or domain whitelisting mechanism without proper code review and testing.

Hybrid architecture for mobile apps

Cordova/PhoneGap provides a framework to develop mobile applications in HTML5, Javascript, and CSS with common APIs to access native device functionality on a number of mobile platforms. Native device functionality that is not built into the Cordova/PhoneGap core can be accessed by using & adapting plugins for the desired platforms. The API function calls between Javascript and the native access classes are almost always asynchronous.

AFAIK there are a couple important things at an itty-bitty level:
  • All native access classes actually subclass from a Cordova plugin class; and
  • All function calls and callbacks are sent between JavaScript & native classes in string form. Function call & callback parameters are generally sent as numbers, strings, or JSON objects.
Despite such a simplistic asynchronous API model, Cordova/PhoneGap has become an increasingly complex framework with a very busy forum.

Simplification: a flow-based architecture

Last year I discovered the concept of flow-based programming which seems to have been used & refined over the past 40 years. Flow-based programming (FBP) breaks a large-scale application architecture down to independently threaded components that communicate via data packets, and there are some nice GUI tools to assemble FBP programs. I like the idea very much, however I have two major issues:
  • Each component is expected to be written as an infinite loop that receives its input as blocking reads; and
  • The data packet format & interface is relatively complex in order to accomodate data that is structural in nature.
I am now in the process of developing an idea called "JSON Flow" to design a flow-based architecture based on JSON messages.

UPDATE (June 2015): The "JSON Flow"/"JSON Bus" idea presented here is inspired by but different from FBP since it relies on (asynchronous) two-way message-based communication.

JSON Bus for a simplified asynchronous API

A subset of the "JSON Flow" idea is "JSON Bus" where Javascript code can send an asynchronous API request as a JSON message and receive a response via a callback. Here is a sample JSON Bus message for a DatePicker request:
{
  from: 'datepickerdemo',
  to: 'datepicker',
  data: {
    mode: 'date', 
    date: '12/12/2012/12/12'
  }
}
Here is a sample callback message:
{
  from: 'datepicker',
  to: 'datepickercb',
  data: {
    date: '12/13/2014'
  }
}


JSON Bus sample for Android

A sample of this idea for Android is available in brodyspark / JSONBus-sample-Android (in public domain). The application contains the following tests:
  • Quick JSON echo test;
  • Open a native DatePicker, which is adapted from the Cordova/PhoneGap DatePicker plugin for Android and display the selected date in the WebView.

Here is a quick tour of the existing sample code:
The first version of the JSON Bus sample does not follow the format shown above, however this should be fixed very soon.

This JSON Bus sample demonstrates an ability to send JSON messages in API function calls & callbacks and integrate some native GUI functionality with  application code developed using HTML5 & Javascript technology.

A first JSON Bus sample version for iOS

As a proof-of-concept, I hacked together a sample version in brodyspark / JSONBus-sample-iOS-with-wvjsbridge, using ExampleApp from marcuswestin / WebViewJavascriptBridge. In this sample, the HTML/Javascript sends a request with JSON data to open a native iOS date picker, which will send a result with JSON data when the user has selected the desired date. UPDATED: This sample is in a very crude state and will be replaced by something better in the near future is now abandoned in favor of: https://github.com/brodyspark/JSONBus-sample-iOS (made without WebViewJavascriptBridge and in public domain)

Next steps

Upcoming steps for the Android version include:
  • Fix existing samples to follow the message format given above;
  • A JSON message routing handler in Java, both for function calls from Javascript and for callbacks;
  • JSON message routing handler in Javascript;
  • Addition of a "subscription" model, where Javascript can make a single JSON Bus function call & continue receiving callbacks based on native events;
  • Adapter classes to include & build Cordova/PhoneGap plugin classes, including some built-in functionality, with little modifications if any.

For iOS the sample should really be is now rebuilt without the WebViewJavascriptBridge (see brodyspark / JSONBus-sample-iOS). I found a couple excellent links how to make function calls back and forth between Javascript & Objective-C here and also here. Then the enhancements from the Android version can be applied to the iOS version.

Tuesday, December 18, 2012

Integrating SQLCipher with Cordova/PhoneGap sqlite plugin for iOS

NOTICE (June 2015): These instructions are completely out-of-date, the following Cordova plugin supports sqlcipher out-of-the-box: https://github.com/litehelpers/Cordova-sqlcipher-adapter

These directions are based on the sqlcipher iOS tutorial, with a few adaptations to integrate with a Cordova/PhoneGap project.

Start with a Cordova/PhoneGap iOS project (documented here for Cordova/PhoneGap 2.2.0).

Download & extract the OpenSSL source from www.openssl.org/source in a location that will be referenced later (I used OpenSSL 1.0.1c).

Inside the PhoneGap iOS project folder, clone the github sqlcipher & openssl-xcode projects using commands like the following:

$ git clone git@github.com:sqlcipher/sqlcipher.git
$ git clone git@github.com:sqlcipher/openssl-xcode.git

Download the OpenSSL source from www.openssl.org/source (I used OpenSSL 1.0.1c) & put the source tar.gz file in the openssl-xcode sub-folder.


Add the subproject references for sqlcipher & openssl-xcode. This can be achieved by:

  • selecting the top-level target at the top of the tree control;
  • press alt-command-a;
  • for openssl-xcode: select the openssl-xcode folder and then select openssl-xcode.xcodeproj &
  • repeat these steps for sqlcipher (select the sqlcipher folder & select sqlcipher.xcodeproj).
Configure build dependencies:

  • select the top-level target again;
  • click the Build Phases tab;
  • expand the Target Dependencies;
  • add crypto (click "+", select crypto, and press Add);
  • add sqlcipher

and add the libraries to link:

  • expand the Link Binary With Libraries;
  • click "+" to add
  • add both libcrypto.a & libsqlcipher.a

IMPORTANT: please make sure that no sqlite3 library is being added here.

CHECK POINT: at this point, it should be possible to build the project with the openssl & sqlcipher dependencies.

NOTE: a couple steps from the sqlcipher iOS tutorial were omitted since they should not be necessary. If the project does not build, here are some things to check & try:

  • Please double-check that all dependencies, including Target Dependencies & Link Binary With Libraries have been fulfilled.
  • If the sqlcipher/libcrypto does not build, please read through README.md under openssl-xcode. You may have to configure the location of the OpenSSL sources if nothing else works.
  • The SQLITE_HAS_CODEC C flag, which is necessary to build sqlcipher with its cipher capabilities, should be defined within the sqlcipher subproject. It should not be necessary to define this flag within the top-level application project, however it is noted here just in case.

It should now be possible to add SQLitePlugin.[hm] to the project Plugins folder & build again. The following patch to SQLitePlugin.m should enable the plugin to use database encryption:


diff --git a/iOS/Plugins/SQLitePlugin.m b/iOS/Plugins/SQLitePlugin.m
index 871bd89..3d62208 100644
--- a/iOS/Plugins/SQLitePlugin.m
+++ b/iOS/Plugins/SQLitePlugin.m
@@ -79,6 +79,9 @@
         return;
     }

+    const char *key = [[options objectForKey:@"key"] UTF8String];
+    sqlite3_key(db, key, strlen(key));
+
     dbPointer = [NSValue valueWithPointer:db];
     [openDBs setObject:dbPointer forKey: dbname];
     [self respond:callback withString: @"{ message: 'Database opened' }" withType:@"success"];



Add SQLitePlugin to Cordova.plist resources, add SQLitePlugin.js to the www folder, and include SQLitePlugin.js in index.html. Try a small test program, like the one from the brodyspark/ PhoneGap-SQLitePlugin-iOS homepage, but open the database with a statement like this:


var db = window.sqlitePlugin.openDatabase({name: "DB",
    key: "secret1"});


If you try the program again but with a different key, you should see a db error in the console log.

In the future, I would like to provide a script or boilerplate to make it easy to create Cordova/PhoneGap projects with encrypted storage working from the beginning.

Thursday, December 6, 2012

Cordova/PhoneGap sqlite plugins offer large db size, excellent reliability

The Cordova/PhoneGap sqlite plugins (PhoneGap-SQLitePlugin-Android & PhoneGap-SQLitePlugin-iOS) offer some major advantages over the built-in WebKit SQL library API including support for large database sizes (see sqlite.org/limits.html) and excellent reliability.

Database sizes

The HTML5/Web SQL API imposes an upper limit of 5MB for client-side databases, which is more than sufficient for some applications but is very small by current standards. When using the Cordova/PhoneGap sqlite plugins then multi-gigabyte databases should be no problem according to sqlite.org/limits.html.

By standard compilation the default limits include:
  • 2 TB database:
    • 2G (2^9) pages with default page size of 1KB
  • 1 billion (1 000 000 000) bytes in a string or BLOB
  • columns: 2000
  • SQL statement length: 1 million (1 000 000) bytes
These should be more than sufficient to satisfy the needs most mobile apps that are published today.

Limits such as number of columns and SQL statement length can be changed at run-time.

Defaults and some other limits such as maximum number of pages can be changed at compile-time. This would require rebuilding the sqlite library itself, which will be covered in a future posting.

Reliability

Keeping the sqlite database in a known, configured location guarantees that the database will be kept up-to-date and backed up on the user's PC or iCloud for the iOS. Using the WebSQL library API does not provide these guarantees for iOS or Android.

There have been a number of reports of data loss problems with the WebSQL library, especially for iOS.

History of WebSQL problems on iOS

Starting in January 2012, this thread on the PhoneGap forum discussed the issue that the local storage or WebSQL persistent data would no longer be backed up as of iOS 5.0.1. Kerri Shotts was kind enough to post a workaround solution that backs the data up during an app shutdown and restores the data upon startup. She made very clear disclaimers that this was only a hack.

CB-330 was filed for this issue, and the solution was in fact to back the data up upon app shutdown and restore upon app startup. This is a pretty good solution but what would happen if an app or even a device would crash?

Some reports have been made recently including:

WebSQL on Android

Fortunately the issues with the WebSQL on iOS have not (yet) shown up on the Android platform. The WebSQL database is kept currently in a location that will be backed up on the PC, however this can be changed in the future.

Also on the PhoneGap forum there was a recent posting about data not persisted on the Android version.

In comparison, these kinds of problems have never been reported for the Cordova/PhoneGap sqlite plugins.

Saturday, December 1, 2012

PhoneGap SQLitePlugin for iOS & Android in separate projects

I have now setup the brodyspark user in github.com and moved the iOS and Android versions of the Cordova/PhoneGap sqlitePlugin to the following locations:


There is now a README.md file in the old location to direct the users to the new location.

The project was moved by first renaming the old github.com chbrody user to brodyspark then renaming the Cordova SQLitePlugin fork to PhoneGap-SQLitePlugin-iOS. In copy of the project, the iOS and Lawnchair adapter directory trees were removed to make the Android version using a git filter-branch command as described in this stackoverflow answer. Finally, the Android version trees and documentation in the README.md were removed from the iOS fork.

The sqlitePlugin offers excellent reliability and much more flexibility in storage size than the built-in WebSQL database. In comparison, there have been postings in the phonegap group about reliability problems with the built-in WebSQL database including this one for the Android version and this one for the iOS version.

The next major step is to provide better support for encrypted databases using SQLCipher. I had already made some posting about integration with SQLCipher in my old mobileapphelp blog but would like to describe a more generic procedure using PRAGMAs sometime in the future.