Build a simple iOS mail application using Swift

In the last few months, I've been doing research on InboxKit, which is about IOS SDK on the Inbox platform. Inbox provides high-level API for interacting with mail data, allowing you to ignore IMAP,Exchange,MIME parsing and thread probing (among other things...). And commit yourself to the creative creation of APP. Our goal is simple: to create as elegant, cross-provider mail as possible. After all, it's hard.

In Objective-C, InboxKit makes it easy to create a mail experience, but what about Swift? Swift has been officially adopted by the IOS community since WWDC, and I think future SDK designs will definitely include both Objective-C and Swift samples.

Our first Swift example, I want to write a simple app, which is like a magic 8 ball:

      shows thread unread in Inbox       when you shake the phone, mark thread as read and display the new thread

(thread is not a thread. One post in the forum is called thread, and the reply is post.)

Use Objective-C SDK in Swift

InboxKit has 6,000 lines of Objective-C code, and we're not going to convert them all to Swift yet. To compile our Swift mail application, I updated open-source SDK to include "Xcode 6 custom framework". Custom frameworks are a new feature of Xcode6 - support for the creation and distribution of 3rd party frameworks. When the DEFINES_MODULE flag is set to available, the custom framework automatically prepares the Objective-C module header for Swift. When Swift is compiled, it reads the module header file and maps the Objective-C classes and methods to Swift.

Once the Cocoa Touch framework includes this SDK, it is easy to use in Swift. For example, when I create a new Swift application, I simply drag the SDK into the project and add import InboxKit to root view controller.

The Xcode 6 custom framework is great, but currently it's only supported by Xcode 6 and iOS 8. If you're working on an application, you can still choose pod InboxKit.

Check email

InboxKit makes it easy to get mail data from the Inbox sync engine. We instantiate an INThreadProvider to show the thread from our mailbox account and visualize the required data. The provider model is a core concept of InboxKit: they are used to get a collection of threads, information, contacts, and more. The provider is somewhat similar to the NSManagedObjectContext and YapDatabase views in Core Data -- they encapsulate the complexity internally, only exposing a result set based on the configuration you provide. At InboxKit, the provider pulls cached data from local SQLite store, while making queries to Inbox API transparent.

Our application will show the unread threads from Inbox, one at a time, so we define the thread provider as follows:

 

var provider:INThreadProvider! = namespace?.newThreadProvider();

provider.itemFilterPredicate = NSComparisonPredicate(format: "ANY tagIDs = %@", INTagIDInbox)

provider.itemSortDescriptors = [NSSortDescriptor(key: "lastMessageDate", ascending: false)]

provider.delegate = self

 

self.threadProvider = provider

Because we've created a thread supplier, we can use it the items array to store our view. The supplier will not synchronize access to the result set, so we need to implement INModelProviderDelegate agreement and to monitor updates. When the new thread is created by the following way, the supplier will call - providerDataChanged method, which create a new thread way includes: 1. From the cache to get 2. Through API loading 3. (some time) through the network packet is pushed to the application. The implementation agreement to ensure our application is always according to the latest data.

There are other proxy methods, such as providerDataAltered: it makes UICollection or
UITableView makes it easier to create a mailbox user interface and can use various insert and delete animations, but for now, let's move on to the basics.
 

func refreshInterface() {

    var items = self.threadProvider!.items

 

    if items.count == 0 {

        // display empty state

        self.subjectLabel.text = "No unread threads!"

        self.snippetLabel.text = ""

        self.participantsLabel.text = ""

        self.dateLabel.text = ""

    }

 

    if let thread = items[0] as? INThread {

        // display the thread

        self.subjectLabel.text = thread.subject

        self.snippetLabel.text = thread.snippet

        self.dateLabel.text = formatter.stringFromDate(thread.lastMessageDate);

 

        ....

    }}func providerDataChanged(provider: INModelProvider!) {

    self.refreshInterface()}func provider(provider: INModelProvider!, dataFetchFailed error: NSError!)  {

    self.displayError(error);}

Mark as read

In our swift example, we mark the current thread as read and display a new thread when the user shakes the phone. With InboxKit, marking as read is very simple.
 

override func motionEnded(motion: UIEventSubtype, withEvent event: UIEvent!) {

    if (motion == UIEventSubtype.MotionShake) {

        var items = self.threadProvider!.items

        if let thread = items[0] as? INThread {

            thread.markAsRead()

        }

    }}

In the background, the -markAsReadqueues method enqueues the new API action, which removes the unread tag from the thread. The INThread object and the locally stored data will be updated immediately, but the action will be queued on the phone until it can be created
The connection. If the server rejects the action, the local data is also rolled back.

We don't need to refresh our thread provider - our work is done! If the current thread is marked read, it no longer needs to meet our thread provider result set criteria. The provider will automatically
Match its contents and call the providerDataChanged method, and the proxy method we implement will refresh our display to represent the first thread in the new collection.

Next steps

Good! In just a few lines of code, we created a sample program that takes threads from our inbox 1 and lets us mark them as read. Now it just needs a little animation and a touch up. You can see the source code for demo here:
: SwiftEightBall Sample App

We've only touched the surface of InboxKit. Creating our swift application on top of IOS SDK means we need to get support for local classes for the model, such as threads and address books,
And an offline cache made more powerful by SQLite, which supports delayed threads and message actions.
Check out iOS SDK documentation to learn more about creating elegant applications on top of your email.