Categories
Apple Cloud Development

iCloud vs. Dropbox

Dave Winer tweeted something today that got me thinking, so instead of tweeting back and forth with him about it I thought I’d jot my thoughts here. Twitter is pretty horrible for discussions.

In response I pointed out that Dropbox and iCloud are different because Dropbox is a file syncing service and iCloud goes beyond that. If you’re a Mac or iOS developer you can sync portions of files to iCloud along with your application settings. Apple created this as an extension of their ecosystem. As a developer you can have automagic syncing for your applications, if you choose.

Of course I misunderstood Dave’s point. His concern is lock in.

Ah, now I see what he’s referring to. Apple has created a walled garden for applications built on their platform. It’s absolutely true. Another concern of Dave’s is the inability of iCloud to share your files outside of applications.

Once again, Dave is absolutely correct. There is no way to get at your content in iCloud if you’re not using an app that implements iCloud API’s. Oh, there is support for Windows, did you know that?

iCloud for DevelopersHere’s the deal. With iCloud Apple allows you to open your document, stored in iCloud, in your local application, make changes, and those changes can/will be sync’d back to your other devices. Here’s the difference as I see it. Dropbox is an extension of the filesystem on my local computer, iCloud is an extension of my application. Subtle, yes.

I’m having a difficult time getting to the difference because it is so subtle. Imagine if you have a Pages document open on your Mac and on your iOS device. You’re making changes on the Mac and you walk away. Those changes will get pushed to your iOS devices without saving the document. As far as I know you cannot do this with Dropbox. Dropbox will sync an entire file, not portions of a file.

Minor difference, but a difference none the less.

How about this. Dropbox allows me to see all my content via the web and my local filesystem has a copy of the documents. It’s absolutely perfect in that way. What about editing? Can you go to Dropbox.com, log in, and edit a binary Visio drawing? No, you cannot. With iCloud we get this feature via apps. Again, it’s avery subtle difference, but it’s something Apple is very fond of.

I’d imagine once Apple can solve these types of issues we’ll see a more open iCloud, until then, if you’d like a great file syncing solution Dropbox is a better choice than iCloud. If you’re after great integration iCloud may be your best bet, although some applications have done a great job using Dropbox as their syncing solution.

In the end syncing of files across multiple computers is a very difficult problem to solve and Apple is just beginning to address the problem. Dropbox has created a very elegant full file syncing solution. Both are useful.

Oh, one more question. I almost forgot to ask this. If Apples’ iCloud is a lock in, which I will not argue, how is being tied to Dropbox not lock in? I would consider it lock in. To me what’s freed us from lock in are open protocols, like HTML, or RSS. They are part of the fabric of the internet and completely open. I can modify HTML with any application that can read, write, and modify simple text. Definitely no lock in. If Dropbox created an open protocol for syncing of files, that could be implemented by anyone, and their client application, as well as anyone else’s, could communicate with any server that implemented that protocol, I’d say it wasn’t lock in.

A stretch? Maybe. But we are, after all, talking about subtle differences.

Categories
Development Indie iOS

Craig Hockenberry on Twitterrific 5 Development

Craig Hockenberry: “What happened next though, surprised us in a very good way. David started using Xcode.”

I love stuff like this. It’s neat to see how folks approach development inside their shop. Most of the post is not surprising. Their approach is the same as every development shop I’ve ever worked in. Divide and conquer where it makes sense. He didn’t go into their unit test process, but does mention he was able to test his code with his own test application. This is important and mostly overlooked by most developers.

A wonderful boquet of flowers.Like I said, it’s mostly basic stuff and common practice, until you come to the line I pasted above. THEY GOT A DESIGNER TO USE XCODE! That’s amazing and it looks like it allowed them to move their application forward without interrupting the developer or frustrating the designer because the developer was too busy to be fussed with a tweak to the UI.

When I’m coding I like to get the basics in place and skin later. It’s easy to do, why not give it a bit of time before you go off and do it, right? Well, if you can get a designer to do the work, why not? It’s a brilliant idea and UIAppearance seems to make it even easier to deal with this kind of stuff. I’m looking forward to using it some day.

Craig also mentions another thing I really love about The Iconfactory.

“We are well aware that people are going to complain about missing features: push notifications and streaming are obvious examples. But so are trends, and video support, and in-line photos, and… well none of that matters. We believe in building opinionated software.

I love that. They managed to build a client that is perfectly suited to how I use Twitter and they did it by building it how they would use it.

The Iconfactory is definitely one of those shops I’d give my left arm to work for. True story.

Categories
Development

Making Twitter post to App.Net

AHHHHHH!Steve Streza: “Today I shipped the first alpha of Apparchy, which turns Twitter’s official iOS apps into App.net clients. You sign up for a free account on apparchy.net, add your app.net account, and then log into the Twitter app with your Apparchy username and password. Then, the Twitter app will start loading data from app.net through the Apparchy API.”

This is a nifty trick. A very appropriate hack for a hackathon. Steve has made Twitter’s own client post to App.net. It’s not as difficult as one might think because of a legacy feature remaining in the official Twitter for iOS, and I believe Twitter for Mac, clients.

It’s interesting to note that Twitter has allowed Twitter for Mac to die. If this works with the Mac client it just breathed new life into an otherwise dead piece of software. Well done.

The big question is, when will Twitter shut this down? One week, two? It won’t take long before we see a new drop of Twitter for iOS in the App Store with this feature removed.

It’ll be interesting to see if they ship another release of Twitter for Mac just to turn this off.

Until then, enjoy!

P.S. – Does this mean Twitter’s official client is breaking the Display Requirements?

Categories
Development Mobile

Choosing Native

Links the kitty!Andrey Butov: “The people who really seem to benefit from using the abstraction layers are web developers who aren’t comfortable with native code (C/C++/Obj-C/Java), but who are very strong in Javascript/HTML5/CSS. I’m not in that camp, so having to skip a native-code implementation, in favor of Javascript, would actually be a disadvantage for me, rather than a benefit.”

Andrey does a great job of sharing some of the reasons it’s best to choose a native platform over something like Titanium.

I guess we all go to our comfort zone when it comes to life, and that holds true for software developers as well. I prefer to use the platform tools, so I have a history of writing in C, C++, and now Objective-C. Yes, it’s painful to learn a new platform, but I think it’s worth it.

UPDATE (8/26/2012, 2:20PM)

Branch: A Blow To HTML5: “Facebook has now largely moved away from HTML5 in favor of native Objective-C code with their new iOS apps. And the results speak for themselves. Facebook had been one of the companies that most vocal in their support of HTML5 as the future of everything. The apps suffered as a result. And now they’re changing their tune. Is HTML5 still just not ready for prime time? At least on mobile?”

HTML5+JavaScript is never going to be as fast as a native application. I think it depends on the goals for you application. If you’re ok with a lowest common denominator experience, a web site will do just fine. If you need a rich, interactive, experience you may want to create a native application, especially on mobile. When I use my desktop I don’t mind visiting website based services as much. I think it comes down to screen real estate and I can easily switch away from the site and dow something else, while it loads.

I guess the bottom like is, I believe native is a better choice, at least for the foreseeable future.

Categories
#twitter Business Design Development Social

Twitter Display Guidelines

A wonderful boquet of flowers.In the wake of the new Twitter 1.1 API changes announcement I thought I’d focus my attention on the Twitter Developer Display Guidelines so I can understand the changes I’ll see to my favorite Twitter client; Twitterrific.

The guidelines will make our Twitter experience more consistent, boy howdy. Basically every Twitter client will look pretty much the same or it won’t be allowed to use the Twitter API, and a client that can’t use the API is useless.

Please note, if you’re using a Twitter provided client, these rules don’t apply, so you have nothing to worry about.

How do the various clients display Tweets in the Timeline? See the Timelines section in Display Guidelines.

Twitterrific

Twitterrific is my favorite client because it’s darned simple, great UX and UI design. Twitterrific is unique amongst the three clients we’ll examine because it shows a reply icon in every tweet. Note the arrow in the lower right corner of the image. Tapping on that icon will display a menu of choices that includes Reply, Direct Message, Retweet, and Retweet with Comment. Not even Twitter’s native iOS client provides this functionality.

Twitterrific: What needs fixing?

I use the term fixing loosely. Here is a list of the rules Twitterrific breaks, according to the Display Guidelines.

  1. Tweet Author
    • The user’s name and @username should be displayed on one line, with the name first.
  2. Retweets
    • If the Tweet being displayed is a Retweet, the name of the user who Retweeted it and the Retweet icon must be displayed under the Tweet text. e.g. “Retweeted by Josh Brewer”. The name should link to the the Retweeting user’s profile [1].

