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*

private int MyAwesomeFunction(int pVar)
{
// coding magic
return pVar++;
}

…where pVar = 10, the returned value will NOT be 11!  The returned value will still be 10.  If you want to return an incremented value for pVar, do the following:

private int MyAwesomeFunction(int pVar)
{
// coding magic
return ++pVar; // or return pVar+1;
}

Just a case of postfix vs prefix.  In the previous example, the variable never gets incremented because the postfix operator would get evaluated after the line is processed, but that never happens because we’re returning the pVar.  By flipping to a prefix operator, we guarantee that we evaluate the opperator against the variable before we return it.

It’s also worth mentioning that being a little verbose here is also good.  Explicitly stating that you’re adding 1 to the variable (as displayed in the commented code) is the same number of characters and we eliminate the confusion over what’s getting returned.

Happy Coding!

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.

Internationalising my app

…and make sure the folders you use follow this format “[Language Abbreviation].lproj” as commenter #4 points out

If you miss one of the major languages, your app will default to English.  As of this post, the iPhone OS supports the following languages:

English (U.S), English (UK), French (France), German, Traditional Chinese, Simplified Chinese, Dutch, Italian, Spanish, Portuguese (Brazil), Portuguese (Portugal), Danish, Swedish, Finnish, Norwegian, Korean, Japanese, Russian, Polish, Turkish, Ukrainian, Arabic, Thai, Czech, Greek, Hebrew, Indonesian, Malay, Romanian, Slovak, and Croatian

1. Keep your .gitignore file.
2. Clear your GIT cache.  Don’t worry, this won’t delete any of your local files, just what GIT is tracking.
   git rm -r --cached .
3. Add everything in your project.  Your .gitignore file will exclude what you want to ignore now and start tracking the good stuff.
   git add .
4. Commit your changes.
   git commit -m "Now my .gitignore file works correctly!"

Happy codding!

body
  line-height:1.2em

h1
  color:red

This would render a blank document for /public/stylesheets/foo.css.  You won’t get an error about it, you’ll just get a blank document.  Here’s the thing, when you’re declaring a CSS property, you MUST put a space after the colon.  Failing to do so will just wind up in parsing errors on the sass side.

I hope I’ve saved you some head scratching.

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!

Now, if you’re on a Mac or Linux system, just add a symlink inside your dropbox folder that points to the other folder you’d like to sync.

On Windows, if you want Dropbox to sync folders outside of your “My Dropbox” folder, you’ll want to use the mklink command to create a directory junction pointing to the other folder you want synced. For example, if you want Dropbox to sync c:\source_code, open a command prompt, navigate to your dropbox directory (cd “My Dropbox”) and type:

(Assuming you’ve already navigated to your “My Dropbox” folder)
mklink /J source_code c:\source_code

Bam. That’s it. Dropbox is now following the link inside the “My Dropbox” directory and it’s syncing c:\source_code because it thinks it’s just another folder in the dropbox. Enjoy!

My message to you is: TDD takes less time, not more.

Today’s example: I’m writing some code that uses a parsing library written by a cow-orker. He’s a sharp guy, and the library generally works well, but it has a couple of undocumented behaviors – they’re mostly benign, and probably work for other users of the library, but for me it’s stuff that would result in misbehavior way up the call stack, or in another module entirely.

While I’m test-driving the code that uses this library, I notice the library itself does not have automated tests. The natural-feeling thing for me to do here is to test some sample calls to the lib to make sure it does what I expect. I know it’s not exactly canonical behavior to test outside libs that are assumed to be functioning, but it is good form to write tests that teach you about the system you’re building, and I needed to learn whether this library was going to parse my input in the way that I expected. The documentation wasn’t there, I wasn’t going to figure it out by inspecting the code (which is relatively complex), so tests it was.

Surprise, surprise – I found out that the library did NOT behave as I expected in every case. Had I not taken twenty minutes to write tests to introduce confidence in the parts of the system I didn’t know well, I’d probably have spent a couple hours debugging and looking in the wrong places for the problems I was having downstream. It also led me to a relatively simple solution where I extended the library class and just overrode the elements related to my handful of problematic cases, without changing his library or breaking code that depends on it.

As an added bonus, not only do I know what the documentation does not tell me, but I’ll also know if and when my colleague makes changes to his library that break the expectations of my code.

So I’ve reduced debugging time, increased my confidence in my code, and protected myself against future changes. I see it time and again – the time saved by writing the extra test code is well out of proportion to the time spent writing it.

There’s an exception here for developers or shops that are fetishistic about 100% test coverage, and do not judiciously use automated testing to learn about the system, drive design, and catch regressions. Writing tests to cover trivial/obvious code (i.e., writing tests that do not teach you about the system) is a time-suck. I’d avoid it, if I were you.

As long as I’m raving about TDD, I have to recommend the work of Kent Beck. I follow him on Twitter, I read his blog, and his book on TDD changed how I write software – I count it among the indispensible books on my shelf, with the GoF Design Patterns and Knuth. Check him out if you’re interested in deep thought about how software gets made.

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!