How to start your game

I’ll assume you already have a game idea. No matter how ambitious you want to be though, think in milestones

1. Display some graphics.
2. Animate your graphics, either manually, or with basic input controls
3. Get hit detection working.
4. Everything else! (level loading, artificial intelligence, etc.)

If you can even make it to the fourth milestone, you’re farther than 90% of most game developers. If you make it past milestone four, you’re farther than 99% of game developers. Only the passionate, motivated and able ship. This is how I’ve started all of my games and it’s important to achieve tangible results to keep yourself motivated. In fact, this same step-by-step process can be used in regular application development as well.

Design

Start your development with a skeleton application. This does one of two things: first, it forces you to plan the architecture of your application by creating the objects (in files) that you’ll need in your development and second, it provides an outline for you to work from. So first, think about what display controllers and object controllers you’ll need, what model objects you’ll need and then go ahead and create the files for those. Also go ahead and fill in some functions too for the basic functionality. The point is, make sure you break up the functionality into bite size chunks. It’ll make your life easier, trust me.

Put in the functions you think you’ll want and then just put in print or trace statements to make sure they’re being called correctly. Then, just build it piece by piece, usually starting with getting something like a player character on the screen (DisplayController, PlayerController, GameController), then getting him to move, moving him via inputs (InputController), then applying constraints like hit detection or getting him to jump (implementing basic gravity), etc, etc. Just keep introducing and implementing new features, one at a time, playing the game, realizing you want to tweak something and playing it some more. This is called iterative design.

Get those milestones done as quickly as possible, keeping your code organized in your skeleton application. Don’t worry about graphics at first. Personally, I stick in multi-colored boxes instead spending a lot of time on graphics I may not use in the end. Objects will be added as you realize you need them, but the idea is to keep it organized, simple and cohesive.

When designing your class structures and diagrams, keep the low level functionality, like file access and keyboard inputs, abstracted and hidden in wrapper classes. The reason you abstract objects is for a couple of reasons: One is to be able to add in hooks before and after a part of code. For example, instead of calling the system clock directly, you want to calculate the elapsed time if your game was paused or suspended on the computer. If you abstracted this in the beginning with a GameClock object, you’d only have to change it once, in a single place. If you called it directly, you’d have to go back to every place in your code and calculate that value. Keep object responsibilities where they belong!

Start Programming!

To start you off, check out a game template designed for the Corona SDK (free 30 day trial), written in Lua. I recommend you create a template of all your project tyes as it’ll help jump start your next big idea and also keep you organized from the start.

Building a Game is a post from: Ziray Studio Labs

Related posts:

1. Corona Game Template in Lua
2. iPhone Pricing
3. How to Program for the iPhone – A Plan
4. Handling Your Initial View Controllers for iPhone

I may not know all the APIs to load and play the video just yet, but at least I’ve given myself an outline and as I fill in the code below each comment, I can see exactly what I’m doing and where I need to go.

Why Your Code Sucks

The point of this article is not to talk about comments, but how to avoid writing them in the first place within your functions and still be clear for everyone else, for the most part. This is your code:

Not even a comment could concisely convey the meaning of that hideous statement. Instead, why not:

Well written code is self documenting. Let me restate that: if you can write code so that someone can jump to any point of that code and understand what’s going on at that point, read it like a sentence, and not have to decipher minute details like what each variable means, then you don’t have to comment most of your code.

There’s no reason you need to shorten the names in your code. Most programmers have never had file size limitations to deal with, so there’s no reason for it. Stop pretending you live in the 1960s and embrace nearly infinite file storage. To save keystrokes perhaps? Please, use a real IDE with code completion and stop doing stupid things like:

Function Names

Also, because your functions are essentially actions, they need to reflect that in the name, so put a verb in the beginning of your function such as: getData(), setStatus(), enableWiFi(), hideControls(), handleGraphicException(), launchBall(), etc.

Class Variables

Get rid of the underscores in front of your class variables. For example: _dg; _myNumber;. All class variables should be private anyway, so why do you need that ridiculous convention? It’s a hold over from C where there was no “private” keyword, so you’re using it and you have no idea why.

Also, what’s with the “my” naming convention? You sound stupid when you have those: myInstanceName, myMovieClip, myGraphicsContext. Of course it’s yours, whose would it be, if not yours? If you’re programming with a colleague, do you refer to his variable references as yourInstanceName? Or hisVideoFileURL? Of course not. Don’t be that stupid; you’re reading too many stupid online tutorials by uncreative people who only code because they have nothing else better to do while living in their parent’s basement.

