Progress made to the Augmented Reality Toolkit. Now a static library!

Today we're please to announce that we've updated the source code on Github.  The latest set of changes made this week fixes  the orientation issue that's been driving me nuts.

A Static Library - Finally!

The project now has the core of the toolkit put into a static library.  Why is this important? In the future when this project has matured, it will allow anyone to add the library to their projects.

We've still have a long way to go. One of the changes we want to have is the ability for any type of view to be added to augmented Reality layer.

Orientation works in both landscape and portrait modes

Woot! We finally got this one piece of code figured out.  It really came down to some simple math.  When the orientation of the phone changes, we need to adjust the azimuth.  We also fixed a stupid mistake where we were checking the same orientation direction instead of checking the left AND right.

The final a-ha moment came in the determining the angle of the phone to know where to draw the y position of a view.

   1:  switch (currentOrientation) {

   2:    case UIDeviceOrientationLandscapeLeft:

   3:       viewAngle = atan2(acceleration.x, acceleration.z);

   4:       break;

   5:   

   6:    case UIDeviceOrientationLandscapeRight:

   7:       viewAngle = atan2(-acceleration.x, acceleration.z);

   8:       break;

   9:   

  10:    case UIDeviceOrientationPortrait:

  11:       viewAngle = atan2(acceleration.y, acceleration.z);

  12:       break;

  13:   

  14:    case UIDeviceOrientationPortraitUpsideDown:

  15:       viewAngle = atan2(-acceleration.y, acceleration.z);

  16:       break;

  17:   

  18:    default:

  19:       break;

  20:  }

As you can see, determining the angle we need to use the y acceleration in portrait mode and the x acceleration in landscape mode.  However, there was one more thing we had to do to make sure the functionality behaved the same way, regardless of the orientation.  We needed to adjust the  x value as negative when the iPhone is in Landscape Right and the y value when the iPhone is upside down. (Not sure why one would do it upside down but we added the functionality anyways!)

Scaling issue resolved!

We finally go the scaling of the views working now too! The funny thing all we had to do was uncomment out the code we had commented out before and it started working.  The problem was solved by another bug we fixed a while back but forgot to uncomment the block code that was scaling the views down to nothing.

What's next?

Now that we have the bare minimum working now by simplifying the code and getting it to work for all orientations and adding it to a static library, we can now get to the fun part.  Making it into a real toolkit.  

I don't recommend forking the project just yet because I still see a ton of refactoring that will go on from the project we forked from to get it to an acceptable toolkit.  My big projects are slowing down a bit right now so I feel I can spend a little more on this project than I had the first couple of weeks of the year.

Stay tuned. The best is yet to come!

Augmented Reality Toolkit for the iPhone on GitHub

A couple of weeks ago I got very interested in doing an Augmented Reality Application for the iPhone and one of business partners had a great idea for a game.  Instead of starting from scratch I decided to see if there was any existing open source projects I could use as base.

I started searching on GitHub and found a very good start of a toolkit.  I downloaded the original code and really liked where it was going.  However there were several things I felt I could do to make the code a bit less complicated and say many ways to improve it!

I've forked the original project and have begun to make the many changes I think could make it into a better toolkit.  I want to thank the original developers for getting me started and doing some of the heavy lifting.

I plan on blogging about the changes I've made and what I plan on adding to the toolkit. 

This should allow me to create the application I'm interested in making but also provide everyone who is interested a great toolkit to make their own projects as well.

It currently has a long way to go but now that I have the code in a manner that I want, I can really start adding the code to make this great!

You can check out the project on GitHub.com

Dismissing the iPhone Keyboard

For some reason a simple task like dismissing the keyboard for the iPhone can cause one to pull their hair out because it just will not work. There are a couple of key points to remember. The number #1 part developers forget to set is the delegate of the textField. If you're using the Interface Builder, remember to set the delegate of the textField to the File Owner.

 If you're not using Interface Builder, then make sure to set the delegate of the textfield to self. I also include the returnType. For example, if the textField was called gameField:

gameField.delegate = self;

gameField.returnType = UIReturnKeyDone;

Implement the UITextFieldDelegate Implement the UITextFieldDelegate for the ViewController is required.

@interface YourViewController : UIViewController <UITextFieldDelegate>

Finally, implement the textFieldShouldReturn method and call [textField resignFirstResponder]

- (BOOL)textFieldShouldReturn:(UITextField *)textField {{
     [textField resignFirstResponder];
     return YES;
}

All the textFields will use this same method, so this only needs to be setup once. Make sure the delegate is set for the textField and the UITextFieldDelegate is implemented for the interface. Finally, add the textFieldShouldReturn method and call the resignFirstResponder . That's it! Now there should not be the problem of dismissing the keyboard if these few steps are followed.

iPhone TableView: Swiping a cell to delete

One of the elegant features added to the iPhone mail app was the ability to swipe your finger from left to right on a tableView cell and have the delete button appear (like the right image below) to delete an item from the tableView.

Many people have asked me if this is possible to do for their own iPhone app. 

The short answer is Yes but you have to use a couple of undocumented API calls. It's actually quiet easy. Set the cell's editingStyle to UITableViewCellEditingStyleDelete. This is an undocumented feature. Currently the documentation will show that it's a read only property. However there is nothing stopping one from setting the set property. A compiler warning like below will appear when implementing the set property.

To set the style, do it either in the cellForRowAtIndexPath method or implement a TableViewCell object. I'm not going to get into details of how to create a cell, I assume you already know how to do that.

- (UITableViewCell *)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath

{

   // Add your code here to create the cell

    .....

    [cell setEditingStyle:UITableViewCellEditingStyleDelete];

}

The final set step is to actually do something when the user swipes the cell and clicks the Delete button. This is handled by adding the commitEditingStyle message to the view.

- (void)tableView:(UITableView*)aTableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath*)

{

    if (editingStyle == UITableViewCellEditingStyleDelete)    {

        //Add Code to delete from the Data Source

    }

}

That's all to it. A very simple implementation for an elegant solution. I'm still miffed why this is undocumented, so be warned, you could have Apple decline your app because of the usage of an undocumented feature. UPDATE: iPhone 3.0 SDK you no longer have to set the EditingStyle of the Cell.

Developing under OSX 10.6 and Xcode 3.2

Snow leopard at first glace did not seem like an upgrade worth buying because not much as changed as far as the presentation and new features.  However after using it you can really tell the work was done to internals of the OS.  What has also impressed me is the new Xcode 3.2 that works only in Snow Leopard.  Apple has done a fine job at bringing this Development IDE to the level of Visual Studio.  When I first started doing some development on OSX, Xcode was no where near the development IDE of Visual Studio.  However that is all changed.

Time to upgrade all the other mac's here at Agilite because once you start using Snow Leopard, you quickly realize it and start looking for the things you've started taken for granted when using Snow Leopard.

If your a Mac or iPhone developer, I highly recommend that you get out to your local Apple store and purchase Snow Leopard just for the upgrade of Xcode alone.  For $49 for the family pack, you can't go wrong!