http://stackoverflow.com/questions/1197746/uiactionsheet-cancel-button-strange-behaviour

Long story short, if your launch an action sheet in a view that lives in a UITabBarController, the “hit” box for the cancel button gets shifted in a VERY STUPID WAY!

The solution is to reference the view you’re displaying in by the UITabBarController like this:

[sheet showInView:self.parentViewController.tabBarController.view];

Freaking WOW! Thanks a heap, Apple!

*grumble grumble*

1] Denial

It doesn’t really say that, does it?  I mean, they  must not realize what this will do to other projects not related to Adobe.  I’m sure they won’t enforce it.

2] Anger

Are you F*%#ING SERIOUS RIGHT NOW!?  Don’t they realize that some EA games use Lua!?  Are they going take those apps out of the store?  Don’t give me that “quality of apps” crap!  There are TONS of horrible apps written in native Objective-C!  “Crappy devs will make crappy apps regardless of how many layers there are & it doesn’t make sense to limit source-to-source conversion.”  This is creativity stifling!  Apple’s going to lose so many apps they’ll repeal this decision with the QUICKNESS!  I’m just going to bang out the best apps ever and we’ll see if Apple tries to take them out of the store.  I DOUBT THEY WILL!  What happened to the approval process!?  Shouldn’t that be enough!?  Don’t they understand how error prone manual memory management is!?  FURY!!!

3] Bargaining

Maybe we can team up with other developers and convince Apple to change this.  We can show them of the talent that’ll jump ship.  I mean, we’re not like those “sexy app” guys, right?

4] Depression

It’s over man!  It’s GAME OVER! Damn it!  I wasted all this time! What will become of my projects!?  I’m tossing out my iPhone & I’m definitely not buying an iPad now.  It’ll just be too painful of a reminder that my app is available on it**.  Nothing to see here except a teary-eyed developer

5] Acceptance

This sucks likes crazy, but I’ve still got time.  I’ll make updates to Touch Playbook for as long as I can.  MonoTouch is talking about giving developers the ability to create Droid apps and that will kick ass!  Windows Phone 7 is right around the corner and since my app is already written in C#, the port should be very easy.  The HP Slate runs Windows 7 and obviously Silverlight so there’s another port right there.  I’ll get started on that this weekend!  If it wasn’t for MonoTouch, I wouldn’t have gotten as far along as I did with Touch Playbook.  I don’t regret a moment.

Conclusion

I don’t know what the future of MonoTouch and iPhone development is.  Rather, I don’t want to admit what I fear the future is.  I’d love for a miracle to take place where the reported language is altered in 3.3.1 to allow MonoTouch and other quality iPhone development solutions.  However, if that doesn’t happen, MonoTouch still definitely rocks!  For the time being, it feels good to be in the final stage.  I don’t like being so angsty.

Update

I do, however, remain hopeful.  I’ve signed the developer driven Tiny Petition against Apple’s reported TOS change and you can too.  You might ask “Abel, isn’t this the barganing step?  Did you relapse?” and I would reply “Not exactly”.  In the bargaining step my thoughts came from desperation in the wake of anger.  Right now, signing the petition springs from hope and a desire to stand with my fellow MonoTouch devs and other devs effected by this.  This time the motivation is less about me and more about the community.

**I’ve already taken a stab at learning Objective-C and would rather use my time on other languages.  I don’t see myself taking up the effort again.  Life’s too short and I really like languages like C# & Ruby.

For the other devs in my shoes looking to play with MonoTouch, here are some things to keep in mind:

