Another great question comes in today from an anonymous "M$ .NET developer",

Hi,

Please forgive my ignorance, but can you tell me which languages you can develop iPhone applications in? From looking around it seems you need to install xCode 3.1 on OS 10 (10.5?) by installing the iPhone SDK and then write code in Objective C. But can you code in other languages, like C#?

Also, what language are the code snippets on you site in?

There's no need for apologies, we're all learning here! This is a great question. You are correct in your assumption. The first step toward iPhone development bliss is installing the latest beta of the iPhone SDK (you'll need a free Apple Developer Connection account to download). Unfortunately, you will only be able to install the SDK on the latest version of OS X (10.5.2 at the time of this writing). The iPhone SDK is not supported on Tiger or any previous versions of Leopard. Once you have it downloaded, install it like you would any other .dmg file and you're off!

The only language you can use to write code for the iPhone currently is Objective-C. Now, there have been some open-source efforts made to bridge Objective-C with other languages (PyObjC comes to mind), but as far as being able to directly develop for iPhone with another language within Xcode (whew, that was a mouthful!), sorry Charlie.

For the code snippets, I believe you are referring to the web applications, correct? The backend code used is PHP and the effects are the result of some crafty Javascript. For the slide effects, we've utilized the IUI on several occasions, the wonderful YUI, and have also taken from the jQuery library. Also, have a look at a nice little list of frameworks that we have previously written about.

Keep those questions coming in! Until next time, stay classy iPhone-diego!

// Albert

Labels: iphone development, objective-c

We received a comment on Basic AJAX Scroll Animation w/ YUI from Joel saying,

These javascript libraries will equal more than 80K. For an iPhone that's just way too much. Especially if it's EDGE.

Any other suggestions for slide?

I agree Joel, you have an excellent point, an iPhone loading a web page on EDGE is much slower than on 3G or WiFi. While I don't have any other suggestions for a slide technique, as a developer I do my best to keep the load times to a minimum, and in all reality the user should only have to load your site once. After the initial load, no more data should be transmitted.

Let's keep this simple; an iPhone application should be "small, lightweight, and portable." Sound familiar? Yeah, that's exactly how Apple describes the iPhone. So we're not stretching far away from the overall goal of the iPhone. "At the touch of a finger." I believe was one of the many slogans used during the initial iPhone ramp-up. We should develop our web applications with the same intent.

While normally loading these AJAX libraries on mobile devices is tedious and increases the load time, I personally have no problem loading YUI libraries on our development iPhone. The way I see it, users of the iPhone expect a slight delay when loading a web page, much like I expected it on my old SideKick. However, when developing these iPhone applications, if you load all your content, whether visible or not to the user, then make AJAX animation calls to bring the content to the iPhone's screen when needed, the overall user model will not take a hit and it will be an experience of the lifetime.

To summarize:

• Keep AJAX Libraries to a minimum.


• Limit the number of pages to load.


• Define a user model that relates to the user.

iPhone web applications rely on solid user models. Build a good one, and you won't have any issues with my methods.

// Jay, aka W3prodigy

With the iPhone SDK out, and iPhone applications moving away from the web, I never thought I'd post here again. Lucky for you, we received an awesome question from Dan in the UK about Animation on the iPhone. Yay Dan!

Hey iPhonemind.com guys,

I was wondering if you could help me with a quick question I have pondering about in my mind relating to the wonderful invention called iPhone. I'm a multimedia student at Stafford College in the UK and having learnt the "designer" side of computing fancied turning to the dark side and have a go at programming. I've done bits of programming here and there before and know Action-script pretty well etc, but since the iPhone currently doesn't support flash yet here is where my question lies.
I want to create an interactive application where the user taps the screen and random squiggles or images will pop up to create a sort of abstract image animation, I've been looking on Apple's Developer website and had a look through most content on their but to no avail I'm still not sure on what the right sort of API's or frameworks to use. The UIKit would be a major player in the making of it but I'm not sure what else to read up on, just hoping someone out there might be able to point out roughly what I should be looking for?
The application is going to include shapes, colours, images, video maybe, sound hopefully, vector graphics and maybe a bit of text, the whole thing is going to be totally random for a college project and have no real purpose other than being one of them cool things you show your mates.

Your website is great by the way, loads of useful tips and tricks that I will be having a tinker with after I've figured all this out.

Many Thanks,

Dan

Well Dan, That's an excellent question! Since we'll never truly know when Flash will become available on the iPhone, I'm very glad you asked. We've all seen ways to animate a web page through the use of AJAX [cough]dhtml[/cough], including my post on creating a Basic AJAX Scroll Animation w/ YUI that was featured on the YUI developers blog.

As of right now, AJAX is the way to go for animation on the web. Here's a few of my favorites...

• Yahoo! UI Library: Animation - A little more advanced, but one of my favorites.


• Script.Aculo.Us - Simple to implement, a little more restricted.


• jQuery - Takes time to learn, but definitely worth the effort.


• MooTools - This one seems to be a popular one, maybe not the best for the iPhone, but definitely fun to work with.

What I suggest is that you sketch out your idea, step by step, then determine from the libraries listed above which would work best for you. JavaScript is relatively simple, and with your ActionScript experience it should be a quick run-through for you. Try to stick to one library to reduce load times. While the iPhone is an amazing device, the technology it runs on (EDGE) isn't completely up to speed for large applications.

I hope this helps you out Dan, I look forward to answering more questions like this. If you have a question about iPhone development, hit us up at ask [at] iphoneminds.com.

// Jay, aka W3prodigy

Labels: actionscript, ajax, animation, flash, iphone development, uikit, yui

All I can say is "holy shnikes!" If you missed yesterday's presentation, head over to Apple's site and watch the QuickTime stream. Especially if you're interested in iPhone game development. Check out the demos! The iPhone appears to be more impressive of a platform that I had originally thought.

Apple revealed two things of importance to developers both big and small. First, despite earlier skeptisism over the immediate availability of the SDK... here it is, complete with a visual interface builder and snazzy iPhone emulation (for testing). Very cool. Second, they've already announced a distribution model that equals money for all developers. Even the lonely one's working from their basement (that's not a stab at you, that's a stab at me).

I won't get into much of the details because Apple's iPhone Dev Center has absolutely everything you could possibly need. But I do want to comment on the revenue model since, from what I can gather, that's the only piece that some have reservations about.

All apps will be sold through the iPhone's App Store. You set the price. Apple takes 30 percent. Is Apple's commission too great? That's what's up for debate. But let's look at this objectively. Apple is handling all credit card charges and hosting fees. Additionally, they're making it simple for developers to update their apps through software updates. Since each developer can name their own price, I personally don't see much wrong with this model and I'm more than happy to throw the burden of money transactions at Apple. Let me concentrate on developing, then cut me a check once a month. This all sounds good to me. But what do you think?

Before I wrap today's post I figured I'd "touch" upon a comment we received yesterday.

Do you think having a native SDK will reduce the number of iPhone web apps currently being developed?

jeffrey.t.lynch

My response was: "Not initially, since any app developed with the SDK will not publicly be distributed until June. Even after the mobile App Store is launched I find it hard to believe that Web Apps will become obsolete. After all, development for the SDK requires knowledge of a much more complex programming language (compared to HTML/CSS/Javascript) and developers will need to pay $99 in order to distribute their SDK-developed wares. I expect all of the bigger named properties and developers to move strictly to SDK development, but I still think there will be plenty of Web based apps for all."

Yesterday I quickly mentioned that Cocoa development requires knowledge of Objective-C. The same holds true for Cocoa Touch (the programming interface for the iPhone and iPod Touch). So, although anyone with $99 can now develop applications for the iPhone and iPod Touch, their may be a steep learning curve for those only familiar with HTML/Javascript development.

// Ryan Jennings

Tomorrow's the day. The day that developers over at Apple finally unveil their plans for third-party iPhone application development. Press members were invited to "join [Apple] to learn about the iPhone software roadmap, including the iPhone SDK and some exciting new enterprise features."

Words like "learn about" and "roadmap" don't quite encourage someone interested in having instant access to an SDK. Will tomorrow's event be filled with more talk, or actual tools? That's yet to be determined, but I have confidence that Apple will not disappoint. After all, they announced this event six months ago.

More than anything, I'm interested in finding out which programming language will be used to develop apps. It's been clear for sometime that Flash is not going to be the answer. In fact, even today, sites like AppleInsider posted interview snippets with Steve Jobs in which his stance on the plug-in is clear. The current desktop version of the Flash plug-in demands too much processing power to currently make sense on the iPhone and Flash Lite is a joke.

The bottom line is that the iPhone's version of Safari is slow, so more robust applications (including games) will need to be developed using a language that can access the phone's guts more directly and intelligently.

In answering a question about an iPhone blogging application, Jobs recommended that "if Apple does not address it" then the individual should learn Cocoa and write an iPhone blogger application himself.

Cocoa is Apple's name for the collection of frameworks, APIs and accompanying runtimes that make up the development layer of Mac OS X. Therefore, it would make sense that Cocoa also be used to develop apps for the iPhone since it runs a mobile version of Mac OS X. But, again, specifics won't be clear until tomorrow. Which is exactly when we'll post again with our impressions of the news that is announced!

P.S. Cocoa applications are mainly written in Objective-C.

// Ryan Jennings

Well, our two week developer's feature has come to an end. I hope you all enjoyed the various discussions and behind-the-scene tips and tricks. Maybe we'll do this again in the future.

Without further ado, here's a link to the final game:


I've also embedded the game below (though it's more fun to play on the iPhone):


