JSButton: A simple way to pass blocks to buttons and trigger them with a UIControlEvent

My friend Josh Sklar (a senior at Michigan, and soon to be full time iOS dev at Detroit Labs) wrote a very cool subclass of UIButton that allows you to pass a block to a button and have it executed with a given UIControlEvent.

For example, instead of creating a ton of selectors, you can now simply do:

JSButton *buttonOne = [[JSButton alloc]initWithFrame:CGRectMake((self.view.frame.size.width - kButtonWidth)/2, kLabelHeight, kButtonWidth, kButtonHeight)];
    [buttonOne setTitle:@"Buton One" forState:UIControlStateNormal];

    [buttonOne performBlock:^(id sender) {
        JSButton *btn = (JSButton*)sender;
        NSLog(@"Some trivial code for touching up inside on %@", btn.titleLabel.text);
    } forEvents:UIControlEventTouchUpInside];

    [self.view addSubview:buttonOne];

Here is a link to the repo: https://bitbucket.org/jrmsklar/jsbutton

Advertisements

Large Social Networks are Doing Mobile Wrong.

Yesterday I had the chance to talk to a Twitter iOS engineer. Although this was part of my interview process, there was some time at the end of the call to discuss whatever I wished to. So, I went ahead and asked why they trashed a pretty fantastic iPad optimized version of Twitter to resort to a strange, stretched out iPhone version of Twitter for all iOS devices.

He responded with this:

  1. It was a struggle to maintain two separate implementations of the same app. Obviously Twitter wants to be able to offer the same great features in all of its apps, and it was very hard to consistently ship  the same features for the two different apps.
  2. New users who are less tech savvy were complaining about how confusing different apps were for Twitter.
  3. We want the ability to define what Twitter is more. Before we sort of let people use it for whatever they wanted, and now as new users join who are less familiar with tech, they want to know what they are signing up for .

This sounds very, very similar to the facebook mobile engineers who defended the use of html5 webviews in the iOS app until recently.

This way of thinking is just wrong for mobile.

The iPad and iPhone are different devices. The same applies for android tablets and phones. Tablets are not phones. With the extra screen space, there is an amazing amount of creative potential for developers+designers+product people.

Although it is easier for engineers to not worry about two separate code repos for the different apps, the end product takes a MASSIVE hit. The entire reason the iPad exists is to allow for a great way to interact with data with the large multitouch screen. If you really think that taking an app interface designed for a screen a 3rd or 4th of the size and just stretching it to fit is the best way for you to allow your consumers to interact with your service, then you are flat out wrong.

Yes, I realize this is not as efficient or logical as shipping a moderately nice app for all devices, but larger social networks need to realize that sometimes sacrificing business logic will produce a much better experience for end users and perhaps also result in happier engineers who are allowed to have more creative freedom in their products/products.