10.25.09
Speaking at iPhone Developers Conference
I am going to be speaking at the upcoming iPhone Developers Conference in Santa Clara on the 3rd of November. I’m going to be speaking on Rapid Prototyping and using QuickConnect.
If you would like to attend the conference, follow these instructions to get in for free.
08.20.09
Belkin Skype phone not connecting
My son purchased the Belkin Skype phone and it came today. He was very excited to use it. We spent hours trolling the internet, trying to install updates as was suggested in many places and all kinds of goofy ideas to get this thing to work.
It turned out that the device reacts very negatively to WEP wireless access points. We had chosen WEP since the early iPod touchs and iPhones didn’t react well to WPA. Of course they do now.
To fix the “cannot connect to Network” problem all we had to do is switch from WEP to WPA. The Skype phone works great now. He also reports that the FaceBook iPhone app is working better now as well.
Go figure.
01.18.09
Palm Pre and Mojo
Well, it looks like Palm has adopted the QuickConnectiPhone approach for their new phone’s SDK. In fact it is strikingly similar. Even down to using JSON as the data transfer type between application code and the device.
Hmm…. I wonder where they may have gotten an idea like that? More power to them.
It sounds like a port Palm’s new phones will be only a couple of days.
Developers —- Want to get an idea of how to develop for this new system type? Start working with QuickConnectiPhone or even the recently released QuickConnectAndroid.
In fact, write off of QuickConnect now and you will get an easy move over of your application to yet another device.
Just a reminder, QC is currently available for iPhone, Android and Mac and coming really soon for Linux, Symbian, and Nokia.
I can hardly wait to get my hands on this new Palm SDK.
01.16.09
QuickConnect Porting and Development schedule
I recently got a request for information regarding the planned development and porting of QuickConnect and thought it should be shared here as well.
I am particularly excited about the ad hoc networking. It will be great when an iPhone, an Android phone, a Linux based phone, macs, linux machines and even PC’s can discover each other and not need to care what the other device/machine is. Then an application can be anywhere and interoperate with versions of itself or other services on any of the platforms. And the applications can be written in JavaScript on all of the platforms. Wow.
The current porting situation is as follows:
- iPhone: release 1.1.1 available 1.1.2 next few days 1.5 beta in next few days as well
- Android: beta 1.0 available today if all goes well
- Mac: 1.0 beta 1 is currently shipping
- LinuxQT: beta 1.0 in a week or so
- MobileQT: about two weeks after LinuxQT beta
- Microsoft porting will happen after the MobileQT port is nearing completion.
The iPhone 1.1.2 release will include access from JavaScript to:
- device information – OS, device type, UID
- The iPhone 1.5 beta 1 release will include access from JavaScript to:
- ad hoc networking and service discovery (Bonjour Networking)
The iPhone 1.5 beta 2 release will include access from JavaScript to:
- Raw socket networking (access via the synch cable)
The Android 1.0 beta 1 will include access from JavaScript to:
- Browser and Native SQLite databases via the wrapper
- AJAX wrapper
- Vibrate
- Play Sounds
- Record and Play Audio
- GPS data
- accelerometer data
Android 1.0 beta 2 release will include access from JavaScript to:
- Embedded Google Maps
Android 1.5 beta 1 will include access from JavaScript to:
- ad hoc networking and service discovery
The LinuxQT 1.0 beta 1 will include access from JavaScript to:
- Browser and Native SQLite databases via the wrapper
- AJAX wrapper
- Drag and Drop utility if web view supports CSS transitions(experimenting with this now)
The LinuxQT 1.0 beta 2 will include access from JavaScript to:
- Embedded Google Maps
The LinuxQT 1.5 beta 1 will include access from JavaScript to:
- ad hoc networking
The MobileQT 1.0 beta 1 will include access from JavaScript to(when the device supports it):
- Vibration
- accelerometerdata
- GPS data
- Browser and Native SQLite databases via the wrapper
- AJAX
- Play sounds
- Play/record audio
The MobileQT 1.0 beta 2 will include access from JavaScript to:
- Embedded Google Maps
The MobileQT 1.5 beta 1 will include access from JavaScript to:
- ad hoc networking
12.16.08
QuickConnectiPhone 1.0 Release has shipped.

