iPhone Unit? TDD?


Thank God for people like Dr Nic. I managed to test drive a simple calculator project on the iPhone using his screencast. Just a quick note if you don’t come from the Ruby camp, (you know, like you spend most of your time obsessing over the JVM and toy with Groovy on the weekends):

You’ll want to install rubigen to get his example to work.

sudo gem install rubigen

You’ll also find that since the project renaming iphoneruby doesn’t work. Instead “gem install rbiphonetest”. My only question is why doesn’t my calculator respond to the reset method after I completed the screencast walk through and added the reset method to the object?

assert_respond_to calc, :reset

fails for me! Must be another one of those iPhone/ObjC inconsistencies that I’ll learn along the way.

Fix Java Swing Apps on Compiz-Fusion


Or fix Swing apps on Beryl…

I’m keeping my eye on this trail:
http://blog.morgan.hk/2007/04/29/display-problems-with-beryl-or-compiz-and-java/
I found it using this search:
http://www.google.com/search?sourceid=mozclient&ie=utf-8&oe=utf-8&q=beryl.jdk6.fix.sh

Because I use Idea and because Idea uses Swing, and because I like eye candy, things just wont work 100% even on Debian/Mepis one of the most stable OSes around. If you use Mepis 7 out of the box then you’ll have a great experience. But if you’re like me then you’ll no doubt push the limits even a little and find your self looking at a blank screen when there should be a diff.

iPhony Development – Unit Testing?


I’ve been at it all weekend. Off and on, spawning threads, updating a dumb UI, now exploring Test Driven Design with Cocoa. Here’s an interesting tidbit that I turned up somewhere in the Apple docs last night. (It was past 12am when I read it, I was tired and now I can no longer find it so I might as well be lying to you but…) “Creating unit test targets is not supported for iPhone development…” or so the text read. Why is it that the mobile community thinks they’re so special? Why do they not need unit tests for their software? Am I missing something? I found an article demonstrating how to Test Drive a TicTacToe game in Cocoa and so far it’s been working pretty well. I’m still hitting my random stumbling blocks here and there. My latest blocker comes from the following test auxillary method:

- (void) assertWinnerIs: (int) expectedWinner withMoveInRow: (int) row andInColumn: (int) col {
	int actualWinner = [game makeAMoveInRow: row andInColumn: col];
	NSString *winner = ( (actualWinner == _X_) ? @"_X_" : (actualWinner == _O_ ? @"_O_" : "NONE") );
	STAssertEquals(expectedWinner, actualWinner,
				   @"Move made in row %d and column %d by player %@ should win but returned winner was %@", row, col, 
				   [game valueInRow:row andInColumn:col] == _X_ ? @"_X_" : @"_O_"winner);
	[winner release];
}

It’s complaining about a pointer type mismatch in my conditional expression. I think I’m being too clever here using ternary operators instead of breaking out the classic if/esle or switch statements. I’m just trying to print out exactly which player is reported as the winner in my test because I like fully descriptive assertion failure messages but at the same time I like more terse code. I hate breaking out verbose if/else blocks if I can avoid it.

On a side note, none of this will do me any good if I can’t run test suites in an iPhone project. Still I’m thinking that I could probably hack around the limitation somehow by creating a Cocoa library project just to get the core logic unit tested then somehow figuring out how to include that unit tested code in my iPhone project. I’m certain there’s a loophole somewhere and I’ll stumble across it shortly. I still wonder why it has to be such a challenge? C’mon, we’re in like, the 27th century or something like that! There’s no excuse for any moder frameworks to be created sans unit test support. I view this as completely unacceptable!

Titles, Strings, and Threads


I just got bit by a subtle Objective C bug. I’m writing a basic application that starts an asynchronous counter that updates an onscreen label. Common sense would suggest pseudo-code like this:

onButtonPress:
   if button title = "Start"
      set button title = "Stop"
      startBackgroundCounter
   else
      stopBackgroundCounter
      set button title = "Start"
