I recently needed to build an “admin” screen for a webapp using ExtJS 4. The wireframe called for a tree to navigate the various admin settings, including settings for individual users (something like what you see at right). To build a tree like this with ExtJS, you usually use the Ext.tree.Panel class (a.k.a., a TreePanel). Unfortunately I couldn’t find any examples of how to make a TreePanel with a mixture of both static and dynamic nodes, so figuring it out took longer than it should have. With that in mind, I thought I’d share what I learned. View Complete Document »
Finding an elegant way to reuse and share code (i.e., libraries) across separate iPhone applications can be a bit tricky at first, especially considering Apple’s restrictions on dynamic library linking and custom Frameworks. Most people agree that the best solution is to use static libraries. This tutorial builds on that solution, showing how your Xcode project can reference a second Xcode project–one which is used to build a static library. This allows you to automatically build that static library with the rest of your app, using your current build configuration (e.g., debug, release, etc.) and avoid pre-building several versions of the library separately (where each version was built for a specific environment/configuration). View Complete Document »
At some point every Cocoa and Cocoa Touch developer has to learn how to manage memory while programming with Objective-C. Unfortunately, it can be a confusing topic if you’re inexperienced or new to the language and frameworks. After doing my own bit of ramp-up in this area a while ago, I distilled everything I learned into three “brain triggers,” or rules, that I can use to easily remember when and how to use -retain, -release, and -autorelease (the three main methods for managing memory in Objective-C). While somewhat similar to the “memory rules” presented in Apple’s 40-page Memory Management Programming Guide for Cocoa, I’ve found my own “brain triggers” to be easier to remember, and the accompanying notes easier to reference. To that end, I decided to share the information here in case it’s helpful to anyone else. View Complete Document »
If you manage your own web server and want to secure your website with SSL encryption (i.e., use “https://” URLs) you must obtain and install an X.509 certificate. Buying a certificate can be expensive, though, often costing upwards of US$100 per year. The cheapest option is to create your own, “self-signed” certificate for free. There’s a popular misconception that self-signed certificates aren’t as secure and that you must accept browser security warnings to use them; this is false. If securely distributed and installed in a browser, a self-signed certificate is just as secure as those sold by Certificate Authorities such as Verisign and will not cause browsers to display security warnings. This document attempts to briefly explain what certificates are, how to create a self-signed certificate that a browser can safely trust (i.e., no browser warnings), and how to use it without being vulnerable to man-in-the-middle attacks.
View Complete Document »