You are here

development

Setting up Appcelerator Titanium under Mac OSX to build mobile apps for iPhone and Android

I recently inherited an older Macbook from my wife after buying her a new fancy Macbook Pro for Christmas. After doing some research, it turns out that using a Macbook is probably the best way to develop mobile applications because the iOS (iPhone OS) SDK requires a Mac to work. Of course, the Android SDK is platform independent because its Java-based. So I might as well put the Macbook to use.

Well, first thing I discover is you need Snow Leopard (OSX 10.6) or later to install the iOS SDK. I am running 10.5.8 so I need to get a copy of Snow Leopard. Well, it turns out this was easier said than done because Lion is coming out and I could not find a copy anywhere. I end up having to buy the family license for $50 rather than the single license for $30. Oh well.

Upgrading to Snow Leopard was a snap. Installing Titanium was simple; I just needed to register an account, select the freebie version of Titanium and had it running in minutes. Now I need to install the iOS and Android SDKs.

The iOS SDK is only available to Apple developers so I had to pay $99 for the privilege. Once I was registered, installation was simple and Titanium automagically recognized the iOS SDK was installed.

The Android SDK was a little tougher. It was unclear as to which version of the SDK I should download and the one I selected was obviously wrong so I just downloaded them all. Once I added a line to my .bash_profile file pointing the $ANDROID_SDK variable to my install directory, everything worked fine.

So now I have a fully functional development environment for creating mobile applications in iOS and Android. Now what?

Drupal module development and block caching issue

I have spent the past couple hours trying to debug a module that creates a bunch of content blocks on a Drupal 6 website. These blocks were set to BLOCK_CACHE_PER_PAGE setting but I changed them to BLOCK_NO_CACHE because I am implementing my own caching on them.

Well, turns out that even if you enable / disable your module and update your block admin page, Drupal never changes the block's cache setting. This is apparently not by design.

I will do a future post about implement custom caching in your modules in the future because I have learned a ton while completing gutting the caching that I did a year ago (which I did a very poor job of). Until then, I guess I chalk up the hours of frustration to "experience".