Xcode and Swift for PowerBuilder developers - Part 1

[Former Member]

Introduction - Part 1

I've been a developer most of my career, and I've worked with a number of different programming languages.  I spent most of the 90's and early 00's working in PowerBuilder.  I still think it's one of the cleanest, easiest to understand Object-Oriented programming environments available today.  (And, yes, it's still available and has a bright future with Appeon.)

But with all of PowerBuilder's strengths, it never really did mobile all that well, and it remains a Windows-only IDE to this day.  That rules it out for Mac or iOS development.  If you're targeting those platforms, there's really only one game in town, and it comes from Apple.  The IDE is called Xcode, and (until recently), you programmed in a language called Objective-C.

In my opinion, Objective-C is just about the exact opposite of the PowerScript language.  It's a variant of the C language (which I never used all that much), so I find it extremely difficult to read and even more challenging to learn.  But, if you wanted to write iOS apps, this was a hill you had to climb...

In 2014, Apple introduced the Swift programming language as a second option for development in Xcode, and believe me, it's a VAST improvement.  Simpler syntax rules, cleaner code structures, and much easier to read and understand.

So I thought I'd start a quick series of blog posts that compare and contrast Xcode and Swift with PowerBuilder and PowerScript.  We'll start with the basics, like variable and function declarations, and work our way up to the more complex topics like delegates, protocols, and closures.

Getting Started

Step 1 in working with Xcode and Swift is pretty straightforward:  get a Mac...  Xcode is not available on Windows.  You have to have a Mac, and you should be running the latest release of the OS/X operating system, Yosemite 10.10.5.  Xcode is available for free from Apple, so you can get started writing code almost immediately.  However, if you plan on compiling your apps and actually deploying them to real devices (not emulators), you'll need to sign up for an Apple Developer account, and that carries an annual subscription fee.

PowerBuilder obviously requires a license from SAP, but compiling and deploying applications has always been royalty-free.  PB apps don't need to be digitally signed to be deployed onto physical devices, as Mac and iOS apps do.

Let's start with some basics of the Swift language, and compare those to similar constructs in PowerScript.

Variable Declarations

Both Swift and PowerScript are considered "strongly-typed" languages, meaning that every variable must be of a specific type at design time.  When you write the line of code, you must give a variable a name and a defined type - either a standard datatype (Int, String, Double...), or a defined class or structure definition. For now, we'll only be referring to "local" variables, even though both languages support the concept of instance, shared or class, and global variables.

PowerScript:

A variable declaration in PowerScript looks like this:

{ constant } datatype { size } { precision } variablename { = value }

For example,

string l_myString = "some string"

• providing the optional keyword "constant" makes the variable read-only, and you MUST provide an initialization expression.  Any code that refers to this variable on the right side of an assignment statement will not compile.
• For most declarations, the datatype comes first.  This can be a standard system datatype, like "string" or "int" or "double", or a known class or structure name.
• size (optional) is for blob variable declarations, and denotes the max size of the blob in bytes.
• precision (optional) is for decimals only, and denotes the number of places to the right of the decimal point.
• variablename must be unique within the event or function script.
• = value is an optional initialization value for the variable.  It must be of the same type as the declaration.

Swift:

A variable declaration in Swift has a slightly different look, and is a lot more flexible, but most of the same concepts are there.

let | var variableName : type = expression

Notice the first choice you have to make - using "let" or "var".  One of the two of these must be used.  If you want the variable to be read-only, use "let".  If your code will alter the value stored in the variable, use "var".  So, "let" is Swift's equivalent to PowerScript's "constant" keyword, and "var" is just like the absence of the "constant" keyword - a normal mutable variable.

The variableName must also be unique within the .swift code file (which we'll discuss in a future post, when we examine the structure of the code assets between the two environments).

A colon must be present to separate the variableName from its type.  You can read that colon as if it says "is of type".

Type can be any defined system type, class or structure definition, and the expression can be used to provide a default value during initialization.  But here's a neat trick - if you provide an initialization expression, Swift will infer the datatype from it.  You can shorten the declaration and leave off the colon and the datatype.  For example,

let myVariable = "some string"

Swift will see that the initialization expression is a string, and will assign the String datatype to myVariable automatically.

Optional variables and null values

PowerScript:

Here's another difference between PowerScript and Swift.  In PowerScript, it's perfectly fine to declare a variable and leave it uninitialized.  If it's a standard datatype (int, string, double, etc...), PB will initialize the variable for you.  Numeric datatypes get set to 0, strings get set to the empty string, and dates contain '1900-01-01'.  That's also true for all the individual fields defined within a structure class.  NVO variables will be set to NULL until they're instantiated with a CREATE statement.  

Swift:

Swift, on the other hand, requires that all variables be initialized to a non-null value before are they are used in the code.  Swift will not automatically initialize an integer variable to zero, or set a string variable to the empty string.  If your code references a variable that has not been initialized or specifically assigned a non-null value, you'll get a compiler error.

But there are cases where a NULL value is the correct state of the variable!  For example, suppose you wrote an app that invoked a web service to retrieve the current temperature. If there's no internet connection, the service can't be called.  You don't want to initialize the value of the variable to 0 degrees - that would indicate that it's the dead of winter!  Data that's "zero" and data that's missing are two distinctly different states.

In this case, Swift has the concept of "optional variables".  You have to decide, on a variable-by-variable basis, whether it needs to support that "uninitialized" state.  The syntax changes slightly for these too.  In the declaration, just add a question mark immediately after the datatype, as follows:

var temp : int?

The variable temp can now be referenced in the code without receiving a compiler error.  But there's a twist...  Let's say the variable temperature contained the value 85.  If you write a line of code that prints out the temperature like this:

println( "The temperature is currently \(temp) degrees.")

you'd expect to see "The temperature is currently 85 degrees" in the console.  However, what you'll see is "The temperature is currently Optional(85) degrees"...   This is because the temperature variable type is no longer an "int", it's an "optional int".  To extract only the value and leave the "optional()" part off, you have to use a technique called "forced unwrapping".  This is as simple as adding an exclamation point after the variable name in the code, as follows:

println( "The temperature is currently \(temp!) degrees.")

NOTE:  the "\(expression)" syntax above is a technique called string interpolation, and it's a quick way to avoid having to do non-string to string data conversions in your code.  If I'd used string concatenation, I'd have had to convert the optional int "temp" to a String value.

Conclusion

In the next installment, we'll discuss basic code constructs, like flow-of-control statements, code blocks, and function declarations.  In the meantime, if you have access to a Mac, I encourage you to play around with Xcode.  It has a really neat new feature called a Playground, which allows you to write Swift code "outside" the constructs and overhead of a full-blown application.  It's exactly what it sounds like - a playground.  There's instant feedback on compiler errors, you can write loops and see the result of code execution.