The 1.0 release version of QuickConnectiPhone is now available for download from SourceForge.
(See the 1.5 release announcement on this blog to see what additional features and examples have been added.)
It allows your application, from JavaScript, to:
- Get browser based database access
- Get access to databases shipped with or created by your application
- Get GPS location information
- Get device acceleration information
- Show and use native Date and Date/Time pickers
- Vibrate the device
- Record and playback audio
- Play system sounds such as the notification sound
- Use a prebuilt drag and drop framework to easily make any DOM object draggable
- Use a prebuilt scaling and rotation framework to easily make any DOM object resizable and rotatable.
Examples for all capabilities are included in the Examples directory included in the download.
An installer is included to add QuickConnectiPhone templates to both Xcode and Dashcode to speed your development. It will also install beta versions of QuickConnectMac and QuickConnectPHP as well as file templates for JavaScript and PHP files.
QuickConnectMac allows you to write Mac applications using the same JavaScript framework that you use for iPhone applications. You can use this instead of Adobe Air. Write your application once and compile it for both iPhone and Mac.
The QuickConnectFamily image Copyright Lee Barney 2008. All rights reserved.
11.29.08
QuickConnectiPhone 1.0 RC3 available
The latest release candidate, 3, is now available for QuickConnectiPhone a framework that allows you to build your installable iPhone applications in HTML, CSS, and JavaScript. If you want to create an iPhone application but don’t have time to or maybe don’t want to learn Objective-C you can use QuickConnect instead.
This release, like RC 2, includes an installer.
It also includes support for embedding Google maps in your installable JavaScript application. This new functionallity, in addition to the previously added capabilities of GPS location, acceleration, JavaScript debugging in Xcode, device vibration and sound, etc., adds new power to your applications easily. All you need to do is make one JavaScript method call that includes the locations where you want a pin dropped and a description. The framework does the rest and your custom map is displayed.
Database access is just as easy. A wrapper for the SQLite database used natively on the iPhone is included in the framework. It supplies you with two methods, getData and setData, that are easily used to access and modify your data.
AJAX is also supported by a wrapper with getData and setData methods.
In addition, this installer will install QuickConnectMac. You can now quickly port your JavaScript application from your iPhone to a Mac. Most of this porting will consist of changing your HTML and CSS to fit the larger screen.
Also, QuickConnectPHP is included. This is an implementation of the QuickConnect framework in PHP. It allows you to create web applications quickly and easily using the same engineered approach that you use for your iPhone and Mac applications. It includes a MySQL wrapper that supplies both of the getData and setData methods as well.
11.28.08
Why QuickConnect?
Recently in a response to a previous blog posting I was asked about what I see as the reason behind and the future of QuickConnect. I am posting my response here to make it easier for all to find.
Brad,
I have as yet not created a web page describing the intent of the QuickConnect platform. It basically comes down to this:
For the last 4 years I have been working on a framework implemented in multiple languages to speed up development of different types of applications. This is why you see QuickConnectPHP and QuickConnectYaws and will soon see QuickConnectJava and QuickConnectJ2EE. You don’t need them to write for the phone or the Mac but you may want to use them if you need to create a web application.
Why should an engineer/developer need to learn one framework for installed applications and another for web applications?
And why should an engineer/developer need to learn one framework to use in a web client and another for the server side of their web application?
And why again should this engineer/developer have to learn a different framework when moving from one language to another?
What I have attempted to do is to boil down all the engineering work I have been doing in the last 4 years to a lean, easy to use framework for multiple platforms, multiple situations, and multiple languages.
I can only hope that it will be of use to someone. I decided to make this work public since it has dramatically increased my productivity when writing apps.
Also, after years in the industry I came to teach in the Computer Information Technology department at BYU-Idaho. We teach the basics of the engineering behind QuickConnect to our undergraduates. This knowledge has given them a distinct advantage in the workplace when it comes to jobs so I felt it should be shared with a wider audience.
I hope this explains why I created QuickConnect.
06.11.08
Hybrid Mac applications
The code example here is now included in a framework called QuickConnectiPhone. If you want to know more have a look at this post as well as others in this blog.
In a previous post I showed how a UIWebview can be programmatically inserted into an application running on the iPhone using the new SDK. In this post I will explain how to insert a WebView into a Cocoa application running on the Mac. This example will show how to use the new Interface Builder that ships with the new SDK. I will also cover this soon for the iPhone.
There are a series of step that you should go through to accomplish this task. The names for items created in this example should be replaced with what you want them to be.
Steps:
- Select ‘New Project’ in the file menu

- Select the ‘Cocoa Appliction’ project template
- Name the new project. Mine will be called ‘example3′

- Create and name a new Objective-C file. I will call mine AppDelegate

