Mar 31 2010

A response to Part 2 of the “iPhone vs Windows Phone 7 Challenge”

Tag: Code,ProgrammingAdam Wright @ 6:05 pm

Readers of my previous post will recall that I’ve been following along with Shawn Burke’s posts as he explores porting Apple’s iPhone Development Tutorials to the Windows Phone 7 development environment. We previously examined his look at the “Hello World” example, showing that despite the claims, it’s just as easy on iPhone as WP7. Here, we explore the second in the series: the “Move Me” example. I doubt I’ll do this for every post, but so far, it’s been an interesting couple of hours.

As before, the example rather falls over by being a comparison of “iPhone Best Practice Tutorial” versus “Ad-hoc implementation”. As I mentioned previously, the Apple tutorial series are designed to showcase development concepts, not necessarily the fastest way to achieve the goal of the sample application. This should not be read as saying the post is bad – it’s an interesting comparison in the differing development philosophy of WP7, wherein the majority of MoveMe can be created declaratively in XAML. Cocoa doesn’t have a similar UI DSL, and one can’t deny the power of the Blend/WPF combination; it made the example trivial. It is, however, probably fair to point out that Expression Blend is not part of Visual Studio (RRP $599), and that UIKit, Interface Builder and Core Animation make this specific task pretty simple on the iPhone as well.

It’s claimed that WP7 needs 5 (6 with a correction), versus more than 100 for the iPhone. We’re not going to beat 6 (typed) lines of code, but we can do a lot better than the claimed 100. By using a custom UIButton configured in Interface Builder along with Core Animation’s implicit property animations, we can achieve the result in 20 lines – with most of the work going into building the bounce animation. If we didn’t want the bounce, 8 lines would do the job. In the following, the only typed lines were the bodies of the functions and the #import statement for QuartzCore. Interface Builder generated the event handler stubs, instance variables and hooked up all the events for us.

#import <QuartzCore /QuartzCore.h>
#import "MoveMeViewController.h"

@implementation moveMeViewController

- (IBAction)touchDown:(id)sender {
    [UIView beginAnimations:@"scale" context:nil];
    button.transform = CGAffineTransformScale(CGAffineTransformIdentity, 1.1f, 1.1f);
    [UIView commitAnimations];
}

- (IBAction)touchUp:(id)sender {
    CAKeyframeAnimation *bounceAnimation = [CAKeyframeAnimation animationWithKeyPath:@"position"];

    CGMutablePathRef thePath = CGPathCreateMutable();
    CGPathMoveToPoint(thePath, NULL, button.center.x, button.center.y);

    int overrun = 10;
    CGPoint pos = button.center;

    while (overrun--) {
        pos.x = [self view].center.x + (overrun % 2  ? 1 : -1) * (pos.x - [self view].center.x) * overrun / 10.0;
        pos.y = [self view].center.y + (overrun % 2  ? 1 : -1) * (pos.y - [self view].center.y) * overrun / 10.0;

        CGPathAddLineToPoint(thePath, NULL, pos.x, pos.y);
	}

    bounceAnimation.path = thePath;
    bounceAnimation.duration = 1.5;

    CGPathRelease(thePath);

    [UIView beginAnimations:@"scale" context:nil];
    button.transform = CGAffineTransformIdentity;
    [[button layer] addAnimation:bounceAnimation forKey:nil];
    [UIView commitAnimations];

    button.center = [self view].center;
}

- (IBAction)touchDrag:(UIControl*)c withEvent:(UIEvent*)event {
    button.center = [[[event allTouches] anyObject] locationInView:nil];
}

@end

The WP7 development magic here is really in Expression Blend – creating the XAML by hand would be around 60 lines of XML. I’m not a XAML expert, but examining the provided code, there’s no specific entry for “Bounce” – the effect seems to be being created by a combination of translations and easing functions. Creating it by hand would, I’d wager, be pretty tough – as hard as it was for me to write the above simple code. Therefore, what we really lack on the iPhone side is a tool or version of Interface Builder that obviates the need for the “bounce” code above. Of course, the code hacked together for the above could be factored into a category on UIView (similar to .net Extension methods) that adds “Animate with fancy effects” method. We could then, on any UIView, call something like

  [button addAnimationFromPoint:a toPoint:b withEffect:BounceEffect];

So, again, the developmental legwork difference for this example isn’t as large as was suggested. To specifically correct the list of concepts that one needs to code by hand on the iPhone:

  1. Drawing Images: No need, Interface Builder will set this up for us.
  2. Drawing Text: Again, handled by IB.
  3. Handling touch events: Nope, both created and hooked up via IB.
  4. Creating animations: Yes, we need to indicate we want animations in the code.
  5. Scaling animations: No – comes for free with CA’s implicit animation system.
  6. Building a path and animating along that: Yes, and this is a pain in the neck.

I suppose it’s hard to argue that in some sense, the WP7 development was not “easier”, certainly for a novice or graphical designer. For an experienced developer, especially one who writes suitably reusable code, I’d argue that it’s pretty much a wash.

