August 16, 2011

QC Native 1.3 available

Posted in Uncategorized tagged , , , , , , , , , , at 3:30 am by tetontech

For those of you doing native, not hybrid JavaScript, development with QC I have uploaded a new version of QC Native.  It rationalizes the differences between the Java and iOS versions making the APIs nearly identical.  I have also updated the API Docs for Android, created API Docs for iOS, and included both in the downloads as well as the QC Family web site.

The download now includes a SimpleDB example for both Android and iOS.  The example inserts values into the database, queries values from the database, and can do an HTTP GET.  The iOS database interactions show how to use CoreData.  I will soon (by the end of the month??) have an example using the Android ORM I’m developing.

Still working on that QC Hybrid release.  It is getting really close.  More on that later.


December 30, 2010

Pre-Threaded Android and iOS Apps now in QC 1.6.5

Posted in Android Development, iPhone development tagged , , , , , , , at 6:56 am by tetontech

All User Interface libraries, regardless of platform, require that the UI components start their updates from the ‘main’ thread.  Sometimes this is referred to as the UI thread but it is actually the main thread of the application.

What most people that are creating mobile apps don’t realize is that if they are using the main thread to do significant computation such as remote server access, XML parsing, database access, number crunching, etc. is that this makes their User Interface slow and chunky.  The ywill notice the unresponsiveness of their UI but will not know why it isn’t smooth.  They generally tend to come to believe that the problem is that the processors are not fast enough to do what they want to do.  This is generally not the case.

What they really need to do is move the computational portions of their apps into background (worker) threads and let the UI thread remain responsive to the user.  This can be a challenge that they are unwilling to attempt due to the perceived difficulty of implementing threading.

Starting with QuickConnect 1.6.5 I have made the native iOS and Android application templates pre-threaded for both iOS and Android apps.  This means that you, as a developer, no longer need to worry about creating the background threads and then executing UI updates on the main thread for your mobile apps.

When you use one of the mobile native templates in QC all of your validation and computation code is automatically executed on a background thread.  When this portion of your application is complete and you make a UI update the framework automatically causes your update to use the main thread.  You won’t even be aware of the change.

All of this is triggered every time you use the QC framework handleRequest method.  This is in addition to linearizing your asynchronous HTTP remote access calls and an easy to use SQLite wrapper.  With this kind of a head start it becomes much easier for you to create highly responsive, high quality apps in a much shorter time.

I will soon be making this multi-threading available to all of you using the hybrid iOS and Android templates as well.  It should make a huge difference in your execution speeds.

February 27, 2009

Android, WebView and AJAX

Posted in Android Development tagged , , , , , , at 3:35 pm by tetontech

Thankfully, as of Google’s release of Android 2.0 the XMLHttpRequest object is now included and supported as is the in-browser database and the CSS animations and transitions.  Welcome to the party Google.  It’s about time.

OK.   An update……  The XMLHttpRequest object does exist but it doesn’t work.  I ended up implementing my own http handling inside of QuickConnect.  Too bad Google.  You’re making our work harder.

The statement below still applies to pre 2.0 Android.

There has been some buzz about how to do AJAX from within the WebView component of the Android platform.  Unfortunately Google has not included the XMLHttpRequest object in the implementation for reasons they only know.  As I have scoured the web on this topic I have found many statements about how a work around ‘should’ be able to be done, some statements that simply state that it can not be done, and others saying that Google gears solves the whole problem.

Here is the reality.

Can it be done?  Yes.  Is Google gears the answer?  No.  It uses the XMLHttpRequest object.

I have spent a significant amount of time exploring possibilities.  The solution requires a call from JavaScript down to the Java layer of the application.  Simply stated, the Java code uses the HTTP classes, Connection , Client, etc. to make the request and the result is then passed back up to JavaScript.

The ‘gotchas’ are as follows.

  1. The return value of a call from JavaScript to Java can only return primitives and strings, not objects.  Therefore no type of complex dom-like object can be retrieved directly.
  2. The Android API requires that all communication from Java to JavaScript be done in the form of a URL change for the WebView.  This means that data must be URL encoded on the Java side and decoded on the JavaScript side.
  3. The URL encoder on the Java side doesn’t match the decoder on the JavaScript side.  The spaces in the data are converted to ‘+’ characters which remain ‘+’ characters in the JavaScript decoder.  This requires that the implementer of a library replace all instances of the space character with some other sequence on the Java side,  I used ‘_SpA_, and then replace all of the placeholder sequences with spaces on the JavaScript side.
  4. The javaScript dom parsing object doesn’t handle XML well.  The parsed result of an RSS feed isn’t even close to the XML it is sent.

After spending over a week exploring the possibilities I have come to the following conclusion.

The best way to get AJAX access within Android’s WebView objects is as follows.

  1. Make a call from JavaScript to Java including the URL.
  2. Using the Java-side HTTP objects make the request including any cookies stored on the Java side that may be needed.
  3. After receiving the completed response from the server determine the data type.
    1. If the data is JSON or HTML URL encode it.
    2. If the data is XML send it to Android’s SAX parser.
  4. Send the data to the JavaScript side of the application
    1. If the data is JSON or HTML do this directly
    2. If the data is XML use the SAX events to produce a JSON string that represent the XML node in question and pass the JSON for this node back up to JavaScript
  5. URL decode the data when it gets to the JavaScript side and put any spaces back in the data
  6. Handle the data in JavaScript
    1. If the data is JSON or HTML take any steps appropriate for you application.
    2. If the data is XML assemble a dom-like node structure as each individual JSON string representing a node is received.  Once the entire ‘dom’ document is built use it as if it had been obtained using the XMLHttpRequest object.

This approach will work.  My tests indicate that this type implementation could mimic the XMLHttpRequest’s functionallity but not necessarily its’ method structure.  They also indicate that implementations that use the Java side to make AJAX requests will be too slow.  Data sets of any significant size require to much encoding and decoding to be efficient.

I would hate to go through the very large development cycle required to do the implementation described above only to have Google wise up and include the XMLHttpRequest object.  At this point in time there are QuickConnectFamily roadmap items that seem much more feasible and demand my time.  If AJAX support becomes critical to QCAndroid developers I am willing to do an implementation with the understanding that it may not be usable for significantly sized data sets.

At this point QuickConnectAndroid will not have AJAX support because of the WebView object’s limitations.  The hope is that Google will realize it’s mistake and put the XMLHttpRequest object back in the WebKit engine implementation for the WebView Java object.  Pressure from the development community on Google may be of help here.

%d bloggers like this: