Why do you need a Tapulous account to use Twinkle, and what exactly is it.?

Well, the reason is we’re building a network, and using Twitter as the first of many gateways. Many people have heard of or know this concept as “friendfeed.” We’re shooting for nothing less, and are planning for the future by supporting multiple accounts. We want to do certain things that friendfeed isn’t capable of, like hosting pictures for our Twinkle Shots, or embedding location information into tweets like we do for our Nearby tab. Neither of these features would be possible or anywhere near as seamless had we not made the decision to build our own network, with Twitter as the first service.

What we don’t want to do however is pick favorites. This means that even if some other service (if one exists) supported image attachments AND locationing, it still doesn’t have the number and activity of users from Twitter. So, we went where the users are with Twitter as our first network.

What many people want is just a Twitter client, and I’m sorry to say as a basic design decision, that’s just not what Twinkle is or is meant to be. You’re welcome to use it as a dedicated Twitter client and we’re trying really hard to make it a first class client for nothing but. We aren’t there yet, and I’m happy to see all the suggestions and feedback pour in. I’d like to address a rather common one which is: Why can’t you disable the Tapulous “stuff”? Well, we didn’t get time to do that! It’s definitely a popular request, and we need to consider how that will impact the application for one very important reason: Twinkle’s Nearby view depends on Tapulous network integration. If everyone just decided to turn off the “Tapulous account” features, no one would see a thing in Nearby! I think what a better solution might be is to simply have all twitter information (avatars, user names, pretty names, etc) take priority over the Tapulous network information, should you choose to do so. We believe this is an ideal solution but one that takes time unfortunately. Consider now we’ve heard everyone’s complaints, and we will address them in due time.

What do you do with my messages after you send them? Are they on your servers too?

The answer is yes, they are. In order to host nearby messages, and for features like our automatic tweet queuing while Twitter is down, we need to store your messages on our server too. The caveat to this is we need to support Twitter’s private profiles, which we do not yet. This is a known and unfortunately overlooked issue.

What about feature X, Y, Z?

We’ve taken a look at the most requested features, and we’ve already planned on implementing of few of them. Built in web browser. This one’s a highly requested, and particularly useful feature on a mobile app where bouncing between two applications is a painful process. Clickable @replies. This feature was actually in the client for awhile, but just didn’t make the cut due to time so we had to take it out. The notification sounds are too jarring/loud. This was a large complaint, which we’ll remedy.

Not all of this may make it into the next release, but this is just a few of the things we’re working on.

Person *person = [[Person alloc] init];
person.mobileNumber = @"1-555-123-1234";

This is uber nifty, and can save you a load of time and redundant code. However it’s often the case that I want to hide access to certain private member variables, but still expose accessors/mutators to attributes on those private variables. Let’s say mobileNumber is actually an accessor/mutator on a sub-object, let’s call it PhoneBook. Under the hood, this is implemented like so:

@interface Person {
    PhoneBook *phoneBook;
}

@property (nonatomic, rertain) NSString *mobileNumber;
@end

@implementation Person
- (void)setMobileNumber:(NSString *)number {
    phoneBook.mobileNumber = number;
}

- (NSString *)mobileNumber {
    return phoneBook.mobileNumber;
}
@end

This seems far from ideal, when really I just want to pass through the implementation of this accessor/mutator to one of my instance variables. A more clean and hypothetical implementation could look like this:

@interface Person {
    PhoneBook *phoneBook;
}

@property (nonatomic, retain) NSString *mobileNumber;
@end

@implementation Person
@synthesize mobileNumber=phoneNumber.mobileNumber;
@end

Broken iPhone
Originally uploaded by tristanotierney

So awhile back (just after macworld) Quynh’s iPhone mysteriously cracked. We didn’t drop it, we didn’t step on it, it just spiderwebbed in the corner for no apparent reason. Needless to say we were hesitant to take it to an Apple genius because anything involving what appears to be user-inflicted-damage is shrugged off. Well, we were browsing the mall today and said screw it lets give it a try. 20 minutes later we were blessed with a brand spanking new phone! I had a similar experience with Ikea, in which we actually brought in an photo of a broken drawer shelf (on our iPhones of course) and they didn’t even ask questions! They just went into the back room and gave us the new board we needed to repair the drawer. Not to go off into too much of a tangent, but I think these two companies share a lot in common.

Frankly I wasn’t quite surprised that they chose not to make a Windows compatible SDK. The entire iPhone development suite, from building tools (gcc, xcode, ib) to debug tools (instruments, which depends on dtrace) are just entirely incompatible with Windows. Even if Apple did keep Yellow Box alive in secret, it would be a monumental effort to port all those tools. So I guess that’s that — in order to code for the most popular mobile device within the next few years, you’re going to need a Mac. If that doesn’t pull in a whole new class of switchers, I don’t know what will.