Edit: Dear me, I’m truly awful at missing “not” from my writing – For those who read the previous version, let me make it clear I was not saying the post was bad, nor was I saying the WP7 development was harder than the iPhone.


Mar 25 2010

Responding to the “iPhone SDK vs Windows Phone 7 Series SDK Challenge”

Tag: Code,ProgrammingAdam Wright @ 7:53 pm

Over at his blog, Shawn Burke is running a series on “iPhone SDK vs Windows Phone 7 Series SDK Challenge”. He takes examples from Apple’s iPhone SDK, and shows how to create them using the Windows Phone 7 SDK, taking care to crow about supposed advantages of the Microsoft approach. In this post, I figured I’d examine his first “Hello World” example, and see how accurate the result is.

Note beforehand that I’m not disputing the power of WPF and C#. Given the choice of C# of Objective C, I’d probably rather work with C#. However, these types of language/API comparisons are rarely useful, nearly always mistaken, and correcting the record seemed an interesting task.

The first problem is that the title is inaccurate – it’s “iPhone SDK Hello World Tutorial vs ad-hoc implementation in WP7 SDK”. To show this, he goes through the tutorial and shows the same result prepared in WP7, with the banner claim being “4 lines of Code for Windows Phone 7, 44 for iPhone”. This is, at best, disingenuous. In the following video, I make the iPhone “Hello World” application using exactly the same number of typed lines of code as Shawn’s blog post. It’s not monumentally fascinating, but might show some Interface Builder features that are not widely known.

He makes two other points I’ll call out before exploring why he might make these mistakes.

“I was surprised that the User Interface Designer in XCode doesn’t automatically create instance variables for me and wire them up to the corresponding elements”

As shown, you can have Interface Builder create instance variables you need them. Regarding the automatic generation of instance variables, this is, I suppose, a matter of opinion – but years of Windows Forms programming has taught me that automated generation of instance variables for all UI elements is a nightmare. Your namespace is cluttered with dozens of instances you never need to reference and just add noise to your code.

“10% of the code, 1 file instead of 4, it’s just much simpler”

As shown, the amount of code you have to write it identical. 1 file instead of 4 is just wrong – if you download his sample program, there are 2 XAML files and 2 C# files. Counting the NIB file and main.m files as part of the iPhone solution, there are 6. So it’s 4 vs 6 in terms of files in the project, but identical in terms of the number of files you need to edit (1 XAML and C# vs 1 NIB and M file).

Why make the errors?

Shawn based his comparison on the Apple Tutorial. Why doesn’t the iPhone “Hello World” tutorial do it my way? Because Apple tutorials teach you the “Apple way” of development; “Best practice iPhone development”, if you will. Cocoa is, for better or worse, as much a philosophy as an API. If you don’t buy into the MVC approach, if you don’t structure your code in a Cocoa friendly way, you’ll be able to develop – but you’ll find it painful. As in it’s products, Apple tries to guide developers into the “right” mindset. Therefore, a fairer comparison would have been “iPhone Hello World vs Best practice WP7 Hello World”.

This is not to say there aren’t real missing features from the iPhone development environment compared to the new Windows 7 setup. Largely, this is down to Apple being conservative with the runtime features they provide for the iPhone OS. Partially, they’re feeling their way as they go. More importantly, they’ve been working on relatively limited hardware. The latest iPhone OS still supports the original iPhone, which had only a 412Mhz ARM CPU with 128Mb of RAM. Windows 7 will mandate a minimum of an ARMv7 Cortex/Scorpion with 256Mb RAM, giving the OS and application runtime a minimum of twice the memory and compute resource to play with.

If we compare against Cocoa/Objective C for OS 10.6, we see a lot of features that are waiting to be ported to the iPhone: Blocks (i.e. lambda functions for C), garbage collection, and API improvements. Given the ever progressing iPhone hardware (and new iPad), I’m expecting these shiny developer tools for iPhone 4.0 – personally, I’m voting for blocks, though a lot of people would prefer garbage collection). I’m also expecting Apple to keep forward porting Application Kit features that are currently missing – Cocoa bindings being the big one. With these, Interface Builder for OS X can build the “Hello World” desktop app without ever writing a single line of code (in fact, by typing only “Hello World” and “Hello” at the keyboard).

As a cross platform developer, I’ll continue reading the series with interest. I do hope, however, for rather fairer comparisons in the future.

EDIT: Woops, first version claimed there are, in fact, no missing features in iPhone development. Now clear that I’m not under RDF influence.


Feb 15 2008

Closing the Windows

Tag: Personal,ProgrammingAdam Wright @ 7:28 pm

After Windows Update toasted my Vista install last week (Twas impossible to login as the console,I could only recover by RDCing in and using System Restore), I bit the bullet and bought an iMac to use as my primary desktop. I’ll keep the Windows machine around for games and some development work.

Overall, I’m very happy (but then, I’ve been a Mac laptop user for years). The only problem is the TN panel screen, which has an annoying top to bottom gradient (some colours get very desaturated as you move down the screen). It’s not ideal, and less than I’d expect from Apple. However everything else is perfect, and as I’m no graphic designer, I can afford to live with it.

My first tiplet (which is no doubt very obvious to most people, and maybe even in the help files) is that you can save Automator workflows as application bundles. It’s significantly easier to achieve some small tasks (which don’t have control structures) with this mechanism – I currently use it to read me the RSS news headlines when the machine alarm goes off. Yes, this could be achieved with more traditional programming methods, but occasionally, graphical workflow tools are useful.


Feb 09 2008

Coarse classifications for bugs

Tag: Computer Science,ProgrammingAdam Wright @ 6:07 pm

As mentioned, some spare time at the moment is being spent investigating the mistakes other people make using the W3C DOM API. Having now looked at literally hundreds of separate bugs, I’ve begun to construct a coarse categorization for each. I don’t claim there’s anything novel here – in fact, most of us have these internal categories well defined. All I’m doing here is spitting out a semi-minimal collection of them, and giving each a title.

Some types of errors can be argued to fall into multiple groups – this is no bad thing. The idea, eventually, is to speak of how effective certain techniques are at preventing certain types of error.

Errors of ignorance
When you don’t know what you’re doing

A remarkable amount of bugs just boil down to raw incompetence. Harsh words, but in reality, we’ve all been there. Using languages and frameworks before we’ve actually performed some experiments, being thrown into fixing a problem in a system we’ve never seen before, being forced to render comment on a project before we’ve even seen a spec – all old stories for even the most talented developers. Errors of ignorance capture the problems you introduce in this state – using the wrong constructs, not knowing what frameworks actually do, and generalised language idiom failures.

Errors of expectation
When the outside world intrudes.

Most of the time, we’re dealing in some form with input in our programs. If we expect input in a certain format, and receive it in another, this is our fault – we need to be more robust. We might also think we’ll get input in a given format, but it’s subtly different.

We can also have expectations on what other people will provide for us, or the side effects they will have on the world. Any problems induced by our expectations differing from reality, I’m currently calling “Errors of expectation”.

Errors of omission
When you forget to handle something

Often, we know what we’re doing, we intend to do it, and then just forget – perhaps to handle an edge case, perhaps to release a resource. Our natural forgetfulness leads us into “Errors of omission”.

NB: This is currently my least favorite category, which I hope to kill off, but some bugs just fall into this group very naturally.

Errors of intention
When you just got it wrong.

These are what most people would call bugs – when the we, the programmer or designer, just get it wrong. Perhaps we thought the algorithm worked when it didn’t, perhaps our mathematics is just wrong, perhaps our expectations are mutually inconsistent. The code is doing exactly what we wanted – it is, in it’s way, flawless work. It just doesn’t do the right thing because, even having missed all the above classes of errors, we still didn’t know what the right thing was – we’ve committed an “Error of intention”.

This is my first attempt at a concise set of names to concepts I’ve been dealing with for years – it will be interesting to see how they evolve as I try and put it to use.


Jan 30 2008

Demons in DOM

Tag: Computer Science,ProgrammingAdam Wright @ 1:38 pm

At the moment, I’m spending spare moments collecting and collating idiomatic failures in Javascript (specifically, failures of DOM manipulation in Javascript). This is, alas, proving harder than I expected – bug database trawling is about as fun as it sounds and, more importantly, the bug databases don’t keep track of developmental bugs.

By idiomatic failures, I’m referring to common mistakes and patterns that cause errors. Suitable examples from other languages would be

  • In C, failing to account for the null string terminator
  • Buffer overruns, in C and C++
  • Off by one errors in pretty much every language
  • With C++, delete’ing a new[]’d resource
  • In PHP and many other scripting languages, failing to account for the weakly typed comparisons (so you forget that 0, null and the empty string are treated as semantically the same under comparison, but are distinct in your program logic).

These are the building blocks of certain types of program failure –often, when debugging, one of these type of error is the cause.

Of course, I’ve run into these many times myself, but that doesn’t really say much about the commonality of the problem; I may be a particularly poor programmer. So, I’ve been spelunking around bug databases for long running open source projects (i.e. the Javascript libraries behind Ruby on Rails); this is proving somewhat fruitful, but it’s a statistically invalid sample. As mentioned, the bug databases only tend to get populated by bugs in release versions, and then only the bugs that people have bothered to report. If a developer finds a bug whilst he’s developing, these are often not added – even if it took days to track down. Moreover, if they find a bug in a release version themselves, they often quietly fix it. Bugs that only occur rarely and are not repeatable are added almost never.

In a way, this is quite good – the failures I’m seeing are the ones that escaped testing, escaped the eyes of the developers, yet blew up in a users face. These are the hard to see bugs – the most annoying of the species. On the other side, this is quite bad – I miss a huge subset of bugs that fall into my class of interest.

Of course, these types of problems could be considered language defects – stupid mis-features that bite people again and again specifically because they are so artificial. After I have a relatively complete map of these failures, I’m going to move onto logical failures and failures of design that are common within Javascript/DOM – i.e. conceptual black holes that people are repeatedly sucked into, the actual failures of programmers.


« Previous PageNext Page »