- Open AppDelegate.h and add ‘IBOutlet id webView;’ to the class. This is the name that will be associated with the WebView that we will later drag and drop when we are using Interface Builder

- Add the WebKit Framework to the project. On my machine this is located in
‘/Developer/SDKs/MacOS10.5.sdk/System/Library/Frameworks
- Open the MainMenu.xib file by double clicking it. This will open Interface Builder. The xib file is found in the Resources group in your project.
- Open the library window by selecting it in the ‘Tools’ menu.
- Drag the ‘Object’ cube from the library to the ‘MainMenu.xib’ window

- Select ‘identity’, the ‘i’ tab in the inspector window labeled ‘Object identity’ and change the Class to be ‘AppDelegate’ or what ever you named the Objective-C class you created in step 4. This will create a link between the xib file and the Objective-C class. Notice that as soon as you rename the class the id you created in the header file in step 5 is now listed for the object in Interface builder as an outlet. This is what will allow us to gain access to the WebView we will soon create in Interface Builder.

- Add a WebView to the ‘Window’ window by selecting ‘Web Kit’ from the ‘Objects’ tab of the library window and then dragging the WebView element to the ‘Window’ window. A WebView will now appear in the ‘Window’ window that you can resize and locate anywhere in the window you would like. I will make mine slightly smaller than the containing window. You will also want to select the ruler tab in the ‘inspector’ window. By clicking on the light red arrows within the box in the ‘Autosizing’ section your WebView will stretch as the window stretches.

- Select the App Delegate item in the MainMenu.xib window and display the connections tab, select the ‘->’ in the blue circle. A small circle will exist to the right of the outlet ‘webView’. Drag it onto the WebView in the ‘Window’ window. This will cause an outlet connection to be made. This means that in the code your Xcode Objective-C code the ‘webView’ you added to the header file in step 5 will in essence be a pointer/reference to the WebView you created in Interface Builder in step 11.

- In the ‘Referencing Outlet’ section of this same inspector window for the App Delegate there is a line that says ‘New Referencing Outlet’. Select the small circle on the right and drag it over ‘Files Owner’ in the ‘MainMenu.xib’ window. A popup will be shown that says ‘delegate’. Select it. You class ‘App Delegate’ will now be used as the delegate for the application. This will allow you to now create functions that are triggered for events that happen in the application. Step 14 will be the implementation of one of these.

- Save the you changes by saving within Interface Builder.
- Implement the applictionDidFinishLoading method in AppDelegate.m. This is where you can write out to the log file using NSLog and tell the WebView to load a specific web page as well as other actions you may want to have happen when the application has completed loading. In this example we will load a page found locally on the machine that is part of the application itself. It is called ‘index.html’ and can be found in the ‘Resources’ group in the Xcode project. The code in the image shows you how to load this web page.

- Compile and select the ‘Build and Go’ icon to run the application.

06.04.08
WebKit speeds
A year ago I created a test to see how different JavaScript loop types compared based on speed. I compared a variant for loop against an invariant for loop and the for each loop. The test results, which can be found in the book Oracle Database Ajax & PHP Web Application Development (Oracle Press) by myself and Michael McLaughlin, showed that for all of the browsers examined the for each loop was much slower than the already slow variant loop and that the invariant loop was significantly faster.
If we were iterating over the elements in an array or map a standard looking variant loop would look like
for(var i = 0; i < array.length; i++)
An invariant loop would be
var len = array.length;
for(var i = 0; i < len; i++)
and a for each loop would look like
for (var i in array)
While the original tests were looking for percent speed improvements within a browser achievable by selecting the different types of loops I thought it would be interesting to modify the test to report raw speeds in milliseconds and then compare various browsers.
The speeds reported here are for the fast invariant for loop over a series of runs.
Safari 3.0 – 98 milliseconds
WebKit 3.1.1 – 37 milliseconds
Firefox 2.0.0.14 – 200 milliseconds
Firefox 3.0 RC1 – 28 milliseconds
The new WebKit shows a dramatic increase over the older Safari as does the new Firefox. WebKit appears to be nearly 3 times faster in this test than its’ older version used in Safari. This may be due to the changing of the JavaScript interpreter to SquirrelFish in the place of the older one. A discussion of SquirrelFish and why it is faster can be found at WebKit’sblog.
It will be interesting to see if this new version makes it into the upcoming iPhone OS 2.0. It would be fantastic if it was stable enough and did. Every bit of speed you can get on a handheld device is precious.