Don’t get the reference? It’s about a quote popularly attributed to Bill Gates.
“I have the second toughest mobile evangelist job,” I used to say when I was a Windows Phone champ. “The toughest job…that’s Alec’s.”
Anybody can promote the Android and iOS platforms to developers. Taking on the job of being the head of BlackBerry’s developer relations team in late 2011, in the era of iOS 5 and the beginnings of Android 4 called for a rock star, ninja, and Jedi master all rolled up into one person. Luckily, Alec Saunders fits that description, and for three years he worked tirelessly to bring developers to the BlackBerry platform.
Yesterday, he announced that his last day at BlackBerry/QNX would be “sometime between now and November 3”. I don’t know what his plans are, but from one tech evangelist to another, I wish him the best in whatever challenge he takes on next, and thank him for honoring the profession through his hard work, and his fearlessness in taking on a cheesy ’80s hit in a “rally the BlackBerry troops” music video. You know the one I’m talking about…
I can’t think of a more fitting way to send him a tribute than with the same song:
I’m wishing you the best of luck, Alec, but I know you’ll kick ass wherever you go.
I was taking a trip down memory lane, flipping through an old Bloom County collection when I saw this classic strip…
Click on the comic strip to see the source.
…and it occurred to me: this is how a lot of so-called “agile” software projects are run.
On second thought, make that software projects, period.
It’s a sign of the times when Visual Studio Magazine covers a development tool that’s neither Visual Studio nor even made by Microsoft. Lately, they’ve been giving a lot of love to Xamarin, which lets you code with C# and the .NET Framework to create native Android, iOS, MacOS, and Windows apps, with particular attention paid to Xamarin.Forms, their new cross-platform UI API that lets you target Android, iOS, and Windows Phone with a single code base.
With Xamarin.Forms, you build mobile UIs using an API that abstracts away each mobile OS’s particular features as far as the developer is concerned. When you create a Button in Xamarin forms, it becomes an Android Button instance on Android devices and a UIButton view on iOS devices. I’ve been noodling with Xamarin.Forms for the past few weeks and it looks like it’s the tool I’ll use to build sales, marketing, and training apps for partner organizations of GSG, the company I work for.
Why use Xamarin.Forms?
In their article, Simplifying Cross-Platform Mobile App Development with Xamarin.Forms, Visual Studio Magazine’s Wallace McClure suggests that you ask these questions when considering adopting Xamarin.Forms as your development platform:
- What type of expertise do you currently have? A company that has invested heavily in C# and the Microsoft .NET Framework would have a significant burden taking on Objective-C for iOS and Java for Android.
- How much do you want to invest for the application you’re developing? Web applications tend to be lower cost to get started. As customers ask for more features, the cost to continually add platform-specific features tends to cost more money than merely adding features to a platform-specific application. Will the application fit within a Web application forever, or will end users ask for features that will result in a dead-end Web interface? What happens when an application needs to use the image processing capabilities in iOS? Will the time, effort, and money spent building a Web application end up being a sunk cost?
- What’s your end-customer expectation? End customers want apps that look like all of the other apps with which they work. Giving iOS users an application that looks like some generic platform (think jQuery Mobile default themes) results in some strange looks from those users. While they won’t hate the application, they won’t love the application as much as if they’d been presented with a platform-looking application.
- Increasing the productivity of end users tends to be much more valuable than increasing the productivity of developers. End users outnumber developers by many times. I have a client with approximately 3,000 end users using an application I’ve written. A simple 5 percent increase in end-user productivity would greatly offset a 50 percent increase in developer productivity gained by using a cross-platform framework.
Xamarin.Forms in action
The article also features a sample app, which takes JSON data from a remote source via .NET’s HttpClient and displays it in list form as shown below:
It’s worth noting that they don’t show a Windows Phone screenshot — just Android and iOS. You can download the code here.
What do developers make of Xamarin.Forms?
Another Visual Studio Magazine article, Xamarin.Forms: What Developers Make of It, has McClure talking to developers who participated in the Xamarin.Forms beta program as well as Xamarin evangelist Craig Dunn. Some quotes:
- “I really like Xamarin.Forms for creating simple and complex UIs for cross-platform (mobile) apps. I’m currently working on a video catalog app for a local telco, which I’ll be building the app for iOS, Android and Windows Phone. The user will scroll through a list of categories and TV shows and pick a video to watch on the handset. The data (menu structure) comes from a JSON feed and is perfect for Xamarin.Forms. Instead of creating a separate UI for each platform I can use one code base to cover all three platforms. I’m very excited about that.”
- “One of the most useful things in XAML is the DataBinding platform and this saves a lot of time in tracking properties and changes. Now it’s in Xamarin via XF [Xamarin.Forms]. Also, you can now separate your UI code from your business/logic code and have a clearer separation of concerns.”
- “The main benefit is that if you have a .NET background or know how to write C# code or F# and want to start building mobile apps, you can start immediately with Xamarin. You won’t need to learn a new programming language, and you can reuse all of your .NET skills building mobile apps. At the same time you are saving precious time by reusing your business logic between platforms, and even your UI if you are using Xamarin.Forms. You should use Xamarin.Forms if your main goal is to develop for all three platforms and share some UI between them.”
- “The project has great traction because Xamarin.Forms is being widely adopted by many developers. We have around 10 contributors, almost 350 commits and we have NuGet packages with around 600 downloads — all this in less than two months of Xamarin.Forms being publicly available.”
Xamarin Test Cloud
Xamarin isn’t just doing their part for cross-platform coding, but cross-platform testing as well, with Xamarin Test Cloud. Xamarin Test Cloud lets you test your apps on thousands on devices with your having to acquire them all. According to the Visual Studio Magazine article Xamarin Test Cloud Now Available:
Xamarin Test Cloud can provide simulated testing environments for more than 1,000 devices, from desktops to mobile devices and includes the various OS versions on a number of platforms.
Xamarin Test Cloud can be used to automate testing of apps through its Calabash cross-platform test automation framework whether developers are working in any C# or Ruby supported tool suite, and can report back on memory and CPU usage performance and test durations. Automated testing can be integrated into Team Foundation Server and other continuous integrations systems like Jenkins and TeamCity.
Xamarin Test Cloud is able to gain access and collect diagnostics information from device logs, stack traces and through hardware data to generate performance reports for more accuracy.
Categories
Swift roundup: Game programming!
Today’s Swift Kick features a roundup of tutorials and resources for the Swift developer who’s into game programming. If you’ve been meaning to learn Swift, games are a fun way to do so, and if you’ve been meaning to learn game programming, you’ll find these useful!
Brian Advent’s tutorial on building a networked tic-tac-toe game with Swift and the Multipeer Connectivity Framework
Brian Advent (whom I’ve written about before) has posted a video tutorial showing how to build a networked tic-tac-toe game using iOS’ Multipeer Connectivity Framework, which allows you to connect and share data with devices nearby.
RayWenderlich.com’s Sprite Kit Tutorial for Beginners updated for Swift
Two years ago, Ray Wenderlich posted the sort of game programming tutorial that he wanted to see: in his own words, “very simple but functional game with animation, collisions, and audio without using too many advanced features.” The resulting game is the one pictured above, featuring a shuriken-hurling ninja taking on approaching monsters.
The game was originally written in Objective-C and used the open source cross-platform 2D gaming framework Cocos2D 1.X, and was followed by an update for Cocos2D 2.X. When Sprite Kit came out, Ray wrote a new version of the game using that framework, and I took some ideas from that game and turned it into a simple shoot ’em up game in Swift.
Conway’s Game of Life in functional Swift
While it can be argued that Swift is not a functional programming language, it certainly lends itself better to functional programming techniques than many other languages, Objective-C included. With this in mind, take The Game of Life with Functional Swift, written by Colin Eberhardt, one of the co-authors of the RayWenderlich.com books iOS8 by Tutorials, Swift By Tutorials, and Core Data by Tutorials. He writes:
This blog post shows an implementation of Conway’s Game of Life using functional techniques in Swift. This results in code which is a clear and concise representation of the game’s logic. I also take a closer look at ranges, intervals, the pattern match operator,
~=and how local functions help organise your code.
Taking a functional programming approach allowed Colin to condense the rules of Conway’s Game of Life down to this:
// rules of life
let liveCells = cells.filter { $0.state == .Alive }
let deadCells = cells.filter { $0.state != .Alive }
let dyingCells = liveCells.filter { livingNeighboursForCell($0) !~= 2...3 }
let newLife = deadCells.filter { livingNeighboursForCell($0) == 3 }
// updating the world state
newLife.each { (cell: Cell) in cell.state = .Alive }
dyingCells.each { (cell: Cell) in cell.state = .Dead }
If you’re looking for a challenge, you might want to take MakeGamesWith.Us’ implementation of the Game of Life (pictured below) and refactor it using Colin’s functional approach.
SwiftCast: Game Programming in Swift
The latest Swiftcast, which you can listen to using the player above, is all about game programming in Swift:
Swift game development is very exciting. If it isn’t already obvious with the content of our site, we love to talk about game development. Mobile gaming is a rapidly growing market, and iOS is by far the most rewarding and exciting to build games for. If you’ve ever wanted to learn how to build an iOS game as an indie developer, we have some resources and advice for you.
iOS Games by Tutorials updated for Swift
RayWenderlich.com’s book, iOS Games by Tutorials, has been updated for iOS 8 and Swift. In 28 chapters and over 800 pages, you’ll learn game programing with Swift and Sprite Kit by building the following games:
Zombie Conga, where the player is a partying zombie who’s trying to build a conga line of cats while avoiding crazy cat ladies. It covers introductory topics such as sprites, processing touches, collision detection and scrolling.
XBlaster: a space shooter where you’ll work with physics and particle systems.
Cat Nap, where you’re trying to help a sleepy kitty get to bed. This is a “physics-based” game, so this introduces the Sprite Kit’s physics engine starting with the basics, but getting into stuff advanced enough for you to write your own version of Angry Birds or Cut the Rope.
Pest Control, a tile-mapped game where you take a Schwarzeneggarian hero on a bug-killing spree. This covers building a tile-mapping engine and adding all sorts of effects to a game.
Circuit Racer, a racing game made more complicated by obstacles on the track. This one features mixing Sprite Kit-based UIs with UIKit-based UIs, using the accelerometer, and interfacing with Game Center.
Also covered:
- Porting your iOS games to OS X
- Using texture atlases for reduced memory overhead and better performance
- Tips and tricks for getting the most performance out of your game code
- Basic game art-making for programmers
iOS Games by Tutorials is available in PDF form for $54, and it’s a great deal at the price. Buying it also gets you free updates for the life of the book; if you bought the earlier Objective-C/iOS 7 edition, you already own the current Swift/iOS 8 edition!
…and don’t forget…
…my simple “shoot ’em up” game in Swift, which has also been updated to work with post-beta Swift.
A couple of quick updates about the simple “shoot ’em up” game tutorial app written in Swift with Sprite Kit that I posted a little while back:
- I’ve updated the code so that it works with the version of Swift compiled in Xcode 6.0 (and any Xcode 6 beta from 7 and later). The original code worked until Xcode 6 beta 7, when Apple made the Sprite Kit APIs optional-conformant. You can find an explanation of what that’s all about in my article Why your Swift apps broke in Xcode 6 beta 7 and the GM versions, and how to fix them.
- I’ve posted it to GitHub in a repo name SimpleSwiftShootEmUp. Grab and enjoy!
For those of you who like living on the edge, beta 3 of Xcode 6.1 (the current stable version is 6.0) is now available to registered iOS developers. Of note in this release:
- More APIs have been made optional-conformant. The good news is that code will make more sense. The bad news is that some existing code may break.
- Value of type
Anycan now contain function-type values, as you might come to expect from a value namedAny. - Documentation for the standard library, which shows up in quick help and in the synthesized header for the Swift module, is improved.
- All the
*LiteralConvertibleprotocols now use initializers for their requirements rather than static methods starting withconvertFrom. Any type that previously conformed to one of these protocols will need to replace itsconvertFromXXXstatic methods with the corresponding initializer. - Xcode now produces fixit hints to move code from the old-style
fromRaw()/toRaw()enumAPIs to the new style-initializer andrawValueproperty. - Class properties don’t need to be marked
finalto avoid O(n) mutations on value semantic types. - iOS Playgrounds now support displaying animated views with the
XCPShowView()XCPlayground API. This is disabled by default, but can be enabled by checking the Run in Full Simulator checkbox in the Playground Settings inspector. When this checkbox is checked, running the playground will cause the iOS Simulator application to launch and run the playground in the full simulator. This is also required for some other functionality that fails without the full iOS Simulator, such asNSURLConnectionhttp requests. Running in the full iOS Simulator is slower than running in the default mode. - Apple has addressed an issue that could cause Xcode to become unresponsive while editing Swift code.
- Dead code stripping no longer removes public declarations from Swift application targets which are needed by unit testing.
- Weakly-linked symbols no longer cause compilation errors in Playgrounds .
- Swift expressions like
expr,p, andprintthat are evaluated from the LLDB prompt in the Debugger console will now work on 32-bit iOS devices. - Profiling App Extensions with Instruments now works.
- Ampersand and double quotation mark characters are now fully supported in the company name for iOS projects you create.
Also available for download is iOS 8.1 beta. As with Xcode 6.1 beta, you have to be a registered Apple developer to get it now.
Remember, these are betas, and the standard caveats apply.
I’ll close with the Dirty Harry clip referenced in the photo at the top of this article, for the benefit of younger readers who may not be familiar with Mr. Clint Eastwood’s iconic character: