Thoughts from the Road

I’m in Tampa, at the University of South Florida, attending the Higher Education Enterprise Mobile Applications Conference (HEEMAC). I’ve seen and heard some really great things that colleges and universities are doing, from a mobile enterprise perspective.

One group, however, is strikingly absent – faculty. I’ve run into Associate Deans, technologists, native app developers, web developers, and even the odd CIO… but only one or two faculty members, out of 100+ conference attendees.

Admittedly, this is an enterprise mobile conference, and not one centered upon pedagogy.

Still.

I believe that faculty are under represented, overlooked, and generally ignored in conversations of campus technology, where they are every bit as much stakeholders as the students we strive to support. This week is only reinforcing – at least, for me – the great divide between academics, and the information technology infrastructure supporting the administrative side of things.

I was heartened to hear words like “enable” and “facilitate” in the context of opening up APIs, mobile development best practices, and providing software development guidance.

I was equally disheartened to hear that some mobile projects are being intentionally “slow walked” in order to have these projects wither and die from neglect.

To paraphrase from Robert M. Pirsig’s Zen and the Art of Motorcycle Maintenance:

“Other people can talk about how to expand the destiny of mankind. I just want to talk about how to fix a motorcycle mobile application.”

We have much yet to do to make our technology decisions inclusive of all stakeholders; not only because it is the right and proper thing to do, but because we are allowing strategic decisions be driven by what is simple to support and easy to do. If we are to innovate, stand out, and convincingly argue our institutions’ cases for value within the current environment of uncertainty, high debt, and questionable sustainability in higher education, then I believe we must do better than simply be “good enough.” We must be exemplary. And that can’t be done on the cheap, nor the easy.

We have real innovation occurring in higher ed mobile. We also have a lot of cookie cutter, least-common denominator solutions.

Is that good enough?

I’m grateful for the forum that our gracious hosts at USF have afforded us to conduct this inquiry into values, technology, and mobile strategy. We have our work cut out for us.

Apple TV – Too Cool for School?

First, let me unequivocally say I love my Apple TV.

Love. It.

That said, I wanted to put it through its paces to see what difficulties one might encounter in placing it into a classroom environment. Just because a device is a great consumer device, doesn’t mean that it is well suited for secure business environments or for complex networking configurations one might find at a college or university.

And that is indeed the case with Apple TV; for most users, it poses a number of challenges trying to integrate it into a corporate or collegiate setting.

First, Apple TV doesn’t support Enterprise WPA2 authentication. Most organizations worth their salt doing Wi-Fi to any serious extent use Enterprise authentication, which leaves one seriously SOL trying to connect the device this way.

Secondly, for those institutions that offer a web page to authenticate access to their wireless networks, this leaves Apple TV in the cold as well; there is no web browser to open and authenticate with.

There is an ethernet port on the Apple TV that works perfectly well. But this leads to the third issue with using Apple TV in the classroom or the boardroom, and that is that the Apple TV mechanism for being “discovered” by iPads and iPhones (which in truth was my main interest in using the device in the classroom) doesn’t work well (or, at all) across multiple switches or routers without wide open access to a number of TCP and UDP ports (which most competent network admins wouldn’t open anyway if you begged them).

So, what does this all mean, really?

It means that if you are serious about using the Apple TV in a corporate setting, you have some work to do to get it to work as well as the device does in the home.

At Hendrix College, we have close to 400 wireless access points, all using Enterprise Authentication. So, connecting to that is a non-starter. If I connect to the wired ethernet network on campus, I can’t “see” the device with anything other than the Apple remote that comes with the Apple TV. No good.

The only real option is to do one of two things:

1. Insert a “rogue” wireless router off of one of our ethernet ports (yeah, right). Or,
2. Configure a laptop or smart phone as a wireless access point, and point the Apple TV to that.

I chose the latter, and configured my Macbook Pro as a secure wireless access point, connected the Apple TV to that, and then connected my iPad and iPhone to that same new wireless “network” being broadcast from my laptop. Under this scenario, the Apple TV could connect to the internet, my iOS devices could “see” the Apple TV, and I could demonstrate “mirroring” my iOS devices using the Apple TV.

As an administrator, I’m always looking for economical and straightforward technologies that I can recommend to faculty for their pedagogical use. On its face, the Apple TV is a relatively inexpensive appliance with lots of promise.

But in its current incarnation, it simply isn’t ready for use in most classrooms without a good deal of infrastructure knowledge, planning, and support. In my judgement, if Apple can add Enterprise security to the device, or make the device easier to discover by laptops and iOS devices in complex networking scenarios, then another evaluation can be made.

For now, I simply have to concede that it’s just too cool for school.

Apple TV Mirroring

Decoding Long Long Integer Values in Objective-C

In the interest of saving someone else some grief, here’s how to decode long long (64-bit) integers in Objective-C:

long long veryLong = 0;

[[NSScanner scannerWithString:@"100001621738699"] scanLongLong:&veryLong];

NSLog(@"Checking '100001621738699': %qi", veryLong);

One usually runs into long longs when dealing with Facebook Ids. I’ve written on this before, here.

Happy Coding.

How to Detect the Height of a UIWebView

A nifty solution from Stack Overflow.

Here’s my particular implementation, where I simply measure the height of the document.body element:

    NSString *output = [myWebView 
                        stringByEvaluatingJavaScriptFromString:
                        @"document.body.offsetHeight;"];
    NSLog(@"height: %d", [output intValue]);

Programmatically Removing a Tab from UITabBarController

There is a right way, and a wrong way, to remove a tab from a tab bar in a tab bar controller within an iOS app. I’m not going to show the wrong way.

Without fanfare:

        // Remove the third tab from a tab bar controlled by a tab bar controller
	NSMutableArray * vcs = [NSMutableArray 
                                arrayWithArray:[self.tabBarController viewControllers]];
	[vcs removeObjectAtIndex:2];
	[self.tabBarController setViewControllers:vcs];

Changing the Navigation Bar: MFMailComposeViewController

The iPhone 3.0 SDK introduced a number of cool new controllers, one of which was the MFMailComposeViewController class.

And although – in and of itself – it does so much, like much of what we run into in this developer life, it leaves some things greatly to be desired.

Like, “why in the heck does it ** have ** to put the subject line in the navigation bar as a title? Don’t they ** know ** I have a cool custom nav bar that they’re totally puking over?!?!?!“

Don’t fret. There is a solution.

First, you’ll need to implement the following delegate in the .h file of the controller where you are implementing the mail composer:

MFMailComposeViewControllerDelegate

Next, you’ll need to implement some sort of event handler. Here’s mine:

-(IBAction)doEmail:(id)id {
if ([MFMailComposeViewController canSendMail]) {

  MFMailComposeViewController *controller = [[MFMailComposeViewController alloc] init];

  controller.mailComposeDelegate = self;
  [controller setSubject:@"My Subject"];
  [controller setMessageBody:@"My Body" isHTML:YES];

  [self presentModalViewController:controller animated:YES];

  [[controller navigationBar] setTintColor:[UIColor greenColor]];
  UIImage *image = [UIImage imageNamed: @"custom_nav_background.png"];
  UIImageView * iv = [[UIImageView alloc] initWithFrame:CGRectMake(0,0,320,42)];
  iv.image = image;
  iv.contentMode = UIViewContentModeCenter;
  [[[controller viewControllers] lastObject] navigationItem].titleView = iv;
  [[controller navigationBar] sendSubviewToBack:iv];
  [iv release];
 
  [controller release];
  }
else {
  UIAlertView* myAlert = [[UIAlertView alloc] initWithTitle:@"My App" message:[NSString stringWithFormat:@"You cannot send email at this time."] delegate:nil cancelButtonTitle:@"OK" otherButtonTitles:nil];
  [myAlert show];
  [myAlert release];
  }
}

Finally, you’ll need to implement a method to dismiss the email composer after you cancel or send.

// Dismiss email composer UI on cancel / send
- (void)mailComposeController:(MFMailComposeViewController*)controller didFinishWithResult:(MFMailComposeResult)result error:(NSError*)error {
  [self becomeFirstResponder];
  [self dismissModalViewControllerAnimated:YES];
}

The bits that take care of the custom navigation bar (and incidentally, hiding the subject line title Apple insists on fobbing off on you) are in bold in the code above.

There are a few interesting details to note:

  [[controller navigationBar] setTintColor:[UIColor greenColor]];

