I started off with making it a decorator.. After 20′ I had to give up, because it was just too complicated to decorate objects where you don’t really know what’s going on. So I had to subclass it – unfortunately, but anyway..

Let’s take a look at what you would probably like to have..

Client

UIAlertTableView *alert = [[UIAlertTableView alloc] initWithTitle:@"Select Option"
    message:@"select option or create one"
    delegate:self
    cancelButtonTitle:@"Cancel"
    otherButtonTitles:@"Create", nil];
alert.tableDelegate = self;
alert.dataSource = self;
alert.tableHeight = 120;

And this should be the result:

Alright, so, we just add a UITableView to the UIAlertView as a Subview, right? Hold on, Tiger :)
First of all, if we set the message to nil, we want to have this:

And if we rotate, we want to have the nice effects! Like this:

Rotate Animation

If you only want to grab the code without BlahBlah: UIAlertTableView on Bitbucket.org (btw. I switched to bitbucket.org – but that’s another story)

So, let’s look at the code a bit:

UIAlertTableView.h

#import <UIKit/UIKit.h>

@class UIAlertView;

@interface UIAlertTableView : UIAlertView {
	// The Alert View to decorate
	UIAlertView *alertView;

	// The Table View to display
	UITableView *tableView;

	// Height of the table
	int tableHeight;

	// Space the Table requires (incl. padding)
	int tableExtHeight;

	id dataSource;
	id tableDelegate;
}

@property (nonatomic, assign) id dataSource;
@property (nonatomic, assign) id tableDelegate;

@property (nonatomic, readonly) UITableView *tableView;
@property (nonatomic, assign) int tableHeight;

- (void)prepare;

@end

You see: we subclass UIAlertView, we have a UITableView, we have a delegate which needs to implement the protocol as well as a dataSource. Straight forward, I’d say…

Now, as for the implementation, one would think: just overload the “show” method and insert the TableView as a subview etc. Well, that works – NOT. First of all: you have to resize your AlertView, then you have to move the buttons down and then you have to place the tableView somewhere (esoteric?).
OkOk, just overwrite the drawRect then? You are getting closer!
But, first, let’s have a look at the prepare method.

UIAlertTableView.m:prepare

- (void)prepare {
	if (tableHeight == 0) {
		tableHeight = 150.0f;
	}

	// Calculate the TableViewHeight with padding
	tableExtHeight = tableHeight + 2 * kTablePadding;

	tableView = [[UITableView alloc] initWithFrame:CGRectZero style:UITableViewStylePlain];
	tableView.delegate = tableDelegate;
	tableView.dataSource = dataSource;	

	// Insert it as the first subview
	[self insertSubview:tableView atIndex:0];
}

This code creates the TableView but does not set a real frame yet. It sets the given DataSource and Delegate. To be totally correct, there should be a custom setTableDelegate / setDataSource method which changes them in the tableView – but this is left as an exercise to the reader :)
After the creation, we insert the tableView as the very first subview of the alertView – so we know where to find it again and that nothing is hidden because of the tableView.

Now comes the tricky part: drawing.
For that, we use a private API call to the AlertView, called layoutAnimated:(BOOL)animated.
We overload it in our custom subclass because the initial drawing and the drawing on setNeedsLayout goes through that method.
After that method is called, all the elements that belong to the AlertView (title, message, buttons …) are arranged, so we can use those values for our next computations.

So, this is how it goes:

UIAlertTableView.m:layoutAnimated

- (void)layoutAnimated:(BOOL)fp8 {
	[super layoutAnimated:fp8];
	[self setFrame:CGRectMake(self.frame.origin.x, self.frame.origin.y - tableExtHeight/2, self.frame.size.width, self.frame.size.height + tableExtHeight)];

	// We get the lowest non-control view (i.e. Labels) so we can place the table view just below
	UIView *lowestView = [self.subviews objectAtIndex:0];
	int i = 0;
	while (![[self.subviews objectAtIndex:i] isKindOfClass:[UIControl class]]) {
		UIView *v = [self.subviews objectAtIndex:i];
		if (lowestView.frame.origin.y + lowestView.frame.size.height < v.frame.origin.y + v.frame.size.height) {
			lowestView = v;
		}

		i++;
	}

	// TODO: calculate this value
	CGFloat tableWidth = 262.0f;

	tableView.frame = CGRectMake(11.0f, lowestView.frame.origin.y + lowestView.frame.size.height + 2 * kTablePadding, tableWidth, tableHeight);

	for (UIView *sv in self.subviews) {
		// Move all Controls down
		if ([sv isKindOfClass:[UIControl class]]) {
			sv.frame = CGRectMake(sv.frame.origin.x, sv.frame.origin.y + tableExtHeight, sv.frame.size.width, sv.frame.size.height);
		}
	}
}

Step by step: first, we call the superclass - so everything gets arranged.
Then, we set a new frame for the AlertView, which is the same frame + tableHeight + padding. But we also need to rearrange the frame - which is half of that additional height.
After that, we compute the lowest "sitting" normal view - no control object - in the alert view. We loop through it, until we find the first control element - which are usually the buttons, because they are added at the end. You could loop through all views and get the lowest from any non-UIControl objects. But this works :)
This position is used to place the TableView at the correct position - whether you have a message, a title or whatever there.. but it needs to be above the buttons - UI standards.
To be above the buttons, we need to rearrange the buttons, and this is what happens: all UIControl object in the AlertView are moved down by the size we added to the AlertView frame - the complete TableHeight. And this is it.
We resize the AlertView, calculate the position where the TableView is supposed to be inserted at and then move the buttons. If we rotate, this gets calculated again and nicely rearranged.

Note: you can apply the very same method for any other UIView object you want to insert into an UIAlertView.. Be it TextField or ImageView or whatever. (For textField, you should use their private APIs though)

Again, code is here: Code on Bitbucket.org

I’m facing two problems with them though. First, I don’t know all of them – which is unfortunate. There are some I just cannot meet because they live in the south of Uguhagdarbia (not quite..) but there are  others which live in the very same city – Zurich – and I still haven’t managed to meet them.

Second, some of them just want to have an application before everyone else does – (no offense guys..) – and what I want in return is feedback – and not always get it. However, there are some very serious beta testers and I really want to thank you :)

This night, I had an insanly great idea to solve both problems at once and actually solve a third problem: get more testers :)

So what is it about? There have been rumors, that Transport will be ready at the end of march, and so I will need testers in the next few weeks.
This is why I proudly announce the “Beer for Issue” program :) What is that? My idea is: If you sign up until the 20th of march on beta[AT]codesofa.com with your UDID, name and e-mail (see Apply for Beta) and you are among the first 70 to sign up, then you get into the “program”. After that, you will receive a copy of “Transport.app” Beta for the iPhone somewhen after the 20th.

`HOLY CRAP WHERE IS THAT BEER!` – yes, we are coming to it. After that, you will receive instructions of how to report bugs/issues/whatsoever to me :) Since I really appreciate your time and haven’t figured out a way to show that to you, I offer Beer. Free Beer actually. :) The exact rules have to be determined after the signup is completed, but I plan to give out a beer for every fibonacci number of issues you report, starting at 3.. As long as they are not a duplicate. With “improvement” requests, I’m not so sure yet. That will be a mater of personal oppinion, if they are great, I’ll buy you 2 beers, if they are ridiculous, you’ll have to buy me 4 to make me implement it ;)

Let’s make an example: You report 3 issues – get 1 beer, 4 issues – still only 1, 5 issues (2+3) – get 2 beers, 6 & 7 issues – 2 beers, 8 issues – 3 beers etc. Maybe there will be more beer – I don’t know yet :)

`IS HE INSANE?!` – No, not at all. This will force me to write good code, so I don’t have to buy a lot of beers and besides that, I get to know all of you :) It’s like a release party.. But more fun because everyone worked on it..

In short:

• Write me an E-Mail with you iPhone/iPod UDID, your name and your e-mail address until march 20th, 2009 to beta[AT]codesofa.com
• Report issues on “Transport” iPhone app.
• Get paid in beer – and yes, for ladies there will be a special arrangement possible :)

Have fun.

btw.: There is some special ruling for the last testing-period testers, I will figure something out – but you’ll get more ;)

Why does this happen? Let me explain.

So far, I used the nearby search from Google to get a list of stations around you. Fairly simple. But.. SBB.ch does i.e. not understand “Bäckeranlage” but “Zürich, Bäckeranlage” which makes sense. But Google only provides “Bäckeranlage” – not so nice to map here. I’ve seen a comment in the AppStore from someone who noted this problem.. And he is right. This gave me a hard time.. [The fact that I'm in the exam session was no helpful either but nevermind :)]

How was the problem solved so far? With reverse geocoding. With the (great) API provided by geonames.org, I could more or less flatten this problems out. More or less? Yes. In the logs (Yes, sorry, I keep logfiles, but it’s to improve the query results, nothing more. I don’t see any IDs or sth. Just from where to where you are going and what method was successful for your query) I saw that a lot of requests for simple station names had to be handled by the “Google Fallback” – which is obviously not intended. This “Google Fallback” should catch up, when/if you search for an address or a POI (like Subway Restaurant Zurich). Why is that? Because the city mapping from Swiss Postal Service and SBB are quite different. I.e. there is a “Klein-Basel” in their database, where there is only a “Basel” on the SBB side. Then there are various ambiguous names, like “Bern / Liebefeld” which is also no hit on SBB.ch .. I guess you see the point.

Summary: Google returns list a stations which do not have the same name on SBB.ch which cannot alway be corrected because the reverse geocoder is not always “right”.

What do you do in your darkest hours? Yes, you ask your friends. There are friends. I’d call them “GottaGo”‘s Baywatch ;) I was looking for a solution. Since we plan to release the next iteration very soon and we need a lot of work to do. (Btw.: we is me and Stefan Sicher from sichr.com who is working on the new design like a crazy cow ;) – and no, that design from the last blogpost is not from him, that’s just a mock-design I used to illustrate the layout)

Again – solution. I asked the guys over at local.ch again to help me out. Guess what – they did. They didn’t even say “Yes, we will look into it” – no. Just “Yes, we do it. Just say what you need so I can do it _before_ holidays”. Really – how awesome is this? This will require a few more Horsepower to be squeezed out of my dear “gonzo” but it’s a real breath of fresh air – the light at the end of the tunnel ;)

So you might wonder, what they will provide me.. A lot. First of all: Station-names as on SBB.ch (really exactly the same) together with coordinates (WGS coordinates, they used CH1903 so far). Together with their superfast services and customized XML interface, this will free us from bloated information we don’t really need and exact information we really need.

Then there is autocomplete. I was really worried about that.. (Really really worried. I set this up on another server so I could do it with a different IP-Address in case SBB.ch would block this). I got full permission and a customized API to do autocomplete stuff on local.ch .. Again: superfast! (I know, SBB.ch does a lot more computing for that stuff, but it was really slow :))

As I read these lines, I wanted to tell Joel to bake a big cake so I could give it to the local team. For all those who asked me to open a Paypal account for donations or sth: abandon search.ch and use local.ch from now on! ;) that would result in a win – win situation for all of us :)

Again: I just want to thank you guys over at local.ch, namely Vasile, Patrice, Ebi and Joel for your effort. I hope the users will appreciate it as much as I do :)

First off: Language support. GottaGo will be available in english, german, french and italian. And as you see: A totally new UI. (The green disappeared! ;))

Then we have had one request to include Cabs.. Well, since I don’t want to waste my time on cars, I asked the guys over at local to help me a bit here. Thanks to the help of Tobias Ebnöther and Joel Bez of the local.ch team at Liip, this works like a charm.

