John Wargo

A lot of people have asked me to post the slide deck from my Lotusphere 2010 Beyond the Browser: Building Rich Client Applications for Domino (AD114) session. I wasn't sure whether I was allowed to post it, but I received the following confirmation from the track manager:

"Attendees can download whole tracks from Lotusphere online so please direct them there if for some reason they are not aware.  For non-attendees, you can post the slides on your site."

So, that being said, the presentation is attached to the end of this article

The session was a lot of fun although the Demo Gods rained trouble on me. I was prepared for that and had finished demos ready, so nobody left without seeing how it worked. That didn't stop people from complaining about it in their session evaluations though. Oh well, sometimes you just can't win. I'm making some progress on the Android sample application I showed a part of in the session. I should have that done in a few weeks (need to finish my move to North Carolina first). Stay tuned.

Attachments:

File	Description	File size
AD114.zip		865 Kb

As part of my family’s move to Charlotte, it was time to start looking for a new bank. We selected Bank Of America and proceeded to setup our new accounts. It occurred to me to take a look to see if the bank had an iPhone application and I was pleased to find that they did. I downloaded the application from the iTunes and proceeded to launch it. When the application starts, it presents you with the screen shown in the following figure.

Figure 1

You can then define your account login information (including the same additional security measures Bank of America uses on their desktop browser application) and access all of your accounts and transactions. It’s pretty cool and I like it. I’m not going to show you this with my own accounts (yes, I blanked out my login name in the figure below), but I’ll describe it. What you see after you login is a list of your accounts. When you select an account, you’re provided with a list of transactions and other information.

Figure 2

The only complaint I have about the application is that it’s very sluggish – after you login and start navigating through the account information, the screen response is very slow. Whoever wrote the application apparently didn’t know how to optimize the menu items and so on to provide the best user experience.

Where the What Were They Thinking stuff begins is when you look at the BlackBerry version of the application.

I didn’t expect that there’d be a BlackBerry version of the app. It wasn’t until I’d used the iPhone version for a while that I thought to look in the BlackBerry AppWorld for the app. Surprise of surprises – Bank of America also offers a BlackBerry application. So many times, vendors decide that all people care about is the iPhone application and skip other platforms. In this case, they are trying to accommodate multiple platforms. The problem is that they didn’t implement the same features in the BlackBerry version of the application.

When you open the BlackBerry version of the app, you see the screen shown below.

Figure 3

It looks like the same features of the iPhone application. When you open the ‘Locations Near Me’ option, the application uses the GPS information available on the device to determine the location of the nearest bank locations – very nice.
When you click on ‘Mobile Banking Sign In’ you’d think it will prompt you for your credentials and allow you to view account information (just like the iPhone app). Nope, that’s not how it works here. When you select this option, you’re presented with the following screen.

Figure 4

What???? The Browser? What were they thinking? The iPhone application shows an interactive list of accounts then allows you to browse the account transactions inside of a native iPhone application. The BlackBerry application launches the browser and gives you the exact same functionality you’d get if you fired up the browser and typed in www.bankofamerica.com in the address bar. The browser???

Eventually you get to the login prompt and you just have to deal with the mobile browser version of the site.

Figure 5

What’s the point? It’s essentially useless except for the branch finder. I just don’t know what they were thinking. The bank spent the time and money to build a fully functional iPhone app but relegated BlackBerry users to a simple application that merely launches a particular URL in the BlackBerry browser.

Developers: Please don’t do this. The functionality the application needs to call on the back end to get the account information and account activity clearly exists (the iPhone application is using it) and the BlackBerry platform supports the exact same application capabilities that the iPhone does (the same API’s are generally available across both platforms) so why the dfifference? I bet it was harder to do for the BlackBerry and it will take them some time to deliver parity. I’m OK with that – UI’s are just easier to build on the newer platforms (iPhone, Android).  But the BlackBerry can call any service on the back end and process the data – just like the iPhone app. If it’s too hard to build the long list of account transactions like used in the iPhone application, just have the server return the activity as HTML and render it in a BrowserField in the BlackBerry version. You’d still get the same data and you can make it look like the iPhone application (although on non-touchscreen BlackBerry devices it won’t be as easy to navigate. You could always intercept the click within the browser field and open up the selected account activity record natively.

Anyway, my personal opinion is that hybrid applications for the BlackBerry should be avoided at all times. If you need to launch the  browser to provide your application with specific functionality then you’re not really trying to build a BlackBerry app – all you’re building is a shell program that uses the browser for its heavy lifting and I’m really not interested in using that kind of application.

Robert X Cringely used to publish on www.pbs.org and now publishes his own blog at www.cringely.com. He has done a bunch of cool things related to the PC industry over the years – including being the author of Accidental Empires: How the Boys of Silicon Valley Make Their Millions, Battle Foreign Competition, and Still Can't Get a Date which I really loved.

Anyway, he writes about US Security every once in a while and recently published the following regarding how hard it was for US Officials to determine whether this Christmas Day Bomber was a terrorist:

“Instead of just complaining, let’s take a look at the issue from another angle. Contrast these three situations: 1) you are sitting in a hotel bar in Mongolia and want to use your Visa card to buy a round of drinks for your friends, and; 2) your Mom is at the check-out counter at a Sears store when the clerk asks her if she wants to apply for a Sears credit card and save 10 percent on her order, and 3) a possible terrorist with a dubious travel record and suspected al-Qaeda connections is standing in line at a European airport waiting to board a flight to the U.S. that leaves in an hour. What happens in each of these cases?

