Without A Map

Editors note: This will be nerdy

I haven’t written about iOS development in several months. I haven’t given up, I just hadn’t had much to say. I was still soaking it in. 

I was reading two separate books, while occasionally going down rabbit holes to understand a topic a little better, and even watching some videos (specifically the much touted CS 193P). I even whipped up a few rough test apps just to prove to myself that I could get something running, even if it didn’t do much.

Then a little while ago I received an email from Apple saying it was time to renew my yearly developers membership. So I had been working on this for a year without much to show for it. So I decided I wanted to start something. Even if it’s terrible, even if I end up trashing it and starting from scratch later, this seems like a good time to take a first concrete steps.

That was my first impulsive decision. The second was, upon firing up Xcode, choosing Swift as the language for my new project.

Even though most of what I had learned so far had been Objective-C, which I have really enjoyed writing, I thought back to my initial feelings after WWDC last year. Swift was my chance to get in on the ground floor of something. 

What made me confident enough to do this the fact that I now had a basic understanding of Objective-C. This is important because Cocoa makes a lot more sense if understand that it was created hand in hand with Objective C. You can still use the Cocoa APIs from Swift, but it still feels like there’s a layer of translation happening. You end up with some weird syntax and excessive casting that only makes sense when you understand that these APIs were designed for an entirely different language.

That said, what have I got to lose, at this point? This is the future, right? And WWDC made clear that Apple was still full speed ahead on Swift.

So I jumped in and started playing around. It had been a while since I read Apple’s The Swift Language, so there was a period of adjustment in getting used to the syntax. Swift is a very programmer-y language. It was built buy compiler guys, so “fast” was as important as “easy” or “intuitive”. 

But after playing around for the last couple of months, I’m feeling comfortable with it. The pace of change has slowed down, and I’m finding myself able to work for longer and longer stretches without having to look up something basic. And Playgrounds have been really helpful. Sometimes you just can’t remember if arrays are passed by value or reference, but it’s easy enough to test in 10 lines of code on a Playground. 

There have been stumbling blocks. I watched Apple’s session on Protocol Oriented Programming, and got so excited I went into my project and made all my model layers structs that conformed to a specific protocol. That did not work out so well, but that story is for another blog post (and if you want a more informed opinion, go back and read Brent Simmons’s Swift Diary). But in general when I sit down I make head way.

So I’m still working. In fact, I’ve got a couple ideas now. It’s all starting to feel manageable. Which, if experience tells me anything, means I’m only a couple of weeks from once again realizing I have no idea what I’m doing. 

Advertisements
Categories: Computer Blue Tags: , , ,

Choosing NSDictionary Keys

February 28, 2015 Leave a comment

Say you’re creating a dictionary in Objective-C. The idea is that you have two objects that you want to link, where whenever you reference the one (a key), you get in return the other (the value). For example, you’re car shopping, and you’re writing a little app to help you pick which car you want. So you create some Car objects, and then go about classifying them. You pick some criteria, like “fastest car” and “most cup holders”, and you want each to reference the appropriate car. And you want all of these together, in one place, so that you can pass this dictionary around and make some kind of checks. 

What do you use as the keys for this? NSDictionary has some pretty strict requirements as to what object can be a key, so most of the time the easiest option is an NSString. I guess you can just create some string literals, and use something like @fastestCar and @mostCupHolders. But that just looks… messy. You could initialize a string like NSString *fastestCar = [NSString stringWithString:@“fastestCar”] , but again, that seems like overkill. It would be nice if you could use an enum, but NSDictionary requires an object.

I noticed that for Apple’s use of imagePickerController, you’re passed a dictionary when the user choses photo. That dictionary contains the image itself, as well as some metadata. What was interesting to me was the keys seem were clearly objects, but really the type was arbitrary. All we were concerned with were the names, which were characteristically descriptive (e.g. UIImagePickerControllerOriginalImage). 

Looking at the declaration, it appears that it’s defined as an NSString * const. Is there a string built in there? Not as far as I can tell. And it wouldn’t matter if there was. 

The object, I learned cannot be nil, but it doesn’t have to actually be some arbitrary string either. Simply declaring NSString *const fastestCar = [[NSString alloc] init]; is enough. You’ve got an initialized NSString that makes a valid key.

Why bother? It’s not going to make a huge difference to your code’s readability, but it can lessens the cognitive burden of having to figure out a placeholder string, and it just looks cleaner than throwing string literals in there every time you want to access a value. It’s boilerplate, but it can be worth it if you’re going to be reusing this key more than a handful of times.  

Categories: Uncategorized Tags:

Objection Oriented Programming

February 7, 2015 Leave a comment

A while ago, I saw a blog post from an experienced programmer lament that younger guys use Object Oriented Programming for everything because, well, that’s how they’re taught now. Often that makes sense, he explained, but sometimes you just want a quick script to do a task and be done with it. What the younger programmer could do in 20 lines of code this guy could do in 10 by getting rid of the object boilerplate. 

I haven’t been doing this long enough to form any habits, but I do have some scripts that I’ve been using for a while at work. They mostly do one thing, They’re not pretty, but they work. 

Then, I found myself wishing one of them did something else too. Or maybe instead of. Maybe I could add a small flag to change a behavior. That seems like it’s within my skill set. 

Except, since it is just a 100 line procedural script, there’s really no way to break it out into base parts and change its behavior under certain circumstances. So I basically started tearing the script apart and putting it back together as a class, which I can then add methods to and call as I need. It’s not only that this will let me get my desired outcome today, but that this will make it (kinda) easier on me down the road, when I get further grandiose ideas. 

The lesson here isn’t, I think, that one should always use OOP (or Functional Programming, if that’s your bag) for everything. The lesson is to think about the future, even with something small. If you’re writing a script that you expect to keep using down the road, try to future proof it as much as you can. Your needs will change over time, and that’s okay.  

Categories: Computer Blue

Ooey-GUI

February 7, 2015 Leave a comment

I saw someone on Reddit recently say that there are four stages to learning to program. I can’t find the link so I’m going from memory, but roughly, they are:

  1. The rush of excitement in learning something new – In this stage, you there are plenty of tutorials and hand holding. 
  2. Venturing out – You are newly confident after having grasped the basic concepts. You can read (some) code and get an idea of what it means, and if you are not sure, you expect that you can look it up and figure it out. Sure, there are some areas of code that look impenetrable, but you are confident that you’re just missing a few more basic concepts and you’ll be able to understand them easily enough. 
  3. The Wasteland – Now you want to do something non-trivial, and all the documentation still seems over your head. Everyone seems to know more than you do, and none of the tutorials are aimed at your level. They are either directed to newbies at stage 1, or they are directed to experienced programmers and assume that the reader has already worked with something similar, so they explain only what is unique about their implementation. 
  4. Actually having some idea of what you’re doing – If you manage to somehow get pas the Wasteland, your confidence builds again, and one day you realize that you actually are able to build non-trivial systems. 

I think the first three stages make a lot of sense. I’m not sure at this point if number four actually exists, or if it is just a cruel joke. I will say that there does seem to be a huge gap between the trivial (“Hello World!”) sort of programming and the more complex programming required to make what the average person on the street would recognize as software. 

Modern software is complex. It does a lot, and everyone has expectations from years of using professionally created applications. This applies to mobile as well. It’s crazy to think that the iPhone launched 8 years ago. Everyone who’s been using a smart phone for even a fraction of that time has an idea of how an app on their preferred platform should look, act, and, more importantly, feel

So what I’ve learned this week is that building GUI is really hard. Sure, you’re probably working with an SDK, so at least you’re not reinventing the wheel, but this is still hugely complex, with a lot of nuances. It’s hard to keep all of that in your brain at once. 

Right now I’m working my way through the Big Nerd Ranch’s book on iOS Programming. They do a fairly good job of speaking in plain English–of helping you past the Wasteland. But it’s tough. I just finished the chapters on UITableView, a super common and relatively basic design. No bells and whistles here. Just a pretty standard list. And I’ve spent a good week trying to figure out a few challenges they give you. Move the items around the list. Create one item at the bottom that doesn’t move. You wouldn’t think this would be so hard. But because you’re not just dealing with variables and simple operations, but instead a whole mass of interconnected objects, things don’t behave the way they do in those first few tutorials. Intuition goes out the window. You’re basically left with trial and error. 

Sometimes that’s good enough. And I get a feeling that more programming—real programming—is trial and error than anyone would ever admit. And through that method, I have almost completed the challenges. Now I have just one more simple method to master. 

Categories: Computer Blue

Mojo

The big question today on the tech blogs is has Apple lost it? You can rephrase that question several ways. Is Apple’s schedule of yearly iOS and OS X releases too ambitious? Are their priorities in the right place? Can any company reasonably expect to simultaneously grow platforms as complex as OS X and iOS and introduce a new watch platform while keeping software quality high? 