Will tint the Cancel and Send buttons to whatever color you like; in this example, I chose green. Use whatever you like here.

  UIImage *image = [UIImage imageNamed: @"custom_nav_background.png"];
  UIImageView * iv = [[UIImageView alloc] initWithFrame:CGRectMake(0,0,320,42)];
  iv.image = image;
  iv.contentMode = UIViewContentModeCenter;
  [[[controller viewControllers] lastObject] navigationItem].titleView = iv;
  [[controller navigationBar] sendSubviewToBack:iv];
  [iv release];

The code above loads an navigation bar image (320 x 42 pixels for iPhone 2G, 3G, and 3Gs; 640 x 84 pixels for retina display), and sets the titleView on the MFMailComposerViewController navigation bar to the UIImageView I constructed with my custom navigation bar background.

And last but definitely not least, we must send the custom titleView to the back so that we can “see” the Cancel and Send buttons.

The subject line will now no longer appear in the title bar – which is why I did this in the first place. It was totally jamming my chi.

Give it a try. I’d be interested in your feedback on this solution.

Sorting NSMutableArrays

For whatever reason, sorting arrays in Objective-C perplexes a great many budding iOS developers.

However, it can be entirely straightforward.

The example below takes a mutable array (in this case, a set of businesses) and sorts them either by a point value or by a distance value, depending upon the state of a button from the UI.

The heavy lifting is all done by the comparison functions compareProximity and comparePoints.

The code is fairly self explanatory. I’ve written the comparison functions in a way as to be totally explicit about what values need to be returned.

Pay particular attention; the comparison function comparePoints is written to sort the array in descending point order; compareProximity sorts the array in ascending distance order.

// Compare Result for Sorting by Proximity
NSComparisonResult compareProximity(Business *b1, Business * b2, void * context) {
	if (b1.distance<b2.distance) {return NSOrderedAscending;}
	if (b1.distance>b2.distance) {return NSOrderedDescending;}
	if (b1.distance==b2.distance) {return NSOrderedSame;}

	return NSOrderedSame;
}

// Compare Result for Sorting by Points, Descending
NSComparisonResult comparePoints(Business *b1, Business * b2, void * context) {
	if (b1.points<b2.points) {return NSOrderedDescending;}
	if (b1.points>b2.points) {return NSOrderedAscending;}
	if (b1.points==b2.points) {return NSOrderedSame;}

	return NSOrderedSame;
}

// React to a button push from the screen
-(IBAction)doSort:(id)id {
	UIButton* btn = (UIButton*)id;

        // Toggle button on display
	if (btn.tag==0) {
		[btn setImage:[UIImage imageNamed:@"points_image.png"] 
                        forState:UIControlStateNormal];
		btn.tag=1;
		}
	else {
		[btn setImage:[UIImage imageNamed:@"proximity_image.png"]
                        forState:UIControlStateNormal];
		btn.tag=0;
		}

        // Order Elements (Perform the Sort)
	[self orderElements];

        // Refresh the data in UITableView
	[self.table reloadData];
}

// Perform the sort, depending upon button state
-(void)orderElements {
	if (self.sortButton.tag==1) {
		[self.businesses sortUsingFunction:compareProximity context:NULL];
	        }
	else {
		[self.businesses sortUsingFunction:comparePoints context:NULL];
	        }
}

Stop the Bouncy UIWebViews!

If you’ve ever used UIWebView inside of any iPhone app, one of the more unique – and some would say, annoying – behaviors of the embedded web view is that it “bounces” when pulled down, exposing a gray background and letting your users know that “hey – this guy is using a web view!“

There is an answer to the “bouncy” web view problem. Actually, there are two (2) answers to the “bouncy” web view problem. Since one uses an undocumented call and will therefore get your app “bounced” from the App Store (sorry for the bad pun), I won’t include it here.

The answer that ** won’t ** get your app declined but ** will ** stop the bouncing may be found below:

// Stop the bounces
UIScrollView* sv = nil;
for(UIView* v in myWebView.subviews){
  if([v isKindOfClass:[UIScrollView class] ]){
    sv = (UIScrollView*) v;
    sv.scrollEnabled = YES;
    sv.bounces = NO;
    }
  }

