It was past time to run an update on Android skills. The last serious app I built was back when Android 2.2 (API version 8) was current and Google have just shipped Android 5 Lollipop and my test devices are running 4.4 Kitkat (API 19) in the main. There has been quite a lot of change and platform development over that time lapse.
Like any platform that has endured rapid development over a (relatively) short timescale things have sort of built up in layers. There are new approaches (things like fragments) overlaid on top of the old with new techniques to be applied to take advantage of the performance and functionality benefits accruing from each development. You also see a lot of yellow underlined code appearing in the Eclipse IDE reflecting deprecated classes – some just a bit mystifying, particularly where something simple looks to have been made unnecessarily complex *.
Having actively worked with .NET since the first usable version (1.1) and seen a lot of similar evolution in the Windows desktop and web application spaces I have to say the Microsoft managed this better overall. I suppose MS started with the advantage of building a fresh foundation rather than inheriting so much from Java.
On the bright side, the Eclipse IDE has improved** and gets excellent support for Android development – Android lint is pretty good and the “intellisense” mostly helpful – although at the occasional risk of assuming the “wrong” module to include (e.g. Android.Graphics.Camera and Android. Hardware.Camera which are not the same at all and we also haveAndroid.hardware.camera2 now available). Eclipse is still a long way from Visual Studio (the touchstone of IDEs?) and I did have a bash at getting Android Studio to work but failed to get anything actually running. Android Studio gets nice press but is still at a “point” release. Based upon JetBrains’ IntelliJ IDE one might have expected better progress since the May 2013 preview launch but to be fair targeting simultaneous implementations on Windows, Mac and Linux is quite a challenge. In the meantime Eclipse is quite good enough.
What I have found interesting about the Android skills revamp is how little attention I need to give to the Java language syntax. After a longish period working in C# and JavaScript there is almost no mental dissonance when switching between the languages themselves – although the environments do of course have a significant impact on what gets written in code. Which sort of brings me to Apple’s Swift.
When Swift was announced by Apple (last May I think) I grabbed a copy of the launch eBook and took the time to read the guide to the beta version. I understand that there have since been some language revisions and improvements but I was immediately taken with the overall approach. This was clearly a vast improvement on Objective C.
Here at Adit we established and nurtured iOS development skills more than three years ago. Big question I suppose we have to face now is: should we switch languages from Objective C to Swift? Given that the iOS platform represents the dominant slice of development focus this should be no more complex that switching between (say) Visual Basic and C# on .NET. There is also the potential to further reduce dissonance between the programming languages in use – although there are a few caveats. Apple is apple and their language development team seem on the face of it to have decided against certain de facto standards to ensure that their new baby has that certain Cupertino style.
The Swift class constructor is a method named init – rather than following the convention of a public method with the same name as the class. The keyword “self” is used where other languages use “this” to refer to the current instance. [I know that JavaScript newbies get in a mess with “this” but changing the name hardly introduces clarity.]
Include values in strings with a backslash – frankly an improvement over the convention but different…
Declaring a function:
func isPositive(number : Int) Bool {}
as Swift does is just as comprehendible as
Bool isPositive(Int number) {}
which is the “convention” and one would have thought just as parsable (is that a word?) – so why be different? Given the way variables are declared in Swift even:
Bool isPositive(number : Int) {}
would have been good.
But this is cool:
func returnPrevAndNext(x: Int) -> (Int, Int) {
return (x - 1, x + 1)
} and has the potential to avoid the overhead of clumsy return structures.
I quite like the Swift idea that variable types should be inferred although I suspect that I would get into the habit of being explicit (just as I tend to be with JavaScript these days when passing variables to functions or in concatenation). You use “var” for mutable variables and “let” for immutable variables – although immutable objects have mutable “content” (class properties and array element content for instance).
More positive point, Swift generic classes are nicely implemented and overall issues such as those highlighted are just minor carping – I just wonder though, that Apple may have made context switching between platforms just a tiny bit more complex than was necessary.
*Example: many methods on the Date() object are now deprecated. So mDate.getYear() which returned an integer in an idiot proof and self-documenting manner now requires something like
cdate = Calendar.getInstance();
cdate.setTime(mDate);
return cdate.get(Calendar.YEAR);
And OK, you would not actually write this code and we are probably supposed to be using Calendar not Date but…
** That understates it – Android development support in Eclipse has improved enormously. Someone has done a brilliant job and I notice that the odd couple of things that Eclipse does better look to have been incorporated into the Visual Studio 2015 preview – I found myself saying “Oh, Eclipse does that.”
Like any platform that has endured rapid development over a (relatively) short timescale things have sort of built up in layers. There are new approaches (things like fragments) overlaid on top of the old with new techniques to be applied to take advantage of the performance and functionality benefits accruing from each development. You also see a lot of yellow underlined code appearing in the Eclipse IDE reflecting deprecated classes – some just a bit mystifying, particularly where something simple looks to have been made unnecessarily complex *.
Having actively worked with .NET since the first usable version (1.1) and seen a lot of similar evolution in the Windows desktop and web application spaces I have to say the Microsoft managed this better overall. I suppose MS started with the advantage of building a fresh foundation rather than inheriting so much from Java.
On the bright side, the Eclipse IDE has improved** and gets excellent support for Android development – Android lint is pretty good and the “intellisense” mostly helpful – although at the occasional risk of assuming the “wrong” module to include (e.g. Android.Graphics.Camera and Android. Hardware.Camera which are not the same at all and we also haveAndroid.hardware.camera2 now available). Eclipse is still a long way from Visual Studio (the touchstone of IDEs?) and I did have a bash at getting Android Studio to work but failed to get anything actually running. Android Studio gets nice press but is still at a “point” release. Based upon JetBrains’ IntelliJ IDE one might have expected better progress since the May 2013 preview launch but to be fair targeting simultaneous implementations on Windows, Mac and Linux is quite a challenge. In the meantime Eclipse is quite good enough.
What I have found interesting about the Android skills revamp is how little attention I need to give to the Java language syntax. After a longish period working in C# and JavaScript there is almost no mental dissonance when switching between the languages themselves – although the environments do of course have a significant impact on what gets written in code. Which sort of brings me to Apple’s Swift.
When Swift was announced by Apple (last May I think) I grabbed a copy of the launch eBook and took the time to read the guide to the beta version. I understand that there have since been some language revisions and improvements but I was immediately taken with the overall approach. This was clearly a vast improvement on Objective C.
Here at Adit we established and nurtured iOS development skills more than three years ago. Big question I suppose we have to face now is: should we switch languages from Objective C to Swift? Given that the iOS platform represents the dominant slice of development focus this should be no more complex that switching between (say) Visual Basic and C# on .NET. There is also the potential to further reduce dissonance between the programming languages in use – although there are a few caveats. Apple is apple and their language development team seem on the face of it to have decided against certain de facto standards to ensure that their new baby has that certain Cupertino style.
The Swift class constructor is a method named init – rather than following the convention of a public method with the same name as the class. The keyword “self” is used where other languages use “this” to refer to the current instance. [I know that JavaScript newbies get in a mess with “this” but changing the name hardly introduces clarity.]
Include values in strings with a backslash – frankly an improvement over the convention but different…
Declaring a function:
func isPositive(number : Int) Bool {}
as Swift does is just as comprehendible as
Bool isPositive(Int number) {}
which is the “convention” and one would have thought just as parsable (is that a word?) – so why be different? Given the way variables are declared in Swift even:
Bool isPositive(number : Int) {}
would have been good.
But this is cool:
func returnPrevAndNext(x: Int) -> (Int, Int) {
return (x - 1, x + 1)
} and has the potential to avoid the overhead of clumsy return structures.
I quite like the Swift idea that variable types should be inferred although I suspect that I would get into the habit of being explicit (just as I tend to be with JavaScript these days when passing variables to functions or in concatenation). You use “var” for mutable variables and “let” for immutable variables – although immutable objects have mutable “content” (class properties and array element content for instance).
More positive point, Swift generic classes are nicely implemented and overall issues such as those highlighted are just minor carping – I just wonder though, that Apple may have made context switching between platforms just a tiny bit more complex than was necessary.
*Example: many methods on the Date() object are now deprecated. So mDate.getYear() which returned an integer in an idiot proof and self-documenting manner now requires something like
cdate = Calendar.getInstance();
cdate.setTime(mDate);
return cdate.get(Calendar.YEAR);
And OK, you would not actually write this code and we are probably supposed to be using Calendar not Date but…
** That understates it – Android development support in Eclipse has improved enormously. Someone has done a brilliant job and I notice that the odd couple of things that Eclipse does better look to have been incorporated into the Visual Studio 2015 preview – I found myself saying “Oh, Eclipse does that.”