Here are some things to keep in mind while playing the game. If the page gets refreshed mid-game, you'll have to start over again. Try not to open new Safari windows when playing on an iPhone or iPod Touch. If you need to open other windows, return to the game window before exiting Safari or turning off your phone, otherwise the page will automatically refresh when you come back to the game after returning to Safari. Also, two clues are repeated in the puzzle. This is not a glitch. Get creative and think about what the two answers might be based on the size of the words you're working with.

UPDATE: It appears that the 1.1.4 iPhone and iPod Touch firmware update preserves the state of Safari "tabs/windows." Meaning, you can start the crossword game in one window and open another without having to worry about loosing your place in the game and starting all over again. I'd encourage everyone to download the 1.1.4 update.

Enjoy!

// Ryan Jennings

Labels: crossword, game, how to, iphone development

Games just aren't interesting without snazzy graphics. But graphics need to be downloaded, and you want to limit as many unnecessary downloads as possible when developing applications for the iPhone.

Until now, our game required only two images. The background image, and the image border used for grid highlights. Together these assets weigh in at about 24.5K. We also embedded a number of images in Javascript, which beefed up that file. All together the images, HTML file (which includes CSS) and Javascript file amount to 50K. That's really good for a complete game and means that the game will load quickly if you need to access it using EDGE.

