Using Swift to build a simple method for iOS mail applications _swift

In the last few months, I've been doing inboxkit research, which is about the iOS SDK for the Inbox platform. Inbox provides high-level APIs for interacting with mail data, allowing you to ignore imap,exchange,mime parsing and thread detection (and, of course, a lot of other things ...) and make you work on creative app creation. Our goal is simple: try to create an elegant, cross-vendor email application. After all, it's hard.

In Objective-c, Inboxkit makes it easy to create an e-mail experience, so what about Swift? Swift has been formally adopted by the iOS community after WWDC, and I think future SDK designs will certainly include examples of both objective-c and swift writing.

Our first swift example, I want to write a simple app, it's like a Magic 8 ball:

• Show unread thread in Inbox
• When you shake the phone, mark thread as read and show the new thread

(Translator Note: The article thread is not the meaning of threads, in the forum of a post called thread, reply called post. This can be understood as an email)

Using the Objective-c SDK in Swift

Inboxkit has 6000 lines of objective-c code, and we're not going to convert them all to Swift. To compile our swift mail application, I have updated the Open-source SDK, which includes the "Xcode 6 custom Framework". Custom frameworks are a new feature of XCODE6-support for the creation and distribution of third-party frameworks. When the Defines_module flag is set to be available, the custom framework automatically prepares the header file for the Objective-c module for Swift. When Swift compiles, it reads the module header file and maps the Objective-c classes and methods to Swift.

After the Cocoa Touch framework contains this SDK, it is easy to use in Swift. For example, I created a new Swift application, just drag the SDK into the project and add the import Inboxkit to the root view controller.

The Xcode 6 custom frame is great, but currently only Xcode 6 and iOS 8 support. If you are developing an application, you can still choose Pod Inboxkit.

View messages

Inboxkit let's get the mail data from the Inbox synchronization engine easier. We instantiate a inthreadprovider to show the threads from our email account, and have the image of the data needed. The supplier model is a core concept of Inboxkit: they are used to capture the collection of threads, information, contacts, and more. The supplier is somewhat similar to the Nsmanagedobjectcontext and Yapdatabase views in core data-they encapsulate the complexity inside, only exposing a result set that is based on the configuration you provide. In Inboxkit, the supplier pulls cached data from the local SQLite store, and makes the query for the Inbox API Transparent.

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

Copy Code code 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

Since we have created a thread provider, we can use its array of entries to store our views. The provider does not synchronize the result set, so we need to implement the Inmodelproviderdelegate protocol and listen for updates. When a new thread is created in the following ways, the provider invokes the-providerdatachanged method, which includes: 1. Get 2 from cache. Load 3 via API. (a certain time) is pushed to the application via a network packet. Implementing the Protocol ensures that our application always displays the latest data.

There are other proxy methods, such as providerdataaltered: it lets you base uicollection or
UITableView creating a mailbox user interface is simpler, and you can use various inserts to remove animation effects. But for now, we continue to look at some basic things.

Copy Code code as follows:

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 sample program, we want to 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.

Copy Code code as follows:

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,-markasreadqueues This method enables the new API action to enter the queue, which removes the unread label from the thread. The Inthread object and locally stored data will be updated immediately, but this action will be queued on the phone until it can be established
Connection. If the server rejects this action, the local data is rolled back.

We do not need to refresh our thread provider-our work has been done! If the current thread is marked as read, then it no longer needs the standard that satisfies our thread supplier result set. The supplier will automatically
Match its contents and call the Providerdatachanged method, the proxy method we implement will refresh our display to show the first thread in the new collection.

The next step

All right! With just dozens of lines of code, we created an example program that could fetch threads from our inbox and let us mark them as read. Now it just needs a little animation and polishing. You can view the source of the demo from here:
: Swifteightball Sample App

We have only touched on some of the superficial things of inboxkit. Create our Swift apps on top of the iOS SDK, which means we need support for the local class for the model, such as threads and contacts,
And more powerful offline caching because of the SQLite that support deferred threading and message actions.
Look at the iOS SDK documentation learn more about creating elegant applications on the top of the message.