In Mongolia the bartender takes your card and authorizes it in seconds across a 12,000-mile round-trip. At the Sears store the transaction is not only authorized in less than a minute, but a new account is created and both your Mom’s identity and her creditworthiness are established and calculated on the spot, along with her discount. Meanwhile the airline, airport, local security, European police, Interpol, Transportation Security Administration, Department of Homeland Security, Customs Service, FBI, CIA, and NSA can’t between them figure out in an hour whether this guy standing in line in Holland should be allowed on the plane or not.

How is it that we can run our credit card operations so well and our national security so poorly?”

He’s right and has every right to be mad. Read the full article: http://www.cringely.com/2010/01/predict-me-im-from-the-government.

As I mentioned last week, I’d been trying to build an Android application for my rich client session at Lotusphere 2010 (AD114). I got off to a very late start, but with the right resources I thought I could throw something together to show in my session.

I took the XML-based web service I created for the BlackBerry Java and Windows Mobile examples (they both provide native support for XML-based web services) and created a new one that used Representative State Transfer (REST) to process the request and return some JSON with the results. The agent is working great, I’ll write about it in a little while.

I created a Android Java project in Eclipse and started coding through my sample application, reading a couple of books as I went. I got the main application working, got the search box and the button that called the service working and was finally able to connect to the local Domino server to request the data (read about that here). As I tried to figure out the Android ListView widget, my application crashed and I just couldn’t get any further. I poked and prodded in Eclipse and the simulator and just couldn’t get anywhere.  Whenever I load the application, I get the following screen:

It’s something in the startup of the application, but it’s not telling me anything about the source of the problem. On the flight home, I read more about the LogCat view in Eclipse that would allow me to see what Android is saying when the application crashes. It turns out that there’s an uncaught exception being generated when the application starts. Here’s the relevant log lines:

01-25 15:57:16.082: ERROR/AndroidRuntime(244): Uncaught handler: thread main exiting due to uncaught exception
01-25 15:57:16.092: ERROR/AndroidRuntime(244): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.johnwargo.contactlookup/com.johnwargo.contactlookup.main}: java.lang.ClassCastException: android.widget.TextView
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2496)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2512)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at android.app.ActivityThread.access$2200(ActivityThread.java:119)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1863)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at android.os.Handler.dispatchMessage(Handler.java:99)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at android.os.Looper.loop(Looper.java:123)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at android.app.ActivityThread.main(ActivityThread.java:4363)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at java.lang.reflect.Method.invokeNative(Native Method)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at java.lang.reflect.Method.invoke(Method.java:521)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at dalvik.system.NativeStart.main(Native Method)
01-25 15:57:16.092: ERROR/AndroidRuntime(244): Caused by: java.lang.ClassCastException: android.widget.TextView
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at com.johnwargo.contactlookup.main.onCreate(main.java:58)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2459)
01-25 15:57:16.092: ERROR/AndroidRuntime(244):     ... 11 more

At least I know what’s happening now – all I need to do now is figure out the source of the problem. I’m disturbed that I’m not getting more information in the UI about the problem. On the BlackBerry platform, you’d get an error message identifying that there is an uncaught exception and listing the exception that should be caught. If I had that information, I think I could find this problem pretty quickly.

OK, so I dug into the code and found the problem. I was using EditText and TextView widgets to create some of the UI. EditText widgets to accept user input and TextView widgets to display some text on the screen. When playing around with some things, I’d inadvertently cast the TextView as an EditText object (that happens some time when you’re copying and modifying code). As soon as I changed the cast to TextView, the application is running again. Woohoo! 

The line containing the information I needed is here:

01-25 15:57:16.092: ERROR/AndroidRuntime(244): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.johnwargo.contactlookup/com.johnwargo.contactlookup.main}: java.lang.ClassCastException: android.widget.TextView

Next step is to figure out how to use an Android ListView widget to display the array of names that is returned by the Domino server. Stay tuned…