I've been doing research on InboxKit for the first few months, which is about the IOS SDK for the Inbox platform. Inbox provides high-level APIs for interaction with email data, allowing you to ignore IMAP, Exchange, MIME parsing and thread detection (of course there are many other things...), and make you devote yourself to creating creative apps. Our goal is simple: to create an elegant, cross-provider mailing app as much as possible. After all, it's hard.
In Objective-C,InboxKitMaking the mail creation experience easy, so what about Swift? Swift has been officially adopted by the IOS community after WWDC. I think future SDK designs will definitely include both Objective-C and Swift-written examples.
Our first Swift example, I want to write a simple app that looks like a magic 8 ball:
- Show unread thread in Inbox
- When you shake the phone, mark the thread as read and display the new thread
(Translator's note: The thread in the article does not mean thread. A post in the forum is called thread and the reply is called post. It can be understood as an email here)
Using Objective-C SDK in Swift
InboxKit has 6000 lines of Objective-C code, and we are not going to convert them all to Swift. To compile our Swift mail app, I updatedopen-source SDK, including "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 available, the custom framework will automatically prepare the header file of the Objective-C module for Swift. When Swift is compiled, it will read the module header file and map Objective-C classes and methods to Swift.
After the Cocoa Touch framework includes this SDK, it is easy to use in Swift. For example, I created a new Swift application and just drag the SDK into the project and add import InboxKit in the root view controller.
The Xcode 6 custom framework is great, but currently only supports Xcode 6 and iOS 8. If you are developing an app, you can still choose pod InboxKit.
View email
InboxKit Let's go fromInbox synchronization engineGetting email data becomes simple. We instantiate an INThreadProvider to display the threads from our email account and visualize the required data. The vendor model is a core concept of InboxKit: they are used to get collections of threads, information, contacts and more. The supplier is somewhat similar to the NSManagedObjectContext andYapDatabaseViews - They encapsulate complex things inside, just exposing a result set, which is based on the configuration you provide. In InboxKit, providers pull cached data from the local SQLite store, while making inquiries about the Inbox API transparent.
Our application will show unread threads from Inbox, one at a time, so we define the thread provider like this:
= NSComparisonPredicate(format: "ANY tagIDs = %@", INTagIDInbox)
= [NSSortDescriptor(key: "lastMessageDate", ascending: false)]
= self
= provider
Since we have created a thread provider, we can use its entries array to store our views. The provider does not get the result set synchronously, so we need to implement the INModelProviderDelegate protocol and listen for updates. When a new thread is created in the following ways, the provider will call the -providerDataChanged method. These ways to create new threads include: 1. Get from cache 2. Loading through the API 3. (At some time) the network data packet is pushed to the application. Implementing the protocol ensures that our application always displays the latest data.
There are other proxy methods, such as providerDataAltered: it is based on UICollection or
It is easier to create a mailbox user interface for UITableView, and you can use various inserts to delete animation effects. But for now, we continue to look at some basic things.
var items = !.items
if == 0 {
// display empty state
= "No unread threads!"
= ""
= ""
= ""
}
if let thread = items[0] as? INThread {
// display the thread
=
=
= ();
....
}}func providerDataChanged(provider: INModelProvider!) {
()}func provider(provider: INModelProvider!, dataFetchFailed error: NSError!) {
(error);}
Mark as read
In our swift sample program, we want to mark the current thread as read when the user shakes the phone and display a new thread. With InboxKit, marking it as read is very simple.
if (motion == ) {
var items = !.items
if let thread = items[0] as? INThread {
()
}
}}
In the background, the -markAsReadqueues method causes new API actions to enter the queue, and removes unread tags from the thread through this behavior. INThread objects and locally stored data will be updated immediately, but this action will be queued on the phone until it can be established.
connect. If the server rejects this action, the local data will also be rolled back.
We don't need to refresh our thread provider - our work is done! If the current thread is marked as read, it no longer needs to meet the criteria for our thread provider result set. The provider will automatically
Match its contents and call the providerDataChanged method, the proxy method we implement will refresh our display to display the first thread in the new collection.
Next steps
OK! With just a few dozen lines of code, we created a sample program that can get threads from our inbox one by one and mark them as read. Now it only requires anime and polish. You can view the source code of the demo from here:
: SwiftEightBall Sample App
We only came into contact with some simple things about InboxKit. Creating our swift application on the upper layer of the IOS SDK means we need to get support for the model for local classes, such as threads and address books.
And offline caches that are more powerful because of SQLite that supports delayed threading and message actions.
have a lookiOS SDK documentation Learn more about creating beautiful and generous applications on the upper layer of email.