I finally wrote my first BlackBerry (handheld) App
I spent a couple days over the last couple weeks working on a BlackBerry WebWorks application. The BlackBerry WebWorks API is basically a HTML/JavaScript application compiled into a Java application for use on the handheld. It has access to a fairly large set of the RIM APIs in the device and as I am not interested in learning Java, is about the only option I have.
As a primarily hobbiest developer I found the process to be fairly straightforward, though unfortunatly extremely Windows-centric. The primary debug workflow involves Eclipse and the BlackBerry device simulators, the latter being Windows-only. Trying to debug without the sim is a non-starter as the JavaScript engine will not throw any useful error messages while running live on a device. It is not wholly awful but I really do prefer avoiding Windows if I can reasonably manage it.
There are obvious Enterprise edges sticking out through the process though happily the new, fluffy, comsumer oriented image that RIM is putting on has really improved the developer start up process. Code signing keys no longer cost money, and getting them is basically a process of signing up in a web form and waiting a few days for the files to be delivered to your Inbox.
I ended up writing a small application that takes some of the backend data that powers my personal Status Board (similar to the Panic Status Board) and displays it on the phone along with some other useful data that I can get out of the RIM APIs.
I originally was just using jQuery to fetch the JSON from my status board but was somewhat unsatisfied by the performance of pulling the data over the macro network and loading it into the page every time the application loaded so I replaced that with an on-device cache and push update system that takes advantage of the BlackBerry Enterprise Server I have (RIM offers a free push service over BIS as well but I like the idea of using the BES’s encrypted transport) hosting my e-mail.
The push server side of the equation is somewhat poorly documented, mostly through snippits of Java and .NET code that other people have implemented and some PDFs from RIM describing the format. After some trial and error I was able to pull together a workable Python update script that fetches the JSON from my status board and pushes it to the handheld. This allows fast, bandwidth friendly, scheduled, asynchronous updates and improves the user experience quite a bit. I totally understand why RIM is pimping their push infrastructure as being a vital part of what they are calling “Super Apps”. Having the data come to the user versus making them constantly update it is kinda awesome.
I doubt this application will be useful for anyone else but in the odd case that it might be the code is available in my bzr repository, which you can view at: http://repo.ub3rgeek.net/branches/blackberry/files, the status-app directory contains the handheld application source and the push-server/status-push.py file contains the push application.
WiFi Calling – The biggest reason I am staying with T-Mobile
It is pretty obvious that T-Mobile is a fourth-string carrier here in the United States. They were pretty late to the 3G game and while now with their HSPA+ network they have the fastest network currently in wide availability in the US they still have a long way to go to even catch up with Sprint.
That said, around 3 years ago I left Sprint (after 7 years) and went over to the magenta side. I started traveling internationally and wanted a GSM phone and so, firmly remembering my hatred for Cingulair wireless (now AT&T) I went to the only provider at the time that would enable me to roam almost anywhere. And boy am I lucky that I did.
No other US nation-wide carrier presently supports dual-mode calling (WiFi and Cellular) which is a huge shame as it has been the single best feature of being a T-Mobile customer. Being able to fill the gaps in their coverage with WiFi is wonderful by itself but the true surprise is being able to reduce or even eliminate roaming charges when traveling internationally. I spent two weeks in Australia earlier this summer and while I was there when I could I spent much of my time actually registered on the T-Mobile network via UMA as opposed to roaming on Vodafone AU. This saved me about $80 on my bill versus the previous year when I was in Australia without having a phone capable of WiFi.
I really don’t know why every carrier doesn’t support this, being able to fill the gaps in your network by using unlicensed access technologies sure beats the hell out of the expensive femtocell technology, and the customer benefits of reducing roaming charges is a pretty compelling business case (if you ask me).
As an aside, presently only the BlackBerry and a couple Nokia handsets on T-Mobile support UMA. This is one of the huge reasons I won’t even consider switching to Android at this point.
Bluetooth DUN with BlackBerry 9700, T-Mobile and Ubuntu 9.10
I just bought a new laptop (Thinkpad T500) but the only WWAN cards available built in were for either Verizon or AT&T, which is suboptimal as I use T-Mobile which uses the AWS UMTS bands (1,4,8) instead of the bands used in the US by AT&T (1,2,5,6). Since my Blackberry 9700 supports T-Mobile 3G as well as their implementation of UMA I decided to try to get the Bluetooth DUN working.
Bluetooth DUN, T-Mobile UMA
After much searching, this post got me the closest though recent changes either with the new OS 5.0 on the 9700 or T-Mobile’s network have made some tweaks necessary.
http://pegelinux.wordpress.com/2008/06/11/blackberry-curve-8310-as-bluetooth-modem-on-ubuntu-hardy/
I will not go into all the step-by-step details as it is covered above and elsewhere, but first you need to get your computer to bind to the Blackberry DUN service via Bluetooth, I chose to edit /etc/bluetooth/rfcomm.conf to make this happen automatically, but BlueManager also seems to be able to do the same thing with a much more friendly UI if you want to try that route, anyway you cut it, you need to have the DUN service show up as a /dev/rfcomm# device. Once you have completed that you will want to setup pppd(8) much like the above article suggests.
This resulted in a session that looked like the following for me:
mernisse@mernisse-laptop:/etc/chatscripts$ pppd call gprs
Press CTRL-C to close the connection at any stage!
defining PDP context...
OK
OK
waiting for connect...
CONNECT
Connected.
If the following ppp negotiations fail,
try restarting the phone.
Script /etc/chatscripts/gprs-connect-chat finished (pid 14835), status = 0x0
Serial connection established.
using channel 1
Using interface ppp0
Connect: ppp0 < --> /dev/rfcomm0
sent LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x5db98b32>
rcvd LCP ConfReq id=0x0 <asyncmap 0x0> <auth pap>
sent LCP ConfAck id=0x0 <asyncmap 0x0> <auth pap>
rcvd LCP ConfRej id=0x1 <magic 0x5db98b32>
sent LCP ConfReq id=0x2 <asyncmap 0x0>
rcvd LCP ConfAck id=0x2 </asyncmap><asyncmap 0x0>
sent PAP AuthReq id=0x1 user="mernisse-laptop" password=""
rcvd PAP AuthAck id=0x0
PAP authentication succeeded
sent CCP ConfReq id=0x1 <deflate 15> </deflate><deflate (old#) 15>
sent IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms -dns1 0.0.0.0> </ms><ms -dns2 0.0.0.0>
rcvd LCP ProtRej id=0x1 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd IPCP ConfReq id=0x2 <addr 169.254.1.1>
sent IPCP ConfAck id=0x2 </addr><addr 169.254.1.1>
rcvd IPCP ConfNak id=0x1 <ms -dns1 0.0.0.0> </ms><ms -dns2 0.0.0.0>
sent IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms -dns1 0.0.0.0> </ms><ms -dns2 0.0.0.0>
rcvd IPCP ConfNak id=0x2 </ms><ms -dns1 0.0.0.0> </ms><ms -dns2 0.0.0.0>
sent IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms -dns1 0.0.0.0> </ms><ms -dns2 0.0.0.0>
rcvd IPCP ConfNak id=0x3 </ms><ms -dns1 0.0.0.0> </ms><ms -dns2 0.0.0.0>
sent IPCP ConfReq id=0x4 <addr 0.0.0.0> <ms -dns1 0.0.0.0> </ms><ms -dns2 0.0.0.0>
rcvd IPCP ConfNak id=0x4 </ms><ms -dns1 0.0.0.0> </ms><ms -dns2 0.0.0.0>
sent IPCP ConfReq id=0x5 <addr 0.0.0.0> <ms -dns1 0.0.0.0> </ms><ms -dns2 0.0.0.0>
rcvd IPCP ConfNak id=0x5 </ms><ms -dns1 0.0.0.0> </ms><ms -dns2 0.0.0.0>
sent IPCP ConfReq id=0x6 <addr 0.0.0.0>
rcvd IPCP ConfNak id=0x6
sent IPCP ConfReq id=0x7 </addr><addr 0.0.0.0>
rcvd IPCP ConfNak id=0x7
sent IPCP ConfReq id=0x8 </addr><addr 0.0.0.0>
rcvd IPCP ConfNak id=0x8
sent IPCP ConfReq id=0x9 </addr><addr 0.0.0.0>
rcvd IPCP ConfNak id=0x9
sent IPCP ConfReq id=0xa </addr><addr 0.0.0.0>
rcvd IPCP ConfNak id=0xa </addr><addr 14.36.76.18>
sent IPCP ConfReq id=0xb
rcvd IPCP ConfAck id=0xb
Could not determine local IP address
Connect time 0.1 minutes.
Sent 186 bytes, received 120 bytes.
sent IPCP TermReq id=0xc "Could not determine local IP address"
rcvd IPCP TermAck id=0xc
sent LCP TermReq id=0x3 "No network protocols running"
rcvd LCP TermAck id=0x3
Connection terminated.
Sending break to the modem
PDP context detached
Script /etc/chatscripts/gprs-disconnect-chat finished (pid 14843), status = 0x0
Serial link disconnected.
As you can see, a number of Naks have been received for things that do not work and the connection fails. Tracking each error down step by step I removed noauth from the peers file and replaced it with user “” to force a null user-name in the PAP authentication. I also removed userpeerdns as it appears that the Blackberry was refusing to give it to me. The final piece was that I was hitting what I assumed to be a race condition, as the Blackberry did not have an IP address to give me yet, it kept sending ConfNak to me until it finished setting up the tunnel to T-Mobile on my behalf… (see inset)
Tunnel List
mernisse@mernisse-laptop:/etc/ppp/peers$ pppd call gprs
Press CTRL-C to close the connection at any stage!
defining PDP context...
OK
OK
waiting for connect...
CONNECT
Connected.
If the following ppp negotiations fail,
try restarting the phone.
Script /etc/chatscripts/gprs-connect-chat finished (pid 15068), status = 0x0
Serial connection established.
using channel 12
Using interface ppp0
Connect: ppp0 < --> /dev/rfcomm0
sent LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x448e9c82>
rcvd LCP ConfReq id=0x0 <asyncmap 0x0> <auth pap>
sent LCP ConfAck id=0x0 <asyncmap 0x0> <auth pap>
rcvd LCP ConfRej id=0x1 <magic 0x448e9c82>
sent LCP ConfReq id=0x2 <asyncmap 0x0>
rcvd LCP ConfAck id=0x2 </asyncmap><asyncmap 0x0>
sent PAP AuthReq id=0x1 user="" password=<hidden>
rcvd PAP AuthAck id=0x1
PAP authentication succeeded
sent IPCP ConfReq id=0x1 <addr 0.0.0.0>
rcvd IPCP ConfReq id=0x1 </addr><addr 169.254.1.1>
sent IPCP ConfAck id=0x1 </addr><addr 169.254.1.1>
rcvd IPCP ConfNak id=0x1
sent IPCP ConfReq id=0x2 </addr><addr 0.0.0.0>
rcvd IPCP ConfNak id=0x2
sent IPCP ConfReq id=0x3 </addr><addr 0.0.0.0>
rcvd IPCP ConfNak id=0x3
sent IPCP ConfReq id=0x4 </addr><addr 0.0.0.0>
rcvd IPCP ConfNak id=0x4
sent IPCP ConfReq id=0x5 </addr><addr 0.0.0.0>
rcvd IPCP ConfNak id=0x5
sent IPCP ConfReq id=0x6 </addr><addr 0.0.0.0>
rcvd IPCP ConfNak id=0x6
sent IPCP ConfReq id=0x7 </addr><addr 0.0.0.0>
rcvd IPCP ConfNak id=0x7
sent IPCP ConfReq id=0x8 </addr><addr 0.0.0.0>
rcvd IPCP ConfNak id=0x8 </addr><addr 14.34.55.230>
sent IPCP ConfReq id=0x9 </addr><addr 14.34.55.230>
rcvd IPCP ConfAck id=0x9 </addr><addr 14.34.55.230>
replacing old default route to wlan0 192.168.196.1
Cannot determine ethernet address for proxy ARP
local IP address 14.34.55.230
remote IP address 169.254.1.1
Script /etc/ppp/ip-up started (pid 15070)
Script /etc/ppp/ip-up finished (pid 15070), status = 0x0
^CTerminating on signal 2
Connect time 4.7 minutes.
Sent 300422 bytes, received 1437245 bytes.
restoring old default route to wlan0 192.168.196.1
Script /etc/ppp/ip-down started (pid 15112)
sent LCP TermReq id=0x3 "User request"
rcvd LCP TermAck id=0x3
Connection terminated.
Sending break to the modem
PDP context detached
Script /etc/chatscripts/gprs-disconnect-chat finished (pid 15117), status = 0x0
Serial link disconnected.
Script /etc/ppp/ip-down finished (pid 15112), status = 0x0
mernisse@mernisse-laptop:/etc/ppp/peers$
Looking at the phone it appears that it snuck into Modem Mode and I was able to ssh around and perform the speedtest that adorns the top of this post. I used the gprs-disconnect-chat file unmodified from the post I linked to, but modified the gprs and gprs-connect-chat files which you can get by clicking on their names or looking at http://www.ub3rgeek.net/gprs/
Modem Mode, UMA
BlackBerry SMS logger and site changes
Firstly let me apologize for the mess, right now I have moved the WordPress installation to a standalone domain for back-end architecture reasons. There are redirects in place for most things but some things may be broken. Accept my apologies in advance for the inconvenience.
Secondly I have removed my old Gallery instance. I’ve been using Gallery 1 for ages because I don’t see a good reason to upgrade to Gallery 2 which I consider HIGHLY inferior due to the reliance on a RDBMS. As a replacement I have redirected all /gallery/ URLs to my Flickr page.
Thirdly, as a result of moving to Bazaar from CVS, much of the code that has been linked in previous entries is now over at repo.ub3rgeek.net.
Finally, for anyone with a BlackBerry that would like to get the SMS messages off the device so they can save the memory without losing the messages, or just to be able to use Unix tools to manipulate the messages I have written a small Python script which can be used, alongside the Barry Project‘s btool program to extract the SMS messages to a set of files sorted by Phone Number of the person you are corresponding with.
You can get the script at http://repo.ub3rgeek.net/branches//top/bbtools/files. Feel free to let me know if you find it useful.
Revision Control Revision
I’ve been using CVS for revision control for quite some time for a number of different things here, not the least of which being a public repository of scripts and miscellany that I have tossed into the Internet for public consumption. Recently I have started to feel the desire to change to one of the newer version control systems out there. Git and Hg smell a lot of ‘ooh shiny’ syndrome and we use Subversion at work so I was sort of naturally drawn towards Bazaar. It doesn’t help that I’m a huge fan of Canonical and Ubuntu, and as that seems to be the VCS du jour over there these days I figured that this would give me a good excuse to learn it.
The moral of this story as I’m sure no one cares why I chose which VCS is to say that any of the code hosted on my CVSweb and linked to in one of my previous posts is likely to have moved to the new loggerhead interface over at repo.ub3rgeek.net. If you happen to follow me on FriendFeed or watch the home page here, you will see updates from my bazaar commits as they happen.
Fancy, eh?
BlackBerry reboot loop :(
So last night I went and cleaned a bunch of stuff off the crackberry, like midpssh, which the 7100t is too slow to really use, and a few advanced themes (like the Dimension Zen theme) which were also slow on the 7100t. I rebooted to finish the removal and the crackberry went into a reboot loop. Terrified that I had hosed the system up big-time I tried to recover it using the awesome howto on crackberry.com (http://crackberry.com/blackberry-101-lecture-12-how-reload-operating-system-nuked-blackberry). Unfortunately vmware-player on linux takes too long to detect the USB device that I couldn’t interrupt the boot process and re-flash the device. Thankfully vmware on the Mac was quick enough to blow the OS back on.
Now to restore all my settings and themes…