And last but certainly not least, we have autocompletion. That’s the reason why the UI changed so much..

 
These are just the most significant changes. There are way more changes that you will notice. (Like track number.. But there will be _no_ track number for Zurich HB since this information is not available to me. (Try it on sbb.ch).

However, I cannot tell you about the exact release date. I’m having some exams the next two weeks, so I won’t have time to work a lot on this, but since I canceled release 0.0.2 (Dhaulagiri), this one might come around that time..

I want to thank you all out there for giving me many flowers and a few complaints. Makes working on this a little easier :)

The last few days, I’ve been browsing through the AppStore and I think it’s pretty cool, that 2 of the top 3 apps are not games in Switzerland. And as of the time of writing, neither is the number 1 app. In a lot of other AppStores, the games lead the rankings :) This might also change in the swiss AppStore in a few hours, but it’s cool that it takes a while..

Well.. I’ve been testing this Locator quite a while now. Today I had my final attempt, to find out, why I always got either a cached location or an extremely inaccurate location.

Today, I went out with my notebook (yes, there where the sun is..) to debug.

The example of apple says, to check the timestamp of the newLocation. (It should be less than 5..). Yeah well, guess what – it is sometimes 0 in a cached location. And somehow it’s sometimes just a bit over 5 and you’ll have to wait forever to get a new location.

- (void)locationManager:(CLLocationManager *)manager
    didUpdateToLocation:(CLLocation *)newLocation
           fromLocation:(CLLocation *)oldLocation
{
    NSDate* eventDate = newLocation.timestamp;
    NSTimeInterval howRecent = [eventDate timeIntervalSinceNow];

    if (howRecent < -0.0 && howRecent > -10.0) {
        [manager stopUpdatingLocation];

        // USE THE FORCE OF THE LOCATION!
    }
}

This one should work. Maybe that location stuff is working in the U.S. but it wasn’t in Switzerland..

P.S.: I had another issue with a pwned iPhone today. NSXMLParser throw me errors back and I didn’t know why.. I still don’t know why, I guess it had to do with the libxml2 update I did. Workaround? Restore, works fine now.

Since this is my most read blog article and it’s now 2 years old, one would think that things have changed, and they have.
2 Things: First, if you are free to choose between any API data representation, use JSON or plist, JSON is especially nice, because it’s very small and can be parsed with YAJL or TouchJSON.
And second, and foremost, please use something less painful.. like WonderXML – it really really helps. However, if you are still up to using NSXMLParser – go on reading..

For a demo on this, you may use http://svn.liip.ch/repos/public/iphone/MyBeer

As promised, here is a little How-I-did-it / How-To.

First off: I am not an experienced SAX-User.. So this approach might be packing the problem at it’s tail, but this is how DOM-Users feel comfortable with ;)

Let’s assume we want to parse the following XML:

tranist.xml

<root>
    <schedules>
        <schedule id="0">
            <from>SourceA</from>
            <to>DestinationA</to>
            <links>
                <link id="0">
                    <departure>2008-01-01 01:01</departure>
                    <arrival>2008-01-01 01:02</arrival>
                    <info>With food</info>
                    <parts>
                        <part id="0">
                            <departure>2008-01-01 01:01</departure>
                            <arrival>2008-01-01 01:02</arrival>
                            <vehicle>Walk</vehicle>
                        </part>
                        <part id="1">
                            <departure>2008-01-01 01:01</departure>
                            <arrival>2008-01-01 01:02</arrival>
                            <trackfrom>1</trackfrom>
                            <trackto>2</trackto>
                            <vehicle>Train</vehicle>
                        </part>
                    </parts>
                </link>
                <link id="1">
                    ...
                </link>
                <link id="2">
                    ...
                </link>
            </links>
        </schedule>
        <schedule id="1">
            ...
        </schedule>
        <schedule id="2">
            ...
        </schedule>
    </schedules>
</root>

In human readable format, this means: We have multiple schedules with from/to etc. These schedules consist of multiple links (different connections for the same route) with departure/arrival etc. These links consist then of multiple parts/sections with various elements which are not sure to be there..

With the let’s find the element called ‘part’ – approach, you won’t get anywhere..

The Basics

So what do we want to achieve? We want a list/array of Schedules, which have the given members. On member is a list/array of Links, also consisting of the given members and a list/array of parts with the respective members.

This is also the basic idea behind my approach: for every new node-container, use a new class/object (an array will also work, but it’s kinda crap..)

Now we have a Schedule class, a Link class and a Part class.

This is an example of the Link class interface:

Link.h

#import "Part.h"

@interface Link : NSObject {
    NSString *departure;
    NSString *arrival;
    NSString *info;
    NSMutableArray *parts;
}

@property (nonatomic, retain) NSString *departure;
@property (nonatomic, retain) NSString *arrival;
@property (nonatomic, retain) NSString *info;
@property (readonly, retain) NSMutableArray *parts;

- (void)addPart:(Part *)part;

@end

We use an accessor method for the parts, because it just feels better when dealing with arrays. (Instead of later using [foo.myArray addObject:..] we have [foo addMe:..])

Also we make it easier for us, using retain properties..

The Parser setup

A short introduction into SAX:

The parsing goes node by node and is not nesting-sensitive. That means that first we get root, then schedules, then schedule, then from, then to, then links, then link, then departure etc. As soon as the parser returns you the node for example, you don’t know anymore in what schedule you were. As long as you have a clearly defined structure where always every element must be present, you could do this using a counter, but as soon as you have multiple nodes with no defined count, you have a problem.

What we do is known as recursive parsing. What does this mean? We implement some kind of memory.

In our parser, we have 4 members and 1 method (to make actual use of the parser..):

@property (nonatomic, retain) NSMutableString *currentProperty;
@property (nonatomic, retain) Schedule *currentSchedule;
@property (nonatomic, retain) Link *currentLink;
@property (nonatomic, retain) Part *currentPart;
@property (nonatomic, readonly) NSMutableArray *schedules;

- (void)parseScheduleData:(NSData *)data parseError:(NSError **)error;

(Yes, this needs to be a NSMutableString..)

Your parseScheduleData method should look similar to the following:

parseJourneyData

- (void)parseJourneyData:(NSData *)data parseError:(NSError **)err {
    NSXMLParser *parser = [[NSXMLParser alloc] initWithData:data];

    self.schedules = [[NSMutableArray alloc] init]; // Create our scheduler list

    [parser setDelegate:self]; // The parser calls methods in this class
    [parser setShouldProcessNamespaces:NO]; // We don't care about namespaces
    [parser setShouldReportNamespacePrefixes:NO]; //
    [parser setShouldResolveExternalEntities:NO]; // We just want data, no other stuff

    [parser parse]; // Parse that data..

    if (err && [parser parserError]) {
        *err = [parser parserError];
    }

    [parser release];
}

Now we need those delegate methods.

- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName attributes:(NSDictionary *)attributeDict