end onButtonPress

The problem is this. The UIButton class in Cocoa has a read only currentTitle property. There’s no writing to this property however you can write to setTitleForState and pass a UIControlStateNormal enum. (Why do I hate enums?) So I’m thinking it’s enough to query the currentTitle property and then set the title for the normal state from “Start” to “Stop”, right? Wrong! Somehow the currentTitle property hangs onto the original value and instead I should be querying the titleForState: method instead! Can you tell I’m missing the JDK?

Stringing me along


Did you know that, when using Objective C over Cocoa, there is no trim method! I’m fooling with some really simple code that should take all of 2 minutes tops but because ObjC/Coca breaks things out completely different than Java I’m facing collisions left and right. Luckily I think I’m smart enough to figure out why:
NSString @someString = @”Start”;
@”Start” == someString;
is not a true statement. I’m relying on my Java background which states that == referrs to object identity not equality is you might hope/guess/pray. Now I’m pawing through the String Programming Guide that sends me off on a tangent. I’m looking at the compare method which returns an NSComparisonResultwhich is typdef’ed to some crazy enum with ordering values. I don’t use enums, not even in Java so now I gotta read up on that too? Where is .equals()? Oh wait… I just looked at the string docs again and there is an isEqualTo method… *phew*

It’s going to take some getting used to. I found the quick API lookup in XCode which is mandatory for writing anything more sophisticated than HelloWorld. There’s a lot of other niceties in XCode as well but, BUT I stand by my original word that XCode has nothing on IntelliJ Idea. There’s an idea! Why doesn’t Jetbrains create an iPhone IDE? That would be off the chains!

The Black Art of iPhone Development


Experimenting with some Cocoa Touch stuff over the iPhone SDK, just for kicks. I’m not comfortable, getting there, but not comfortable yet. I truly miss Idea/Java when using XCode/Obj C. Don’t get me wrong, Apple put a lot of nice features in XCode (a very pretty IDE) and Obj C blows away anything C/C++ related. I can’t see how I’d be comfortable using it for daily development. Too many things are left out. For example, where the HELL is local history? Why does refactoring involve a dialog??? I would think that Apple of all people would get this right on the 1st attempt. Die hard programmers love things like EMacs, hot keys, command lines, single command/action type systems. Anything that takes you out of that flow is a distraction.

Here’s the thing, I think XCode is beautiful. I can see Apple put their touch on it as they do everything else. I love the way the matching left bracket animates when you type a right bracket. Hands down the IDE is prettier than anything from Eclipse, Netbeans, or Idea. For mobile development it beats the pants off of the competition. Blackberry might as well call up their chief JDE architect, invite him out for beer, chat about the McCain/Obama campaign for a good twenty-thirty minutes, pretend to have car trouble late in the night when it’s time to go home, then quietly slip a choke-wire around his neck while he’s not looking and squeeze the living RAPC knowledge out of him slowly. If this were a competition on sexiness, XCode would be Jessica Alba, Eclipse would be Tyra Banks (sexy but fading), Idea would be America Ferrera (appealing ot a certain niche), and Net Beans would be Britney Spears (sexy to those who have no idea what sex appeal truly is).

Productivity is key to an IDE. If productivity were money you would be living like Warren Buffet with Idea, paid like Bill Gates with Eclipse, comfortable like Trump with Net Beans, and just making it like Michael Jackson with XCode. (On the surface you look rich but behind the scenes there’s all these issues.) I need to be able to refactor comfortably. I need to be able to depend on local history instead of some just the undo button. I’d like to be able to tag my project, or whatever file I’m working on so that I can introduce changes and roll back and forth to see the impact of those changes. I’d like to be able to shelve my changes when I get side-tracked, then pull them off the shelf later without missing a beat. Productivity! XCode lacks all of these features and these are the things that make development a breeze.

