Firefox got real slow

One day Firefox just came to a crawl when running web pages with JavaScript. Then I found out what was causing it and how to fix it. Here’s how.

I was using the Firefox 3.6.16 web browser and it got really slow.  Unbearably so.

When I went to look at the console, it was filled with all kinds detailed of JavaScript warnings, the kind one might expect out of JSLint.  It was spending so much time checking the JavaScript code that it was barely spending time executing it.

The “culprit” was the Web Developer add-on.

Normally, the Disable / Disable JavaScript / Strict Warnings menu item is checked.  Unchecking it gives some fantastic diagnostic messages when writing code.  Forget to re-check it and regular web usage may come to a crawl.

Aside from the console being a clue, you may also see a caution sign or a red circle with a white ‘x’ in it on the Web Developer toolbar.

For normal speeds when regularly browsing, just disable strict checking.

Thick Menu Separators in ExtJS

Do your menu separators on Ext web applications suddenly appear as thick bars instead of thin lines? Here’s how to fix it.

I ran across a problem in Firefox 3.6.16 where my JavaScript applications produced with ExtJS were producing menu separators that were extra thick.

Even Ext demo pages did this: Menu Separator

Here’s how I solved it.

The problem can be addressed with the Web Developer add on.

Normally its Disable / Disable Minimum Font Size is checked. If it gets unchecked, Ext behaves very badly.

Check it and then reload the page; menu separators will be back to normal.

Where’s my JDK?

Caught in the Java depreciation battle under OS 10.6 and can’t find where the Java Development Kit (JDK) now resides? Here’s a command that will tell you, allowing you to still use InteliJ and other IDEs on OS X.

There’s a lot going on with Java at the moment. Oracle acquires Sun, putting the language in squarely in hands that don’t inspire trust; the same thing happened with MySQL. Meanwhile, the Apache Software Foundation quits the Java SE/EE Executive Committee. And now Apple deprecates Java, and the reason doesn’t appear to be what you’d think.

Starting with OS X 10.6.3 update, developers got caught in the back lash. Things moved on the file system.

Upgrading IntelliJ, the IDE was asking me where my JDK was, as it certainly wasn’t where the software, or I, thought it should be.

You won’t find the location using /Applications/Utilities/Java Preferences.app.

But you can find it with some digging. Thanks to this developer release note from Apple, the following command from Terminal will spew out some XML.

$ /usr/libexec/java_home –xml

Find the dictionary section that has ‘x86_64’ in it, and you’ll find an entry that has a ‘JVMHomePath’ with something like:

/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

You want to provide this full path to the IDE as where the JDK lives.

It’s worth pointing out that Apple recommends that if you install any 3rd party JVMs they should be installed in /Library/Java/JavaVirtualMachines or ~/Library/Java/JavaVirtualMachines.

Found: The Best iPhone Development Book So Far

Want to write your own iPhone applications but Objective-C, XCode, Interface Builder, and the steep learning curve of Cocoa getting in the way? Have I found the book for you.

Warning: long and geeky post follows — iPhone wanna-be developers, read on!

Beginning iPhone Development - Exploring the iPhone SDKI’ve found it, finally, the best iPhone development book so far! Read on to see why.

Fairly recently, I decided to turn my attention to native iPhone application development, but I found the arena a little sparse when it comes to what I’d call good documentation.

For some perspective, I’m a software developer of 20+ years with background in Unix and Windows; I’m very well versed in C, C++, C#, and Java, among a good number of other higher-level languages, having produced a number of enterprise applications.

You’d think that picking up Objective-C and the Cocoa Touch frameworks would be a fairly simple task. However, the moment you step foot into the pool, you’re get a cold shock at how much you don’t know and it can feel daunting enough to want to retract back to familiar territory.

Don’t give up. It is easy.

Looking forward into the unknown presents a much more gloomy impression than when you’ve taken a few steps and looked back to see just how far you’ve come and in such a short period of time.

Here’s what’s happening: The Apple Frameworks represent a large and mature collection of some impressive code. The closest experience I’ve felt to it, and this is admittedly a horrible analogy, is Ruby on Rails.

With Rails, there’s so much going on by convention that you have to sling very little code to get impressive things to happen. This makes it hard to understand: there is no code to trace.

Same way with the Apple Foundation classes that are based on NeXTSTEP — a lot is handled for you, and often in new ways you might not have thought about because of limitations of other platforms, so that very little code is required to do something quite impressive. The problem is figuring out what that code is you’re supposed to write, and more importantly how’d you know to go about doing that in the first place. Hint: knowing the Foundation Framework is important to understanding the Cocoa Touch Framework.

This leaves one in the lurch that the sample code appears rather sparse, and the framework documentation overwhelming, with little guidance on how all the pieces fit together into a simple, cohesive whole. The problem is all too common.

My biggest gripe with many frameworks, especially Java and it’s auto-generated documentation, is that all you’re really presented with is a list of method signatures with very little discussion about what they do, purpose and limits to the input values, discussions of side effects, the importance of call order, and so forth. With other languages, you’re lucky if you can find the header file to include or the library file to link against. It’s all just expected that you somehow know this, and that doesn’t work when you’re learning a framework, though it’s fine if you just need a reference.

Apple’s online documentation is certainly comprehensive, but the reality is you’re going to be watching videos and reading tons of documentation, picking up crumbs of useful bits as you go. The cohesive moment of comprehension will come, but it will be a long and slow ride. You want something faster.

If you’re learning Objective-C at the same time, the ride is extra bumpy, because not only are there just a few language extensions sitting on top of C, but the ObjC library is actually doing some clever work that you want to know about, and this has additional implications because there’s a lot of convention going on as well. Further obscuring things is the fact that, due to historical reasons, the terminology you are most likely already familiar with doesn’t map nicely. A nice look under the hood solves this. Objective-C isn’t just some new keywords, it’s new application behavior.

What’s Wrong With Other iPhone Books At The Moment
As of early 2009, you’re going to find few iPhone books out there. Most of what exists is for the hacked version of the iPhone, and while that may even sound useful, the tearing apart of the SDK is rough and incomplete, not to mention the implementation to call is painful. This just isn’t applicable to the real world constraints of native mode development.

Think you can get by with a slightly out of date copy of a Cocoa book? Think again. The UIKit framework is just different enough that your approach needs to be slightly different. Tight, efficient, resource management becomes very important.

Also, unless you already know and understand Interface Builder, it can be a hard time following along when your book doesn’t match your software version. Apple keeps modifying Interface Builder, making it better, but the changes can come across as so dramatic, interface-wise, that to the new comer it looks like a totally different application each revision. Once you “get it” the sweeping changes are cognitively transparent. The iPhone SDK includes, you guessed it, a new XCode and Interface Builder.

What few modern iPhone books there are out there jump straight into a technical feast of SDK details, leaving the reader with a learning curve that’s as vertical as a brick wall.

What’s needed is a book that introduces only what you need to know, when you need to know it, explaining tips and tricks along the way, delving into the philosophies of why things are the way they are, what the developers were thinking, how the frameworks are structured, what the conventions are, and when those conventions aren’t followed. And, instead of showing you the end solution all refactored into a neat package, take the long way, when needed, to introduce you to what’s going on and then evolve into the optimal solution.

I’ve Found Such A Book!
The book, by Apress, is called Beginning iPhone Development – Exploring the iPhone SDK by Dave Mark and Jeff LaMarche. This book is about the fundamental concepts you need to understand in order to make the frameworks do their magic.

Its tutorials are very well constructed, easy to follow, and are specifically designed to teach the framework in such a way as you understand what’s going on and learn to fish for yourself.

This is in stark contrast to substandard books that merely cover a framework’s capabilities with cut’n’paste examples that have little bearing to real applications. This alone gives is five out of five stars by my standards.

My only complaint is a minor nit that there are a small handful of typos, and unfortunately, they happen in the code examples. However, they’re glaring, and you won’t get tripped up by them. (For example, on page 85, the tutorial is about UIImage. And, UIImage appears four times in a six line sample. The first one, however, says “jmUIImage” and the indentation is off. It looks like a macro expansion, a note, or the mangled initials of one of the authors. The code won’t compile with it, and it’s obvious from context what it should be.) To me, this is forgivable. Especially since it’s rare.

Tagging 1430216263I want to show you something.

I have a habit of tagging my books when I find an exceptional piece of information that I haven’t found elsewhere. I give a book high marks if it earns somewhere between three to seven tags, as the majority of my collection never gets any tags. Tagging, for me, is not note taking — it’s rare event.

I think the picture speaks for itself.

For Example…
So, at this point, I present for my own edification and future reference, some of that tagged content. Who knows, maybe something you see here might just get you traction on the learning curve.

– In Objective-C, colons are a legal character of the method identifier, they are not syntactic sugar.
– Even though a number of macros translate to nothing, void, zero, or null under the hood, their presence provides important hinting for data types and method calls.
– The NIB’s File’s Owner is a place holder for the class that loaded the NIB file.
– The NIB’s First Responder is the object the user is currently interacting with.
– The application icon is a 57×57 .png file, see Info.plist’s Icon File.
– The iPhone specially optimizes .png files so this is the best format.
– Reset the iPhone Simulator by deleting its directory from ~/Library/Application Support
– You want to use @property (retain, nonatomic) as often as possible.
– Interface Builder uses your defined accessors to properties, which use retain; that means you do need to deallocate Interface Builder objects, even if you didn’t instantiate them.
– There are four control states on a control, often you want UIControlStateNormal.
– Learn to use retain/release, there is no garbage collecting on the iPhone.
– It’s better to init/release than using factory methods; factories use autorelease pools, and while this will work, it often keeps resources around longer than you intend — avoid autorelease pools.
– Hog too many resources, whether CPU or memory, and the phone will reboot.
– Everything from UIApplication on down will fire messages to Delegate objects at certain well-defined times, you need to learn what these times are and what messages are sent; it’s not just subclass avoidance.
– You can Option-Click on a class or interface name in XCode and go right to the documentation.
– You can press ESC to cause auto complete to happen immediately.
– Command-equal_sign will size a control to fit.
– When you’ve got a lot of control hierarchies going on, use the View Mode button to see them as a list.
– Scaling an image takes computational overhead, avoid if you can.
– Set the Alpha slider to 1.0 in order to optimize the drawing sequence, it skips looking at the underlying background and factoring it in — it applies to the image drawn.
– Also set the Opaque checkbox in order to optimize the drawing sequence, it skips drawing the underlying background for the parts where the image is transparent.
– The Tag control allows you to assign a numerical identifier to controls to locate them later.
– You need to handle the Did End on Exit event in order to make the keyboard go away.
– You may also need a huge, invisible, custom button as well to make the keyboard go away.
– In XCode, use Option-Command-up_arrow to toggle between a header and its source file.
– In the Interface Builder, move the cursor over a view and hold down Option to see how many pixels there are between the item and its superview.
– Option-dragging a control in Interface Builder makes a copy.
– Nifty buttons are actually stretchable images, and Apple has buried a ton of them free for your use in the UICatalog sample code on their site.
– There are three different ways to handle layouts when rotation happens: autosize, reposition, and view swapping.
– The rotation callback passes you the orientation the phone came from, you need to use other means to get the current orientation.
– If you want to use Core Graphics, for things like view transitions, you need to link the framework into your application.
– Some frameworks, like Core Graphics, have one version for the iPhone hardware and one version for the iPhone Simulator.
– If you use the correct parameters, XCode’s build process can play games with the path and always target the right framework (use Relative to Current SDK, and do not select Copy items).
– Right-click the Resources folder and use Add / Existing Frameworks… to do this process in a safe way.
– If a view isn’t shown, it’s superview is nil.

…there’s plenty more, but you get the idea. The book is jammed with all kinds of useful things to someone who is new to iPhone development. This presentation of material makes the learning curve very approachable.

And, once over that hurdle, all those other books that I said were problematic suddenly make a whole lot of sense.

This book is the best first step I’ve seen in the journey to writing iPhone applications. Period.

Walt gives “Beginning iPhone Development” two thumbs up, five stars our of five starts, and a head nod of appreciation to the authors. Well done, guys. Well done.