Quick Hits: UIActionSheet cancel button strange behaviour

I just got bit by this and fixed it thanks to this StackOverflow post.

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*

Quick Hits: Becareful when returning inc’ed vars

I noticed this in some MonoTouch code that I wrote recently, but I think it makes sense across other languages as well.  Let’s say you write a method that returns an incremented variable like this:

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!

The 5 stages of 3.3.1

Developers have been up in arms on the news broken by Daring Fireball and TechCrunch.  The reported change in the iPhone developer agreement definitely stops Flash developers from creating iPhone apps using the new tools available CS5, but the sword Apple used also cuts into the heart of the MonoTouch, Appcelerator, Unity 3D, Corona, & PhoneGap communities.  Being a member of the MonoTouch community, I’m directly affected by this reported change.  Easily said, I’ve gone through the 5 stages of grief over the news:

Read the rest of this entry »

Quick Hits: Localization strings in Monotouch

It’s pretty straight forward. Check out this post:

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

Quick Hits: When your .gitignore file gets…ignored

I made a mistake while creating a GIT repos that I’m hoping I can save you from making.  I made my first commit on a project and I realized that a bunch of files were getting in that shouldn’t be.  I created a .gitignore file, but the issue kept happening on subsequent commits.  As I learned later, you SHOULD create your .gitignore file first.  However, if you forgot, this is how you fix it:

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!

Quick Hits: Sass demands syntax perfection!

Just a quick note about sass.  Let’s say you had the following in /public/stylesheets/sass/foo.sass:

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.

I LOVE MonoTouch

Don’t get me wrong, XCode is great…in it’s own way…but as a .Net dev coming to the iPhone platform, MonoTouch rocks my world!

For the other devs in my shoes looking to play with MonoTouch, here are some things to keep in mind: Read the rest of this entry »

How to Get Dropbox to Backup Files in Other Directories on Windows

If you’re using Dropbox (affiliate link), and you should be, because it’s awesome, you might have noticed that Dropbox will only backup/sync files inside your drop box folder; you can’t tell Dropbox to also sync with other folders.

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!

TDD Makes Software Go Faster

One of the gripes I hear about TDD is that it takes too much time. People look at the idea of it and think, “So I have to write code and tests and update the tests when the code changes? WTF?”

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.

Quick Hits: Unit Testing iPhone Apps

I have a few things to add to the woefully incomplete official documentation on setting up automated tests in your iPhone apps:

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!