February 4, 2009

QuickConnectLinux Beta 1 is Now available

Posted in Uncategorized tagged , , , , , , , , , , , , , , at 11:50 pm by tetontech

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

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.



  1. Hi –

    Just downloaded the Linux beta and compiled on Ubuntu, before I realized that it was intended for Nokia. Too bad it seems to build anyway.

    I had to make the following two changes to compile cleanly, oh and the diffs came out backwards, the corrected result is marked as <

    rec@elf5:~/Sources/QuickConnect$ diff QCAppController.cpp*

    > resultArray->append(result);
    rec@elf5:~/Sources/QuickConnect$ diff QCAppController.h*
    < #include

    > #include \

    I haven’t figured out what to do with it, but it built and ran, sort of.


    — rec —

    • tetontech said,


      I built and ran on Ubuntu using the QT library and the Beta IDE supplied by Nokia. The Symbian QT port is still in the works. What did you use to compile the example app? What are the issues you are seeing? If you give me more information maybe I can be of help.


  2. Hi Lee —

    Wow, you’re on top of this.

    I used the standard Ubuntu packages for QT4 and webkit, pulled for Jaunty Jackelope whatever alpha it’s at now 64bit. The idea is to build webkit based apps for Ubuntu itself, because why not. I built the minimal gtk/webkit app last night, so I wanted to see what QuickConnect and PhoneGap add to the minimum.

    The two compilation problems are evidently a stray backslash, which only generated a warning from the preprocessor, and what appears to be a deref level error, ie result vs *result. The latter generates a:

    g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_SQL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtWebKit -I/usr/include/qt4 -I. -I. -o QCAppController.o QCAppController.cpp
    /usr/include/qt4/QtCore/qvariant.h: In member function ‘void* QCAppController::dispatchToCO(QString&, QList*, QMultiMap*)’:
    /usr/include/qt4/QtCore/qvariant.h:413: error: ‘QVariant::QVariant(void*)’ is private
    QCAppController.cpp:60: error: within this context

    This is qt 4.5.0 so maybe they added some private’s since Nokia shipped the sdk.

    I’m finding your documentation a bit scattered. It seems that besides providing a webkit based app environment with access to some of the host native facilities through a javascript bridge, you’re also offering a packaging mechanism which bundles up whatever sources the app requires, too.

    So what it was that ./QuickConnect did when I started it up and clicked wasn’t obvious at all. It had a window with a database name, sample, a SQL query, select * from score, a button to execute the query, and a reset window button. The startup generated 24 lines of text on stdout/stderr.

    When I push the execute query button it generated about 3 pages of output to stdout/stderr and a javascript alert containing a JSON string. Dismiss the alert and the results of the query get displayed in the window, Inga’s doing well.

    I guess it makes more sense when I ignore all the noise coming out on the console. But what to do with it, how to make it do something isn’t at all clear from what I’ve read on the Blog, the Wiki, or the Source.

    I find it highly gratifying that it builds for Ubuntu as well as on Ubuntu for Nokia. That’s sort of surprising, but it means that it would probably build on every other Linux with a recent QT and WebKit.

    — rec —

    • tetontech said,


      All of the output to the console are my debugging messages for the Beta and can be ignored.

      Sorry for the lack of documentation. I have been working on it when I can but between writing the book for QuickConnectiPhone, keeping up with functionality requests, porting to various platforms, and debugging, life has been a little hectic. The book is almost done so I should have a little more time for documentation. I’m also a little tired right now so hopefully what follows will make some sort of sense.

      I had the idea for and began developing QuickConnect a little over a year ago when the first iPhone SDK beta shipped. The idea was to make it possible to create applications on all types of platforms in JavaScript since WebKit is so widely available. I also wanted to speed up application creation for implementers and so I added a framework implementation of a design I had been refining for 4 years.

      So QuickConnect has two main goals, the first is to have a library that allows calls to be made to the underlying system from within a JavaScript API that is identical across all platforms. The second is to eliminate the ‘glue code’ that we commonly have to write when we create applications. This second goal is accomplished by using the QC framework’s command-response paradigm that is implemented as a Front Controller and a series of Application Controllers.

      Most of what I am going to go over here can be found in the Wiki here. Since the JavaScript framework API is identical across all platforms, what is said there is the same for QuickConnectLinux.

      If we start with the database access example application that is currently shipping as the QCLinux Beta I can help you understand.

      BCF (Business Control Function) – a function used to access, store, and manipulate data
      VCF (View Control Function) – a function used to update/modify the visible portion of the application.
      ValCF (Validation Control Function) – a function used to validate user input.
      ECF (Error Control Function) – a function used to handle errors.

      The application creator needs to be aware of only a few files: index.html,databaseDefinition.js, mappings.js, and functions.js. All other files are supporting files that are part of the framework.

      To add functionality to your application you begin in the mappings.js file. The one you have in the example has two different commands. The first is ‘sampleQuery’ and the second is ‘reset’. The ‘sampleQuery’ command is mapped to a stack of functions to be executed when the framework receives the ‘sampleQueryCommand’. They execute in order from top to bottom. The first, getScoresBCF, makes a call down to the QT layer and makes a call to the sample.sqlite database to retrieve the data to be displayed. The second, getSillyMessageBCF, is in the stack to show that data can be retrieved from within the JavaScript application as well. After the BCF functions have been executed the framework will execute the VCF functions.

      The Wiki entry here has a diagram that may be of help since it shows graphically how a stack of functions are called by the QuickConnect framework.

      The first, displayScoresVCF, takes the query results passed to it by the framework and updates the view to display them. The displaySillyMessageBCF does the same.

      So, to put all of this in a nut shell so far, you map a command to a series of functions that the framework calls for you. The framework will handle all of the data passing between functions required for your application to execute correctly.

      If we look at the getScoresBCF and displayScoresVCF functions found in the functions.js file this will become clearer.

      the GetScoresBCF function puts together the SQL statement that will be run against the SQLite database included in the application. The query is executed as the result of making the getNativeData call. This call will execute code on the QT side of the application and the data will be asynchronously passed back up to the JavaScript side and recieved by the framework. That is why you don’t see any type of return of the data in the BCF.

      When the framework has called all of the BCF functions associated with the command it will call all of the associated VCF functions. The one we are interested in is displayScoresVCF.

      The results are passed into the displayScoresVCF as a JavaScript array containing one element for each BCF called. Since the getScoresBCF was called first the results of that call are found in the first element, data[0]. This element is a JavaScript object of type QueryResult. It has several attributes that contain the information from the database query.

      fieldNames: The names of all of the fields in the query result set
      data: a two dimensional array of data that is the information retrieved in the query result set
      errorMessage: the error message from the database, if any, generated as the result of the query
      rowsAffected: the number of rows added or changed if setNativeData was called.
      insertedID: the id of any new record inserted into a table that uses auto-incrementing primary keys

      You can see in the displayScoresVCF function that we are just building an HTML table with rows and columns, inserting the values in the fieldNames array into the table’s header and then inserting the query result data into the rows of the table.

      Having now mapped the commands and the functions to each other and created the functions now all we need to do is trigger the functionality. You can see where this is done in the index.html file. Notice that the ‘onclick’ listener for the Execute Query HTML button is set to “handleRequest(‘sampleQuery’)”. This call is the front controller for the framework. It instructs the framework to execute all of the functions in the stack mapped to the ‘sampleQuery’ command.

      All we have left to do now is setup the connection to the database. This is done in the databaseDefinition.js file. You can see that a new JavaScript DataAccessObject is created with a series of parameters. The first is the name of the SQLite database file, the second, third, and fourth are pertinent only to HTML 5 SQLite databases within the webKit implementation itself and so are unused for installed databases. The fifth and last parameter is a boolean indicating that the database is an installed or ‘native’ database.

      That’s it. It is now ready to run. Notice that you don’t need to worry about getting the data results and passing them around to your other functions. The framework handles all of that.

      In addition to the database access capability there is a wrapper for AJAX calls, called ServerAccessObject, that uses the same API as the DataAccessObject.

      If you look at the development roadmap you will see that many other types of functionality are in the works or already exist for the various ports. I’m working on getting all of the Beta’s updated with the functionality described.

      I hope this helps. I’m happy to answer any questions you may have.


  3. Lee —

    Thanks for the detailed explanation. I see there’s a lot more going on than I expected which explains some of why it was more confusing than I expected.

    — rec —

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: