Archive for the 'iOS Dev' Category

Autoresizing text view in table cells

Thursday, August 11th, 2016

Continuing from the previous version, I upgraded to Swift 3 and Xcode 8 (beta 4). Most of the glitches are gone, but every now and then one shows up. So I’m not entirely sold on the whole thing yet. I’m still having doubts if it wouldn’t be simpler to just have the user enter text […]

Autoresizing table cells

Monday, July 25th, 2016

Extending the autoresizing of UITextView to table cells, this is how that looks. First, let’s create a trivial model class and a storage class for that model: class Item: NSObject {   var text: String        init(text: String) {     self.text = text     super.init()   }     } class ItemStore {   var allItems […]

Autoresizing UITextView

Sunday, July 24th, 2016

A problem I needed to solve was: while editing in a text view, I want the view to grow and shrink depending on the text entered. I also want this to work in conjunction with auto-layout. This is something I’ve been fighting for some time, but now I sat down and spent enough time (and […]

Server-side Swift

Thursday, July 7th, 2016

This presentation from WWDC 2016 boggles the mind. It completely overturned all my concepts about server-side nodejs and javascript in general. If you’re into docker containers or anything of the kind, and you develop in Swift client-side, this must be seen. Let’s hope the project doesn’t die. Let’s hope I didn’t overestimate this.

How Do I Declare A Block in Objective-C?

Saturday, December 20th, 2014

An incredibly well named domain. Go there and check it out: How Do I Declare A Block in Objective-C?

Swift, missing idea #1?

Tuesday, June 3rd, 2014

Going through “properties”, I’m not finding anything about private and public properties, or protected. I’m also not seeing anything about header files and class files, so at first blush it seems we can’t hide properties from other classes. How do we stop people from using the wrong properties? That can’t be good. I must be […]

Swift, good idea #1

Tuesday, June 3rd, 2014

There’s a lot of good stuff in Swift, of course, but adopting Ruby’s block syntax seems a really nice idea. It’s called “trailing closures” in Swift, but it’s the same thing, as far as I can see. An example from the text: let strings = { (var number) -> String in var output = […]

Swift, bad idea #3

Tuesday, June 3rd, 2014

Function types are declared like: var mathFunction: (Int, Int) -> Int In this example: mathFunction is a variable that can hold any function that takes two Int as parameters and returns one Int. Fine, so far. Functions can take such functions as parameters and also return them. For instance, a function taking a function like […]

Swift, bad idea #2

Tuesday, June 3rd, 2014

Function parameters now have distinct “internal” and “external” parameter names. The simplest form does away with named parameters when calling functions, that is, we can now do: mysteriousFunction(15.2, “yeah, right”, “only on a sunday”, -1) …just like in the good(?) old days of plain C/C++. Yes, you can force naming of parameters on the caller’s […]

Swift, bad idea #1

Tuesday, June 3rd, 2014

Looking over the “Swift” language Apple presented during the WWDC keynote. First off, declarations using “var” and “let” made me think of Basic, and had to stifle a gag reflex. I’m reading the iBooks book on Swift. When I got to closed and halfopen ranges on page 100, I thought this was a big mistake. […]