In the very least, be consistent with your naming conventions.

Hungarian vs. Polish notation

Depending on which language you’re coding in,  you may need to use a notation to help you with type casting. Let me rephrase that: if you’re using a loosely typed language, use Hungarian notation. You should probably use this with strongly typed languages anyway because with abstract types, you never know what you could get into and it’s just generally less confusing.

Hungarian Notation: vendorNameTextField or vendorName_txt

Polish Notation: txtVendorName or textFieldVendorName

Why not Polish notation? Not only is it ugly, but why would I sort on variable type instead of the variable name like I can do in Hungarian notation? The notation names come from how the speakers of those languages modify their verbs and nouns. To say: “My ball” in Hungarian is:  ”labám” where “labda” is the root word and the ‘m’ singifies a first person possessive. Hence the ending of the word shows the crucial information. It’s the opposite in Polish notation where the beginning of the word is modified. In the interest of full disclosure, I love the Polish, but I am Hungarian, but I promise that’s not why I prefer one over the other.

Final Thoughts

In the end, be consistent, be clear and spell out your variable and function names.

Why Your Code Sucks – Naming Conventions is a post from: Ziray Studio Labs

Related posts:

1. Corona Game Template in Lua
2. Handling Your Initial View Controllers for iPhone
3. Dynamic Textfields in Flash AS3 and Their Bugs
4. Custom Mouse Cursor for ActionScript 3

The template includes example code for:

• Display groups
• Orientation and accelerometer
• Touch with buttons
• File reading
• Example level file for scripting game play

The template separates functionality into modules for an object oriented approach. I’m still learning the techniques for Lua, so if you notice a better way to do it, please don’t hesitate to let me know in the comments below. Some things in the template are not the best way to accomplish some things, but should give people a good idea on best practices of software design. This will also with work Corona’s Game Edition.

If you find the template useful, please consider buying a copy of our current application to support us. It’d mean a lot. Also, check out our company website if you’re an iPhone programmer as we’re looking to bring on some independent programmers.

Download the Template Code

Again, if this helps you out and you want to support us, check out the links on the side. Thanks!

Corona Game Template in Lua is a post from: Ziray Studio Labs

Related posts:

1. Building a Game
2. Why Your Code Sucks – Naming Conventions
3. iPhone Pricing
4. Handling Your Initial View Controllers for iPhone

The Beginning

As far as we could tell when we started the BarNinja iPhone app, there weren’t any other apps like it on the Apple App Store. That was back in April of 2009. While I was in San Francisco back in March, I got a Facebook message from Jason asking if I was interested in doing an iPhone app. I had done a bunch of Mac development and even independently sold a previous application. I had also attended Apple’s developer conference (WWDC) on two separate occasions so I was quite comfortable with developing for Apple products. When I got back from California, we sat down at a local bar in Blacksburg and wrote down our ideas for the app he wanted to make. That was prior to iPhone OS 3.0 being released and we were counting on some key features in that release for our app. In the end, we ultimately failed when the features didn’t work out exactly as we expected. Luckily, only a little code had been written and that was enough to get me up to speed with the current iPhone development platform.

Instead of quitting, we got BarNinja, another local Blacksburg startup involved in another app idea. We wanted to leverage the shake feature (iPhones can detect when you shake them) that was relatively new and make a mixed drink app based around that.

Soon after we started, a few other apps starting hitting the app store with exactly those features. But the competition didn’t deter us, but instead pushed the bar higher for us. We now knew we couldn’t just make another mixed drink app with a shaker feature, we had to make the best mixed drink app with a shaker feature. We were also creating a 730+ recipe database (including ingredients and other drink information) that would hopefully give us an added advantage. Luckily, at the last WWDC (2005) that I attended, they announced a technology called CoreData which allows developers to place small databases easily within their applications. They also included it in the iPhone OS and I ran with it.

Problems and Solutions

The problem with having 730+ recipes is that it becomes nearly impossible to find a drink in a list. The list view we had, took minutes to scroll through and even tired out your finger having to swipe so much! We added an index on the side to quickly scroll through the list alphabetically. We also added a search to find a drink by name and even added a filter to sort out if the drink was a “mixed drink” or a “shooter.” But that still wasn’t good enough.