• If you want to subclass something like UIView, UIImageView, or any class that’s originally an Objective-C class & use your new class in your  XIB, you need to…
  • Make sure your constructor includes IntPtr constructor.
  • Sometimes you’ll need to register your classes like this:

    [MonoTouch.Foundation.Register("MyAwesomeView")]
    public class MyAwesomeView : UIView
    {
       public MyAwesomeView (IntPtr handle) : base(handle)
       {
          Initialize ();
       }
       //My awesome code here!
    }
    

  • If you simply type in the name of your custom subclassed view into IB without declaring it in code first, sometimes you get a “partial class” in the view controller’s xib code-behind file (MySensationalViewController.xib.designer.cs).  If that happens, you DON’T need to register your class, but you DO need to set your class definition to ‘partial’.  Here’s an example:

    public partial class MyFantasticView : UIView
    {
       public MyFantasticView  (IntPtr handle) : base(handle)
       {
          Initialize ();
       }
       //Your awesome code here!
    }

• Much like Visual Studio, you get awesome debugging tools so make sure to get familiar with “watches” (While at  break point: View -> Debug Windows -> Watch) and the “Expression Evaluator” (While at  break point: Run -> Expression Evaluator).
• There are also helpful tools such as a “Reg-Ex Toolkit” and an “Add-in” manager that can be hooked into repositories for even more functionality…as more repositories become available

When you have a friendly, yet powerful IDE to work with, developing software becomes enjoyable.  I’ll definitely be using this IDE to create my first iPhone app submission to the AppStore.  As I learn more about MonoTouch, I’ll make sure to post my findings here.  In the meanwhile, those of you looking to get more info about MonoTouch should checkout its homepage.  The MonoTouch site has a ton of tutorials, documentation, and multiple ways to plug into the MT community.  At a glance, you might scoff at the asking price of $399 for a yearly license, but when you consider how much faster you’ll be able to put together quality apps, it might be worth it for you.   I know it is for me.

Happy Coding!

1. You need to add your main application executable target as a direct dependency of the test target, so that you’re always testing against your latest build. Do this by double-clicking on the test target, going to the “General” pane in the properties dialog, and adding your app under “Direct Dependencies”. (This was actually mentioned in the OCUnit tutorial for Cocoa, but not the one about iPhone testing.)
2. Your linker needs to know about the objects you’re testing. An easy way to do this is to add the .m files for those classes to the “Compile Sources” group in your test target. You’ll also have to make sure you link against any frameworks used by these objects. (You could also tell your app target to export all symbols, then link your test target to it as you would a library.) (Thanks to Chris Hanson for pointing out this procedural improvement in comments.) You need to explicitly link the object files of the classes you’re testing. These are the “.o” files in your build folder. To do this: Double-click on the test target, go to the “General” pane, add a new item under “Linked Libraries”. In the dialog that pops up, choose “Add Other…” and add your class’s .o file.
3. When you run your tests, one failure looks like two: Failed tests show up in Xcode as errors (just like compile errors, &c). Any test failure triggers a second error, and you’ll see something like “Failed tests for architecture ‘i386′ (GC OFF)”. The docs never say so, but this appears to be normal. Fix the failing test, and it goes away.

Anything else to add? Drop us a comment!

This post assumes that you’re familiar with the fundamentals of iPhone programming, including view controllers, UINavigationController, and delegates. There is sample code for this post, which is released under version 2 of the WTFPL.

The Problem

I’m working on a multi-step UI for a game. Expressing these steps as a regular drill-down table-style UI on the iPhone felt cumbersome, and games can’t afford for processes to feel cumbersome; people will stop playing. One solution that occurred to me was batching related sets of steps in a smaller navigation table – so in Step 1 you’d drill through substeps 1A, 1B, and 1C before moving to Step 2. The fact that the whole view wouldn’t be replaced with every choice seemed like it would be less destructive of the user’s mental context, and the chunking of substeps should make it easier for the users to wrap their heads around the process. (No word yet on whether this solves my UI problem, but I like it so far.)

My UI solution contained its own technical problem, though: If I’m expressing the process steps in a UINavigationController, and expressing the substeps in a nested UINavigationController, how does the inner navigation controller notify the outer one that the user’s last substep choice completes that step and it’s time to move to the next step – or in programmatic terms, how does the inner UINavigationController tell the outer one to push a new view onto the outer one’s stack?

