Why read email when you can peek?
A demo app built using Office 365 APIs
Imagine if you are away from your desk for prolonged amount of time, or simply on a vacation. You still want to read email, but you’d really want to receive only the messages you really care about.
Email Peek is an iOS demo application we created using O365 APIs that does just that.
How did we do it?
Authenticate using Azure Active Directory
The ADAL iOS SDK provides a super simple programming model for signing in Azure AD users to our app and consuming the Office 365 APIs. We used the ADAL iOS SDK in conjunction with the Office 365 iOS SDK to manage all of the authentication and token management in our app.
Fetch and send email using Office 365 APIs
We used the Office 365 iOS SDK for Objective C to integrate Office 365 REST APIs and to communicate with the Outlook services to do the following.
- Fetch email
- Send email / replies
With the simplicity of REST, you don’t need any specialized Exchange, SharePoint, or Azure AD knowledge to access Office365 services.
You can program directly against the REST APIs to interact with Office 365. If you use the REST APIs, you’ll need to write and maintain code around managing authentication tokens, constructing the correct URLs and queries for the API you want to access, and other tasks.
The Office 365 iOS SDK take the Office 365 REST APIs a step further by encapsulating token management, and many of these mundane tasks so you can just focus on the functionality you want to enable in your app. We used the SDK to fetch email as well writeback to the server while sending replies and storing custom data.
Do server-side processing as much as possible
In Email Peek, we chose to perform most of the operations server-side to optimize the performance of the app. We did this by using server-side filtering offered by the Office 365 APIs.
When you fetch data from an Office 365 service such as Outlook, you can use the $filter query parameter to specify search criteria.
Email Peek uses filters to fetch only the email messages that match the settings configured by the user. For example, Importance eq ‘High’ selects only the messages sent with High importance.
We also use logical AND and OR to combine the many different filter clauses we need to match the criteria in the Settings.
Load only what we need
We load only what we need in each view to maximize the responsiveness of the app.
Office 365 APIs return a lot of rich information. In the case of mail messages, usually the body of the message is very dense with information and rich HTML data.
So initially when we fetch the mail messages from Outlook to present the messages on the home page of the app, we only get the subject, sender’s email, timestamp and a few other pieces of information necessary for that view. We fetch the body of the message only when the user taps a message to view its contents.
Store custom data on the server
Office 365 API entities such as “Mail”, “Contacts’ , etc. currently offer a Category field which can be used to store custom name/value pair data on each item.
We used this feature to mark an item as read in Email Peek and also mark it as hidden from Email Peek if the user hides an item in Email Peek. When we fetch items from Outlook, we make sure to exclude items that are marked as hidden and this way, we avoid using client side local data storage and any additional client side processing that would be required to hide items or figure out the read/unread messages.
How you can do it too
Integrate Office 365 APIs into your own app to connect to data stored in the cloud.
- Get users’ mail, calendar, contacts and files data, with more REST APIs coming soon.
- Use on any platform. We provide SDKs for iOS, Android, .NET and Cordova.
The complete source of this demo is available on GitHub now.