I could find drinks like “Vodka Martini,” but what if I wanted a drink with vodka as an ingredient? So we added in a search that would find ingredients too. That worked out well, but often times vodka isn’t named vodka, it’s also names just “Absolut,” which everyone knows is vodka, but the iPhone doesn’t, so we had to teach it what kind of alcohol those products were.

More progress, and we were rolling right along until we tested it out on the actual device; it was painfully slow. The user would hit a key on the virtual iPhone keyboard and the key would get stuck in the “up” position until the search was done and only then could you hit the next key. Searching 730+ recipes is easy, but searching on average 6 ingredients for 730+ (~730 x 6 = a lot) takes 4 or 5 seconds on an iPod Touch 2nd generation. So we had to get a little creative.

My solution was to split off the search into a separate thread (a simultaneous process within the application) and perform the search in the background. This introduced a few other problems that I had to fix but the responsiveness improved dramatically. Then, using Apple’s performance tools, increased the search algorithm by about seven times. Thanks to all those boring Computer Science classes I took at Virginia Tech I was able to speed it up and also make it appear to speed up.

Updating the table view, after finding each recipe that matches the criteria, is slow (thanks to the performance tools for reminding me of this). So I returned the first 5 results instantly because those are the only ones you can see initially on the screen and then the rest were updated in a decaying frequency as they were found until the search was done.

Iteration

Early Search

Icons, glass name and index

Early drink details view

The Final Product

Initial Screen

New search screen

New drink details view

Results

They say if you’re happy with your 1.0 version of your application, you didn’t release it early enough. While we definitely have plenty of work yet to do on this application, we didn’t release it soon enough. It did not take a year of programming to get this done. The programming was the easy part, it was all the other stuff that got in the way, distracted me and things I had to wait on that took the longest. Back in the day, when doing my Computer Science homework, the motto was “Start early, and start often.” That rings true for every long term task.

We didn’t run any real usability tests. This upsets me a bit, but we never really got to show it to too many people. Now LTZ has a few more developers working on more apps, so we have a larger pool of testers, but in the end, we still need to test it out on real human beings and put all those Human Computer Interaction (HCI) skills I spent a lot of time learning, to use.

I did try to apply those skills with the layout of the app. When the app launches, the first screen is the random drink screen, which you can tailor to your tastes in the options. We wanted to give the person using our app something to do right away. We didn’t want to over whelm them with a list of 730+ ingredients; it doesn’t impress anyone. In our limited testing everyone figured it out and got a kick out of the shake feature. With other apps, we noticed, they presented a huge list of options that just left you wondering what you should do next. It’s that classic “uuuuh” moment. With ours, right after the launch of the app you can start enjoying the functionality.

The next screen is the raw list of drinks, plain and simple. Our search is straight forward and easy to figure out and the index on the right helps users navigate down the list quickly. We also stuck to using as many user interface elements from the standard set of Apple iPhone as possible. Many other apps try to be creative and diverge from the standard set of UI elements and consequently from the Human Interface Guidelines that Apple has set forth. The result is a poorly designed, clunky looking application that takes time to figure out how to use. Since we’re using a standard search bar, people using our app know right away what that means and can start right away in using the search feature.

We also chose a dark theme for our colors, not because it looks cool, but because most of our users, we assume, will be using it in a bar, or bar like conditions such as a party, etc. But we also didn’t want to give it a depressing theme since it was suppose to be fun and helpful, so there are a few bright colors in there. The design will most likely change and be updated, but that’s the rationale for the initial release. We’ll see what our users think and how they use the app.

We know our app isn’t perfect, but we’re confident we know where to go from here to improve it and fix some of the problems we know exist in it. Through additional usability testing, we’ll slowly improve upon BarNinja to make it the best drink application on the app store. We know we’re not there yet with the initial release, but we look forward to adding great functionality that people will love.

BarNinja – An iPhone App Postmortem is a post from: Ziray Studio Labs

Related posts:

1. iPhone Pricing
2. Handling Your Initial View Controllers for iPhone
3. How to Program for the iPhone – A Plan
4. Photos of the Week – Black and White

design

A lot of webpages and articles talk about how to program, but they don’t talk about how to design a program. Good program design separates the weekend programmers from the professionals. Sure, anyone can piece together a working application but a good design allows a power and flexibility of adding new features, for example, without having to recode half of your application.

Here, we’ll talk about handling your initial views when your iPhone application loads. This might be a simple task if your application is simple, but take the case of having a welcome screen followed by a login screen followed by a tabbed view controller. You might set it up so that one activates the other upon being dismissed itself.

Here’s an example of how the process might look:

Program loads AppDelegate

Load Welcome view from AppDelegate

Dismiss Welcome view -> Tell Welcome view to load Login view

Dismiss Login view -> Tell Login view to load Tabbed view

What if you had to add a view or remove one, say if the login was no longer needed if you gave your users the option to save their credentials. You’d have to rewrite two different view controllers at least. And this is just a simple example so you can see how complicated this chain of views would get once your application grows. For most programmers this way is fine, and sadly enough most of the time, this is the way it’s done. But true programmers are lazy. Lazy programmers are good programmers. So be lazy and write good code so that when (not if) you go back and edit your code, it’ll be a snap.

A design starts on paper

Your programs should be conceived on paper. Even with applications that attempt to do this, I still find paper the ultimate programming tool (even though I did the one below on a computer).

Class Diagram

First off, your controllers should be logically separated based on their tasks that they need to accomplish (not based on how the user will view them). So, you should have a controller or controllers to handle logging in and session creation and have appropriate UIViews and UIViewControllers to get and display info to your user. This may not be a one-to-one relationship though. For example, you may not have a UIViewController that’s associated with creating your sessions at all.

Next you will have your application’s business logic view controllers, controllers and all that jazz. The controllers sit independently to the view controllers except, of course, where there’s coupling or interaction. They are not tied directly, or rely upon any particular view. You illustrate those connections on paper (or in this case in the example diagram above). So if your “Add New Event” feature, let’s say, needs access to the session data, draw a line from your SessionController to your EventsController with an arrow pointing in the direction of the flow (from EventsController to SessionController in our case since the Events controller needs to know about the SessionController but not vise versa).

Abstraction solves everything

Since your controller code should be independent of how your views are laid out, you won’t have your AddNewEventViewController (the view that lets the user add an event) handling the actual creation and saving of events but will instead gathering and packaging the information taken from the user and given to an EventsController to handle the manipulation. Who knows, you may have several views that edit an Event in one way or another and if you change something in how the Event is saved, you’ll have to go into the code of each one that touches Event and rewrite code — exactly what we’re trying to avoid.

Abstracting the data in this way is called indirection and “All problems in computer science can be solved by another level of indirection;” — David Wheeler, except as Kevlin Henney says, “…except for the problem of too many layers of indirection.”

Singletons, under used

and under appreciated

So, you should have a session controller that sits somewhere ready to be called by who ever needs to validate a session or login (those views that would need access could be your tabbed views, could be your app delegate when your app starts, or could be in your settings views where you type your login info or when you log out). This is usually accomplished with a singleton class where any controller can access that one (and only) instance of your controller without having to pass around references to that controller. It not only cleans up your code, but also helps data integrity by not allowing multiple objects to edit the same data.

Handling your initial views

You should really have a separate controller handle organizing your views rather than the app delegate since the app delegate should really only be used to initialize your app and handle delegation of your application, not controlling business logic. So the structure should look like:

AppDelegate -> MainViewController -> LoginViewController

I like to have an overall MainViewController that handles all the subviews, be it a tab bar view controller, a table view controller, or whatever your main view is going to be. This level of indirection allows you to easily change what your main view controller is later, should your requirements or ideas change. Having said that, the MainViewController is going to need to get and maintain a reference to the application’s window.

To actually add the views, stack them on top of each other. Add the Tab Bar Controller’s view to the Window’s view first, then if needed, add your login views after that to stack them on top, and then remove them as needed when you’re done with them. By removing them from the top, it reveals the bottom view.

In MainViewController’s implementation file, your viewDidLoad: will look like:

Where mainWindow is an IBOutlet to your Window in your MainWindow.xib file (or you could get it programatically if you prefer). Also, loginViewController is a pointer to your view controller that you put on top of the tab bar controller. On top of your login view, put a welcome view displaying any text, graphics or video to show after your application loads; note that this is different from your Default.png initial image. Then when you’re done with your login view, call removeFromSuperview on them to remove them from the view stack. So something like this in your MainViewController (since it handles all manipulation of your main views):

Obviously, when you remove the welcome screen view, under it (since you added it on the stack before the welcome view) is your login view. Then, removing the login view will show the tab bar view since that was added first in your view stack:

