August 16, 2011
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
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
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.
The ‘gotchas’ are as follows.
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.
- Using the Java-side HTTP objects make the request including any cookies stored on the Java side that may be needed.
- After receiving the completed response from the server determine the data type.
- If the data is JSON or HTML URL encode it.
- If the data is XML send it to Android’s SAX parser.
- If the data is JSON or HTML do this directly
- If the data is JSON or HTML take any steps appropriate for you application.
- 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.