- (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName

- (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string

- (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string

This function is called by the parser, when it reads something between nodes. (Text that is..) Like with blah it would read “blah”. It is possible, that this method is called multiple times in one node. As you will see later, we define the property “currentProperty” only if we find a node, we care about. That’s why we test it against this property to make sure, that we need this property. This will then look something like this:

Parser

- (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string
{
    if (self.currentProperty) {
        [currentProperty appendString:string];
    }
}

- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName attributes:(NSDictionary *)attributeDict

This is called, when the parser finds an opening element. In this case, we have a few cases, we need to distinguish. These are:

It’s standard property in the schedule (like <form> etc.) or it’s a deeper nested node (like <links>), the same for all the other nodes.

How to? We define, that we only set a member, if we are in that node. That means, only when we have entered a <part>, then currentPart is set, otherwise it’s nil. The same with the others.

We do then need to check them in reverse order of their nesting level.. Why? Because if we would check for currentLink before currentPart, currentLink would also evaluate to YES/True and hence we will have a problem if their are elements with the same name. If we aren’t in any node, then there is probably a new main node comming -> in the else..

When we hit a nested node, we need to allocate the respective member of our class, so we can use it when the parser gets deeper into it.

This will look like this:

Parser

- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName attributes:(NSDictionary *)attributeDict {
    if (qName) {
        elementName = qName;
    }

    if (self.currentPart) { // Are we in a
        // Check for standard nodes
        if ([elementName isEqualToString:@"departure"] || [elementName isEqualToString:@"arrival"] || [elementName isEqualToString:@"vehicle"] || [elementName isEqualToString:@"trackfrom"] || [elementName isEqualToString:@"trackto"] ) {
            self.currentProperty = [NSMutableString string];
        }
    } else if (self.currentLink) { // Are we in a
        // Check for standard nodes
        if ([elementName isEqualToString:@"departure"] || [elementName isEqualToString:@"arrival"] || [elementName isEqualToString:@"info"]) {
            self.currentProperty = [NSMutableString string];
        // Check for deeper nested node
        } else if ([elementName isEqualToString:@"part"]) {
            self.currentPart = [[Part alloc] init]; // Create the element
        }
    } else if (self.currentSchedule) { // Are we in a  ?
        // Check for standard nodes
        if ([elementName isEqualToString:@"from"] || [elementName isEqualToString:@"to"]) {
            self.currentProperty = [NSMutableString string];
        // Check for deeper nested node
        } else if ([elementName isEqualToString:@"link"]) {
            self.currentLink = [[Link alloc] init]; // Create the element
        }
    } else { // We are outside of everything, so we need a
        // Check for deeper nested node
        if ([elementName isEqualToString:@"schedule"]) {
            self.currentSchedule = [[Schedule alloc] init];
        }
    }
}

- (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName

Basically, the same things apply as for didStartElement above. This time, we need to clean things up and assign them if they are set :) This is a bit a pitty, since it’s a lot of code.. *(for not so much)

It’s the same checker-structure..

If we are in a deeper nested node (like <Link>) and we hit an ending element of that nested node (like </Link>), Then we need to add this element to the parent (like <Schedule>) and set it to nil

See yourself:

Parser

- (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName {
    if (qName) {
        elementName = qName;
    }

    if (self.currentPart) { // Are we in a
        // Check for standard nodes
        if ([elementName isEqualToString:@"departure"]) {
            self.currentPart.departure = self.currentProperty;
        } else if ([elementName isEqualToString:@"arrival"]) {
            self.currentPart.arrival = self.currentProperty;
        } else if ([elementName isEqualToString:@"vehicle"]) {
            self.currentPart.vehicle = self.currentProperty;
        } else if ([elementName isEqualToString:@"trackfrom"]) {
            self.currentPart.trackfrom = self.currentProperty;
        } else if ([elementName isEqualToString:@"trackto"]) {
            self.currentPart.trackto = self.currentProperty;
        // Are we at the end?
        } else if ([elementName isEqualToString:@"part"]) {
            [currentLink addPart:self.currentPart]; // Add to parent
            self.currentPart = nil; // Set nil
        }
    } else if (self.currentLink) { // Are we in a
        // Check for standard nodes
        if ([elementName isEqualToString:@"departure"]) {
            self.currentLink.departure = self.currentProperty;
        } else if ([elementName isEqualToString:@"arrival"]) {
            self.currentLink.arrival = self.currentProperty;
        } else if ([elementName isEqualToString:@"info"]) {
            self.currentLink.info = self.currentProperty;
        // Are we at the end?
        } else if ([elementName isEqualToString:@"link"]) {
            [currentSchedule addPart:self.currentLink]; // Add to parent
            self.currentLink = nil; // Set nil
        }
    } else if (self.currentSchedule) { // Are we in a  ?
        // Check for standard nodes
        if ([elementName isEqualToString:@"from"]) {
            self.currentSchedule.from = self.currentProperty;
        } else if ([elementName isEqualToString:@"to"]) {
            self.currentSchedule.to = self.currentProperty;
        // Are we at the end?
        } else if ([elementName isEqualToString:@"schedule"]) { // Corrected thanks to Muhammad Ishaq
             [schedules addObject:self.currentSchedule]; // Add to the result node
             self.currentSchedule = nil; // Set nil
        }
    }

    // We reset the currentProperty, for the next textnodes..
    self.currentProperty = nil;
}

Finally..

Well, that’s it. You can expand / shrink this principle as you like. You can also add a maxElements counter, like in the SeismicXML example of the iPhone SDK to get only a certain number of elements. You can abort the parser with [parser abortParsing]; It is important, that you don’t abort while in a deeper nested node, because this could lead to inconsistencies. You will need to skip them..

Please note, that I wrote this, while watching TV, so you may need to fix some syntax errors ;) But I hope you get the idea..

I had to modify the online service, since Google and SBB don’t always play nice together. Example? Hmm.. Google thinks, that there is a station named Rathaus, but SBB thinks, there are many many stations called Rathaus.. So I needed reverse geocoding for that. I did my own implementation with Google-Maps – but I cannot open it to anyone since they kinda don’t like that ;) I may publish the source though, I guess.

The next thing was, was to harden that thing – make it foolproof. Not an easy task, you say? Well, I gave it my grandfather for testing, he clicked things I would never click and that’s how I found a few more issues – I think this should be best practice ;)

Another thing I noted was that I fetch a ton of information I didn’t use.. like the vehicle and stuff. So the sections are now implemented as well.

So much about `software is done’

The reason why I made this entry at all is:
– GottaGo is now ready for beta testing.. 

That means I may invite 100 users to try out gottago without waiting for the AppStore release it.
 

What do I need/you need to do?

You’ll need an iPhone. (first and second gen will work). iPod touch may also work, would be nice to have a tester.

I need your e-mail address – like in non-spam-e-mail address.
Then I need your UDID/Device Id of your iPhone.. this is a tricky one :) Either you are an iPhone developer and you know how to find it or you can try the following:

1. Connect your iWonderTouch with iTunes
2. In the Summary tab, click on the label “Serial Number” (yes, move your mouse over the “Serial Number” text and click!).
3. The “Serial Number” label should become “Identifier” and the ID should get longer ;)
4. You may screenshot this ID or type it into the e-mail by hand.. UPDATE: As Marc Liyanage noted in the comments: Just hit cmd-c after you see the identifier and paste it wherever you want it.. (thanks!) :)

Should be it. Just send it to: m.m.ammann@gmail.com or leave a comment below. I will send you further instructions like our bugtracking system and stuff.

So, what kept me from submitting to the AppStore?
Well, first of all I had to get my hands on a JesusPhone.. One I could work with. – Done -

You might say – there is a Simulator, the phone should be a small stage for the final testing. Yes, that’s what I thought.

Apparently, Apple allowed system libraries to be compiled into your software, while using the Simulator. Well – and since NSXMLDocument is not included in the final build of the SDK – I’m quite frankly – doomed now when I try to compile on the iPhone.

My options now are:

• libxml2 wrapper:
  • fix the iconara to work with iphone (linker errors)
  • write my own (jeeez)

• use plain libxml2:
  • spaghetti code
  • wheee

• use my own webservice to aggregate and send a small xml and parse via NSXMLParser (SAX):
  • sbb might block me for too many requests
  • bottleneck
  • yet another system that may fail

I think I’m going with the own webservice. It doesn’t feel right though. I think in a device that powerful, there should be a simple implementation of the DOM. I see the iPhone as a mobile device which should profit as much as possible from different webservices and cache only necessary things. Obviously Apple is more concerned about OpenGL(-Games) than about web-service access.

If there is a libxml wizard out there, feel free to contact me :)
I’ll try to focus on libxml for some additional hours and if there is no hope, I’ll set up my own webservice. I hope I’ll be able to submit GottaGo to the AppStore this weekend.

And to clear some things up:

• GottaGo will be free of charge
• GottaGo will only work in Switzerland for now

UPDATE Well.. After some hours of hacking, I was able to put GottaGo on my iPhone in a light-version. That means: location tracking and station finding, but no SBB querying for now. For SBB, I will probably have to proxy the requests since their response html is not even valid html.. But now there is some pressure on my shoulders. I was able to submit to AppStore. The requested release day is: July 19, so stay tuned :)