tweet @echoz email jeremy@ornyx.net
My recap of WWDC10.
Just about a month ago prior to WWDC10, I made the decision to drop any web development and concentrate on native development for the OS X platforms which include the iPhone and the Mac.
Since then its been a whirlwind with many opportunities presenting themselves. Sadly I can’t take any offers to join companies due to issues with my Scholarship. That being said, freelancing and consulting generally works out to be alright.
Right now, I’m currently engaged in a project so I won’t be free to handle anything during these few months. Still, drop me an email if you have something that comes after that.
(I so have to update this page.)
A year back, I attended my first WWDC. It was a fantastic experience and upon coming back, I set to create an iPhone app as a precursor to starting development on the Mac.
Now the inspiration simply came from splitting the bill with friends when we went out to eat. I set to create a replica of an actual check and gave an iPhone user the power to accurately get the amount payable per person based upon the numerous taxes and weird charges that local eateries have.
It was an exciting time, I came up with concept art, I coded, I designed. Then reality set in and school consumed me. I had interesting ideas about the input methods and various other functionalities.
I never really did get to it ever again despite getting numerous prompts from friends to continue. I knew it had potential.
So when I was working on Traversity, I told myself it’ll be the next project once its done. Next because at that time and now, I know more than I used to, having pushed out a Mac app as well.
Then I found out about BistroMath.
The feeling was bittersweet. It was exactly the same idea, with a better UI. It was however something I am confident of coming up with if I had more time. I bought the app and spent some time playing around with it and was absolutely blown away by the whole thing.
It is simple, elegant and gets straight to the point. It was the whole thing I was writing about functional design. I loved the category selection. I loved the way you select and add other people to split the check with. It was genius. The intuitiveness of the whole process should not be underestimated as well. It is a fantastic product.
I’m happy that they didn’t butcher the idea. And sad that it wasn’t me that saw to its completion. So I’m dropping Go Dutch. Not really a point in duplicating features when they have such a sweet implementation.
I emailed the guys who worked on it with congratulations as well as a note to say that I’ve had something similar brewing in the works too. Daniel was nice enough to reply and I really hope to meet up with them come WWDC10.
Congrulations BlackPixel for shipping BistroMath. It rocks as much as I envisioned mine. :)
So yesterday Apple finally approved Traversity after 2 weeks in the App Review process. My education with regards to developing and deploying an app on the iPhone platform is more or less done. Save for bugfixes and feature improvements, Traversity should be on hold until I get the next app out.
Still, important lessons were learnt and it was a worthy project as a first foray into the whole thing. Go Dutch was not such a good platform, but I’ll save that for later.
So what did I learn?
It was a fun experience nonetheless and I will be applying what I have learnt into the next app that I’m planning.
There’s this curious thing about working on Xcode.
I’ve never seen myself, upon finishing a project, go immediately back to the IDE and start on a new one. Has never happened to me back in my Windows days with Visual Studio 5.0, 6.0, .Net and what not. Has never happened to me with NetBeans and whatever other incarnation of a Java IDE for school.
Maybe its just being a fan boy, but seriously, an IDE? Comparing Xcode to something that is more featured and complex like Visual Studio, you get a feel that Xcode is not truly in the the same game.
Hell, for newbies going to Xcode for the first time, its the most unintuitive POS ever. And yet, it still is a joy to work on once you get the hang of it.
I sometimes think, Objective-C has a part to play. But I can’t be sure.
Its official, just got my WWDC10 ticket activated.
Will be in SF from the 4th to the 13th of June, so for people who want to meet up, hit me up then. Twitter (@echozdevdiary) is fine to leave messages. I’ll try my best to get back to you.
This is the idea. To have an application that does signature matching via regular expressions while also being able to update the signature remotely. This method makes exclusive use of RegexKitLite because libicucore is bundled with Mac OS X as well as the iPhone OS.
Presenting JOSignature. This version just implements NSCoding so you would have to call the serialization and deserialization yourself in order to rebuild the signature object.
#import <Foundation/Foundation.h>
#import "RegexKitLite.h"
@interface JOSignature : NSObject <NSCoding>{
NSString *regex;
NSDictionary *regexmap;
}
@property (readonly) NSString *regex;
@property (readonly) NSDictionary *regexmap;
-(id)initWithRegex:(NSString *)exp map:(NSDictionary *)map;
-(NSDictionary *)match:(NSString *)string;
@end
@implementation JOSignature
-(id)initWithRegex:(NSString *)exp map:(NSDictionary *)map {
if (self = [super init]) {
regex = [exp retain];
regexmap = [map retain];
}
return self;
}
-(id)initWithCoder:(NSCoder *)aDecoder {
if (self = [super init]) {
regex = [[aDecoder decodeObjectForKey:@"regex"] retain];
regexmap = [[aDecoder decodeObjectForKey:@"regexmap"] retain];
}
return self;
}
-(void)encodeWithCoder:(NSCoder *)aCoder {
[aCoder encodeObject:regex forKey:@"regex"];
[aCoder encodeObject:regexmap forKey:@"regexmap"];
}
-(NSDictionary *)match:(NSString *)string {
NSArray *matchedgroups = [string arrayOfCaptureComponentsMatchedByRegex:regex];
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
for (int i=0;i<[matchedgroups count];i++) {
[dict setValue:[matchedgroups objectAtIndex:i]
forKey:[regexmap objectForKey:[NSString stringWithFormat:@”%i”,i]]];
}
return dict;
}
-(void)dealloc {
[regex release];
[regexmap release];
[super dealloc];
}
@end
So how does this work? libicucore doesn’t let you do named capture groups, so we implement our own mapping dictionary to map the appropriate capture group to its property name. Additional extensions to this could be simple things like init’ing it with the remote serialized plist itself.
Working on a new project. Using stuff learnt from the initial work on Traversity. Namely the process where creation of the data model and associated libraries are done first and foremost before connecting up the GUI.
As a usual practice, the library will be open source. No sense creating something that no one else will use. Check the progress on Github.
This should be fun.
Too often we get too caught up with features and frameworks available to us that we go overboard with using everything. There are many developers that overuse custom user interface elements, and others that misuse system user interface elements.
When I was developing Traversity, I was looking around to see how best to make the App look good. Of all the Apps on my iPhone, one that stood out the most was Tweetie. It was simple, thoughtful and very Apple-esque. That was where it hit me that the thoughtful or lack of usage of custom elements provides an infinitely better experience. That is unless you are Bjango or Tapbots.
Instead of throwing all your custom elements onto your app to showcase your design prowess, consider that perhaps user experience is more important than just plain aesthetic appeal. A picture is still a picture unless it does something after all.
Apart form following Apple’s guidelines, there are some additional things that should matter when thinking about design for iPhone applications.
You don’t have to be an design god to make applications that work fantastically. Even little tweaks can help immensely.
App Store approval has always been a controversy. So much so that Apple has devoted a small 230x190px space buried under “App Store Approval Process” in the developer portal to telling you the percentage of apps that were approved within a 7 day period.
We have OpenRader to track bugreports, so why not a community drive initiate to get better approval ratings. Last I checked, the percentages on that small space was updated on the 20th of April. 2 whole weeks ago. Or more.
I suppose there would be some way to push baseline data by having dev submit a html page of their status history for submissions. That way the system can parse and get the average rate of approval thus far.
Apply a little magic for applications still currently in approval and we could get a very up to date picture of how long apps might get approved.
Separate by new app submissions and updates and we would have a fantastic idea of how long everything takes.
And with everything, there are more things that can be done with such an idea.