The @username doesn’t appear in the tweet and the retweeted by text doesn’t show below the tweet. It’s not seen here, but the retweet text displays to the right of the users name. One of the great things about Twitterrific is how it displays tweets in different colors depending on the context of the tweet. I’m not sure how Twitter will feel about that, but the guideline doesn’t call it out.

That’s not so bad, but it does mean Iconfactory will need to fix some things.

Tweetbot

Tweetbot: What needs fixing?

  1. Tweet Author
    • The user’s name and @username should be displayed on one line, with the name first.
    • The avatar must be positioned to the left of the name, @username, and Tweet text.
  2. Timestamps
    • Tweet timestamp should be displayed in the top right corner.
  3. Retweets
    • If the Tweet being displayed is a Retweet, the name of the user who Retweeted it and the Retweet icon must be displayed under the Tweet text. e.g. “Retweeted by Josh Brewer”. The name should link to the the Retweeting user’s profile [1].

Tapbots has a bit of work. In most cases the users avatar is displayed in the proper position, unless its your tweet, then it’s on the right. That’s an easy fix for them. Once that is fixed the timestamp will move to the proper position in the upper right corner. The Retweets item is interesting. The rule states it should display the name of the user who retweeted it. Tweetbot does that, sort of. If the retweet was by you it displays “Retweeted by You”, which doesn’t fit the rule to the letter.

Twitter

Twitter: What needs fixing?

  1. Retweets
    • If the Tweet being displayed is a Retweet, the name of the user who Retweeted it and the Retweet icon must be displayed under the Tweet text. e.g. “Retweeted by Josh Brewer”. The name should link to the the Retweeting user’s profile [1].

Not surprisingly Twitter does the best job of following the rules, but they do break this one. In the Twitter iOS client a retweet icon is display in the upper right hand corner of the tweet and the user’s name isn’t displayed.

Random Note

In the Individual Tweet section under the Branding bullet point this is listed.

The Twitter logo or Follow button for the Tweet author must always be displayed in the top right corner.

Emphasis on the word Tweet is mine. Twitter didn’t coin the term “Tweet”, the fine folks at Iconfactory did.

EOL

Categories
Development

My next text editor

My next text editor, is my current text editor. It doesn’t suck.®

‘Nuff said.

Categories
Design Development

What He Said

Dave Winer: “Working with computers isn’t conducive to a whirlwind approach. You really can’t do writing, design or development work inbetween crazy-busy-life tasks. Computers don’t lend themselves to that kind of thought. You often don’t find the problem till you have a chance to quietly and dispassionately go through the situation, asking all kinds of questions along the way. It’s been observed many times that the problem often turns out to be something dumb that you overlooked. That’s exactly the kind of thing you can’t see when you’re whirling around. “

When it comes to coding I tend to stare at the screen for a long time before writing a line of code. Often I create experiments and throw them away before doing the real version. It’s not always like that, I usually do that when I’m trying something new, but work like that takes uninterrupted time.

I think Dave really nailed it.

Categories
Business Development

The Sparrow Acquisition Is A Good Thing

A wonderful boquet of flowers.Selligy Weblog: “This is not a good trend for Apple. Apple is depending on apps like Sparrow to make the iOS platform shine. Excellent apps like Sparrow cost a lot of money to build and maintain. Apple should be working hard to ensure independent app developers can earn even more than top salaries at Google, or they will all be poached away.”

Why should, or would, Apple care about keeping developers around? If someone walked up to me with a big pile of cash and wanted to acquire my popular, or unpopular app, and I felt it was a good thing, I’d do it in a heartbeat. So would a lot of people. This is the American Free Market at its best. A company puts together a group of talented people, creates a product people love, and gets the attention of a bigger company. That bigger company comes along and gobbles up the talent. Sure, as a user of Sparrow you may be a bit bummed, but it won’t last for long. As a little guy just getting started this is an opportunity. It means if I wanted to, I could pick up where Sparrow left off and create a great email client that looks and acts just like it. Filling that hole. Heck, maybe I’ll do something MUCH better. It will happen.

I have a feeling there is a company, or individual, out there today, slinging code in hopes to bring a new Sparrow-like client to life.

That’s pretty exciting.

Categories
Development

Revisiting Objective-C, REST, and JSON

I get a lot of hits on this site for two posts.

  1. Objective-C REST and JSON
  2. Objective-C Objects from JSON