(Top)

Welcome View

Login View

Tab Bar View

This way we’re loading all of our views at once and stacking them so the one on top hides the one below. This has a slight overhead since you’re adding all your views when your applications starts but you can always delay adding the tab bar controller to the Window’s view until all the initial views are removed, for example. Then, if you’d like, using the MainViewController, you can add views on top of the tab bar view during execution, for example if you need to login again.

There are a few different ways to handle multiple views and each case is different. This is just one idea, with a few general guidelines. Feel free to ask any questions in the comments if anything wasn’t clear enough.

Sample Code

The following sample code is provided as is for educational and demonstration purposes. I threw it together really quickly and is only used to demonstrate the use of a MainViewController. Normally, you’ll want to make your MainViewController a singleton class, but in this example I passed the MainViewController instance to the subviews in order for them to call different methods on MainViewController to change the current views. By using a singleton design, you can avoid passing around this reference since there is only ever one MainViewController.

Also, this code demonstrates how to create a tab bar programmatically. It needs to be the root view of your window, but that doesn’t mean it needs to be the root view controller. We are still allowed to use a MainViewController as our root to handle all subviews and their controllers.

Download sample code (2010-02-11_TabBarTest.zip)

Handling Your Initial View Controllers for iPhone is a post from: Ziray Studio Labs

Related posts:

1. How to Program for the iPhone – A Plan
2. BarNinja – An iPhone App Postmortem
3. iPhone Pricing
4. Building a Game

This is not so much how to make applications for the iPhone, since there are so many on of those on the web already. This is more a syllabus on how to get started with the vast amount of information already out there and where to start from to quickly become proficient at iPhone development without getting frustrated or discouraged.

Development Requirements

An Intel-based Apple Mac
$99 (optional – if you want to actually publish your app)
That’s all!

Apple Developer Account

Development for the iPhone is initially free. So feel free to head over to http://developer.apple.com and sign up for a developer account if you don’t already have one. This will give you access to the Integrated Development Environment (IDE) called XCode, which is required to develop applications for the iPhone and iPod Touch. It also serves as a treasure chest of free information, sample code, tutorials, how-to videos and news, all of which I’ll talk about how to use later.

Once you’ve signed up for a developer account, you’ll need to download XCode and install it on your Mac. PC users are, as they always are, out of luck since a Mac is required for development. Once that’s done, put it aside as you won’t need it for a bit.

Learn to Program

An Important Design Pattern: Model View Controller

If you already know how to program a little bit, but haven’t gone through the rigors of a four year university Computer Science degree or something similar, start with learning an important design patterns, namely one called Model View Controller (MVC). Of course, a 4-year degree is not necessary, but you need to understand basic software engineering principles, design patterns and basic usability practices, which practically none of the programming tutorials, books and online articles teach. Also, a lot of practice helps as you’ll learn how to fix non-obvious compiler and runtime errors, how to structure your code, and pitfalls of each language you use.

Objective-C: The Language of Choice

After you understand the basic principle of MVC, you can then move on to learning the language of choice, Objective-C. Why Objective-C? Why didn’t Apple just choose a common language like C++ or Java? The reasons will become obvious as you learn about the language, it’s power, and how it fits into the MVC methodology better than any other language you’ve likely seen before. So here’s a nice tutorial on how to program in Objective-C.

If you already have a great understanding of programming and know a C-based langauge, skip the lengthy tutorial and take a look at this primer to get a sense of the additions to C that Objective-C brings to the table. For most people who are familiar with a C-based language, this will be all you need to get started.

The Cocoa Framework: Because Reinventing the Wheel is for Marketing Types

Ok, great. Now you speak the language, but you need to know the framework and how the language leverages this technology so you don’t have to reinvent the wheel. Take a look at Cocoa Fundamentals to learn how the fundamentals of Cocoa work. The Cocoa framework is a superset of the Cocoa Touch framework that is specialized to fit the paradigm and requirements of the iPhone and iPod Touch devices. Knowledge of the Cocoa framework is essential to understanding how to use such things as data structures and containers, user interface (UI) elements and the rich built-in functionality that all these components offer you for free. Many of the Cocoa framework elements carry over into Cocoa Touch, such as strings, CoreData, CoreAudio, CoreAnimation and concepts such as delegation, protocols, interfaces and application bundles.

XCode Tools: The Real Workers

Once you know how to speak the language and use the technology, you need to know how to use the tools to make it all happen. Here’s another Apple document that explains what XCode is and how to use it. Even if you’ve worked in XCode before, it’s worth checking out as XCode is a powerful code editor, debugger and provides a host of other tools and features. If you’re interested in what else XCode has to offer, there’s a more detailed explanation of the other tools that come with XCode.

Your First iPhone Application

You need to keep in mind that even though this is a lot of information to process, if you’re unfamiliar with the platform, it’s all very intuitive and will become second nature with a little practice and time. Just keep looking at a little bit every day and re-read some of the things you read early on. No one can learn a foreign language in a week, so don’t expect to be fluent in everything Objective-C and Cocoa in less than that. Spend a little time with it every day, go through sample code that interests you, read developer forums to see what other people are having trouble with and come up with a few of your own app ideas just to put all this theory to work. You never truly learn something until you have to use it in the real world.

So now that you have made all the theory, concepts and language familiar to you, you can cement it in your brain with your first iPhone application. This tutorial will cover most of the concepts you already learned (repetition is the key to really cementing that knowledge) but it will also show how they all tie together, which is the most important part. Don’t just copy and paste the code. You don’t have to memorize it, but typing it out really helps you recognize the code later when you have to use it on your own.

Beyond the Basics

This is where most tutorials stop. They pat you on the back, call you an iPhone developer and send you on your way to flail your way through haphazard development. All you really know however is how to put a few buttons on the screen and make them do something stupid (which admittedly is most of the apps that are available on the app store). There’s a lot more you need to know to be truly dangerous.

Usabilty on the iPhone: The Apple Human Interface Guidelines (HIG)

Take an afternoon and sit down and read the Apple Human Interface Guidelines. This will give you a slew of iPhone capabilities, but more importantly, it’ll give you a sense of how to properly use the interface elements of the iPhone. Nothing shows an amateur or know-nothing developer than an improper use of an interface element or using a certain interface element because it looks or acts cool (anyone remember the drawer?).

Developing iPhone Apps:

Gather those Building Blocks

Create an iPhone Utility Application

iPhone utility applications are the easiest to understand. They have two views, a front side and a back side. This type of app is great for learning how two views can communicate without worrying about complex data structures, implementing confusing protocols or dealing with the frustration when your code compiles, but doesn’t work. You can also experiment with new technologies such as CoreData, CoreAnimation, CoreAudio, WebViews, playing music or anything else you’re interested in without the overhead of managing views and other complexities like that. Keep it simple and think of a few ideas that fit the paradigm of an iPhone utility application.

Navigation Controller: Controlling Presentation

After you’ve successfully completed a working iPhone utility application, the next and most common interface technology is the Navigation Controller. This is the controller that allows you to hit a button and have a new view slide in from the right. I love this controller because it adds a lot of functionality to your app without a lot of work. Simply allocate a new view, push it onto the navigation controller and release it because the navigation controller does the rest.

Tab Bar Controller: Multiple Sections in One App

The Tab Bar Controller is a great way to segment your applications into features. It’s a bit trickier to set up, but once you know how it works it’s intuitive and flexible. For example, you can use the views that Interface Builder gives you to drop your UI elements onto, or you can tell Interface Builder to load a particular View Controller of your choice. It greatly extends your application’s functionality with minimal work.

Tableview Controller Class: Displaying Your Data

Table views are a bit more complex and involve a bit more understanding but it’s hard to get far in iPhone development without using a tableview. Invest the time to understand these creatures and it’ll give you a nice return on your investment. Take a look at the TableViewSuite sample code to learn how to do everything you ever wanted to with table views.

Tool Bar: Making Your App Accomplish Something Useful

Applications need to do something useful besides editing data. Sometimes you may want to do something a little bit different and adding a tool bar to your application is a great way to add a different kind of functionality. It’s simple to use and gives you a standard way to manipulate data in your application.

Core Data: Handling Lots of Data Without Too Much Real Work

A lot of your app ideas are going to be based on having lots of useful data that needs to be displayed and manipulated and Core Data is the easiest, most flexible and optimized way to do that. So spend some time and read the Core Data Programming Guide. Secondly, it’s important to learn how to use a fetch results controller as it will allow you to display your data in a tableview in a simpler way than straight out of the fetch request. It will also give you the functionality of indexed tableviews for free (as seen in the Contacts application).

More Programming for iPhone

This is the one of the best paths to picking up programming for the iPhone. It starts you off with the most useful items without overwhelming you. However, it does take a lot of time to read and a little more than that to understand, but take it slowly, look at it over a course of several weeks and soon you’ll be able to add anything to your application by only reading the API references.

There are a ton of things that you’ll need to learn in order to be an effective developer, so in future articles I’ll take what I’ve learned, some pitfalls and neat tricks and show you some of the basic stuff that you can’t find in the Apple developer documentation such as handling common problems, design patterns and usability pitfalls.

After all of this, you’re still not done. You’ve only grasped the basics, but at this point, the real challenge is not understanding the technologies, it’s figuring out where to go from here: what should you learn next, how can you get started programming a real app, and most importantly how you can make a lot of money. All of this will be covered in future articles as this one is too long already, but I will leave you with some of my favorite links. In the mean time, subscribe via RSS or email to get future articles on iPhone and everything else I do. Finally, frequent the Apple developer forums and try to answer some of the questions there. You won’t always know the answer, but a little research and you will be able to figure it out and learn in the process.

Additional Links

Stack Overflow – A great site for asking programming questions of all kinds.

iPhone Dev SDK – Forum-based site for asking and answering everything iPhone related.

iPhone SDK Articles – Blog-based site with lots of useful and informative examples on iPhone development.

My Apple Background

I’ve been developing Mac applications since 2003, attending WWDC 2004 and 2005. I’m the author of several small Mac applications including a Terminal GUI tool that’s been quite popular in the past. I have taught Code Kitchens at Virginia Tech on Cocoa through the Mac Users Group and I use to sell, support, demonstrate and evangelize Apple products to college kids as an Apple Campus Rep. I’m now an independent developer, working in partnership with LTZ, a company started to give independent developers and free thinkers a platform and voice from which to launch their apps or app ideas.

How to Program for the iPhone – A Plan is a post from: Ziray Studio Labs

Related posts:

1. iPhone Pricing
2. Handling Your Initial View Controllers for iPhone
3. BarNinja – An iPhone App Postmortem
4. Corona Game Template in Lua

Obvious Solutions

The obvious solution when you have a dynamic text field, that is either driven from XML, RSS, or other external document or data source, is to embed the font’s character sets. Obviously if you are going to be using Korean in your Flash application, you want to embed the Korean character sets so the Korean characters show up in the font you have chosen. However, with so much emphasis on branding these days, not all specialized fonts have characters in Korean.

For example, the Star Wars Jedi font that I once worked with has absolutely no other characters beyond A-Z, a-z and numerals. Forget Spanish and it’s tildes, forget German and its umlauts, but Russian?! Ha! Everyone knows there were no Russian Jedis! So, what to do?

Dynamic Font Swap!

There are several nuances to Flash character embedding (ok, there’s probably a few hundred as I find at least one new one a week). Unfortunately Star Wars applications with the Jedi font won’t work in any language but High Schooler English since they don’t use punctuation either. So we have to change the font to something more appropriate if we want to use another language. Here’s the ActionScript 3 (AS3) code, which I’ll explain a bit after:

Ok, so what does that all mean? We take the textfield’s font properties (say, Jedi Font, size 14pt, embedded characters, etc) and alter some of the properties we need to so that our application can speak to our Russian Jedi friends. This particular code will accept a fontsize_num variable in case you want to alter the font size of the text so that it will fit within the given textbox because we all know Russian Jedi Masters are sometimes really wordy!

Next, we have a variable isSpecialCharacterSet_bool, that if true, will execute the font swap that we need. You can set this variable via XML to control, on a per language basis (having a separate XML file per language), if you want to swap fonts. After that is the defaultFont_str variable, which we can also set via XML to determine which font we want to use as a replacement of our Star Wars Jedi font. Recommended fonts are _sans, _serif, Arial and Helvetica as those are fonts that include almost every character known to modern languages.

Then, we turn off bold because, believe it or not, a bolded font is an entirely different character set and causes all sorts of other problems. We also turn off kerning because it’s a ridiculous feature that doesn’t work and I guarantee will mess up your dynamic text fields, foreign or otherwise.

The next two lines are super important:

