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:
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:
…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.
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.
This process sucks. Period. To get you through the suckage, I found this article with clear and useful steps. If you’re becoming an iPhone/iPod Touch developer, this is something you NEED to read. The article presents the steps of the deployment process in the best order possible to improve your chances at a successful push.
I came across this video from Brian Greenstone, the president and CEO of Pangea Software. You might remember him from such iPhone games as Enigmo, Cro-Mag Rally, or Bugdom 2.
He’s made a video answering “10,000 ft view” questions about iPhone game development that people who are new to the platform should hear. What he’s saying isn’t revolutionary, but it’s a lot of very good advice in 1 spot.
It isn’t the end of the world if you don’t do it ahead of time, but it does make life slightly easier.
(2) Remember that when you find a bug, you should write a test for the expected behavior BEFORE fixing the bug. “The Rails Way” has a great quote about testing:
“It’s not that Rails encourages you to do test-driven development, it’s that it makes it difficult for you not to do test-driven development.” ~Brian Eng
I’ve interpreted this quote into the following mantra:
“It’s not that rails makes it easy to test, it that it makes you pay when you don’t”.
Finding a bug after creating your test suite just means that you missed a test. Take the opportunity to correct that.
Thing 1:FasterCSV is really cool! It’s easy to use and does exactly what it should. Here’s Scott Becker’s exporting tutorial. For importing, i’ve hacked together bits from Peter Larkmund’s travels and the FasterCSV documentation. Thanks to these tutorials, AMB will give users the ability to upload and export CSVs.
Thing 2: Default values for the win! If you have a table that has a column for an amount, feel free to set the default value to 0.00. Otherwise you won’t be able to do the following:
a = Account.new
a.amount += 20
…because a.amount will be nil. You’ll throw an error and if you just updated a bunch of code, you might waste an hour trying to figure out why you’re throwing an exception. However, if you declare a default value, you’ll be able to avoid any issues.
If you want me to go into further detail on either thing, just leave a comment.
