iPad Printing for Line of Business Applications

The iPad’s printing technology is built upon AirPrint, a technology introduced in early 2010. Hewlett Packard was the first printer manufacture to include the technology in their printers. The AirPrint technology is intended to relieve the need for printer drivers. It allows a computing device to print to an AirPrint compatible printer without having to search and install any printer drivers.

The iPhone, iPod Touch, and iPad devices use AirPrint because of the clamshell nature of their form factors. Apple chose not to include USB ports on their iOS devices so there is no place to physically connect a printer to the device.

The USB port alone would not solve the problem; printer drivers have long been an issue for mobile printing. A printer driver for Windows XP or Windows 7 would not be compatible with iOS devices and subsequently would need to be both developed and distributed by the printer’s manufacture. AirPrint is a solution that alleviates the manufacture’s need to create printer drivers for every flavor of desktop and mobile operating system. AirPrint provides the modern day one-size-fits-all page printing definition once dominated by Adobe PostScript.

Printer Manufactures supporting AirPrint

HP first introduced support for AirPrint within their e-All-in-One series product family, and it is available in all HP printers enabled with their ePrint technology. Epson has recently announced AirPrint support for future inkjet printers launched from the Fall of 2011 and forward. Cannon has released firmware updates to enable AirPrint support for their MG8220, MG6220, and MG5320 printers. Additionally any printer can be supported as an AirPrint compatible printer by loading software on a PC or Mac and then hosting the AirPrint service through the personal computer.

Possible configuration options

The AirPrint technology is dependent on the iPad and AirPrint device being on the same network and able to communicate over TCP/IP. This may present a particularly challenging problem when on customer’s campus where the guest WiFi access does not provide connectivity to their network printers. It is conceivable that a sales person could be granted access to their customer’s corporate Wi-Fi and print to all AirPrint compatible printers on that network, but the relative newness of AirPrint compatible printers makes it unlikely that one would exist onsite. If an AirPrint compatible printer did exist onsite, gaining access to the secured WiFi network would likely remain somewhat challenging in general.

An alternative option is to utilize a pocket router to connect a portable AirPrint compatible printer. Attaching the iOS device to the pocket router’s wireless network and the AirPrint compatible printer to the pocket router’s wired network will allow the two devices to connect. With the printer and iOS device sharing the network, successful printing can occur. The primary issue with this configuration is the pocket router’s inability to provide connectivity to the Internet without a wired connection to another Internet Service Provider’s (ISP) router. If the document intending to be printed is already open on the iOS device, then printing can occur. But if the iOS application requires connectivity to open the document needing to be printed then a ‘connected’ workflow required by the application would not be available because the document could not be successfully delivered to the iOS device without an internet connection.

The third possible configuration would be to use a cellular wireless access point like the Verizon MiFi 3G device. This will provide wireless connectivity to both the printer and the iOS device. The iOS device and the AirPrint compatible printer could communicate with each other through the MiFi hotspot. If connectivity between the two devices occurs, it would be possible for the iPad to communicate with both the AirPrint compatible printer and the internet.

When do the Agile development cycles cease

What is Agile:

Agile is an iterative software development process that helps flush out application requirements and functionality during development. This popular process has won the hearts of many software developers such as myself... but sometimes you have to ask... will we ever release this software?

Struggles Agile is not designed to assist with:

Winding down a development cycle is not about iterating on the app. And once the app has met the stability level necessary for release, the process becomes about user acceptance testing. As each stage progresses, the threshold for changing the code must become higher.

The threshold for code changes must be raised because code changes by nature introduce new bugs. They interrupt tested code paths. Some bugs can be critical to fix before releasing a quality application; changing code under those circumstances is necessary. However, if the threshold for code changes is too low then the project runs the risk of introducing new code that introduces new bugs, which in turn causes a downward spiral of new bugs and never ending code changes.

Agile does rapid software development well:

The agile process generally provides a lot of flexibility through iteration during app creation. The agile process stops when "code complete" occurs. At that point, the app's code base cannot continue to change or the code freeze process by nature must restart.

A few days are generally not enough time to go from code complete to app store release. I would concede that the smaller size of today's mobile apps have made it possible to reduce beta testing of enterprise apps from months to weeks.

What to do with the bugs found during code freeze:

There is a short answer as to what to do with bugs deemed not critical for release. Unfixed bugs remain logged in the ticket system and are then prioritized upfront when planning for the next release. If the application life cycle does not include releasing another version then each bug must be elevated to the quintessential "feature" or elevated into the critical bug list

There are countless positives to releasing a quality application. But the negative effects of elevating every bug or last minute feature request to critical are the development cost. Those last minute feature's and bug fixes are expensive to incorporate because the "fix" often resembles a round peg in a square hole. What I mean to say is that in general the solution works but it's not elegant, probably shoe-horned into already well-functioning code, and often containing a bug or two. During the final development stage project sponsors must be cognitive of if development cycles of never ending code changes are causing the development costs to exceed the eventual ROI of the project.

Twitter account available too: @benhorgen

Six months ago my wife finally talked me into creating a Facebook account. It appears my progression into social media continues. I opened a twitter account earlier today, and now this blog starts too. My goal: share current software development challenges and different ways I overcome them... or to sob publicly when I can't.