Apple’s new legalize in their latest SDK seems to not only kill Flash, but hint at the possible removal of many frameworks like Unity3d. I can’t say for sure how true that is, but that would be a huge blow to developers. It seems Apple wants you to do it all the hard way. Using only XCode and Objective-C. I guess some folks think that this will result in better quality programs, because it’s written in their native language. Being a programmer myself that is the most stupidest excuse I’ve ever heard. There’s plenty of CRAP apps in their App Store written entirely without frameworks in Objective-C. So, the excuse of better because it’s in their native tongue holds little weight in my opinion. It’s disappointing to think that I could have jumped onto Flash Actionscript and built an app or game for the iPhone, doing so would have been so much faster for me. Especially considering that I’m not very well versed in OpenGL-ES, nor do I really want to be. I don’t dream about writing 3d game engines, and having seen the amount of Objective-C code that’s required to put a 2D box on the screen at the Big Nerd Ranch was enough to make me run for the door. I want to be able to make what I envision into a reality without having to outsource my development or hire highly skilled specialized programmers. The other point raised by folks is that Apple doesn’t want you to cross-platform develop, which I can see too, but it’s not very fair to force developers to choose like that. Yes, there are lots of iPhones and iPads, but to say you can only choose one isn’t right. It’s like asking a child you can only choose your mom or your dad.

In the end, so far Apple has managed to make enemies of Google and Adobe, and alienated some developers. It saddens me to see this happen, because I see so much potential in the platform, when you consider what things people have done with jail broken iPhones, it’s a missed opportunity. I’ve been witnessing for some time a change in how Apple’s attitude. They’ve become quite the opposite of it’s roots, when they were gunning for the corporate giants like Microsoft and IBM. Now that they themselves have become this bloated beast of a corporation, much like their old enemies, they don’t need to embrace customers or developers. “Just suck it up or go elsewhere”, seems to be their stance, and I guess there’s enough people out there keeping Apple afloat that they can maintain that stance. It’s times like this that reinforces why I would like to love Apple, but I can’t because they keep pulling stupid shit like this.

There are better articles written on Ars Technica, TheFlashBlog, and TUAW.

Unboxing and Initial Impressions

I won’t bore you all with how cool the box is, because well, it’s a box, and true to Apple, it’s minimalistic, and the iPad fit in almost completely edge to edge in the box. It’s interesting to note that the box is padded to make it taller, which I guess is to make it more store shelf friendly, otherwise it would be a pretty thin box.

Holding the device for the first time, I was treated to the usual Apple quality I’ve come accustomed to. The iPad is well made. The back is the same type of metal used in their laptops, so durability shouldn’t be and issue. When I first saw images of the iPad, I thought the bezel around the device looked ugly, and an unnecessary design option, but upon holding the device, it turns out it does have a purpose, which is to be a place to put your thumb, something that didn’t need considering for the iPhone due to it’s smaller size. In general, to no one’s surprise, it looks like a big iPod Touch, but that’s not necessarily a bad thing.

Apps and Impressions on Using the iPad

Upon turning it on, I was surprised to see that the battery was fully charged, and was pretty much ready to use, well almost, you still need to hook it up to iTunes first, but after that, it was ready to go. I hooked it up to my wireless network with ease, and synced some of my apps to the phone. I hit Safari and surfed around to some sites and typed out a few messages. I am very impressed with the new form factor, the size of the iPad makes a very big difference in it’s usability. Compared to the cramped quarters of my iPhone, the iPad is a pleasure to use. Typing on the larger on screen keyboard feels more like typing on a real keyboard, I can actually use more than one finger to type! I always suspected that the new form factor would really make this device successful, and so far, it’s proving true, everything feels so much better to use!

I loaded a bunch of my iPhone apps on, just to see how they would work. Navigon, Metal Gear Solid, Time Crisis, Tetris, Facebook and a few others. My son put the iPad to the test with Kid’s vs Zombies, and it works quite well, although he complained about the screen shrinking back down to 1x size from the 2x size option. But I think that’s because he unknowingly hits the little button on the lower right that enlarges the iPhone app. Navigon threw me back to the desktop when I touched the Show Map button, so I guess the iPad doesn’t have a full fledge GPS in it (someone correct me if I’m wrong, I didn’t bother looking that spec up). Facebook worked like a charm, and Tetris played pretty nice.

Overall, the iPad is a pretty impressive device, but honestly, I can’t call it the magical and revolutionary device Apple’s marketing touts it is. Will this device fail? No, honestly, I can’t see that. Mainly because, even though Apple didn’t make me the tablet I wanted, they were smart in leveraging the large developer community fostered by the iPhone, because honestly, it was the developers that helped make the iPhone the monster it is today, and these same developers will do the same for the iPad.

Next thing for me to do now is update my SDK, and see if I can start making some apps for this new platform, and see what other things I can make this thing do.

The sad part about this little tidbit is that it would have saved me and the team I’m on a ton of time. You see, we work quite a bit with secure web sites using https, SSL protocol. But it’s a fickle thing, because web browsers hate it if anything on the page is linked without SSL if you’re already in SSL. In our development environments, we don’t have certificates installed, so sometimes we forget to put that elusive little “s” at the end of the http. What happens then for those who don’t know is your customer’s browser is experience on your site is abruptly halted to prompt you that there’s unsecured content on the page! GASP!

Needless to say that’s mud in your face when you present your awesome secured site to your customers. What ensues then is a mad search and replace for that lone link sitting in some obscure corner of your html that has that hard coded “http”!

The epiphany is you can use what’s called a Protocol-Relative Hyperlink, so you can just create a image link for example like this:

<img src="//yoursite.com/yourimage.gif" />

instead of coding in the full URL:

<img src="https://yoursite.com/yourimage.gif" />

So the // in front acts just like a relative link for your protocol, picking up whatever you were at, SSL or not! It’s so simple it’s hard to believe I missed it, heck, that’s probably why we missed it! Unreal…

So, now I know, and I’m writing it in here so I never forget, and who knows, maybe it’ll help someone else too.

It takes a URL as input and does a pre-flight check to ensure that the endpoint is available before launching the user to the destination.

Most web developers probably never need to take this extra step, since it’s another layer in the link chain, but this becomes important if you are dealing with a large multi-environment site or external links that are a critical portion of your web site. The trend (at least in the company I work for) seems to be a move move toward outsourced web services, where whole portions of your website functionality is literally outsourced to a vendor. The outsource component is more complex than it seems, because this isn’t just sending the user blindly over to the vendor; we must perform authentication in some fashion, a single sign on, if you will, to allow for a more seamless experience. In the case of a large internal multi-environment web site, you have multiple pieces, which are expected to behave as a single entity, so any failure in one part ruins the cohesive single experience.

The code below also provides a simple mechanism to disable parts of my web site, based upon trigger files which I can set to determine if I should even send the user over, if the destination is available.

Wait – did you say TRIGGER FILES? Yes I did.

There are those that will probably argue with me how poor this concept is and how mundane, but honestly, it works, and it’s pretty quick to put together.

I had about little over an hour to whip the code up to do this, or suffer from manually fudging the site to take links down during an upcoming maintenance window (I won’t go into how we got to this state.. That’s for another story). Of course the more PRO way of doing this would have been to either create a cool Coldfusion application that read a database table or read an XML file to get all sorts of nifty data to show and a cool kick ass admin interface to handle it all! But honestly, I’m not that good at Coldfusion, and I don’t have a guru handy at the moment to help me figure out the CFML to parse XML, nor a DBA available at my beckon call to whip up an awesome Schema for me. So, in the time I’m given, trigger files were easy.

Hopefully someone might find this code handy, or at least parts of it, since I’ve not found anything this specific online. I paraphrased some of the details, like the exact messages, but you should get the idea. Enjoy

<!--- dest is the parameter passed in --->
<cfif isDefined('url.dest')>
	<cfhttp url='#url.dest#' method="head" resolveurl="no" throwonerror="no" />
	<cfif NOT IsDefined("cfhttp.responseheader.status_code") OR cfhttp.responseheader.status_code EQ "404">
			I just checked the header response for a 404.
<pre style="font: normal normal normal 12px/18px Consolas, Monaco, 'Courier New', Courier, monospace;">			Sorry the destination is down</pre>
<cfelse>
 <!--- ok the destination is there, can I go to it? --->
 <!--- here, I check to see if I'm calling this proxy script from my member section --->
 <cfif #CGI.HTTP_REFERER# contains "member">
 <cfif fileexists(expandpath("/outage/member.html"))>
 <cfset outage = 1>
 <cfelse>
 <cfset outage = 0>
 </cfif>
 <!--- I do this for other sections of my site --->
 <cfelse>
 <cfset outage = 0>
 </cfif>
 <!--- Now I check to see if there was an outage, if not, we send the user to the destination --->
 <cfif outage eq 1>
 <p>We're sorry, but due to maintenance, this part of the site is down. </p>
 <cfelse>
 <cflocation url='#url.dest#' />
 </cfif>
 </cfif>
<cfelse>
 <!--- Do Nothing, since no Parameter came in --->
</cfif>

So, was it worth it all? Yes, I feel it was. It was probably the best learning experience I’ve had the pleasure of participating in. Having waited this long to write this post, I have a more objective view of what transpired. It’s not that I came away from the Big Nerd Ranch an absolute expert in iPhone development, on the contrary, I’m still very much a novice, but what it has given me is a solid foundation on which I can better build upon; one which would have taken a very long time to build on my own or at home. My situation at home is busy, I have a wife and 6 year old which keeps me busy, but I also have a busy work schedule, which at times, goes beyond the normal nine to five grind. So, being in such an environment, I may have only an hour, maybe two, per night to really dedicate time to working on iPhone development. At the Big Nerd Ranch, I was completely absorbed in learning about the iPhone, from the start of the day to the later hours in the evening, I was learning! A very different experience than something like conference, or being at a corporate training center, where breaking for lunch usually meant seeking food elsewhere, and class would normally end at 5pm or 6pm, then you were on your own. Over at Banning Mills, we were out in the country, nowhere near the bustling city of Atlanta, so there was no temptation to go running off to see the sights. We worked from 9:00 am till 6:30pm, with a break for breakfast, lunch, a brief hike, and dinner (no need to seek food!). We never left the facility, and we ate together as a group, so we all got to know each other. The teacher, Mark (for the weekend), and Joe (for the week), were with us, and stayed after dinner in the lab till 9pm or 10pm each night so we can continue working.

So where am I at now. Well, I’ve not really created anything solid on the phone, but I’m comfortable using XCode, reading the syntax, and able to at least write code and deploy it to my phone. I can easily look at all the resources on the web and understand what they are trying to accomplish. The overview of C/Objective-C, which was a little slow at first was very important for me, since I’ve studied C in the past, I hadn’t done any serious work in it, so having that foundation was extremely helpful for the remaining iPhone classes. The content got increasingly harder as the week progressed. The hardest part had to be the OpenGL ES section, it was alot of typing, and probably the only part of the bootcamp I didn’t get much out of, except an understanding of how hard raw OpenGL work can be.

In the end, I’m happy with what I learned and I’m also happy to have a group of people that have gone through the same thing I have and can call upon for help and suggestions. I would recommend anyone that’s interested in learning iPhone development to attend their bootcamp!