This will still allow your web view to scroll, but won’t “bounce” when you try to pull the view up or down outside of its given bounds. If you also want to stop scrolling, simply change the sv.scrollEnabled line to NO.

When Your Baby Is The Ugly One

This scenario plays itself out repeatedly:

Company A releases a great new mobile app. Initially, it runs on only mobile OS X.

Users of mobile OS Y decry how epic this FAIL is on the part of Company A, how clueless they are, and how they are totally missing the boat and losing their business.

Wash. Rinse. Repeat.

Trust me – companies don’t go out of their way to NOT service their customers and consumers.

These decisions are based upon market share, money on hand, time to market, and availability of manpower to build product.

In short, it’s business.

For the most part, this script usually translates as: Company A releases an iPhone app, initially. Users of Android, Blackberry, Palm, etc. are unhappy that they are being slighted. They think the company doesn’t value them.

In fact, the company is probably coping with a small set of developers, looking to get the biggest initial bang for their constrained development resources, and has every intention of getting their product on these other platforms, as time, resources, and money permit.

Apple’s ability to allow consumers to discover new applications is superior to what Android and Blackberry offer. I’m sorry. It just is. You can’t browse the Android Market or the Blackberry App World from your laptop to discover apps. You can with the App Store. Therefore, the chances for new consumers to discover, disseminate, and advertise your new app are greatly multiplied by releasing an iOS version, first.

Again, this is a business decision, not a straight-up fan boy love affair.

Yeah – it totally blows to have to wait for something the other cool kids are playing with now (hear that Twitter? Still waiting on “new” Twitter. Le sigh).

This is how I, as a cross platform developer, look at these platforms when trying to design and develop a new commercial product. I’m keeping “religion” (i.e., the relative merits of open source vs. closed source) out of this discussion in the main, aside from mentioning availability of sample code:

Apple:

Pros: Has maximum reach, best application discovery, best user experience with regard to UI and overall integration, highest quality store; customers spend actual money here. Best UI design tool of any of the mobile smartphone environments (Interface Builder) . Easiest to system test code, because you only have 3 basic iPhone models.

Cons: Strict curation can be an impediment to delivery. Wait times for approval have gotten better, but definitely adds friction to the process.

Android:

Pros: Easiest to ship, fastest growing smartphone OS. Lots of open source examples. No curation to get your app in the market, which means revisions and bug fixes happen in “internet time.” The ability to customize AVMs for creating device simulator configurations is the most flexible across all OS SDKs.

Cons: Horrible UI design tool. No application discovery, aside from third party websites. No curation in Android Market means anything goes. System testing is a nightmare, because you have a cross product of dozens of combinations of hardware and OSes that realistically won’t be fully exercised by small developers. The user experience across carriers is inconsistent – anyone who have ever implemented an application on Android that has to use the camera can attest to the variability in operation, quality, and performance. Fragmentation really doesn’t capture how fast this is getting worse rather than better (see: Verizon and Amazon creating their own market, see: carriers installing root kits to frustrate rooting, see: application filtering by carrier).

Blackberry:

Pros: Huge installed base of devices. Market leader in penetration inside of enterprises. Secure. Dozens of software simulators available for testing.

Cons: Worst SDK of any smartphone OS. SDK runs only on Windows (technology release now available for Mac OS X, but no simulators and it works only for directly attached OS 6 devices, which is one: the 9800 Torch). No UI tools, period. Worst developer community of any smartphone OS (no disrespect to the many fine BB developers I have met the past couple of years. But in the main, most of these guys – and they are guys – are usually company drones that I for the life of me can’t seem to find any actual apps that they have written. Prolly cause there’s only 9,000 apps in Blackberry App World, and unless you have a Blackberry Phone with a data plan, you’d never see ‘em anyway). Multiple OSes, hardware form factors make unit and system testing impractical for rapid releases. Browser – with the exception of the latest OS 6 release – is the absolute worst of any smartphone. Research in Motion also doesn’t seem to really care about software, except for only the sense that it is needed to operate the hardware. They’re a hardware company first and foremost, and it shows in spades.

Your mileage may vary.

But since the majority of application release scenarios we see play out in the marketplace are iPhone First, Android Second, Blackberry when we get around to it, I don’t think my take differs from those actually doing cross platform development, rather than those opining about it.

Nobody likes to have their baby called ugly.

But when it is, it is.