Chris' Blog.

Have you ever seen the term 'MVVM' (Model-View-ViewModel) and been intimidated by yet another acronym in our industry that you don't understand? In this article, I'll explain how you are very likely already doing MVVM, and you'll see how to tidy it up into a neat little state machine.

What you're probably doing

You're probably doing something like this in your view controllers. Nothing wrong with it, it's a good place to start:

class ProductListViewController: UIViewController {
    var isLoaded: Bool = false
    var isLoading: Bool = false
    var products: [Product]?
    var error: NSError?
    ...
}

See those four instance variables? Those are your ViewModel - see, you're doing MVVM already, without realising it - no big deal.

So here's a few stabs at a working definition of a ViewModel: It's the variables that drive what is being viewed. Or the model for what's happening in your views. As opposed to your real model, which has eg Products, Customers, Orders, etc.

Your VC is probably a state machine

A 'state machine' is one of those computer-science concepts that goes pretty deep. But for our purposes, all I mean is that your view controller has a limited set of possible states it can be in.

Here's a good analogy: It's very much like the gear selector in your car, you only have limited options: F, N, R, D (or 1..5+R if you love driving a manual!).

So what are the kind of states you're likely to see in a view controller:

• Loading
• Empty (loaded but there's no data, eg inbox zero!)
• Loaded
• Error
• Not logged in (eg cannot load)

So lets bring the ViewModel and state machine concepts together into one nice package.

Enums to the rescue

Now if the above sounds like an Enum, you're right! So lets tidy up our original bunch of variables into an enum and a single state variable - emphasis on single:

class ProductListViewController: UIViewController {
    enum State {
        case Loading
        case Empty
        case Loaded([Product])
        case Error(NSError)
    }
    var state = State.Loading
    ...
}

One advantage here is that there is zero ambiguity about which state you're in. In the earlier example, it is possible for isLoaded and isLoading to both be true if you make a coding mistake, which is a confusing situation. But with an enum that is simply impossible.

Make the Enum drive the views

Next, I recommend using a didSet handler on the variable to update your UI. Eg:

var state = State.Loading {
    didSet {
        ... update views ...
    }
}

Now it's a simple matter of simply setting the value of the state variable whenever you want your UI to change. Eg your data fetching code will look as simple as the following:

func loadProducts() {
    state = .Loading
    ProductManager.sharedManager.requestProducts(success: { products in
        if products.count > 0 {
            self.state = .Loaded(products)
        } else {
            self.state = .Empty
        }
    }, failure: { error in
        self.state = .Error(error)
    })
}

To make the above example make more sense, here's some example code for the product manager:

struct Product {
    // ...
}

class ProductManager {
    static let sharedManager = ProductManager()
    func requestProducts(
            success success: [Product] -> (),
            failure: NSError -> ()) {
        // ...
    }
}

Table example

And for the sake of a half-fleshed-out example, here's something I commonly do: I have a view controller with a table view. For the loaded state, normal data rows show. For error state, one entire-screen-height cell shows with an error message. For empty state, one big cell with a helpful message shows. And for loading state, we have one big cell with an activity indicator. It all comes together beautifully as we'll go over now:

When setting the state, all that is required to update is to call the table's reloadData method:

var state = State.Loading {
    didSet {
        tableView?.reloadData()
    }
}

The table data source then looks like below. It is responsible for showing one special cell for the loading/empty/error states, as well as the typical product cells:

extension ProductsViewController: UITableViewDataSource {

    func tableView(tableView: UITableView,
            numberOfRowsInSection section: Int) -> Int {
        switch state {
        case .Loading, .Empty, .Error:
            return 1
        case .Loaded(let items):
            return items.count
        }
    }

    func tableView(tableView: UITableView,
            cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        switch state {
        case .Loading:
            return tableView.dequeueReusableCellWithIdentifier(LoadingCell.cellId, forIndexPath: indexPath)
        case .Error(let error):
            let cell = tableView.dequeueReusableCellWithIdentifier(CaptionCell.cellId, forIndexPath: indexPath) as! CaptionCell
            cell.caption.text = error.localizedDescription
            return cell
        case .Empty:
            let cell = tableView.dequeueReusableCellWithIdentifier(CaptionCell.cellId, forIndexPath: indexPath) as! CaptionCell
            cell.caption.text = "There are no products to view today, sorry!"
            return cell
        case .Loaded(let products):
            let product = products[indexPath.row]
            let cell = tableView.dequeueReusableCellWithIdentifier(ProductCell.cellId, forIndexPath: indexPath) as! ProductCell
            cell.textLabel?.text = product.name
            cell.detailTextLabel?.text = product.description
            return cell
        }
    }

}

And the table view delegate is responsible for making those special cells fill the whole screen:

extension ProductViewController: UITableViewDelegate {

    func tableView(tableView: UITableView,
            heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
        switch state {
        case .Loading, .Empty, .Error:
            return tableView.bounds.height
        case .Loaded:
            return tableView.rowHeight
        }
    }

}

And that's pretty much it for this post! Read on if you're curious about advanced enums.

Nested enums

A friend asked me to write about this one: An interesting technique you can use is nested enums. Now it can be a bit over-the-top, so use it judiciously, but here goes:

Say your state machine, when drawn out on paper, consists of maybe two 'top-level' states, but if you drill down there are more subtle states that are possible. Basically a hierarchy of states, like so:

Logged in
    Playing
    Paused
    Stopped
Logged out
    Registered
    Unregistered

You may want to consider nesting your enums like so:

enum UserState {
    case LoggedIn(LoggedInState)
    case LoggedOut(LoggedOutState)
}

enum LoggedInState {
    case Playing
    case Paused
    case Stopped
}

enum LoggedOutState {
    case Unregistered
    case Registered
}

var x = UserState.LoggedIn(.Playing)
var y = UserState.LoggedIn(.Stopped)
var z = UserState.LoggedOut(.Unregistered)

I'll leave this as an exercise to the reader.

Hope this has been helpful!

Did you know that UIApplication.setStatusBar[Style|Hidden] has been deprecated in iOS9? We all know that Apple are ruthless in deprecating old API's, so it's time that we got on board with the new(ish) viewcontroller-based status bar style API's. Here's everything you need to know:

Info.plist

It's now deprecated to have UIViewControllerBasedStatusBarAppearance=NO in your Info.plist file. It was common for people to use this as the 'nuclear option' - that is, you set your status bar style in the plist and it overrides the entire app. I can empathise with developers taking this shortcut but we really shouldn't any more. I recommend removing this key from the plist entirely (as opposed to setting it to YES).

You'll still want to use the following keys to set the status bar style for your launch screen, since the launch screen is visible before any code runs:

• UIStatusBarHidden aka "Status bar is initially hidden"
• UIStatusBarStyle aka "Status bar style"

New API

So we should all now be using the following in (most of) our view controllers. I'll get to why I said 'most of' later...

• preferredStatusBarStyle (white or black status bar content)
• preferredStatusBarUpdateAnimation ("Specifies the animation style to use for hiding and showing the status bar for the view controller")
• prefersStatusBarHidden

In Swift, it looks like doing the following in your UIViewController subclass:

override func preferredStatusBarStyle() -> UIStatusBarStyle {
    return .LightContent
}
override func prefersStatusBarHidden() -> Bool {
    return true
}
override func preferredStatusBarUpdateAnimation() -> UIStatusBarAnimation {
    return .Slide
}

FYI: they have to be overridden functions instead of setting them as variables because they are methods not properties in the UIViewController source .

Note: You don't need to override all these methods every time, only where you depart from the default style, which is black+visible+fade, respectively.

And if your view controller ever needs to change its status bar for some reason, simply call setNeedsStatusBarAppearanceUpdate and change the code in your preferredStatusBarStyle to reflect whatever you want it to look like.

Navigation Controllers

It all gets more 'interesting' when there's a UINavigationController involved. And by 'interesting' I mean 'a little complicated'. But read on and you'll be fine, and hopefully you'll get back to feeling like you're in control of your status bars.

And this is why I said 'most of' earlier - oftentimes, view controllers inside a navigation controller don't need an explicit style since the navigation controller dictates the status bar style.

So here's the rule of thumb:

If the navigation controller's navigation bar is visible, then it is responsible for the status bar

In other words:

• If UINavigationController.navigationBarHidden = false, the UINavigationController's preferredStatusBarX methods are called, after all it is displaying the content under the status bar.
• If UINavigationController.navigationBarHidden = true, the child UIViewController's preferredStatusBarX methods are called, since the child is displaying the content under the status bar.

Here's a twist: If you don't like the above behaviour, and would like your navigation controller to pass on responsibility for the status bar to the child view controllers for some reason, you can't simply subclass UINavigationController, override preferredStatusBarX, and call through to topViewController. This is because UIKit has a private mathod called UIApplication._updateCurrentStatusBarViewControllerAppearance, which in turn calls your nav controller's _currentStatusBarHiddenViewController to get the child, then calls the child directly, leaving your nav controller out of the loop with no way to intervene. So don't bother trying unless you want to burn several hours like I did.

Now, UINavigationController isn't really designed to be subclassed. So you're not supposed to subclass it and override preferredStatusBarStyle to get white status bar content. Instead, the colour of the status bar comes from navigationBar.barStyle: .Default = black status bar content; .Black = white status bar content.

Important: So if you're setting barTintColor to your brand's colour (which you likely are), you also need to set barStyle to .Black to get white status bar content. I'd set barStyle to black before setting barTintColor, in case barStyle overrides the barTintColor for whatever reason.

Modals

Modals act as you'd expect: A modally displayed UINav with a navigation bar dictates the colour via the barStyle, otherwise UIViewController's preferX get called. However, there's one more twist:

Modally displayed UIViewController's only get a say in the status bar if modalPresentationStyle = .FullScreen. Other presentation styles don't get a say in the status bar by default. I guess UIKit assumes that partial-screen modals (eg a UIAlertController) don't cover the status bar - a reasonable assumption!

However, if you've got a custom presentation style modal view controller and you really want it to control the status bar for some reason, you can override modalPresentationCapturesStatusBarAppearance to return true.

That's it! Everything you wanted to know about how to get that status bar to do what you wanted.

Source code can be found here: github.com/chrishulbert/AndroidService

Summary: To make a persistent Android server, you'll need a Wake Lock, a Wifi Lock, and a Foreground Service.

How to use an Android phone as a [web] server

For a change of pace, I've been experimenting with using cheap Android phones as servers. I've been toying with the idea of getting some Raspberry Pis for various uses, however they're quite expensive in Australia, and cheap android phones go for $20 a pop. So i've been playing with them, to see what I could come up with.

So I wanted an android phone that acts as a web server, getting content from a Samba server. The Samba server in my case is my router, which exposes any USB drive via Samba. I wanted it to serve up via HTTP, so that I could use it to play movies etc from. And i got it to work!

You will likely be reading this article for the information about how to run a long-running Android server mainly, and will likely be less interested in my Samba stuff. So I'll skim over that.

NanoHTTPD

I recommend using NanoHTTPD, it's a simple embeddable Java web server. Simply download its JAR, go to the project view, drag it into MyApp/app/libs, right click it and select the option to include it in your project via gradle.

Next, create a subclass of NanoHTTPD for your server. The only interesting method you need to override is serve. For example, here is some stuff I've been doing with it, but of course yours will vary significantly depending on what you actually want to do:

@Override
public Response serve(IHTTPSession session) {
    Log.d("MyHTTPD", "Serve called...");

    String uri = session.getUri();
    if (uri.equals("/api/foo")) {
        try {
            SmbFile smbFile = new SmbFile("smb://admin:[email protected]/usb1_1/");
            JSONArray list = new JSONArray();
            for (String file: smbFile.list()) {
                list.put(file);
            }
            String json = list.toString(1);
            return newFixedLengthResponse(json);
        } catch (Exception e) {
            return newFixedLengthResponse("<html><body>Error: " + e.toString());
        }
    } else {

        // Browse.
        try {
            SmbFile smbFile = new SmbFile("smb://admin:[email protected]/usb1_1" + uri);
            if (smbFile.isDirectory()) {
                String html = "<html><body>";
                // ListFiles seems to be really slow - does that matter once we're up and running?
                for (SmbFile file : smbFile.listFiles()) {
                    html += "<p><a href='" + file.getName() + "'>" + file.getName() + "</a>";
                    if (file.isDirectory()) {
                        html += "<a href='" + file.getName() + "hls.m3u8'>HLS</a>";
                    }
                    html += "</p>";
                }
                return newFixedLengthResponse(html);

            } else if (smbFile.isFile()) {
                String mime = "application/octet-stream";
                String name = smbFile.getName();
                if (name.endsWith(".m3u8")) {
                    mime = "application/x-mpegURL";
                } else if (name.endsWith(".ts")) {
                    mime = "video/MP2T";
                }
                Log.d("MyMedia", "serving: " + name + "; mime: " + mime);
                return newChunkedResponse(Response.Status.OK, mime, smbFile.getInputStream());
            } else {
                return newFixedLengthResponse("<html><body>Not a file or dir, uri: " + uri);
            }
        } catch (Exception e) {
            return newFixedLengthResponse("<html><body>Error: " + e.toString());
        }
    }
}

You've now got your NanoHTTPD server created. It's not android-specific code at all at this stage, next we need to make it work as an Android service.

Service

Next make a subclass of android.app.Service, to fit into Android's ecosystem. This is responsible for the following:

• Starting the NanoHTTPD service
• Keeping the CPU awake
• Keeping the Wifi awake
• Registering as a 'foreground service' so that Android doesn't simply shut us down after a while.

It looks like this:

public class MyHttpService extends Service {

    public Context context = this;
    public Handler handler = null;
    public static Runnable runnable = null;
    PowerManager powerManager;
    PowerManager.WakeLock wakeLock;
    WifiManager.WifiLock wifiLock;

    private MyHTTPD httpd;

    @Override
    public IBinder onBind(Intent intent) {
        return null;
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        // Start the httpd.
        try {
            httpd = new MyHTTPD();
            httpd.start();
        } catch (IOException e) {
            e.printStackTrace();
            Toast.makeText(this, "Service failed to start.", Toast.LENGTH_LONG).show();
        }

        // Keep the CPU awake (but not the screen).
        powerManager = (PowerManager)getSystemService(Context.POWER_SERVICE);
        wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "Httpd");
        wakeLock.acquire();

        // Keep the WIFI turned on.
        WifiManager wm = (WifiManager)context.getSystemService(Context.WIFI_SERVICE);
        wifiLock = wm.createWifiLock(WifiManager.WIFI_MODE_FULL_HIGH_PERF, "Httpd");
        wifiLock.acquire();

        // Become a foreground service:
        // http://developer.android.com/guide/components/services.html#Foreground
        // https://android.googlesource.com/platform/development/+/master/samples/ApiDemos/src/com/example/android/apis/app/ForegroundService.java
        PendingIntent contentIntent = PendingIntent.getActivity(this, 0, new Intent(this, DashboardActivity.class), 0);
        // Set the info for the views that show in the notification panel.
        Notification notification = new Notification.Builder(this)
                .setSmallIcon(R.drawable.ic_sync_black_24dp)  // the status icon
                .setTicker("My service")  // the status text
                .setWhen(System.currentTimeMillis())  // the time stamp
                .setContentTitle("Http")  // the label
                .setContentText("My service")  // the contents of the entry
                .setContentIntent(contentIntent)  // The intent to send when clicked
                .build();
        startForeground(1, notification);

        return Service.START_STICKY;
    }

    @Override
    public void onDestroy() {
        stopForeground(true);
        wakeLock.release();
        wifiLock.release();
        httpd.stop();
    }

}

Potential ARP issues

I've had issues with my server dropping off the network intermittently then coming back hours later. I've been advised this is a bug in the Android kernel not performing a proper ARP advertisement, and have been told to either try a different device, or a newer Android version, or a static IP address, or anything else. You may want to watch out for this. In the end this problem defeated my plans for an Android server but hopefully your mileage may vary.

Main activity

You'll need an activity for your main UI. (iOS friends: an activity is a view controller). In your activity, add a button, and give it a click handler in the layout xml like so: android:onClick="onStartHttpServer".

In your activity class, you'll need to implement the aforementioned method to start our web service. It'll look like so:

public void onStartHttpServer(View v) {
    Intent intent = new Intent(this, MyHttpService.class);
    startService(intent);
}

Thanks for reading! And again, you can find the source here: Source code can be found here: github.com/chrishulbert/AndroidService . Hope you found this helpful, or at least mildly interesting in the case of my typical iOS readers!