Wednesday, 27 April 2011

Tour de Mobile Flex on iOS

Domino data access - SOAP vs AMF3 - a live performance test...

OK, I believe it is clear that this test is all about receiving data from a Domino server in a non Notes Client using our data access API for Domino called soapgateQ!

But nevertheless I will provide some background:

soapgateQ! - as the name indicates - is a web service based generic data access API to the Lotus Notes Domino server. So soapgateQ! only talks SOAP. We have been interested on whether we will experience a performance gain, if we sort of plug a PHP server running AMFPHP in front of the Domino server.

So the test looks at 2 scenarios:
  1. A Flash/Air application talking to Domino via web services (SOAP)
  2. A Flash/Air application talking to a PHP server using AMF and the PHP server in turn talks to Domino using SOAP
Because of the reduced overhead using AMF, data is received much faster at the client. For the test we used a simple Notes database with 3.871 documents (rows), listed in a view with 2 columns. To test the performance we used the dbColumnX() web service operation provided by soapgateQ. This operation returns any requested  column, plus another 2 columns (noteID/UNID and the view entry number). Hence for this test we receive in total 4 columns of data or in technical terms an array of strings with 15.484 elements (as web services only support single dimensioned arrays). Using SOAP (1) the received data amounts to  ~ 531.859 Bytes, whilst using AMF (2) this amount is reduced to ~155.633 Bytes.

I believe the below table speaks for itself:

Server Upload Speeds
GSM (14,4 Kbit/s)
ca. 309.074ms
ca. 91.830ms
GPRS (53,6 Kbit/s)
ca. 86.871ms
ca. 25.901ms
UMTS (348 Kbit/s)
ca. 21.267ms
ca. 6.759ms
DSL 1000 (1024 Kbit/s)
ca. 13.125ms
ca. 4.952ms
HSPA (7327 Kbit/s)
ca. 10.447ms
ca. 4.766ms
DSL 16000 (16000 Kbit/s)
ca. 10.189ms
ca. 4.385ms

Here is a link to the live application:

Monday, 25 April 2011

Bookstore Demo for Playbook has been approved...

yeah, I finally got confirmation that my signing process was successful. The Bookstore Demo application as been approved by Blackberry App World...

Saturday, 16 April 2011

Signing your Playbook apps for the Blackberry AppWorld...

28/4/2011: I added a comment further down...

For the last week I have been struggling to get my first Blackberry Playbook application signed so that it may finally pass the approval process. The problem is: the procedure as outlined on the Blackberry Vendor pages is just not working.

The Signing your application page provides a number of links for the different methods of signing an application depbatending on the EDI and the target platform. The two I thought relevant to me would be the first two:

However, you can simply forget all that is written in there. The configuration process is creating a corrupted certificate and the sign process simply fails without any notification whatsoever.

After quite some correspondence with Blackberry App World Requests I got a link to a video of another developer struggling with the same issues...

Just in case you're too lazy watching it, the summary is, that the Flash Builder UI driven process is not working or not reliably working and the alternative Command Line Process has also lots of problems. Quintessence is to wait for the final build of Flash Builder 4 Burrito and for Blackberry improving on the signature process itself.

Well, interesting is that I got the link to the video as a means to help me in solving my problems...hmmm!?

OK, I'm not the character giving up easily, so I looked into the Command Line signing process and - to fast forward a bit - got it to work. Not without some tweaking though. but before I go into details, here are the two links to what Blackberry has to say about the command line procedure:

As I already had created my certificate using the Flash Builder UI (not knowing at this point in time that the certificate was invalid), I initially tried to call the blackberry-signer.bat with the appropriate parameters. I actually created my own batch file for it:

CD "\Program Files (x86)\Adobe\Adobe Flash Builder Burrito\sdks\blackberry-tablet-sdk-0.9.4\bin\"

blackberry-signer -verbose -cskpass -keystore "D:\FlashAppCert\flexdominonet-dvl.p12" -storepass [password] "D:\BlackberryApps\" RDK

blackberry-signer -keystore "D:\FlashAppCert\flexdominonet-dvl.p12" -storepass [password] "D:\BlackberryApps\" author

Unfortunately the first call of the blackberry-signer batch file created following error message:

Error opening registry key 'Software\JavaSoft\Java Runtime Environment'
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.

I checked the registry and indeed nothing there would have pointed to my Java SE Runtime Environment. So I visited the Java download sites and first run the provided verification test, which said that I had the recommended version installed. So all OK, right!?  Well, just in case, I re-installed the Java runtime. But no luck, it still did not work. So I had a look at the blackberry-signer.bat file and all the other .bat files too. Just in case you haven't read the details in the provided links above, the mentioned batch files are located in the BIN sub-directory of the Blackberry tablet sdk directory, which should be somewhere here...

C:\Program Files (x86)\Adobe\Adobe Flash Builder Burrito\sdks\blackberry-tablet-sdk-0.9.4\bin

...and the content is this...

@Java -cp "%~dp0\..\lib\EccpressoJDK15ECC.jar;%~dp0\..\lib\EccpressoAll.jar;%~dp0\..\lib\BarPackager.jar;%~dp0\..\lib\BarSigner.jar"  net.rim.device.codesigning.barsigner.BarSigner %*

The failing bit is the @Java part. Replace this by the physical path to the java.exe of your Java Runtime Environment and the batch files will work correctly. I actually copied my current 32bit Java Runtime Environment into the Blackberry SDK directory and hence my blackberry-signer.bat looks now like this:

"C:\Program Files (x86)\Adobe\Adobe Flash Builder Burrito\sdks\blackberry-tablet-sdk-0.9.4\jre\bin\java" -cp "%~dp0\..\lib\EccpressoJDK15ECC.jar;%~dp0\..\lib\EccpressoAll.jar;%~dp0\..\lib\BarPackager.jar;%~dp0\..\lib\BarSigner.jar"  net.rim.device.codesigning.barsigner.BarSigner %*

I made that same change to all other batch files in the BIN directory.

When I was running the signing process now, I got yet another error message from the second blackberry-signer call (the -keystore one...see above), and this one was even more confusing:

“barsigner error: Certificate chain not found for: must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.”

This was the point where I thought the best is to create the certificate again. I looked at the Configure Application Signing procedure (see above link) and skipped points 1 and 2 and just re-created the .p12 certicate file using following batch file:

CD "\Program Files (x86)\Adobe\Adobe Flash Builder Burrito\sdks\blackberry-tablet-sdk-0.9.4\bin\"

blackberry-keytool -genkeypair -keystore "D:\FlashAppCert\flexdominonet-dvl.p12" -storepass [password] -dname "" -alias

================================== added comment
According to Elliott Bebane's response to this posting,...

the last parameter above -alias, must 
eventually be changed to the fixed term -alias author
instead of the vendor name registered with Blackberry
(which in my case is

I can't recall exactly what I did at this point and 
I don't dare to change my working environment to 
re-test. So try it with author if your vendor name as 
alias is not working.

After that I ran the second blackberry-signer call again (only, as the first call succeeded and cannot be repeated unless a new version number for the .bar file is issued):

CD "\Program Files (x86)\Adobe\Adobe Flash Builder Burrito\sdks\blackberry-tablet-sdk-0.9.4\bin\"

blackberry-signer -keystore "D:\FlashAppCert\flexdominonet-dvl.p12" -storepass [password] "D:\BlackberryApps\" author

And finally I got my .bar file signed. Recognizable on the fact that the BAR files META-INF directory contains the required signature files:


Finally there are a few things to take care of with regards to the packaging of the BAR file. The following link explains this in detail: