Pete On Software

RSS Feed

Archive for 'Objective-C'

My First Dimecast is Up!

I’ve been a fan of Dimecasts.Net for some time. In fact, four and half years ago I mentioned the site in a post on this very blog. Unfortunately, the site hadn’t been updated with a new video in almost two and a half years.

I kept checking in with it periodically, but never saw updates. One day, my curiosity got the better of me and I started looking around the Internet and I found that Dave Schinkel was planning to take the site over from Derik Whittaker. I reached out to see if I could help and Dave was gracious enough to let me play along.

The site is still going to be undergoing a redesign (to be casted, of course), but for now, Dave has re-encoded all of the old videos to MP4 from WMV, boosted the volume, and added a modern player.

All of that being said, I am proud to announce the first new Dimecast in 2.5 years, Episode 206 – Learning Objective-C – Part 1.

Author Screen from my Learning Objective-C Part 1 Dimecast
(A Screenshot of the Author Screen)

Sample Action Screen from my Learning Objective-C Part 1 Dimecast
(A Screenshot of me in action 😉 )

The goal is to roll out a lot of new episodes about a lot of different topics soon and get the site back into a vibrant place to help developers learn new skills.

I’m very excited for what’s to come and I hope that you go check out the episode.

iOS – TableView Row Height Wrong on 64-bit Only

I had a fun little problem pop up at my client site today. We had a tableview that was displaying data that looked perfect when running on everything except for an iPhone 5s. After a little bit of DuckDuckGo-ing, we came across these Stack Overflow questions here and here that suggested that the heightForRowAtIndexPath method might be the culprit.

When I went and dug in, I found this warning (I did do some cut and paste to get the warning just over near the code):

float to CGFloat Warning

If you can’t read it, that warning says, “Conflicting return type in implementation of ‘tableView:heightForRowAtIndexPath:’: ‘CGFloat’ (aka ‘double’) vs ‘float'”

The code was the following:

The signature for that method means that the code should have looked like this:

So what is the explanation? Basically CGFloat was typedef’ed as float. However, Apple wanted you to use CGFloat in case they ever changed what a CGFloat was going to stand for. Apparently, with the move to 64-bit, Apple has done just that. In 32 bit versions, the signatures were identical. However, now in 64-bit land, because the method was returning the wrong type, iOS considered the return value to be 0, breaking our layout. By only changing the return type in the signature to the proper value, the app functioned again properly.

Keep this in mind the next time you might think about being smarter than the language designers and consider not using their typedefs.

An Intro to CocoaPods

CocoaPods LogoIn today’s development landscape, dependency management is becoming an increasingly important problem to solve. As applications incorporate more and more external libraries (especially very active open source libraries), making sure that your application has the most up-to-date versions of those libraries becomes more tedious. Add in the necessity to make sure that every one of your dependencies has its dependencies met, you are definitely facing a headache.

If you come to Objective-C and iOS development from other languages, you might already be familiar with the solutions that those ecosystems provide. In .Net there is NuGet, Ruby has Gems, Node has NPM, etc. In Objective-C, the most popular dependency management system is CocoaPods.

CocoaPods is made with Ruby and you can get started with it with the version of Ruby that is on the Mac by default. All you have to do is type “sudo gem install cocoapods” (without quotes) in the terminal, enter your password, and you are off and running.

CocoaPods Install

The terminal will just sit and wait for awhile during the install. Unlike Homebrew, you don’t get any feedback during the installation. When it is finished, you will get a bunch of text for the change log for the version that you just installed and – if all went well – it will conclude with this message (the version could vary based on what is current when you are doing your install):

After that, CocoaPods is ready to use.

For the first step, we need to have to make a new project (or use an existing project). Since we are starting fresh and new, I’ll just make a new project. I’m going to open Xcode and make a new project:

Xcode New Project

Then, I’m going to choose “Empty Application” and click next. (Note: you might see different options here based on what you configurations or installations you have on your machine.

Choose a Template

Then, we can fill out a little information about our application and click Next again. After that, choose somewhere to save it and finish up:

Set Project Options

After your project opens, go ahead and shut down Xcode. You are never going to intentionally directly open that .xcodeproj file again.

Open the terminal and navigate to the directory where you saved your project. First, we’ll create a podfile. A podfile is just a text file that keeps track of what dependencies you are taking and a list of the versions that you are willing to accept. We are just going to make a very simple podfile and take a dependency on AFNetworking, a very popular Objective-C networking client.

With your terminal active in your project’s directory, just type “touch Podfile”. That will make a podfile (no extension) in your directory. Then, you can edit that file in your favorite text editor. If you want to stay in the command line, you can type “vim Podfile” and then press i to go into insert mode. Then add the following text, followed by the key combination of Esc, then colon, then wq then . This will take you back to your terminal.

The file contents:

Here are those steps visually:

Touch Podfile

Podfile Contents

Type pod install and your pods will be installed and configured*
pod install

If you look at the project directory in Finder, you will now see that files and folders have been added.

After the Pod Install

The file that you care the most about now is the .xcworkspace file. If you are familiar with .Net, the .xcworkspace file is like the .sln file and the .xcodeproj file is like the .csproj or .vbproj files. The way that CocoaPods works, it makes your Pods code its own project and your existing code stays its own project and the .xcworkspace encompasses them both. As I mentioned earlier, from now on, don’t open your .xcodeproj file, but instead have Xcode open the .xcworkspace.

I find it handy to go File -> Open Recent -> Clear Menu from the Xcode menu so that my .xcodeproj file is removed from recent files and I don’t accidentally open it. Then, I can either double click on the .xcworkspace or choose “Open Other…” from the Xcode launch screen.

Now that the workspace is launched, you can see that the CocoaPods have been added to your code. Now you are able to import the header files into your code files and use your imported libraries as if they had always been there.

Podified Workspace

It might seem like we did a lot of steps to get to this point, but that was only because we had to include the initial CocoaPods gem installation. From now on, you just need to add a completed Podfile to your project directory, run pod install and then use the workspace from then on.

If you are the kind of person who likes to watch to learn rather than just read, you can check out a FREE video available over at NSScreencast about CocoaPods. Happy Podding!

* If you have an error when you run pod install, check out this StackOverflow, it solved my issue caused by a bad update to Cocoapods.