February 28, 2009
QuickConnectFamily Development and porting RoadMap
I have created a page for the official QuickConnectFamily development and porting roadmap. It can be found on the wiki here. I will keep it updated as Beta and release versions are shipped.
Feedback about priorities for development or additional functionality is appreciated.
Detecting Device information on the iPhone
Detecting the device specific information for the device your application is running on is very easy. The code below shows how this is done in QuickConnectiPhone 1.5 Beta 2 that will soon be released. It is found in the GetDeviceInfoVCO.m file.
I am gathering the following and putting it in an array so that the data can be passed up to the JavaScript.
- The device unique identifier
- The name of the device
- The localized version of the model of the device (iPhone, iPod Touch)
- The system name (iPhone OS)
- The system version (2.2.1, etc.)
- The language and locale used on the device(en_US)
- The short version of the time zone (MST)
UIDevice *aDevice = [UIDevice currentDevice];
NSLocale *currentLocale = [NSLocale currentLocale];
NSTimeZone *timeZone = [NSTimeZone systemTimeZone];
NSUserDefaults* defs = [NSUserDefaults standardUserDefaults];
NSMutableArray *passingArray = [[NSMutableArray alloc] initWithCapacity:5];
[passingArray addObject: [aDevice uniqueIdentifier]];
[passingArray addObject: [aDevice name]];
[passingArray addObject: [aDevice localizedModel]];
[passingArray addObject: [aDevice systemName]];
[passingArray addObject: [aDevice systemVersion]];
[passingArray addObject: [defs objectForKey:@”AppleLocale”]];
NSString *timeZoneString = [timeZone localizedName:NSTimeZoneNameStyleShortStandard locale:currentLocale];
if([timeZone isDaylightSavingTimeForDate:[NSDate date]]){
timeZoneString = [timeZone localizedName:NSTimeZoneNameStyleShortDaylightSaving locale:currentLocale];
}
[passingArray addObject: timeZoneString];
The JavaScript to display this information, found in the functions.js file of the DeviceDescriptionExample, is seen here.
function displayDeviceInfoVCF(data, paramArray){
document.getElementById(‘devDisplay’).innerText = ‘UDID: ‘+paramArray[0]+‘\n\ndevice name: ‘+paramArray[1]+‘\n\nmodel: ‘+paramArray[2]
+‘\n\nsystem: ‘+paramArray[3]+‘\n\nOS version: ‘+paramArray[4]+‘\n\nLanguage and Locale: ‘+paramArray[5]+‘\n\nTimeZone: ‘+paramArray[6];
}
Here is an image of this code running in the DeviceDescriptionExample application incuded in QC 1.5
A display of the information about the device running the application
February 27, 2009
Android, WebView and AJAX
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.
- 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.
- 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.
- 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.
- 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.
- Make a call from JavaScript to Java including the URL.
- 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.
- Send the data to the JavaScript side of the application
- If the data is JSON or HTML do this directly
- 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
- URL decode the data when it gets to the JavaScript side and put any spaces back in the data
- Handle the data in JavaScript
- 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.
February 22, 2009
QuickConnect 1.5 Beta 1 is now available
QuickConnectiPhone 1.5 Beta 1 includes the new Ad Hoc (Bonjour) Networking capability. From JavaScript you can now publish a service, connect a Bonjour browser to one of these services, and send messages from both the browser and the server. An example of how to use it is included. It is called BonjourNetworking. The BonjourNetworking example app is a chat service and client. Run it on your device and on the Simulator and you can test it out.
Since the server can send messages the framework allows for push from the server after the browser has connected. It will not push to a device on which the browser is not running.
Beta 2 will include the ability to ’round trip’ a request. That is to say you will be able to make an asynchronous request for data from a service and the framework will activate and act on the data when it is received. A new example application will be provided for how to ’round trip’ a request.
Beta 2 will also include the new Charting library mentioned in the previous posting.
Give it a try and tell me what you think.
The BonjourNetworking example running. A message has been received and sent.
February 21, 2009
Navigation bars in hybrid applications
I have had a couple of questions regarding if it is possible to have navigation bars, at the top or bottom, in a hybrid application. The answer is an emphatic yes. In fact it is dead simple.
I have been working on a charting library QuickConnect that is soon to be released in QCiPhone 1.5 Beta 2. The example application uses a navigation/tool bar at the bottom of the screen to change the chart being displayed. The first picture below shows the application with a pie chart displayed. The second image shows the same application after the bar button has been selected. I am showing these running in Mobile Safari in the Dashcode emulator so Safari’s standard bar is below the button bar. This example also works when put into a QuickConnectiPhone Xcode project. There Safari’s bar would not exist.
Showing a pie chart.
Showing the bar chart after the bar button has been selected
The bar at the bottom is the same element in both pictures. The way to do this is to make the stack layout part shorter than the screen and place the bar at the top or the bottom. If you want the default navigation bar at the top of the screen like the Mail app use Dashcode’s Browser part rather than it’s Stack Layout part and the navigation bar will be created and handled for you.
The image below shows the development screen for the charting example app. The upper-left of the picture shows box3, the navigation/tool bar, with its’ contained buttons. It also shows the stackLayout with its’ contained views. Notice that box3 is not a sub-component of any of the contained views.
In the design portion of the Dashcode screen notice that box3 is below the stackLayout object. It will stay there as the views update.
The design screen for the example application showing the stack layout part and the box that is the navigation/tool bar at the bottom
I hope this helps you see that there is little that you can’t do in a hybrid application user interface that you can do in UI builder.
February 7, 2009
QuickConnectiPhone 1.1.3 now available
QCiPhone version 1.1.3 includes the following changes.
- Example applications updated to 1.1.3
- apostrophes in the data of native databases now handled correctly.
- a stopBounce() function added in the JavaScript. It stops the UIWebView from bouncing when the interface fits in the view. Thanks
to Aarpn for the initial code. I’ll work on getting it to be more
flexible. - A Default.png file added so you can replace it with your own.
If you are interested, QCiPhone 1.5 Beta 1 is now available. The announcement is here
February 4, 2009
QuickConnectLinux Beta 1 is Now available
It took longer than expected, but it is here. QuickConnectLinux 1.0 beta 1 uses the 4.5 version of QT as the support for JavaScript application creation. Since the QT 4.5 library license is LGPL just like QuickConnectLinux, when the release of QT 4.5 is shipped by Nokia your applications can be created for free or you can charge for them without any payments or royalties.
The framework access to SQLite databases shipped with the application or created at runtime are both supported in this first beta.
I used Qt creator from Nokia to write the C++/QT back end code.
The nativeDBAccess example application running on Linux
Just like the other members of the QCFamily you write your application in JavaScript, compile it, and ship it. You users can then install the application and run it without access to the internet. QWebView is the class in QT that contains the WebKit engine and makes all of this possible. I have attached an image of the exact same HTML, CSS, and JavaScript used in the QuickConnectiPhone nativeDBAccess example application running on top of the QT port of the native framework.
I’ll put the Qt Creator project up on SourceForge as QuickConnectLinux 1.0 Beta 1.
I can now move back to working more heavily on QCiPhone 1.5 beta and then moving the QCAndroid and Mac versions from Beta to release. After than I will port QCLinux to Symbian. That should be easy since the Linux Beta now exists.
Progress is being made.
Teton Technical 