Productivity aside my biggest problem comes from the lack of simplistic code examples and full fledge easy to use documentation available for the iPhone SDK. There are downloadable sample projects but nothing that shows you, fo instance, “Hello world” over an HTTP request. I can’t even pin point conclusive text that explains whether the iPhone UI follows the same single thread event dispatch model as is present in every UI toolkit I’ve encountered. My common sense tells me that all things like network calls should be done on a background thread to free up the EDT but I can’t find a conclusive simple code example that says, “Hey Idiot, call the OperationQueue API to background your slow network call then batch your screen updates back onto the EDT thread using this other API!” Then Apple makes things worse with their non-disclosure act… not allowing those who know disclose what they know so those who don’t know can know, y’know? it’s like a big secret, learning iPhone dev stuff must be done exclusively using the Apple online docs and nothing else. If you know anything about the black art speak up so we can open a private channel. I really want to learn and Apple isn’t making it easy. Holla’ at’cha man…

CSS and IE6


*Update*
I figured out the answer to the problem I was having during this post. The answer is IE6 was created by a Satan himself and for the low, low cost of one soul you too can guarantee that all of your CSS, Javascript, and angle-bracketed HTML hard-work will render as anticipated as it is delivered downstream to the hungry rendering engine created by Mr. Beezlebub. Simply deposit one soul into your USB port and click [send], or fill out a soul retrieval form and register for an authorized agent to pick up your soul at your local UPS store. All sales final. Tax, title, and tags are due at inception.

I don’t normally do front end weby stuff but eventually, working for a company like MapQuest, your gonna have ta’ do something that involves Internet Explorer. So today’s post is going to sound really stoopid to those of you who’ve dealt with the issues for the majority of your career, but for me… well I’m brand new so just be quiet, act like you never heard this stuff before and let me flow a minute. I’m working with CSS professionally for the first time now and I hit a snag with Internet Explorer. I’ve always heard horror stories about IE is so non-standard, Gecko, KHTML, Opera all follow the spec more closelier, yada-yada. When you do mostly rich client server Java stuff you get numb to the complainers. What whiners! Just use a layer of abstraction and interface or something and quit complaining will ya?

This past week I finally see why these babies cry so loudly. Trying to get some text to line up correctly in an already broken (well it looks broken to me but what do I know) layout has been such a chore. In recent findings I discovered the expression feature in Internet Explorer. You can, apparently, pass a Javascript expression in a stylesheet and have it evaluated as the page renders. I found this tip online and used it to address the missing support of min-width attributes in IE. It looks something like this:


p {
width:expression(document.body.clientWidth < 800? "800px": "auto" );
}

That sets a minimum width for a p tag. (Flip the alligator mouth the other way for max width.) I’m too stoopid to understand the ramifications of throwing Javascript into CSS (like what if the browser disables Javascript? Well the rest of our site kinda depends on it so I’m good there…) but experience will tell. If any of you gurus out there have styling experience give a bro. a shout, y’know? I can use a lot of help here.

How to use rapc from RIM… dirty details!


What’s really going on in rapc, Blackberry’s crazed compile tool? Let me begin by telling you that everything you’ve read until this point is not entirely accurate. There are those that will tell you that you have to run preverify.exe prior to running rapc. Then there are those who will tell you that the bb-ant-tools are sufficient. There are people that complain that the RIM compiler has bugs in it. (This may be true but I’ve so far been able to fix broken builds by using all of the advice I’m including here.) I’ve also found a blog that claims you can build from non-Windows operating systems. I’ve read in some places that either WTK or the JDE must be in the PATH so that rapc can find a preverifier. While some of these tips, tools, tutorials work they all have limits. Eventually you’ll find your application either throws random NPE’s, verification errors, or infinitely reboots the device! Now pay attention!

Now let me explain my project. I have a little bit of dependency injection going on via source generation. Then I also have some external jar dependencies. All of this creates a bit of a challenge for basic rapc invocation. In order to generate my midlet cod file I need to:

  • Run a source generator
  • Include the generated source in my list of things to compile
  • somehow include my external jar dependencies in the compile.
  • Include resources in my compiled output
  • Pick up my suit from the cleaners
  • Get the entire thing to run on my Mac?

While the last bullet is entirely optional and irrelevant, I include it because its the only way to get completely familiar with rapc. That is, if I can meet/greet/beat the challenge of cross platform compilation of Blackberry then I’ll really understand the intracacies of compiling with rapc. Now onto the juice.

How Rapc works… I think…
There are various approaches to compiling Blackberry applications that I know of.

  • Compile your app against the MIDP and CLDC APIs (include either WTK or MPowerplayer or someother party’s midp and CLDC jars on your bootstrap classpath for javac… making sure you use javac1.3 or below), preverify with JDE preverify.exe (found in %JDE_HOME%/bin), jar and finally compile with rapc.
  • Compile your application source files entirely with Rapc.

The first option has problems because there’s the possibility that javac will generate class files that will cause verification errors or (as my team discovered recently) the white screen of death when loaded onto the device. The second option has problems because it’s very tricky and prone to the same errors unless you are very dillegent. It took a lot of head banging and trial/error to come up with these details so read closely.

How do we use rapc? This is the question that still plagues me. There’s little documentation around the nuances you’ll encounter when invoking the rapc compiler from the command line. The rapc compiler is an executable (.exe) file in the JDE install directory living under the bin subfolder. First thing to note is the rapc.exe just delegates everything to rapc.jar. That means the same exact command line parameters you would use with rapc.exe will work with rapc.jar. (Call the jar with the “java -jar” command.) The most important thing to understand is that you cannot mix and match. That is you cannot use the output of javac/WTK preverify to fuel rapc. Furthermore you need to pay strict attention to the version of the JDE you use because it must be the same (or earlier) version of your target platform. For eg., if you intend to target Blackberry devices running a 4.2.2 OS you should use the compiler tools from the JDE version 4.2.2 or earlier. If you don’t pay attention to this step your product will work just fine until it’s time to ship… at which time you’ll experience weird, impossible to track/reproduce on a developer workstation, errors. There are other important tools in the JDE that you’ll need as well. The preverify tool is required (unless you’re using JDE 4.3.0 and targeting OS 4.3+) as well as the SignatureTool.jsr. Finally there is the net_rim_api.jar which lives under the lib folder in the JDE install directory. The next big thing to understand is the command line options.

import
Use the import= to specify the location of the net_rim_api.jar. This flag takes the relative or absolute path of not only the rim APIs but any other jar or cod dependencies your application has. (I haven’t tried cod dependencies but the docs say you can list cod files.) Be careful because this is only for resolving dependencies. Anything you list here will not be included in the final output cod. What this means is any jar files listed here must either be compiled as separate cod libraries or their source files somehow inlined in the final compiled. Dependencies listed here are scope as provided. In other words it is assumed they will be made available at runtime by either the RIM platform or by some pre-installed package.

codename
(codname for 4.3.0+)
This parameter threw me for a minute when I attempted to roll back to an earlier version of the RIM compile toolchain. I believe (and I need to double check and update this fact later) that rapc version 4.3.0 and higher expect a codname flag while versions prior to 4.3.0 expect a codename flag. The value you specify here will be the value used in the output codfile name. Paths can be relative to the working directory (the folder rapc is called from) or possibly absolute paths. For instance if you give build/MyApp as the value then rapc will spit all of its output into the build folder relative to the working directory giving you a final MyApp.cod file there. (you’ll also have MyApp.jar, MyApp.csi, MyApp.debug and other files in this folder.)

midlet
This is the application type. Use this flag if you plan to develop a J2ME spec compliant midlet. Blackberry support another application type, cldc, which provides RIM specific features (more on that in possibly another post) and is specified by the mutually exclusive -cldc flag. A You have to -midlet or -cldc to specify which kind of application you are building.

cldc
Use this flag if your are building a CLDC application that adheres to RIM’s proprietary launching interfaces. CLDC apps offer abilities to run in the background and be started at device boot time. There are other hidden gems here that I’d have to get into with another post.

