Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘iPhone

Adding Unit Tests to My Swift Application

with 3 comments


Last time I blogged on creating my first Swift application that would display a Koch Snowflake fractal on an iPad or and iPhone. This time I’m going to look at adding some unit tests to that program to see how that works in XCode and Swift. It appears that Apple has built some nice unit testing support into XCode so doing this was actually quite easy.

I put the Koch Snowflake Swift project on Google Drive here. Feel free to download it and play with it. Refer to this project or the previous blog post for the code we are actually testing in this article.

Test Driven Development

If I was following proper Test Driven Development (TDD) then I should have written the unit tests before I wrote the actual code. This would force me to think about the design of the APIs and the testability of the program first, and then would force quick cycles of writing tests, writing code so the tests pass and then refactoring the code to make it all better. However, in this case I ported an old Objective-C program to Swift to play with Swift and now that I’m getting more familiar with Swift, I’m finally looking at the unit testing framework. So what I’m doing is perhaps not a good practice, but adding the unit tests later is better than not adding them at all.

The danger I could have run into is that the program could have turned out to be quite hard to test due to perhaps some bad design decisions and then required quite a bit of refactoring to make it properly unit testable. Fortunately, in this case the program is fairly simple and adding a good set of unit tests was fairly straight forward and didn’t require any changes to the program.

One criticism of TDD is that there is a perception that it interferes with good program design and architecture. This isn’t true. The misconception is that the first tests need to be truly useful, whereas the first tests usually just call the API and set how the API to the various classes is used. The classes are just skeletons and the unit tests pass as long as everything compiles. Getting everything to compile is the first step and thinking about all the APIs before writing the real code that does stuff is the first step to getting a good modular design.

Apple has adopted TDD for a lot of their own projects, for instance their Core Data module was developed this way. Since Apple developers use XCode and now many are using TDD this means that a lot of good support for TDD is being baked into XCode. It also means that newer Apple technologies are much easier to use in a TDD environment than some of their older ones. But even for the older ones there are lots of clever examples on the web of how to work around the various challenges they introduce.

Screen Shot 2016-05-31 at 10.41.21 AM

Testing Turtle Graphics

When you create a project with XCode you have the option to include unit tests (which I did) and this gives you a test project that you can run with some dummy tests in it. So I figured first let’s add some unit tests to my TurtleGraphics class. This is pretty simple you move the turtle and turn the turtle and it leaves a trail behind it. For drawing fractals turtle graphics makes the algorithms very easy since it fits in well with the recursive algorithms typically used.

The turtle graphics class uses Apple’s Quartz2D library to draw on the screen. Perhaps the first possible design flaw is that when I instantiate the turtle graphics library I need to pass its constructor a valid graphics context. The underlying Quartz2D library routines certainly don’t like this being nil and throw an exception if you try that (ie my first try). So I thought I would just create a graphic context object but after battling with Swift a bit, I found I couldn’t do this because the underlying class doesn’t have any constructors. This also prevented me from mocking the class (at least using the real class and replacing just a few methods). This is because Apple wants to make sure you get a valid graphics context from one of their factory methods. If you are actually in the drawing routine this is passed to you by the system, but as a unit test, we aren’t running in a screen drawing context. Fortunately there is a way to get a graphics context to draw on an in-memory image file, so I used that.

To solve this, I could have refactored the drawing routines into another class and had this class accept nil for the graphics context and just return when this happens. This is basically just making a new class that pass through to the real class when the program runs, or acts as a stub class when running unit tests. I didn’t like this so much since then if the real program did pass nil, it wouldn’t get caught and the program just wouldn’t work properly. Even though I’m not testing the actual placement of pixels on the screen, it makes me feel good to know the actual real drawing routines are being exercised during the unit tests, so if they do get an invalid argument or something the problem will be caught.

The unit test framework lets unit tests get at variables in a class to help you set up the asserts to prove correctness (you import the module via @testable import KochSnowFlake rather than just import), so to test it, I just did some simple move and turns and then tested that the internal state of the turtle graphics module was correct. Notice when I turned 45 degrees I used trigonometry to calculate the new position, for testing its usually good to test against a calculation, rather than running the program to see what the value is and then using that. Notice the use of XCTAssertEqualWithAccuracy, since we are using floating point arithmetic, rounding errors creep in, so the equals will never be exact. You can configure XCode to either stop on each error or run to completion just recording all the errors, its up to you. For this I usually just stopped on an error and then fixed the problem.