But of all the things that irk me in life, only one is intolerable. A shitty ending to a video game. I mean you spend 40+ hours of your life (many of which are extremely aggravating) glued to the game. Is it too much to ask for a slick 5+ minute movie ending? Something brilliant that wraps up everything at the end. It only seems appropriate. So, I think it's important to give the winner of our puzzle something nice to look at when they're done.

End Screen:
Okay, it's not much, but hey, this game is being developed for demonstration purposes. Still, I think it satisfies the "snazzy graphics" requirement. Keep in mind that by the time you see the curl, the grid will be filled with letters. I didn't want to give away all of the words so I left the grid empty.

In my "Preloading Commonly Used Game Assets" post I mentioned that it would not make sense to embed all images in Javascript using URI Kitchen. The curl PNG weighs 69K. That's more than the entire game weighed up until this point. So, is it worth forcing the user to wait for this image to download when they won't even see it until the end of the game? Sure it is. Because we're not going to "force them to wait."

Since this image isn't required until the very end of the game (and it would probably take anyone at least 15 mins to solve the puzzle), we're going to load the image behind the scenes while the user is playing the game. Here's how we'll do it:

First, we set the game up. This includes waiting for all of the assets (except the curl) to download. Once the HTML has been parsed, Javascript hides the iPhone address bar, reads the game's XML file and builds the game's grid. The game is now ready to be played.

At this point we execute the following Javascript:

setTimeout(function() {
    var curl = new Image();
    curl.src = 'curl.png';
    curl.onload = function() {
        var img = document.createElement('img');
        img.id = 'curl';
        img.src = curl.src;
        document.getElementById('body').appendChild(img);
        img.onclick = function() { resetBoard(across, down); };
    };
}, 30000);

Again, the above script will not execute until the game has completely downloaded and is playable by the user. This script then waits 30 seconds before it downloads and sets up the curl image, giving the game more than enough time to prepare the asset before it's required.

For dramatic effect, we're going to fade the curl in when the user has completed the puzzle. There are a number of Javascript resources you can utilize to create fades. MooTools is a great option. But since we're not relying on MooTools to manage the styles or effects of any of the other elements that make up the game, it doesn't make sense to include the MooTools Javascript library (an extra download) only to access it for one effect. There's a simpler way.

The Mac software company Panic has, for a long time, been a leader in creating compelling, and shockingly easy to use, Web applications (they of course make brilliant Mac applications as well). On their site I found a small snippet of math which we can use to fade the curl.

Javascript:

function cubicOut(t, b, c, d) { return c*((t = t/d-1)*t*t+1)+b; }

Using the cubicOut function, we can do the following:

var curlanim = { time:0, begin:0, change:0.0, duration:0.0, timer:null };

function curlFade(start, end, duration) {
    if (end == 1) document.getElementById('curl').style.visibility = 'visible';
    if (curlanim.timer != null) { clearInterval(curlanim.timer); curlanim.timer = null; }
    curlanim.time = 0;
    curlanim.begin = start;
    curlanim.change = end-start;
    curlanim.duration = duration;
    curlanim.timer = setInterval(function() { fadeAnimDo(end) }, 15);
}

function fadeAnimDo(e) {
    if (curlanim.time > curlanim.duration) {
        clearInterval(curlanim.timer);
        curlanim.timer = null;
        if (e == 0) document.getElementById('curl').style.visibility = 'hidden';
    } else {
        var alpha = cubicOut(curlanim.time, curlanim.begin, curlanim.change, curlanim.duration);
        document.getElementById('curl').style.opacity = alpha;
        curlanim.time++;
    }
}

In the last post I mentioned that the matrix array keeps track of whether or not correct letters have been added to the 225 different spaces that make up the puzzle. If it is determined that the puzzle is filled with correct letters (using the matrix array), then the game has been won and we initiate the curl fade with the following code: curlFade(0, 1, 50).

And that's it! The tutorial portion of this feature is complete. Although we didn't post every bit of the game's Javascript, I hope we've explained enough to provide a good sense as to how everything was developed. Come back tomorrow for a link to the working game!

// Ryan Jennings

Labels: crossword, game, how to, iphone development, javascript