Interface Builder about ios-open-gpx-tracker

[doedje]

I guess this is a matter of personal preferences. Using the IB would involve a lot of tidious clicking, dragging, filling in of forms, and such...

I find it much more convinient to just add some code and get the same effect out of it... It is a lot more readable to me (as a programmer) that way.

I also tend to make classes of my UI components to avoid repeating myself:

speedItem = createHudItem("speed", value: "100", label: "km/h", pos: (x: 0, y: 0))

// ...

func createHudItem(name: String, value: String, label: String, pos: (x: CGFloat, y: CGFloat)) -> HudItem {
    return HudItem(name: name, value: value, label: label, pos: pos, viewController: viewController)
}

// ...

class HudItem {
  var viewController: UIViewController!

  let valueButton: UIButton = UIButton()
  let labelButton: UIButton = UIButton()

  init(name: String,
    value: String,
    label: String,
    pos: (x: CGFloat, y: CGFloat),
    viewController: UIViewController
  ) {
    self.viewController = viewController
    let x = Constants.xstart + pos.x * Constants.spacingWidth
    let y = Constants.ystart + pos.y * Constants.spacingHeight

    valueButton.frame = CGRectMake(x, y, Constants.width, Constants.valueHeight)
    valueButton.setTitle(value, forState: .Normal)
    valueButton.titleLabel!.font = Constants.largeFont
    valueButton.titleLabel!.shadowOffset = CGSizeMake(2,2)
    valueButton.setTitleColor(Constants.whiteColor, forState: .Normal)
    valueButton.setTitleShadowColor(Constants.blackColor, forState: .Normal)
    valueButton.backgroundColor = Constants.transparentColor
    valueButton.accessibilityLabel = name
    valueButton.addTarget(viewController, action: "HudButtonClicked:", forControlEvents: .TouchUpInside)
    viewController.view.addSubview(valueButton)

    labelButton.frame = CGRectMake(x, y + Constants.valueHeight, Constants.width, Constants.labelHeight)
    labelButton.setTitle(label, forState: .Normal)
    labelButton.titleLabel!.font = Constants.normalFont
    labelButton.titleLabel!.shadowOffset = CGSizeMake(1,1)
    labelButton.setTitleColor(Constants.whiteColor, forState: .Normal)
    labelButton.setTitleShadowColor(Constants.blackColor, forState: .Normal)
    labelButton.backgroundColor = Constants.transparentColor
    labelButton.accessibilityLabel = name
    labelButton.addTarget(viewController, action: "HudButtonClicked:", forControlEvents: .TouchUpInside)
    viewController.view.addSubview(labelButton)
  }

  func setValue(value: String) {
    valueButton.setTitle(value, forState: .Normal)
  }
  func setLabel(label: String) {
    labelButton.setTitle(label, forState: .Normal)
  }
  func toggleLabel(labels: [String]) -> String {
    var newLabel: String = labels[0]
    for (i,label) in labels.enumerate() {
      if (labelButton.currentTitle == label) {
        if (labels.count > i+1) {
          newLabel = labels[i+1]
        }
        break
      }
    }
    setLabel(newLabel)
    return newLabel
  }
  func getLabel() -> String {
    return labelButton.currentTitle!
  }
}

[onato]

This example has a circular dependency with the controller, which is a code smell. Very long classes with multiple responsibilities is too.

Using a storyboard to seperate the layout from the logic reduces complexity along the lines of the MVC pattern.

Using a storyboard also make using autolayout easy which is important now that we have so many different screen sizes and multitasking.

[doedje]

Personally I am quite new to iOS development, so I am quite curious to know what circular dependency you are talking about.... And what you mean with 'very long class with multiple responsibilities'.

Using the IB kinda reminds me of the early days with MacroMedia's Flash... As a programmer you had to use the IDE to click together some parts of your interface (namely buttons) while as a programmer I just want to write code.... Clicking in the IB is like, well, not really coding, is it?

And you are probably right about using autolayout, but I guess that could be done programmatically also...

[onato]

The circular dependency is when the controller refers to the HudItem and the HudItem refers back to the controller. This makes code reuse difficult as the code grows. This is explained quite well in this book https://en.wikipedia.org/wiki/The_Pragmatic_Programmer.

The ViewController.swift is very long. This is a code smell (https://en.wikipedia.org/wiki/Code_smell) and this will be pointed out by static code analysers like SwiftLint or Taylor. SwiftLint considers more than 350 to be an error, not just a warning. Why you should keep your classes short is explain well in http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882. The multiple responsibilities can be seen by the number of protocols that the class implements (7).

Lots of people starting off with Xcode thinking the same thing as you did because of experience they had with software like Flash and Dreamweaver. The difference is that Interface Builder is really good. Most people realise this after a while. Storyboards also give you a number of features for free like state restoration.

The main advantage of IB is that you can see what the interface looks like and you don't get your layout code mixed up with your logic. You have a lot of flexibility to change the interface later.

[doedje]

Thanx a lot for all the links you provided, I'll read all of it!

Let me make a clear statement about one thing: I am not the or any of the authors of iOS-Open-GPX-Tracker... I am following this project because I am building my own gps navigation app, which is the first thing I've ever done on iOS development and is purely an experiment on a different UI for navigation applications in general... iOS-Open-GPX-Tracker, and its code have helped me greatly with my first steps in XCode-land... Deploying to the Appstore is not in my priority list at the moment.

As a programmer I prefer not to use any drag-and-drop interface to create my application. I am a coder, not a drag-and-drop-and-click-and-click specialist... I write code, and whatever you do in IB is essentially converted to code.... So I will try to stay away from IB for life! Cause I am convinced that every benefit from the IB is accessible from code aswell.... Just my 5 cents here..... I just hope I won't get proven to be wrong on this one! ;)

I totally agree with you on seperating looks and logix, but I just don't think I need the IB for that... You could create 1 file for setting up the UI and 1 for dealing with logix.

To finalize my post: Thanx for all the insights, it is wonderful to play around with iOS development. If it wasn't for swift2.0 I wasn't even here.. Obj-C was just too weird for me to even begin with... =] I really appreciate our conversation and hope to learn from all of this. This is why I like the open source community and I am really happy about the fact that we (as iOS developers) can share our code via github and deploy to our devices these days! This is a big step forward in iOS developement, let's use it to its full potential!

Best regards!

[merlos]

I stopped using IB some time ago, I don't remember the exact reason, probably in early versions of XCode it was not that good, it was a mess, and also I think I had problems with IB resources and maintenance when creating a library....