Unless you embed ALL the font characters that Flash will let you, you won’t have your foreign language characters, which I don’t recommend anyway due to a huge increase in file size and also for the fact that it still won’t work (I’ve tried, trust me on this one). So, even though everyone has _sans, _serif, Arial and Helvetica on their computer (which allows us to display the characters without embedding them), if you DO embed some character sets, it won’t show up. Go ahead, create a dynamic text field in Arial, embed A-Z, a-z, numerals and punctuation and watch it NOT show up when you assign a string in Russian to it. Go back, click “Don’t Embed” on the textfield and watch as your Russian characters show up again. So, we programmatically disallow fonts from being embedded.

Another thing you’d think Adobe could have gotten right but doesn’t seem to care about the non-English speaking community, a.k.a. the 6 billion other people on this planet, is the bug that if a foreign character exists in a textfield that is even slightly rotated, the entire textfield disappears. So, thank you Adobe for wasting my time with your poorly programmed textfields. The trick though, is to simply make the textfield’s rotation 0. Strangest thing ever, but give it a try if you don’t believe me. And if the textfield’s parent movieclip is rotated, not your child textfield within said MC, try:

You can also programatically set the multiline property if translated text seems to be a bit wordy. But you should probably have set up your textfields to handle the expanded text anyway.

Put that code into a function and throw the textfield at it and additionally the font size (which I usually get from the XML node’s property). Unfortunately, you have to do this for every textfield and every time you set the text, but if you plan and build your Flash applications correctly, this should be a simple addition to your application framework. If it’s not obvious, let me know and I’ll write another article on best practices for localizing your Flash applications.

Flash Textfields Are Still Broken!

What isn’t broken in Flash? If you’ve delved deeper into Flash than simple animations, you’ve more than likely run into several on your own. Most of the time, restarting Flash will work, but other times, some detective work must be done in order to sort out the workarounds.

Masked fonts

If your dynamic textfield is masked, in anyway, fonts won’t show up if you disallow font embedding. Why? Well isn’t it obvious? Flash is broken. So, don’t mask your fonts if you want them to work internationally.

So many thanks to Adobe, we enjoy overpaying for your products so that they’re full of bugs. I’ve worked in Flash since the late 90s and I can’t remember them EVER releasing a patch for it. Just a new version that you have to pay several hundred dollars for. So my advice is to use an open standard for your applications and websites since those always support international languages.

Did you find this useful?

If you found this page useful, please consider helping us out by checking out the links on the right. Thanks!

Dynamic Textfields in Flash AS3 and Their Bugs is a post from: Ziray Studio Labs

Related posts:

1. Tech Update
2. Fixing What’s Not Broken: A User-Centric Perspective
3. Custom Mouse Cursor for ActionScript 3
4. How to Program for the iPhone – A Plan

I’m mostly coding up stuff for Flash, Flex, Augmented Reality, iPhone, PHP, and CSS/HTML right now so hopefully I’ll have the time to post more snippets of things I’ve figured out trying to get all this technology to work.

Direct Access to the X and Y Mouse Coordinates

The first method allows us a finer control over the movement of the cursor by directly changing the X and Y coordinates of the cursor movieclip with the X and Y coordinates of the mouse. If we wanted to restrict the movement to say, a specific Y coordinate (as we’ll see in the next example), we can do that just as easily by keeping the target_mc.y a constant when we update it’s X coordinate.

The Drag and Drop Method

Our next method uses the drag function built into Flash. With this function you can drag a movieclip around the stage with the mouse automatically. This restricts some of our freedom, but gives us some very easy coding to control the mouse cursor to specific regions. In this case we simply restrict the motion of the cursor along a rectangle of 0 height (so it won’t move along the Y axis) and with a width as wide as our boundary box. This feature has its advantages, and I merely include it to demonstrate how to use it in the context of a custom mouse cursor.

I hope the code is commented well enough for you to understand what’s going on. It should be fairly self explanatory, but if not, feel free to ask.

Sample Code

Below is the source code for the SWF used at the top of the post:

Download the Custom Cursors sample code.

Did you find this useful?

If you found this page useful, please consider helping us out by checking out the links on the right. Thanks!

Custom Mouse Cursor for ActionScript 3 is a post from: Ziray Studio Labs

Related posts:

1. Dynamic Textfields in Flash AS3 and Their Bugs
2. Handling Your Initial View Controllers for iPhone
3. Fixing What’s Not Broken: A User-Centric Perspective
4. Why Your Code Sucks – Naming Conventions