Both posts touch on using JSON to create Objective-C objects. The first one mostly talks about great Cocoa Libraries you can use to make REST calls and parse JSON results.

Since that time JSON parsing has become a part of iOS. In iOS 5 Apple introduced NSJSONSerialization.

For a presentation on REST and JSON to @NSSLO back in May I created a super simple project that used NSURL, NSMutableURLRequest, NSURLConnection, and NSJSONSerialization to call the iFixIt API.

If you’re interested in grabbing the project, it’s available on GitHub.

Will write C/C++ for food

The Code

Most of the RESTTest project is a boiler plate iOS application. There are a couple places in MasterViewController.m you should pay attention to and we’ll take a look at the iFixItBadges and the iFixItBadge classes.

The Basics

To get the ball rolling we make a call to a private method: getBadges.

- (void)getBadges; {
	NSURL *url = [NSURL URLWithString:@"http://www.ifixit.com/api/0.1/badges"];
	NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url
                                                           cachePolicy:NSURLRequestReloadIgnoringCacheData 
                                                       timeoutInterval:10];
	if (request) {
		[request setURL:url];
		connection = [[NSURLConnection alloc] initWithRequest:request delegate:self];
	}
}

This method is pretty straight forward and uses three of the four classes we mentioned above; NSURL, NSMutableURLRequest, and NSURLConnection. That’s all it takes to do a simple(REST) HTTP GET call. Yes, it’s sample code, so it’s not complex and is not something you’d find in a shipping application as is. It would need some beefing up and it definitely changes if you’re going to do a POST, or DELETE call, not to mention the lack of authentication. I picked the badges call because it didn’t require authentication.

When we allocate and initialize NSURLConnection it takes off and starts doing the work. Notice we’ve specified self as the delegate, which means NSURLConnection will expect us to have implemented the NSURLConnectionDelegate Protocol.

The next method we’ll want to take a look at is connectionDidFinishLoading.

- (void)connectionDidFinishLoading:(NSURLConnection*)connection
{
	NSString* s = [[NSString alloc] initWithData:receivedData encoding:NSASCIIStringEncoding];
	NSLog(@"Received data %@", s);

    badges = [[IFixItBadges alloc] initWithData:receivedData];
    
    [self.tableView reloadData];
}

This is called by NSURLConnection when it’s finished receiving the response from our badges call. At this point we should have a nice JSON response to parse. Notice we’re working on receivedData, which is private and is built in the didReceiveData method. I’d recommend building the code and running it in the debugger to see how it works.

Back to connectionDidFinishLoading. We have our receivedData (an NSMutableData*), now we’re going to create an IFixItBadges object.

Creating objects from JSON

To review. We’ve called the iFixIt badges method and we’ve received our response data. Now we need to do something with it. Say hello to NSJSONSerialization.

- (id)initWithData:(NSData*)data;
{
    if ((self = [super init])) {
        badges = [[NSMutableArray alloc] init];
        
        NSError *error = nil;
        NSArray *resultData = [NSJSONSerialization JSONObjectWithData:data
                                                              options:kNilOptions
                                                                error:&error];
        if (resultData && nil == error && badges) {
            NSDictionary *badgesData = nil;
            NSEnumerator *resultsEnum = [resultData objectEnumerator];
            while (badgesData = [resultsEnum nextObject]) {
                IFixitBadge *badge = [[IFixitBadge alloc] initWithDictionary:badgesData];
                [badges addObject:badge];
            }
        }
    }
    
    return self;
}}

When we get our result back we create an iFixItBadges object, which is a collection of iFixItBadge objects. We could’ve just as easily used NSMutableDictionary or NSMutableArray to hold these objects.

Notice the use of NSJSONSerialization. One call. That’s all it takes to create an array of data we can then iterate over to create an iFixItBadge to add to our collection. Once the collection is created we tell the table view to reload itself using [self.tableView reloadData];

That’s it in a nutshell. If you have any questions about this, or find a problem, please feel free to leave a comment or send email to rob.fahrni@gmail.com.

Happy coding.

Categories
Development iOS Objective-C

Native is still King

The New York Times, Bits: “The current version of the app is essentially an Objective-C shell with a Web browser inside. When it comes to speed, this is like putting the engine of a Smart Car in the body of a Ferrari.

That’s a decent way to describe wrapper apps.