Or, putting it more visually, how do I get from here:

…to here:

In the non-nested situation when you wanted to push a new view onto a UINavigationController’s stack, you’d do the following in the current view:

[self.navigationController pushViewController:nextViewController animated:YES];

So in my nested case, I need to do that, but pushing onto the outer navigation controller’s stack from a view controller on the inner navigation controller’s stack. I tried a number of naive (but sensible-seeming) targets for the pushViewController:animated: action, such as:

self.navigationController.navigationController
self.navigationController.parentViewController.navigationController

Nothing worked. I set a breakpoint and drilled down through the members of self.navigationController, and no path to that outer UINavigationController was apparent.

The Solution

While investigating the innards of UINavigationController, I stumbled upon a writable property that looked like it might help: The delegate. When creating the inner UINavigationController, I added one line of code:

innerNavCntlr.delegate = self; // THIS IS THE MAGIC, PART 1

Keep in mind that this is called in the view controller on top of the outer navigation controller’s stack, so “self” has access to the outer navigation controller.

When the view on top of my inner navigation controller’s stack is ready to signal the outer navigation controller, I do the following:

// THIS IS THE MAGIC PART 2
UIViewController *topVC = (UIViewController *)self.navigationController.delegate;
[topVC.navigationController pushViewController:nextCntlr animated:YES];

A couple of notes: First, the view controller that creates the inner UINavigationController must implement UINavigationControllerDelegate, or you’ll get a compiler warning – but you can just declare that it does so in the header file, as none of the methods in that interface are required.

Secondly: If you’re like me, this feels like an abuse of the delegate property. Now there’s no reason that you couldn’t actually use that object productively as the inner navigation controller’s delegate – I just haven’t done so here. And the fact that the delegate property has to be casted to be used this way says to me that it wasn’t meant for this – explicit casts are always a code smell. (Anal-retentive types might want to put in some type-checking around that cast for safety.)

That said, it works, and I haven’t run into a maintainability problem yet, as this code doesn’t really get re-used in many places. Were I expecting to use this trick often, I might package up a subclass of UINavigationController (call it NestedNavigationController) that actually took an outer UIViewController or UINavigationController property. Then again I’m finding that in Cocoa, subclassing is often a code smell…

Got a better solution? I’m interested – please leave a comment below!

Update: Whoops. Comments are enabled now.

The solution was quick & dirty (as most solutions are during Rails Rumble), but the results worked, and allowed us to qualify for judging and reach a respectable 28th place finish in the “Completeness” category.

Check out the details after the fold.

Design Constraints

Great Minds is a word game played by 2 or more players. The game is played in a virtual chat Room, containing one or more Players. Players can take various actions, such as submitting a word to the game, chatting, or changing their handle/username. The results of these actions must be transmitted to other players in the room.

Other constraints on the design included:

• No New Technologies: There are tools like Juggernaut that make messaging pretty easy, but we had no hands-on experience with them, and learning a new tool on a 48-hour schedule was deemed a risk to completing the project & qualifying for Rumble judging.
• Broadcast: We needed something more than a simple message queue like Beanstalk; the consumer of a message couldn’t remove it from the queue, as there might be other consumers needing the same message.
• Room State Reconstruction: Someone coming to the room for the first time (or leaving and returning) should be able to see the current room state, including all participants, recently played words, and recent chat.
• Replay: Though we didn’t get around to implementing it, we wanted to offer the ability to review a particularly funny game.

The first two constraints affected our design and technology choices; the second two demanded that the messages be persisted. (Alternatively, we could have saved the room state in some other way, but as long as we had the messages anyway, it seemed simpler to just keep them and reconstruct the state.)

Client Implementation

In the absence of a viable push solution like Juggernaut, we opted for a polling solution: Clients would periodically send a signal that:

• let the server know they’re still alive and connected,
• sent any new messages to the server, and
• requested any pending messages from the server.

