CodeIgniter Simplifies Web App Development
I wanted to take a moment to thank all of the folks who have worked hard to create what I consider to be the best web application framework available today– CodeIgniter.
CodeIgniter is an open-source PHP framework for developing web applications that greatly simplifies the development process and allows applications to be developed quickly and efficiently. CodeIgniter also includes numerous security features to help keep the sites that are using it safe.
DLF Systems chose CodeIgniter as the framework for the web application we developed for InSequent. For more information on that project click here.
The Perils of Upgrading
I’ve just had a very frustrating day trying to upgrade my Netbeans installation to version 6.5. I have a new J2ME project for a client that required the latest version of the Sprint Wireless Toolkit (3.3.2). It has been a while since I last worked with Netbeans so I figured upgrading all the components to the latest version would be in order. I would need the latest JDK as well (version 6, update 12) so that everything would be up-to-date. I spent an hour or so grabbing all the necessary files and running the installers, only to find that the shiny new Netbeans would no longer let me add a new MIDP platform to the project. All of the right buttons were there, but when I clicked ‘Next’ to choose the directory where the Sprint WTK resides, nothing happened. I had to cancel the dialog and finally I noticed the little red ‘something went wrong’ icon in the lower-right corner of the Netbeans window. Clicking on it revealed that a null pointer error had led to the badness I was seeing.
Needless to say I was very disappointed, and I ended up spending the rest of the afternoon trying various things to resolve the issue. The final solution was to downgrade back to JDK 6 update 11. Unfortunately the only way I could get my hands on the JDK 6 update 11 installer was to re-download the version of Netbeans that came bundled with it. Wouldn’t it be nice if Sun provided stand-alone access to previous versions of JDK 6? Anyway, I would recommend sticking with update 11 for a while if you’re using the Mobility plug-ins, especially if you are moving projects around.
Getting Started with iPhone Development
I was recently asked to recommend some books on iPhone programming, so I thought it would be good to share my experience in learning to code for the iPhone with everyone. While there are many books popping up on this subject (see Amazon’s list), I haven’t actually read any of them. I found the best resources were free and came directly from Apple. In order to get access to them you’ll need to register as a developer at Apple’s iPhone developer site, but you’ll be doing this in order to download the iPhone SDK anyway.
Once you are a registered developer, you’ll find a wealth of videos, how-tos, and other documents on Apple’s site to get you started. In my opinion, though, there are two documents that really contain the meat of what you’ll need to know to write apps:
These documents assume that you have a decent knowledge of C programming, which is the foundation for Objective-C. If you are a total beginner you will probably want to explore the plain-old C programming language before you try to dive in to Objective-C. Once you have your bearings, though, these two guides will be indispensable references as you begin coding for the iPhone.
And, much like the Windows Mobile world, iPhone programming is very similar to programming for its parent OS. If you’ve got experience coding for MacOS X much of that knowledge is directly applicable to coding for the iPhone. And if you’re starting out on the iPhone you’ll have a big advantage if you decide to write applications for MacOS X.
Good luck and happy coding! If you have questions feel free to comment here 
AT&T to Lock Down Windows Mobile?
It seems that AT&T will no longer be allowing third-party software to be installed over-the-air on Windows Mobile devices they sell without their approval. The latest batch of AT&T’s Windows Mobile phones may require any CAB files downloaded by the user to be signed by the carrier in order to be installed if the security policies of the recently-released Pantech Matrix are any indication. This is bad news for mobile developers with limited resources since it will require them to enter into a relationship with both AT&T and GeoTrust if they want to make their applications available for download on the latest AT&T WinMo devices.
Entering into this relationship will cost developers a lot of time, but they will also be taking a financial hit. The signing process is handled by GeoTrust (aka Verisign) and they require the use of a hardware key that plugs into a USB port on the developer’s system in order to authenticate the developer. This hardware is not free of course, and neither is actually getting an application signed. GeoTrust requires developers to buy ‘signing tokens’ which are consumed every time an application is signed for a release. Luckily developers can sign an application for testing without burning a token, but these signatures are only good for three days.
In addition to the cost factor, developers must also be approved by AT&T before any signing is possible. That means that if your application might compete with any AT&T products or they simply don’t like it for any reason your application will remain unavailable to AT&T customers. This is a departure from AT&T’s (and most other carriers’) previous stance on third-party applications, which only required their signature if the application required special permissions such as accessing the user’s phone book or sending SMS messages. It is still possible for applications to be loaded on J2ME-based handsets without the signature, they will simply deny the offending transactions or ask the user for their permission before doing things like accessing the network. The Windows Mobile lockdown, on the other hand, keeps any unsigned application from ever being installed in the first place.
It’s easy to see why AT&T would like things this way. This requirement would give them a lot of control over how their devices are used and a huge influence over the third-party application marketplace. While it’s still possible for end users to ‘side-load’ applications through ActiveSync and a USB cable, most people will certainly prefer the convenience of installing over-the-air without a connection to a PC. If your product can’t be installed over-the-air but a competing product can, you can be sure that the competing product will enjoy many more sales. This distribution model leads to a world where certain companies are almost guaranteed a majority of market share simply because of their relationship with people inside of AT&T.
I don’t mean to pick on AT&T exclusively, though. The ‘on-deck’ model of mobile software distribution is standard practice for carriers operating in the United States. Verizon Wireless operates under the same principles with their BREW platform and every carrier does this to a lesser extent with J2ME applications. Up until now, though, the world of Windows Mobile development has been relatively wide open, and WinMo developers enjoyed a level of access to the hardware that other platforms did not. It’s a safe bet that other carriers will take notice of this precedent and go the same route as AT&T, giving themselves much tighter control over how their devices are used. It certainly makes business sense for them to do so, but it comes with a great cost to consumers.
AT&T and other carriers will tell you that this distribution model protects consumers from malicious hackers who would like to control your phone. This is true, but any such distribution model will never be able to replace common sense. Mobile platforms are already fairly well protected from malicious code in that the user has to ‘invite them in’ by choosing to download the software in the first place. I have yet to hear of any incidents where hackers take control of mobile devices from the outside as they often do with PCs. In the meantime consumers will miss out on offerings from developers who would like to release free or open-source products and don’t have the time and money to spend engaging companies like AT&T and GeoTrust.
There is hope for change, though. I know of at least one major media company that is pushing forward with off-deck software because they use an advertising-based revenue model. Since AT&T doesn’t directly make money on software that’s given away, this media company is forced to charge users a monthly subscription fee in order to get their application delivered on AT&T handsets. Since consumers have to pay a monthly fee just to have the application on their device this keeps the vast majority of potential users from ever signing up. This goes against the media company’s desire to reach as many consumers as possible and has led to them offering their application off-deck. It’s still unclear how this will play out in the long term, but I’m willing to bet that there are other companies in the same boat who would rather not be under the carriers’ thumbs.
EDIT: I have worked with a few more AT&T Windows Mobile handsets since I originally posted this article that DID NOT require carrier signing for over-the-air CAB installation, so it is not clear whether AT&T intends to make this their policy moving forward. This article is based on my experiences with the Pantech Matrix handset, which we released with the security policy mentioned in this article. I do not have any sources within AT&T that can confirm or deny their intent to tighten security policies on Windows Mobile devices.
Identifying Your Windows Mobile Device
Sometimes your application will need to know what type of device it’s running on. One app I’ve been working on lately needs to get some configuration information from a server, but in order to give back an accurate config the server needs to know exactly which handset it’s dealing with. If the user were using the handset’s browser to make the connection the server would be able to figure out the model of the handset from the User-Agent header supplied by the browser, but our application is making those connections directly via calls to the HTTP functions in the WinInet library. In this case we need to figure out what device the app is running on through the API.
Luckily Microsoft anticipated this need and provided a way for us to get the information we need via a call to the SystemParametersInfo function. This function can actually tell you all sorts of things about the platform your app is running on, and lets you set many parameters as well. For a full list of what it can do, check out the details on MSDN. In order to solve our problem we only need to call it two ways:
TCHAR modelBuffer[64];
TCHAR manufacturerBuffer[64];
BOOL result;
result = SystemParametersInfo(SPI_GETOEMINFO, modelBuffer, 64, 0);
result = SystemParametersInfo(SPI_GETPLATFORMMANUFACTURER, manufacturerBuffer, 64, 0);
These calls will fill the two buffers with the manufacturer and model information for the Windows Mobile handset your application is running on. The third parameter specifies how many characters your buffer can hold. The final parameter is unused when we’re only reading information, so we just set it to zero. If the function returns a true value then you can expect that your buffer will now contain a string identifying your handset. You can then pass that information on to a server through calls to WinInet functions or just use it locally.