I don’t know the answer to that. But I can tell you that I don’t see Apple slowing down any time soon. 

Imagine a world where Apple held back several years between releases. We would all be using, what, Mountain Lion and iOS 6 today? Sure, it would be stable. But it would feel stagnant. Lacking of ideas. Your iPhone 6 would look antediluvian running a two year old OS, especially next to Android’s new Material design language. The “Apple bit off too much–is doomed!” argument would be replaced by “Apple is out of ideas–is doomed!”.

Apple are in a tough spot. On the mobile side, their competition is stronger than ever. Microsoft has stumbled on the desktop, but that doesn’t matter because the Mac is being measured against its younger siblings now. We expect our devices to work seamlessly together. 

As a customer, I do think now would be a good time for a “Snow Leopard” type release. Fix the weird little bugs. But I don’t think Apple can get away with that. A year is a long time to tell the world that you’re busying working on bug fixes. 

And frankly, while I do have complaints about the software I’m running today, I sure wouldn’t go back. 

Categories: Computer Blue Tags: , ,

Standing In The Way Of The Future

December 20, 2014 Leave a comment

Via Jason Snell at Six Colors, it’s becoming apparent to many that if a la carte programming is the way of the future, the math doesn’t add up for professional sports. My initial thought is… good.

It’s clear that there is a ton of dead weight in professional sports right now. People complain about athlete’s exorbitant salaries, and sometimes rightly so, but in general let’s remember that they are the reason we watch sports. Without them the whole system falls apart. Still, if demand lowers to some sort of natural plateau (without the artificial inflation of cable companies subsidizing them), eventually we’d reach some equilibrium. Player salaries would lower. The owners would either take a pay cut themselves, or sell to some other one-percenter who just wants the prestige of owning a ball team. And the teams would be forced to find ways to make the games more appealing and actually draw in enough viewers to sustain itself. 

My point is that we all have a lot more entertainment options right now. The movie and music industries are similarly being forced to question what is really necessary to sustain themselves. They’re sliming down, and that’s tough. Peoples jobs are going away, and I don’t want to diminish that. But I do think that these industries will come through stronger once they learn to pare away some of the excess and focus on what made them popular in the first place. 

Categories: Uncategorized Tags: , ,

Learning By Doing

November 30, 2014 Leave a comment

Several months ago I made two resolutions. One was to learn how to program, the other was to write about it more on this blog. I’ve partly kept one of those. The other, not so much.

Part of the reason is that I don’t feel that I had quite as much to say as I expected I would. I was reading some books and following along in some online communities, and that didn’t really sound interesting.

Now, though, I have a project. A personal itch that needs scratching. It’s small, and it’s pretty banal in the scheme of things, but it is kind of gnawing at my brain.

For my job, I find myself sorting large numbers of PDFs pretty often. The details aren’t important, but suffice it to say that this is something I’m sure a computer can do much more quickly than I can. So I set about figuring out how to get this done.

My first inclination was to come up with a Python script. I’m sure that it is possible in Python, but if I wanted to get into the raw data inside the PDF, I thought I’d need something more powerful. My next thought was to write something in C. This seemed like it would be way more effort than it was worth, since my knowledge of C is… well, lets just say I read a book on it once, and still own that book, so at least I have that.

My next thought was Swift, but again, there’s a serious learning curve there. Finally, I decided on Objective-C. Xcode offers an option for “Command Line Utilities”, so why not actually create one?

This is exciting because it’s my first time diving into an Objective-C project without a net. I honestly have no way of knowing how far above my head this project is until I hit a wall, and at that point there’s no flipping to the back of the book.

I started my project on Wednesday, after preparing for Thanksgiving. After working for a few hours here and there over the weekend, I currently have two classes totaling a couple hundred lines of code. I roughly sketched out the plan. The first goal was to find all of the PDFs in a directory. I got that part down. It took me a while, figuring out when to use NSArrays and when to use NSMutableArrays.

Beyond that rather basic syntax, my biggest confusion so far has been navigating the file system from inside an app. You have NSFileManager available to you, but some methods take NSURLs, and some take paths. How exactly do they work? Can I convert between the two? Are they really giving me what I want? How do I check?

I think I have that more or less sorted out. But now comes the hard part. Digging into a PDF file and seeing what I can pull out. I know the raw bytes I’m looking for are there. My worry now is separating the signal from the noise.

Categories: Computer Blue