Comments (6)
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!
}
}
from ios-open-gpx-tracker.
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.
from ios-open-gpx-tracker.
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...
from ios-open-gpx-tracker.
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.
from ios-open-gpx-tracker.
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!
from ios-open-gpx-tracker.
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....
from ios-open-gpx-tracker.
Related Issues (20)
- Wish: additional warning when cancelling recovery HOT 1
- Allow setting for accuracy when saving track HOT 2
- Auto-recover last track instead of asking
- Use a non-cache folder for keeping the cache
- Fix swiftlint in source code HOT 1
- Import GPX Tracks HOT 2
- Top labels hidden by Dynamic Island on version in App Store HOT 4
- SwiftUI rewrite for the watch app. HOT 2
- Wish: Apple Fitness integration HOT 1
- Search by location
- App Crash
- Data out of order if iPhone unloads app from memory HOT 1
- Issue after long recording session (data loss) HOT 1
- Feature Request: Second confirm for deleting GPX file HOT 1
- Feature Request: shortcut support (also for AW)
- Feature Request: PinπFor accurate moving position
- Bug: Weird GPX output caused by pausing and unpausing HOT 1
- controlling maps by Keyboard Bluetooth
- Background tracking HOT 2
- Feature Request: Load *.gpx file into Apple Watch
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ios-open-gpx-tracker.