jad
Use this parameter if you have a JAD file that includes your application’s meta data. This parameter is optional as you may substitue a .rapc file to include the meta data. Application meta data includes things like the icon to display on the desktop, the midlets contained in your aplication bundle, runtime properties, etc. Referr to the J2ME midlet spec for more detail.

rapc file
This would be the path to a “.rapc” file that includes meta data about your application. I’ll probably follow up with another post to explain the details behind this proprietary RIM spec. While a JAD file also includes meta data there are certain properties that can be included in this file that cannot be included in the JAD file and vice-versa.

class or java files
The last parameter should specify either a jar file containing the compiled classes or be a list of the .java files you intend to compile. Here’s where rapc gets really interesting. If you precompile your “.java” files you had better be certain you run the RIM preverify tool against these class files prior to invoking the compiler. Also I will repeat that you must use the same (or earlier) version preverify as your target platform. For eg., if you intend to target Blackberry devices running a 4.2.2 OS you should use both RIM’s rapc and preverify tools from the JDE version 4.2.2 or earlier. If you don’t pay attention to this step your product will work just fine until it’s time to ship… at which time you’ll experience weird, impossible to track/reproduce on a developer workstation, errors. (I said this before didn’t I?) Rapc is very picky here and the behavior varies between versions. It first calls out to javac assuming that the Java compiler is in the PATH. It then passes the output from javac to preverify. Note that in JDE 4.3.0 both “.java” source compiling and preverification is done from within the rapc.jar while earlier versions of rapc call out to the command line using the command “preverify” (not “preverify.exe”… this is an important distinction) and passing standard preverify parameters. Finally it creates the final “.cod” that will run on the device. What is included in the cod file depends on what is passed on the command line and what’s available from the working directory. For instance, your application icon (and I found this through trial and error) must be locatable from the working directory unless you specify an absolute path in the jad file. If you compile a jar file (not recommended for rapc prior to 4.3.0) then everything in that jar file (images, multimedia files, application resources, etc.) will be included in the final cod file. If you compile “.java” files directly from rapc then no application resources will make it into the final output cod file, only the compiled .class files will be there (along with the application icon specified in the jad if it can be found from the working directory). It took a lot of banging my head to figure this out. Finally instead of a jar file or space delimited list of “.java” files, you can specify a text file that lists (new line delimited style) all of the “.java” files you wish to pass to the compiler. This is a potential work-around to command line size restrictions that may be present on some versions of Windows. This file should be given with an @ prefix. For eg. if your have a MyApp.txt file then the last parameter for rapc will be @MyApp.txt. This is the preferred method of giving files to rapc because as your application grows so will the list of files.

One last got’cha I found was with trying to use rapc.jar directly instead of rapc.exe. If you are running a JDE earlier than 4.3.0 then you’ll get into trouble here because there is a secret parameter passed from rapc.exe that RIM won’t tell me about. Because the command line syntax for the jar is identical to the command line syntax for the “.exe” you can almost get away with it but because of a secret exchange happening between the Jar and exe you’ll get undefined behavior and weird errors in certain circumstances. This last gotcha is what makes it impossible to compile on an OS other than Windows while targeting a RIM OS earlier than 4.3.0.

In the end I’ve determined that it is not possible to accurately build a blackberry application on an operating system other than Windows. Also while there may be some truth to the myth of bugs in rapc I believe it all boils down to a bunch of nasty assumptions the RIM developers made during the design. (they assumed everyone would be so thrilled with their Swing based IDE that they would throw away Eclipse/Idea/Netbeans and burn their Macintosh laptops in celbration of the obviously superior RIM tool chain.) I do believe that if you pay close attention to the details outlined above you can diagnose most preverification and random erros you may be suffering from. I plan to revist this topic in the future as I’ve taken a break from mobile and begun work on some other things. However I do not plan to let rapc defeat me entirely. Keep an eye out because I’ll likely be updating this very same post with more details.