If you used our QuickStart guide, we may have breezed past some of the details about all of the different parts that combine to form an app using Clutch. This article should serve to highlight each part of the system, how it works, and how it all fits together.
The way the suggested directory structure looks is something like this:
MyApp/ MyApp/ MyApp.xcodeproj Clutch.framework MyApp/ clutchmyapp/ clutch-core/ global/ myscreen/ index.html screen.js style.css clutch.plist
If you have a directory structure that looks different, that’s fine, but this is the one that the QuickStart guide will start you with. (The most common way that yours could differ is if your clutchmyapp directory is in a different spot, or is named something different.)
First, there’s the outer MyApp directory. This is honestly just a container to hold the inner two directories, so that they can both be checked into a single source code repository. Feel free to rename this container directory to anything you want.
Inside that container, there’s an inner MyApp directory which stores your iOS XCode project and the Clutch framework, as well as an inner inner MyApp directory which contains your actual native Objective-C code. This is pretty straightforward.
The second reason that this folder needs to be linked into your app as a folder reference is due to the clutch.plist file contained within. This file is used to store configuration. You can use the ClutchConf module to access the contents of this file, and then later you can update this configuration file remotely without having to push out a new application. This might be used, for example, to determine the text to display on a native button.
The only thing that changes from normal iOS development is that instead of using a XIB or interface builder to build your UI layer for some screen, you can have Clutch help you to use web technologies instead.
That means, you carve out an area that you want to be able to update dynamically, and in that UIViewController‘s loadView method, you simply instantiate a ClutchView and add it as a subview.
Then you use our bridge layer to pass any important events from the Clutch view back into the Objective-C layer, and handle those events natively.
So there’s this whole step that you did where you entered in your phone’s identifier and associated it with your account, but what was that for?
It allows Clutch to enable development mode. Nobody writes perfect code on their first try. We know that there’s a back-and-forth where you want to experiment, try out a change, see how a CSS tweak looks, and you don’t want to send that out to your users every time. Instead, we provide a development mode which, when it sees your specific registered phone, it doesn’t serve the normal app using the normal methods.
Instead it connects to your local computer, to your working set of files, and renders what you’ve written–rather than what you’ve deployed. On top of that, it shows a nice toolbar that lets you know you’re in development mode, and gives you the option to quickly refresh the ClutchView, so you can avoid lengthy recompiles or re-navigating back to that same screen that you’re viewing.