BlackBerry Facebook Application Broken

Details

Category: BlackBerry

Published on Tuesday, 14 May 2013 06:23

Something’s up with the latest version of the Facebook app for BlackBerry. Parts of the UI simply don’t work and I don’t know how to let BlackBerry know about it. Apps like TeleNav Navigator have a feedback function which allows you to let them know when something doesn’t work or if you have suggestions for the application. All of the different mobile OS are adding APIs for Twitter, Facebook and so on, why not add a feedback API that allows an app to send customer comments/feedback to the developer? No sense in each developer writing their own when it can simply be a default API on the device.

Anyway, to my problem! If you look at Figure 1, you’ll see the standard Facebook home screen running on my BlackBerry Bold 9930. Notice the three images at the top center (in the blue bar). What it’s showing me is that there are three ‘view’s available here and that one of them has new items.

Figure 1

Unfortunately, when I tap on one of those images (or even click on them using the touch pad that the Bold 9900 still has) nothing happens as shown in Figure 2. I can click on that image repeatedly and nothing happens except that the image gets highlighted.

Figure 2

Same thing with the little globe icon – click on it and it highlights but doesn’t change anything on the screen.

Figure 3

I can click on the chat icon and see the messages that have been sent to me by my friends, but clicking on either the people or globe icons does…nothing. Are any of you experiencing the same issue? Any suggestions on how I can let the folks at BlackBerry know and hopefully get a fix?

What Were They Thinking #13 – VZ Navigator

Details

Category: Mobile Development

Published on Tuesday, 30 April 2013 11:47

While I worked at AT&T, I became a big fan of the TeleNav Navigator application which later became AT&T Navigator. The interface was intuitive and it worked pretty well. When I joined SAP, they gave me a Verizon BlackBerry 9900 and I lost access to the navigation solution I was accustomed to using. On Verizon, they have their own navigation solution called VZ Navigator; here’s what it looks like:

Figure 1

I was using it recently to navigate somewhere and noticed something about the UI that really struck me as stupid, so of course I had to write about it here.

When you press the volume buttons on the side of the device to increase or decrease volume, instead of actually increasing or decreasing the navigation volume (which is what ANY smartphone user will expect), the application instead opens up the dialog shown in Figure 2.

Figure 2

This is simply the wrong way to implement this interface, and, to make matters worse, you can’t use the volume controls (those buttons on the side of a BlackBerry device) to move the selection on this dialog. I thought perhaps they simply made a mistake by implementing this dialog, but they compounded their error by forcing me to physically touch an item to make a selection rather than to just allow me to use the volume buttons to move the selection down and up on the screen.

Think about the use case – I’m driving my car and using this application to help me get to my destination. There’s  background noise in the vehicle, so I’m trying to increase the volume so I can hear better – and the application forces me to take my eyes off the road and make a selection on the screen rather than to simply use the buttons that BlackBerry put on the device to allow a user to adjust output volume. What this ‘feature’ does is make the application more difficult to operate and deliberately creates a safety issue for the user (and the occupants of the vehicles around the application user).

All the developer had to do was register a listener for the two volume buttons and act accordingly. The developer did register the listener, but instead of implementing expected behavior, they instead broke the application by implementing an unexpected and difficult to operate dialog. This makes no sense to me.

The market in general hates BlackBerry applications, but it’s not BlackBerry’s fault that this application is unusable – they provided all of the features the developer needed to make this application as functional and beautiful as similar applications on Android, iOS or Windows. The developer is the one that made this application less appealing.

The Solution to My Domino Server Configuration Problem

Details

Category: IBM Lotus Domino

Published on Thursday, 18 April 2013 20:51

Thanks to all of you who helped out last week as I struggled to get my IBM Lotus Domino server to accept HTTP PUT and DELETE requests. I posted two articles about my issues, you can access them here:

• Domino Server 405 Error
• Update on My Domino Server Problems

Essentially, I was building a sample Sencha Touch application for an article series I’m writing for The View (www.eview.com) and the Sencha Touch proxy by default uses different HTTP request types for each of the CRUD operations. The Domino server was refusing PUT and DELETE even though there were settings in the Domino Directory which enabled the server to accept them as shown in the following figure:

Figure 1

The answer came from Stephan Wissel who said:

... the classic Domino agents to GET/POST not Put. After you allow it you need to have an endpoint that actually handles PUT. A servlet does that. XPages might since it is a servlet (haven't tested it). Classic agents don't. Probably it is easier to reconfigure your app to use POST?

and Nathan Freeman who said:

It spells it out right there in the popup on the label for "Methods." You have to write your own Java servlet to handle PUT and DELETE. The native HTTP server simply doesn't process them at all. The checkbox is there just so the web server will accept those methods on the assumption that it's passing the request to a CGI or Java program that can handle them.

You'll have to write a servlet to do what you're trying to do.

So when I enabled the settings shown in Figure 1, all it seemed to do was allow the requests to pass through and I was responsible for implementing a servlet to deal with those requests. Yeah, I’m not doing that.

So,  I turned to the Sencha Touch Proxy configuration to see if I could change the way it worked to get around this limitation in the Domino server. When I started the process, I had a very simple proxy configuration as shown in the following code segment:

proxy : {
  type : 'rest',
  id : 'ci-proxy',
  url : 'http://server1/compete.nsf/(rest2)?openagent',
  enablePagingParams : false,
  reader : {
    type : 'json',
    rootProperty : 'ci_data'
  }
}

Looking through the docs, I found that I could add an actionMethods property to my proxy as shown below:

actionMethods : {
  create : "POST",
  read : "GET",
  update : "POST",
  destroy : "POST"
}

What this does is configure which HTTP methods are used for each proxy action type. OK, that seemed cool although it didn’t get me all the way there. See, when you change the actionMethods property, you lose the ability to easily detect the CRUD operation on the server side. This doesn’t change the URL passed to the Domino server, it only changes the HTTP method used to get to the server.

So, what I had to do next was use the proxy’s api property to specify the URL format to use for each request as shown below:

api : {
  create : 'http://server1/compete.nsf/(rest2)?openagent&cmd=create',
  read : 'http://server1/compete.nsf/(rest2)?openagent&cmd=read',
  update : 'http://server1/compete.nsf/(rest2)?openagent&cmd=update&',
  destroy : 'http://server1/compete.nsf/(rest2)?openagent&cmd=delete&'
}

With this in place, I had now configured the proxy to send a differently formatted URL with each request type.  That was exactly what I needed; now I simply had to parse the URL on the server to be able to tell what the Sencha Touch proxy was asking me to do.

Note: at about the same time I found these settings in the Sencha Touch documentation I received a comment on the site from Jack Ratcliff with a pointer to these settings. Thanks Jack.

So, at the end of all of this, here’s what the Sencha Touch proxy configuration looked like:

proxy : {
  type : 'rest',
  id : 'ci-proxy',
  url : 'http://server1/compete.nsf/(rest2)?openagent',
  enablePagingParams : false,
  actionMethods : {
    create : "POST",
    read : "GET",
    update : "POST",
    destroy : "POST"
  },
  api : {
    create : 'http://server1/compete.nsf/(rest2)?openagent&cmd=create',
    read : 'http://server1/compete.nsf/(rest2)?openagent&cmd=read',
    update : 'http://server1/compete.nsf/(rest2)?openagent&cmd=update&',
    destroy : 'http://server1/compete.nsf/(rest2)?openagent&cmd=delete&'
  },
  reader : {
    type : 'json',
    rootProperty : 'ci_data'
  }
}

Worked like a champ! Thanks everyone.

I’ll be finishing up the article this weekend and hopefully you’ll see the results in The View in a few weeks.

You may be wondering why only the update and destroy commands have the trailing ampersand - you'll have to read the article to see why (sorry).

Calatrava

Details

Category: Mobile Development

Published on Monday, 15 April 2013 20:23

My publisher told me about a cross-platform mobile framework today called Calatrava (http://calatrava.github.io/). I still need to do some reading about what it really is, but something in the announcement caught my eye:

"Mobile is the oncoming train of the future of computing. For more and more users their mobile device is becoming their first way to reach everything on the Internet. You need to be on-board with this. But there are three platforms to support: iOS, Android and Mobile Web."

I’m surprised – I wasn't aware that there were only three platforms a developer needed to target for their mobile apps. It does surprise me sometimes how much ignorance there is in the world.

And mobile an oncoming train? Where have they been - the train has stopped in the station, refuelled and picked up a bunch of passengers. Heck, it's halfway to its next destination.