On the client side, this meant that every message got packaged as JSON, stuck in a queue, and periodically collected and sent to the server as the optional payload of a keep-alive signal. With some help from Prototype, this was as simple as:

  function SyncMessages() {
          var data = Object.toJSON(MESSAGES_QUEUE);
          var url = '/room/sync_messages';
          var params = {
                  authenticity_token: AUTH_TOKEN,
                  messages: '[]',
                  //messages: Object.toJSON(MESSAGES_QUEUE),
                  last_message_id: LAST_MESSAGE_ID };

          new Ajax.Request(url, {
            method: 'post',
                  parameters: params,
            onSuccess: HandleMessages });
  }

  SyncMessages(); //start first on load
  var message_syncer = new PeriodicalExecuter(SyncMessages, 3);

HandleMessages() updates the DOM based on messages coming back.

The other feature to note is the LAST_MESSAGE_ID token above. Each client is responsible for keeping track of the last message ID it got. On the server side, message IDs are assigned sequentially, so all new messages are guaranteed to have a higher ID.

We could have kept track of each client’s last message on the server side, but this would have been much more complex – we would have needed to store data either in the session (which already held a fair amount of stuff) or in another table in order to keep track of who had received what.

Server Implementation

On the server side, messages were persisted in a table. This table would have relatively frequent inserts, somewhat more frequent reads, and no updates or deletions. For this reason, we went with the default MyISAM table architecture. (We had considered a design that would have updated the table with delivery status information and would have required InnoDB’s row-level locking, but in the end we opted for the simpler design.) The table looks like:

  class CreateMessages < ActiveRecord::Migration
    def self.up
      create_table :messages do |t|
        t.integer :message_type_id, :room_id, :game_id, :user_id
        t.string  :data, :user_handle
        t.timestamps
      end
    end

    def self.down
      drop_table :messages
    end
  end

It also has an index:

  class AddRoomIndexToMessages < ActiveRecord::Migration
    def self.up
      add_index :messages, [:room_id, :id]
    end

    def self.down
      remove_index :messages, [:room_id, :id]
    end
  end

Recall that the client keeps track of the last message it got, and periodically requests all messages since. This index speeds that request - which is just msgs = Message.find :all, :conditions => ['room_id = ? AND id > ?', session['room_id'], last_message_id], rder => 'id'. (Yes, I know that should be a named scope. I hadn't gotten around to learning those yet at the time of the Rumble.)

When the a keep-alive signal hits the server:

• any new messages attached to the signal are added to the messages table,
• any game mechanics related to those messages are executed (which may result in more messages being added to the table), and
• all messages for the caller's room with an ID greater than the caller's LAST_MESSAGE_ID are packaged as JSON and sent back down in the HTTP response.

A note: If you're in a room and you enter (for example) a chat message, there's actually a server round-trip involved (pushing the message to the server and getting the same message back as a response) before that chat message is shown in your browser. We worried about this, but not for long - the interactivity delay turned out to be minimal, and it was much simpler to keep it this way (every message is treated the same for all clients) than to create an exception (you update your DOM with your chat messages immediately, but your own chat messages are somehow filtered from your message stream).

What's Missing?

Obviously, this was a quick & dirty solution, tailored to the immediate needs of a Rails Rumble project. Here's what I'd do differently (and indeed, will do differently, as we have plans for the future of Great Minds - stay tuned):

• Security: We do use the Rails session authenticity_token, but there's still no protection from a server flood from someone who has a token, either by cranking down the polling interval or by fiddling with the LAST_MESSAGE_ID.
• Server Push: Polling is wasteful - requests are made whether or not there are any messages to send or receive. We plan to move to Juggernaut soon.
• Decoupling from Game Mechanics: In the first iteration, message receipt and delivery were too intimately tied to game mechanics, with Message objects being explictly constructed and followed by Message.save! calls. I've already started the process of teasing them apart in preparation for the move to Juggernaut, factoring this into a deliver_message() method.

Questions? Thoughts? Add a comment! I promise to get back to you.