func testTurtleGraphics() {
 // Test the turtle graphics library.
 // Note we need a valid graphics context to do this.
 UIGraphicsBeginImageContextWithOptions(CGSize(width: 50, height: 50), false, 20);
 let context = UIGraphicsGetCurrentContext();
 let tg = TurtleGraphics(inContext: context!);
 XCTAssert(tg.x == 50, "Initial X value should be 50");
 XCTAssertEqual(tg.y, 150, "Initial Y value should be 150");
 XCTAssertEqual(tg.angle, 0, "Initial angle should be 0");
 XCTAssertEqual(tg.x, 60, "X should be incremented to 60");
 XCTAssertEqual(tg.y, 150, "Initial Y value should be 150");
 XCTAssertEqual(tg.angle, 0, "Initial angle should be 0");
 XCTAssertEqualWithAccuracy(tg.x, 60, accuracy: 0.0001, "X should be o 60");
 XCTAssertEqualWithAccuracy(tg.y, 160, accuracy: 0.0001, "Initial Y value should be 160");
 XCTAssertEqual(tg.angle, 90, "Initial angle should be 90");
 XCTAssertEqualWithAccuracy(tg.x, 60 + 10 * sqrt(2) / 2, accuracy: 0.0001, "X should be o 60+10*sqrt(2)/2");
 XCTAssertEqualWithAccuracy(tg.y, 160 + 10 * sqrt(2) / 2, accuracy: 0.0001, "Initial Y value should be 160+10*sqrt(2)/2");
 XCTAssertEqual(tg.angle, 45, "Initial angle should be 45");

Testing the View Controller

Now let’s test things at a higher level. Generally, we don’t do UI testing in unit tests, but we can do some basic tests to ensure everything is created properly and is more or less hooked up correctly. XCode does have built in support for UI testing and perhaps we’ll have a look at that in a later blog post. In this case we are going to create the storyboard (where the UI is defined) and from that instantiate our View Controller. Then we do a dummy access for the view to get the delay loaded elements loaded and start calling the View Controllers methods starting with viewDidLoad(). For our test we set the fractal level to 3 in the text box and then call the notification methods and see if it then updated properly in our View.

func testInitialViewController()
 // Test that the storyboard is connected to the view controller and
 // that we can create and use the view and controls.
 let storyboard = UIStoryboard(name: "Main", bundle: nil)
 let viewController = storyboard.instantiateInitialViewController() as! ViewController
 _ = viewController.view
 viewController.fractalLevelTextField.text = "3"
 XCTAssertTrue(viewController.fracView.level == 3)
 // This next line is just to get 100% code coverage.

Test Coverage

The big questions that is usually asked about unit tests, is how much code to they cover (or exercise). XCode can give this report which you can see in the screenshot:

Screen Shot 2016-05-31 at 10.42.53 AM

Amazingly we nearly get 100% coverage. The only module with poor coverage is AppDelegate.swift which is code generated by XCode and then I never use it. The reason we get such good coverage is that this is a fairly simple program and it draws the snowflake when it initializes. But the key point here is that I am testing a lot of things fairly easily and fairly quickly. It tests the functionality of the turtle graphics library and it tests that the UI is all hooked up properly and working.

A true TDD adherent would delete all the code in AppDelegate.swift, since code shouldn’t be written unless it is to make a unit test pass. But I tend to give an exception to code generated by the tools like XCode, to me this code is Apple’s responsibility and not mine. Plus, if I ever do add code to this class then I would need to start adding unit tests and take it a bit more seriously.

Harder Cases

This program is pretty simple, so I didn’t need to do anything too fancy to unit test it. This is mainly because there is no database access, no hardware access (beyond drawing and one text field) and no communication with a server. If you add these then you would need to add mock, stub and/or fake classes to assist in testing. You want your unit tests to be fast and run on every compile. You don’t want to require databases be setup or that servers are running somewhere in a certain state. Fortunately, Swift is a very powerful object oriented language and creating all of these is fairly easy (extensions are especially helpful). The main problems you run into are in using the Objective-C libraries like UIKit, but again you aren’t the first to run into these and there are tons of sample code, blogs and lessons on how to deal with these.

Another tricky area is with asynchronous calls. When you make a call to the server, the response will be returned asynchronously. What this means that as soon as your unit test sends the server request, it will complete. Since the asynchronous request comes back on a separate thread later, you need to ensure your main thread doesn’t just end and you wait for the results, or the tests in the callback will never be executed. There are lots of examples on how to do this, but it definitely adds some complexity to your tests.

Continuous Build Server

If you have a team, then you will probably want a continuous build server that monitors your source code repository (probably Git) and then does a build and test each time something new is checked in. Apple has an XCode Server that you can purchase if you are a registered developer. Or you could use the Jenkins Build Server which is open source and free. Jenkins also has an XCode plugin to make life a bit easier. Though XCode is quite good at letting you control it from the command line. This way you can be notified as soon as something breaks and ensure problems get fixed right when they are caused, which is the easiest time to fix them.


That turned out to be quite a long posting on unit tests. XCode and Swift have a very powerful and easy to work with unit testing framework built in. If you are developing a new application, certainly consider using TDD for your development methodology. If you are porting or doing a new version of an app, then certainly try adding some unit tests. Unit tests will help you greatly over the lifetime of your product, making it more reliable, bug free and easier to maintain.

Written by smist08

May 31, 2016 at 8:17 pm

My First Swift Application

with 3 comments


Back in 2013 I purchased a MacBook Air, installed XCode and wrote a small Objective-C program to draw a simple fractal on an iPad. Which I then blogged on here. Now we are a few years later and I thought I would give Apple’s new programming language Swift a try and see how iOS/OSX development has evolved as a result. For more details on Koch snowflakes and what I the program does, check out my original article.

The Evolution from Objective-C to Swift

Objective-C was one of the first object oriented extensions to the C Programming language. Its first main usage was by Steve Jobs and NeXT Computer as the primary programming language of the NeXTStep operating system which later became OS/X and iOS. Objective-C had a lot of innovative ideas behind it like treating everything as sending messages between objects (rather than directly calling methods). But then C++ came along and became the main standard for an object oriented extension to C.

One of the complaints against C is that it puts a lot of burden on programmers since they are dealing with memory and the computer architecture at a very low level. You are manipulating memory pointers directly, allocating memory buffers, etc. This is all very powerful and produces very fast, compact and efficient programs. But there is a lot of room for error, since making a mistake here will lead to buffer overruns, program crashes and such. In the days of standalone computers this was annoying but not fatal. Now with the internet, these sorts of problems lead to security vulnerabilities and server crashes. All that being said, if you have skilled programmers, C, Objective C and C++ are very powerful and you can produce great reliable programs with them.

To address these problems, Sun Microsystems invented Java. Java was essentially an object oriented extension of C, but with all the pointers and low level memory access removed. Java then included a large standard class library to give an alternate way of doing all the low level things you did in C. Java compiled to P-Code which ran on a Java Virtual Machine. This could then be sandboxed to allow greater security. To some degree this was to try to reach a compromise between scripting languages like JavaScript or VBScript and true fully compiled languages like C++. I.e. to make it easier to program with less gotchas, but still maintain the compiler checks for correctness and modules features required to program large systems.

Microsoft saw the potential and growing success of Java and came up with their own competing system namely C#. C# was initially very similar to Java with a very similar class library. Microsoft actually originally had their own implementation of Java, but it really sucked and it was easier to move true Java programs to C# than it was to Microsoft Java. Similar to the Java VM, C# runs on Microsoft’s .Net framework which isolates you from the underlying operating system.

Java got off to a great start, but as Sun workstations went into decline, Sun couldn’t put the necessary R&D resources into supporting Java and forward progress slowed. Oracle bought Sun and took over Java, but Oracle doesn’t seem to be putting much effort into Java, besides suing the various users of it like Google.

Microsoft has been doing a lot of good work developing C# and has been putting a lot of work to evolving the language and evolving the .Net framework. Certainly modern C# has come a long way and contains a lot of powerful modern object oriented features that weren’t present initially and aren’t present in Java.

A couple of years ago Apple finally noticed this trend and produced their own modern object oriented language namely Swift. Swift isn’t a true object oriented extension to C, the core language has a lot of differences to C. Some things are quite similar like building expressions, but other things are quite different, like how you define variables. Swift has all the modern object oriented features like closures, extensions, generics, etc. which you would expect. Further since a lot of the language was re-imagined over C, it has a lot of nice built in features like ranges. If you look at just the core language, its quite clean, powerful and modern.

There are quite a few blog posts comparing these various languages such as these two articles on C# vs Swift: C# vs Swift and C# vs Swift. If you Google, there are a lot of discussions on the various points of these languages. Often the discussions also consider Go and Python.


The ugliness in all these safe modern languages comes in with how they interact with the underlying operating system. Neither Apple nor Microsoft re-wrote their operating systems to be safe and natively support these. At some point you have the transition from the nice safe, clean object oriented world into the old pointer based C world. Microsoft with the underlying Windows DLLs and Apple with the Objective-C based application frameworks and then to the underlying Unix based operating system kernel.

Sun took the highest approach making its own frameworks for everything and then leaving it to the JVM implementation on each system to translate native to this, so to a Java programmer everything looks the same. This sounds great, but doesn’t work well in practice since it doesn’t give you access to all the operating system features and makes your program less competitive. This resulted in the development of JNI and Java programs natively calling through to the ugly world outside the JVM.

Microsoft built the .Net framework on top of Windows, which provides most things you need and has been filling in more and more. But you still often need to call native DLLs directly (which makes you application unsafe).

Apple decided to use the current iOS/OSX frameworks directly and allowed Swift to interact bi-directionally with Objective-C libraries. This then allowed Swift programmers to directly leverage their knowledge of UIKit for instance to write programs. The downside of this is that it puts a lot of ugly code directly in your nice clean Swift program to deal with these older frameworks.

Koch Snowflakes Revisited

I ported my Objective-C Koch Snowflake program from 2013 over to Swift. This turned out to be pretty straight forward. I think the program source code is much cleaner once moved over to Swift and I definitely prefer Swift to Objective-C for programming. Since I’ve been doing mostly C# programming the past few years, it fells much more natural to me than Objective-C.

Although most of the code is cleaner, you can see a bit of ugliness around the interactions with the UIKit framework. I especially don’t like using the types their rather than the native Swift data types.

Screen Shot 2016-05-16 at 9.46.04 AM

Other Development Notes

For the UI, I used the standard storyboard screen designer which is shared by both Objective-C and Swift. Like most systems that edit your code, you just need to be careful not to edit the code inserted by the UI designer or they get out of sync and produce weird errors. I changed a variable name generated by the UI designer and it was a bit of a head scratcher tracing back from the error message to what was wrong.

I created the project as a standard single page application and set it to run on both an iPhone and iPad. There are now 12 standard devices of various iPad and iPhone models directly supported, I tried a couple of them, but certainly didn’t test with each one.

Generally, when you make a project you can create any new class in either Swift or Objective-C and have them interoperate. So you can bring in older code rather than porting it.

The debugger is quite nice, its easy to step through your code and see what is going on. Generally, XCode is a very powerful development platform and has a lot of great tools to support you in your programming. I haven’t added any unit tests yet, but I plan to have a look at the testing framework next and perhaps that will be the topic of a future blog.

Screen Shot 2016-05-16 at 9.44.39 AM


I think Swift is a huge improvement for programming iOS and OS/X over Objective-C.  Although Swift is open source and can be run on Linux, the Apple UI frameworks like UIKit are not open source. So I don’t think Swift will be any help in developing cross platform programs (unless they are very simple command line utilities). Swift is quite a modern language and its object oriented implementation is quite nice. Apple seems to be putting quite a bit of effort into Swift with version 3 of the language soon to be released. There is certainly a large community of iOS developers out there who should be putting it to good use.

This was a fun little project and I think I will be spending a bit more time dabbling is iOS development using Swift.

Source Code Listings

//  ViewController.swift
//  KochSnowFlake
//  Created by Stephen Smith on 2016-05-13.
//  Copyright © 2016 Stephen Smith. All rights reserved.

import UIKit

class ViewController: UIViewController {

    // MARK: Properties
    @IBOutlet weak var fractalLevelTextField: UITextField!
    @IBOutlet weak var fracView: FractalView!

    override func viewDidLoad() {
        // Do any additional setup after loading the view, typically from a nib.

        fractalLevelTextField.text = "2";
        fracView.level = 2;

               selector: #selector(textChangeNot),
               name: UITextFieldTextDidChangeNotification, object: fractalLevelTextField);

    func textChangeNot( object: AnyObject )
        if let enteredLevel = NSNumberFormatter().numberFromString(fractalLevelTextField.text!)
            fracView.level = Int(enteredLevel);

    override func didReceiveMemoryWarning() {
        // Dispose of any resources that can be recreated.

//  FractalView.swift
//  KochSnowFlake
//  Created by Stephen Smith on 2016-05-13.
//  Copyright © 2016 Stephen Smith. All rights reserved.

import UIKit
class FractalView: UIView {
    var level = 1;

    // Only override drawRect: if you perform custom drawing.
    // An empty implementation adversely affects performance during animation.
    override func drawRect(rect: CGRect) {
        var frac: KochFlake;

        // Drawing code

        let currentColor = UIColor.blackColor();
        let context = UIGraphicsGetCurrentContext()
        frac = KochFlake(inContext: context!);

        //Set the width of the "pen" that will be used for drawing

        //Set the color of the pen to be used
        CGContextSetStrokeColorWithColor(context, currentColor.CGColor);


        //Apply our stroke settings to the line.


//  KochFlake.swift
//  KochSnowFlake
//  Created by Stephen Smith on 2016-05-13.
//  Copyright © 2016 Stephen Smith. All rights reserved.

import UIKit

class KochFlake
    var tg:TurtleGraphics;
    var context:CGContextRef;

    init(inContext: CGContextRef)
        context = inContext;
        tg = TurtleGraphics(inContext: context);

    func KockSnowflake(level:Int)
        tg.turn( 60 );
        KockSnowflakeSide( level , size:400);
        tg.turn( -120 );
        KockSnowflakeSide( level, size: 400);
        tg.turn( -120 );
        KockSnowflakeSide( level, size: 400);

    func KockSnowflakeSide(level:Int, size:Int)
        if (level == 0)
            tg.move( size );
            KockSnowflakeSide( level - 1, size: size / 3 );
            tg.turn( 60 );
            KockSnowflakeSide( level-1, size: size / 3);
            tg.turn( -120 );
            KockSnowflakeSide( level-1, size: size / 3);
            KockSnowflakeSide( level-1, size: size / 3);

//  TurtleGraphics.swift
//  KochSnowFlake
//  Created by Stephen Smith on 2016-05-13.
//  Copyright © 2016 Stephen Smith. All rights reserved.

import UIKit
let pi:CGFloat = 3.14159;

class TurtleGraphics
    var x, y: CGFloat;
    var angle: CGFloat;
    var context: CGContextRef;

    init(inContext: CGContextRef)
        context = inContext;
        x = 50.0;
        y = 150.0;
        CGContextMoveToPoint(context, x, y);
        angle = 0.0;

    func move( dist: Int )
        x = x + CGFloat(dist) * cos( angle * pi / 180.0);
        y = y + CGFloat(dist) * sin( angle * pi / 180.0);

        CGContextAddLineToPoint(context, x, y);

    func turn( angleIncrement: Int)
        angle = angle + CGFloat(angleIncrement);


Written by smist08

May 16, 2016 at 8:00 pm

Apple Mobile Trends

with 2 comments


With Apple’s WWDC conference just wrapping up, I thought it might be a good time to meditate on a few of the current trends in the mobile world. I think the patent wars are sorting themselves out as Google and Apple settle and we are seeing a lot more competitive copying. Apple added a lot of features that competitors have had for a while as well as adding a few innovations unique to Apple.

The competitive fervor being shown in both the Google and Apple mobile camps is impressive and making it very hard for any other system to keep up.


Cloud Storage

Apple has had the iCloud for a while now, but with this version we are really seeing Apple leverage this. When Google introduced the Chromebook they used this video to show the power of keeping things in the Web. This idea has been copied somewhat by Microsoft. But now Apple has taken this to the next level by allowing you to continue from device to device seamlessly, so you can easily start an e-mail on your phone and then continue working on it on your MacBook. No having to e-mail things to yourself, it all just seamlessly works.

Apple also copied some ideas from Google Drive and DropBox to allow copying files across non-Apple devices like Windows as well as sharing documents between applications. So now this is all a bit more seamless. It’s amazing how much free cloud storage you can get by having Google, Microsoft, Apple and Dropbox accounts.

Generally this is just the beginning as companies figure out neat things they can do when your data is in the cloud. If you are worried about privacy or the NSA reading your documents, you might try a different solution, but for many things the convenience of this outweighs the worries. Perhaps a bigger worry than the FBI or NSA is how advertisers will be allowed to use all this data to target you. Apple has added some features to really enable mobile advertising, whether these become too intrusive and annoying has yet to be seen.

Copying is the Best Compliment

Apple has also copied quite a few ideas from Google, Blackberry and Microsoft into the new iOS. There is a lot more use of transparency (like introduced in Windows Vista). There is now a customizable and predictive keyboard adding ideas from Blackberry and Microsoft. Keyboard entry has been one of Apple’s weaknesses that it is trying to address. Similarly the drive option in the iCloud is rather late to the game.

Apps versus the Web

There is a continuing battle between native applications and web applications for accessing web sites. People often complain that the native mobile application only gives them a subset of what is available on the full web site, but then on the other hand the consensus is that the native mobile apps give a much better experience.

True web applications give a unified experience across all devices and give the same functionality and the same interaction models. This is also easier for developers since you only need to develop once.

However Apple is having a lot of success with apps. Generally people seem to find things easier in the Apple App store than in browsing and bookmarking the web. Apple claims that over half of mobile Internet traffic is through iOS apps now (but I’m not sure if this is skewed by streaming video apps like Netflix that use a disproportionate amount of bandwidth).

Yet another Programming Language

Apple also unveiled a new programming language Swift for mobile development. One of the problems with C, C++ and Objective C programming is the use of pointers which tends to make programming harder than it needs to be. Java was an alternative object oriented extension to C with no pointers, then C# came along copying much of Java. Generally most scripting languages like Basic, JavaScript, Python, etc. have never had pointers.

Rather than go down the road of Java and C#, Swift has tried to incorporate the ease of use of scripting languages, but still give you full control over the iOS API. How this all works out is yet to be seen, but it will be interesting if it makes iPhones and iPads really easy to program similar to the early PCs back in the Basic days.


The Internet of Things

Apple introduced two new initiatives, their Health Kit and Home Kit. Health kit is mostly to encourage adding medical sensing devices to your iPhone, whereas Home Kit is to extend iOS into devices around the home and to control them all from your iPhone.

The Health Kit is designed to centralize all your health related information in one central place. There is getting to be quite a catalog of sensors and apps to continuously track your location, speed, heart rate, pulse, blood pressure, etc. If you are an athlete, this is great information on your fitness level and how you are doing. Garmin really pioneered this with their GPS watches with attached heart rate monitors. I have a Garmin watch and it provides a tremendous amount of information when I run or cycle. I don’t think this is much use for the iPhone, which I always leave behind since I don’t want to risk it getting wet, but this might really take off if Apple really releases a smart watch this fall like all the rumors say.

Home Kit is a bit of reaction to Google buying Nest, the intelligent thermostat. Basically you can control all your household items from your phone, so you can warm up the house as you are driving home, or turn all the lights on and off remotely. We have a cottage with in-floor heating, it would be nice if we could remotely tell the house to start heating up in the winter a few hours before we arrive, right now it’s a bit cold when we first get there and turn on the heat. However with zoned heating we would need four thermostats and at $250 each, this is rather excessively expensive. I think the price of these devices has to come down quite a bit to create some real adoption.

There is a lot of concern about having all of these hacked and interfered with, but if they get the security and privacy correct, then these are really handy things to have.


Apple has introduced some quite intriguing new directions. Can Swift become the Basic programming languages for mobile devices? Will Health Kit and Home Kit usher in a wave of new wonderful intelligent devices? Will all the new refinements in iOS really help users have an even better mobile experience? Will native apps continue to displace web sites, or will web sites re-emerge as the dominant on-line experience? Lots of questions to be answered over the next few months, but it should be fun playing with tall these new toys.

Written by smist08

June 7, 2014 at 4:27 pm

Sage Mobile Service

with 22 comments


Last year at Sage Summit we showed proof of concept demos of a number of mobile applications we were developing. At this year’s Sage Summit we announced that these were now shipping. In this blog posting, I’m going to talk about one of these new mobile applications, namely Sage Mobile Service. This application dispatches technicians to perform work for customers and enables them to get directions, customer information and to collect payments.

Common users of this service would be plumbers or electricians. Where calls come into a dispatch center and they need to be scheduled to visit various sites. There they perform work and can collect payments. Hopefully any companies that perform work of this nature will find this App helpful.

This application consists of three parts: a web application to manage customers and dispatch work orders, an iPhone application for technicians to receive information and take payments and then a connection to your on premise ERP system to share transactions and data.

The Dispatch Web Site

The Dispatch Web Site is a standard web application that runs in any modern browser. From this website you can manage your customers and create work orders for your technicians to perform. Below is the welcome/dashboard home page for this website.


You can get lists of the current work orders along with lists of your customers and drill down into the detailed information of anything listed.


When a call comes in from a customer, perhaps for a plumbing problem, you can enter in all the information and then schedule a technician to perform the work.


As soon as the work order is saved with an assigned technician and scheduled time, it will be available on his iPhone so he can go do the work.

The iPhone App

The technician receives these service call requests from their iPhone via an App. This App lets them know where they should be and when. The App will present a schedule of the work they need to perform today, tomorrow and in the future. This gives the technician an idea of all the work they have to do today and how long they have been scheduled to perform that work. Below is a screen shot of a work order on an iPhone, you can scroll down for more information or tap to drill down for more detailed information.


They can also get additional information on the customer, like their location, directions and contact people. They can also bring up a history of service calls for that customer so they know ahead of time what work has been performed previously.


From the App they can also add work items and parts. So if they need to add their billable hours or add any chargeable parts then they can do this.

When the work is completed, the technician can either receive payment via swiping a credit card through a device attached to their iPhone or they can mark it on account. Of course all sales taxes will be calculated automatically as part of this process. If it’s on account then an invoice will be sent later. Next week I’ll talk about the Sage Billing and Payments web application which can be used to collect these invoices if they aren’t paid on time.

Connected to ERP

Where do the customers come from? Where do the payments made go? The answer is your on premise ERP system. A small connector is installed onto your on premise ERP system which is configured to communicate with your Sage cloud account. This connector will upload information from your ERP like your list of customers to the cloud and will download transactions as they are completed to the ERP. Initially we have connectors for Sage 100 ERP and Sage 300 ERP. We will have connectors for Sage 50 ERP (US and Canada) following shortly.


In the case of Sage Mobile Service all the customer information along with information required to fill out A/R Invoices is uploaded to the cloud and then A/R Invoices are downloaded and inserted into the ERP as transactions are processed in the cloud or on the mobile devices. The connectors for Sage 100 ERP and Sage 300 ERP run continuously as a Windows service and need to be installed on a server that is generally running. The Sage 50 ERP connectors are part of the product and need to be run manually every now and again.

All the requests are queued, so if one system or another is down, things will catch up again once it is available. The connectors only call up to the cloud, the cloud never calls down to the ERP. This means you don’t need to operate a web server and you don’t need to reconfigure your firewall. Installation is very easy and transparent.


Initially we have been rolling this out in North America. We will be rolling this out internationally, but first we have to provide the sales tax calculation engine (currently we use Avalara) and we need to provide integration to local credit card processors. Depending on the region, it might make sense to roll out the service, perhaps without credit card support, but this will be on a case by case basis. Fortunately most regions have simpler VAT type sales taxes rather than the crazy US system.


The world of mobile applications is opening up all sorts of new opportunities to expand ERP systems from beyond hidden backroom offices out into the real world. No one wants to have to enter data twice, so these applications are great mechanisms to get transactions entered directly into the ERP from the point of work and not relying on paper records that are later typed in (perhaps inaccurately). Sage Service Billing is one of our first wave of these applications with more to follow.

Written by smist08

August 10, 2013 at 7:26 pm

Google Forks WebKit

with one comment


WebKit is the underlying HTML rendering library used primarily by the Apple Safari and Google Chrome browsers. It is used in a lot of other projects like the Blackberry Browser, Opera, Tizen, Kindle and even some Microsoft e-mail clients. Even Nokia was a big WebKit user before switching to Windows Phone. Generally it’s been considered a great success, rallying the web around standards and making life easier for web developers.


WebKit is a solid open source project with lots of support. This is one reason it’s so successful. Currently in Internet browsers there are three main HTML rendering engines: the Internet Explorer Trident engine, the Mozilla Firefox Gecko engine and then WebKit.

The big news around the Internet on this front recently is that Google is forking WebKit (meaning starting a new open source project based on WebKit) and then taking it in its own direction with a project called Blink. This raises all sorts of questions: like what it means to web developers? What is Google’s real agenda? Will this damage web standards? Will this slow WebKit development? In this blog posting I want to give my perspective on a few of these questions.


Actually WebKit was started out of a similar controversy. Back in 2001, Apple forked the KHTML/KJS HTML rendering engine used by the browser that is part of the KDE Linux User Interface system. Basically Apple wanted something better and more tuned for its OS X project. The result was the Safari browser built on the first WebKit HTML engine. At the time no one in the Linux community was happy about this, but in the end looking back, success makes everything all right.

So now that Google is forking WebKit, claiming that it’s for the same reasons that Apple forked KHTML, will history repeat itself and a much better HTML rendering engine will emerge? Or will this just fragment the market into more slightly different HTML rendering engines making life more difficult for web developers?

WebKit’s Mobile Success

In recent years, now that Android and the iPhone have completely taken over the mobile phone market, developing web sites with HTML5 and JavaScript has become much easier. This is because WebKit is used in both of these families of devices. This means to cover 95% of the mobile market you just need to target WebKit. This greatly simplifies development and testing. Further WebKit follows web standards diligently, it keeps up with evolving standards, has great performance and great quality.

I think that WebKit has been a major contributor to the combined success of both Android and the iPhone. You can easily browse most websites from these devices. Plus when Apps incorporate browser controls they are using WebKit.

Further both Apple and Google are contributing actively to WebKit. It’s been an interesting combination of co-operation and competition. When new hardware devices come out, initially it tends only be accessible for Apps. But Google tends to very quickly add JavaScript APIs for the device to WebKit. Then Apple tends to follow suite quite quickly. Further each is driven to keep incorporating the latest version into their devices since they don’t want to let the other get ahead of them.

One of the worries of Google forking WebKit and going its own way is that we will lose the competitive nature of Apple versus Google that has been driving WebKit forwards.

Why Fork?

So why is Google forking WebKit? A lot of opinion on the Internet is that this is a strategy to sabotage Apple. I guess Google could be egomaniacal enough to think that WebKit will fail without them participating. But Apple is such a big company with so much money and talent, I think they can do just fine with WebKit, after all they did start it without Google’s help. Further I suspect the army of independent open source programmers that contribute to WebKit will continue to do so and won’t switch to Blink.

Google’s official reason is that the code in WebKit is getting too burdened with supporting code for Safari, Chrome and all the other various things it does. That if they take WebKit and remove anything that Chrome doesn’t use then they will have a smaller, faster and easier to develop code base. Basically they claim they want to move the HTML engine forwards more tightly coupled with their multi-processor architecture to improve security and performance. That doing this while supporting competing architectures within the same code base is getting harder and harder.

When Apple started WebKit and later when Google joined it, both Google and Apple were primarily worried about Microsoft and wanted to have Browser technology clearly superior to Internet Explorer. Now with their success, Microsoft is now pretty well non-existent in the mobile world. I think as a result Google isn’t feeling threatened by Microsoft anymore and is turning its attention to Apple. Generally relations between the two companies have been getting colder and colder in recent years.

Actually Google currently only uses the HTML and CSS rendering part of WebKit called WebKitCore. They stopped using the JavaScript component JavaScriptCore in favor of their own V8 JavaScript engine. The V8 JavaScript engine has been blowing away the competition in JavaScript benchmarks for some time now. In fact the V8 JavaScript engine is also the heart of Node.js the highly successful JavaScript server side processing framework. I think Google is looking to get the same sort of success out of Blink that they got from V8.

What’s the Problem?

The problem is for developers. Right now developing good web pages that run nicely anywhere means targeting IE, FireFox and WebKit which then covers the main HTML/CSS rendering engines. Unfortunately HTML and CSS are very complicated and quite subtle. Although all adhere to the published web standards, there are differences in interpretation. Also there are emergent properties that get exploited as features, things that aren’t really in the standard but have appeared in an implementation.

In the mobile world right now, developers have it easier since they can target Android, iOS, Blackberry, Tizen and Symbian by just targeting WebKit. This makes life much easier since you really can develop once and deploy pretty much anywhere. It will be a pity to lose this, and potentially quite expensive for smaller development organizations.

I imagine that many source code files will continue to be shared by WebKit and Blink. But for how long? When will we have to pay attention between differences between Blink based browsers and WebKit based browsers?


Although I find it appealing that Google is hoping to do for HTML/CSS rendering speed what it did for JavaScript execution speed with V8, I’m really worried that this is going to fragment HTML5 development for mobile devices. I tend to think this will cause more web developers to decide that if I need to develop Android and iOS separately then I may as well do both natively in Apps. To me this will be a sad further fragmentation and polarization of mobile developer communities.

Written by smist08

April 13, 2013 at 3:40 pm

Frustrations in Developing Mobile Applications

with 14 comments


Recently I’ve been talking to many people about various techniques to develop portable mobile applications. In the good old days of the 90s with the Wintel monopoly usually you could just develop for Windows and you would reach 99% of the market. The main challenge was just adapting to new versions of Windows where you would get things like UAC thrown at you.

Now suddenly we are developing for various Windows devices, various Apple devices and various Android/Linux devices. Plus we have some other contenders like Blackberry clamoring for our attention. The market is now highly fragmented and all of these have considerable market share.

I develop business applications and the functionality I’m most interested in has to do with ERP and CRM workflows. This means I’m not writing games, although it would be fun to produce a game like “Angry Accountants” or “ERPville”.

I know I’ve blogged about mobile development a few times like here and here; but my thinking on this keeps changing and I’m still not happy with the whole situation. There are many mobile frameworks and I’m only touching on a couple of representative ones here. I’ve got to think there will be a better solution, but until then I feel like ranting.

mobile device frustration

Going Native

There is an appeal to going native. The native development environments are really excellent. I’ve been playing with Apple’s XCode development tools for OS/X and iOS development and they are really amazing. They’ve progressed a lot since I last saw them over 20 years ago when I worked for a company that did NeXTStep development for the NeXT cube. Similarly Visual Studio 2012 for Windows 8 development is really quite good and so are all the Android tools.

If I only needed to development for one of these, I would be happy with any one of them. But keeping several in my brain at once really hurts.

You get the best results for the given platform with any one of these, but you don’t really get anything reusable except the basic design. All the platforms use a different object oriented extension of C (namely Objective C, Java and C#). All the platforms have different operating system functions and different separations between what you do in the application versus have as a service.

C Reborn

One surprising thing I found from talking to people was that the idea of writing as much as you could in C. All the main platforms use extensions of C and all support compiling and running C code. This reminds me of the old days where you tried to write a portable application for Mac, Windows and Linux by isolating the operating system dependent parts and then writing as much code as possible in good old portable C. Funny how what was old can be new again. But then it was a good idea back then, why wouldn’t it be a good idea now?


Much maligned Adobe always seems to have a proprietary solution in the game. With Flash being booted from most platforms, Air seems to have followers in some areas. Some people really like Adobe development tools, I’ve always found them strange. Like with Flash, uses ActionScript which is a nice object oriented extension to JavaScript, but then that makes it all non-standard. Then strangely you have to structure Flash projects as a movie which I’ve never liked. Air seems to claim to follow standards but then keeps dragging in Flash technologies. My own bias is that if you go down this route, you may as well stick with using JavaScript which is then more standard and more cross platform.

The other problem with Adobe is that they are the leading vendor in producing software with giant security flaws. This means they are more likely to be blocked or dropped from platforms. It is also a big risk for app development since your app could be tarred by Adobe’s problems.


Xamarin takes the Mono project and ports it to mobile devices like iOS and Android. The goal then is that you can develop a C# Windows application that will also run on iOS and Android. We tried Mono as a way to move some .Net projects to Linux, but just ran into too many problems and had to give up. As a result Mono has left a bad taste in my mouth so I’m inclined to avoid this. I also wonder how much code you will have putting the .Net runtime on top of the native iOS or Android operating systems. Is this just going to have too many layers and is it just going to be too fat and bloated?

If they can pull it off with high quality and compatibility there is potential here, but I suspect, like Air, you will just get a big non-standard mess.


Ever since the first Netscape browser we’ve been promised that the web will standardize all programming. Then came a proliferation of web standards and incompatible browsers. Now things are coming back together in the web world. We have good standardization on HTML5, JavaScript and CSS. We have a number of browsers with good support for these and they run on pretty much all PCs, laptops, tablets and phones. So you would think you can just develop once as a web application and run happily everywhere.

Unfortunately all the vendors have a vested interest in their app stores (like iTunes). Vendors like Apple, Google and Microsoft make 30% off all software sold through their stores. They make nothing on people running web applications from browsers. As a consequence quite a few native platform functionalities are held back deliberately from the web. Then they market hard that for the best experience you must use a native app form their store or you are getting a second rate experience. Strangely the reverse is often the case where the app is just providing a subset of some web site and you lose abilities like being able to zoom.

In the current market/environment it’s very hard to compete against native apps with web apps which is really too bad. I think at some point the app store monopoly will fall apart, but that is today’s reality.


Phonegap is an open source library to try to bridge the gap between HTML/JavaScript apps and native apps. It adds a hardware API for JavaScript apps and allows them to be packaged for distribution via app stores. Phonegap was recently purchased by Adobe which really worried me. So far Adobe hasn’t done anything bad (that I’ve seen) and hopefully it will survive as a good open source solutions.

The main risks with Phonegap is that it usually lags the native apps in adoption of new operating system features, Apple may at some point start rejecting apps made with Phonegap and Adobe may start adding proprietary Flash like technology.

Beside these drawbacks the other problem is that your app is still made out of Browser controls and not the UI widgets that are part of the underlying operating system. You can style away a lot of differences but discerning users will be able to tell the difference.

Phonegap is a great technology which does really help JavaScript/HTML apps be more native and is really worth considering if you go down this road.


I’m still frustrated. I’m not really happy with the quality of apps produced by the cross platform technologies and I don’t like developing the same thing multiple times using the native SDKs.

I also find it a bit monotonous to develop the same program over and over again for iOS, Android, Blackberry and Windows.

Written by smist08

February 23, 2013 at 11:34 pm

On Connected Services

with 5 comments

Connected services are a rather generic term that is used in many contexts. Often a connected service is a Web Site that offers a Web Services based API to access. Many times connected services are promoted as add-on services to some core application or service.

In our case we are going to consider the core application service as ERP (such as Sage ERP Accpac, Sage ERP MAS 90/200, Sage ERP MAS 500, etc.). Then we are going to consider various types of add-on services that received over the Internet, making them connected.

Disclaimer – This blog post isn’t meant to describe any specific products or services that are in the works, but to just talk about connected services in general. Anything mentioned is just an example not an indication of a future partnership or product offering. Of course some services like ERP integrations to Sage Payment Services are either already deployed (such as in MAS 90/200/500) or coming soon (April for Accpac).


iTunes is the first wildly successful connected service that got everyone excited. When the iPod first launched there were lots of other MP3 players, most cheaper than the iPod. What set the iPod apart was the iTunes store where you could very easily buy music over the Internet at quite reasonable prices. The end result was that Apple pretty much replaced the music player market with the iPod (including CD players) and further replaced the music distribution industry with the iTunes store. It could be argued that the real genius of t the iPod was taking a music player and connecting it to the Internet to buy music. Others might argue that as people acquired more music, managing it became unwieldy, some companies invented 100-disc CD changers, others MP3 players. After all you can play your regular CDs on an iPod. But even if the iPod had become popular just playing CDs copied from your PC, it became wildly popular due to the iTunes store, which is its connected service.

App Stores

The iPod then developed, becoming the iPhone and then getting a bigger brother in the iPad. Meanwhile the iTunes store developed, offering music for sale, small applications that run on these devices, movies, TV shows, books and so forth. Now most people think more of the part of iTunes that sells applications (the App Store) than the part that sells music.

Branching away from the iPod family there is now an App Store for the Mac computer as a distribution method for Mac applications. Many other people have since copied the Apple App Store to some degree allowing various things to be sold from these Web Stores.

A key feature is that the object bought is immediately transferred to the device where it is run or played and is immediately available. There are many fake App stores where you select the item and then when you hit buy it indicates a sales person will now call you or a DVD will be shipped to you. These services miss the point.

The point is that when you buy, you get the product available to use almost immediately. You aren’t aware of any installation process, you just know it needs a bit of time to download and then away it goes. This really means that the cost of the goods really is the cost of the goods; no more money needs to be spent installing, configuring or otherwise messing around before using it. Of course this isn’t suitable to everything, but as technology improves it is suitable for more and more things. It’s easy to come up with examples that won’t work in this model, but this shouldn’t be an excuse not to do the 90% of cases that will work.

Keeping the size of the applications small, concentrating on volume and eliminating physical production costs has really lowered the cost of applications. But it has also really un-bundled applications. The previous trend was to buy one mega-application like Microsoft Office that supposedly comes with everything you need, but now the trend has reversed and now you buy a collections of smaller applications that combined do everything you need. This prevents buying things you don’t need, such as buying a very expensive package and then only using 10% of the functionality.

Transaction Based Services

Everyone’s dream is to skim some sort of small percentage off every transaction made in the world. This is the allure for things like Credit Card processing services. These are usually categorized as connected services since a Web Service call is made to the Credit Card processor to record the sale. However these aren’t simple add-ons to an ERP system, they are quite complicated integrations and require changes to document processing at several points. The Accpac integration to Sage Payment Services is covered here. A scary SciFi novel I once read (but don’t remember the title or author) had the world government running taxation this way, taking 50% of every transaction; hopefully we don’t reach that point.

Other transaction based services could include sales tax calculation and reporting, income tax reporting/filing, direct deposits and check printing/mailing.


So how can ERP and CRM packages incorporate some of these ideas into their products?

Incorporating Credit Card processing is fairly straight forwards. The goal would be to integrate as many payment methods as possible including Credit Cards, Debit Cards, Gift Cards, Mobile Payments, etc. Basically accept money anyway possible via any hardware device (dedicated, phone, etc.). Other transaction based services like tax calculation, direct deposit and tax filing can also fit this model quite well. Here the sales model is switching from an upfront sale and M&S to a transaction based sales model.

Does an app store make sense for an ERP or CRM package? A common complaint we get is that people would like to use more third party add-ons, but finding out about them, buying them, installing them, maintaining them is a hassle. We get the same complaint for our own extended solutions and options products. An App Store seems like an ideal way to make this all easier. It gives one place to shop for extended solutions, it provides a simple unified way to buy them and then they will download and install automatically. Plus this simplification usually leads to higher volumes and lower costs. TechCrunch published an interesting article on how the Mac App Store greatly increased sales for the EverNotes application: This shows that an App Store can be more than a small incremental increase in revenue, but quite game changing.

The trend in our products recently has been to bundle many options or extended solutions products into the main product. Now we seem to be going through a period of unbundling. The interesting question will be if say we offered more Accpac dashboard widgets on an App Store rather than including them with the core product? Would this cause a lot of complaints? It wouldn’t if they are offered for free, but if we start charging how much can we charge? Will this make a profitable side business? These will be interesting questions and things move forwards.

Sales Cycle

Often connected services can be added to augment standard parts of a typical ERP process. For instance let’s consider a typical sales cycle and the some possible connected services that could augment each part of the process.

You could then do the same thing for other ERP processes. For instance in the HR module you could have various connected services that help with the whole hire to fire cycle.

Free Stuff

Not all connected services have to be charged. For instance automatically drawing a Google Map by every address is a connected service, but thanks to Google, quite easy to integrate into applications and then available for free. Same thing for doing research via a web search and many other things. As we go forwards we will see many cases where ERP or CRM forms are supplemented with information gathered from the Internet.


How do Business Partners factor into these equations? Certainly the role as Business Advisor and Accountant are still as strong as ever. I hope as these sort of concepts move forwards that we do reduce the role of Software Installer and Data Converter. I tend to think that if our Partners are freed up from these sorts of roles they can concentrate on higher value activities like new sales, expanding the role of ERP/CRM in existing businesses and acting as Business and Accounting advisors. One of the big problems we have is that whenever we release a new version, upgrading the entire customer base, far exceeds the Partner channel capacity. We really need to ease this burden so that so much of our Partner capacity isn’t used performing upgrades.


Connected Services are an exciting area. The Web and Mobile worlds are becoming more and more interesting and applicable whether you are running locally installed Windows desktop applications or Web applications that live in the cloud. As ERP and CRM applications move forwards rather than adding all functionality into the core product, far more effort will be going into integrating in all these readily available connected services. The other key part is to work hard to reduce installations issues, so all these things can be installed very simply by a download and putting the files in the right places.

Written by smist08

January 22, 2011 at 5:54 pm