2. Running your IOS app against Drupal
We’re going to be talking about building iOS applications today that can run against a Drupal backend. If you’re looking for a different talk, then it might be in a different room.

3. National Practice Lead for Customer Experience
Brian Short
National Practice Lead for Customer Experience
Thank you for joining me today. My name is Brian Short. I’m with BlueMetal, an Insight company. I’m a national practice lead for customer experience, which means I head up our group that creates and delivers customer-facing applications.

4. Who am I? Working with Drupal for 8 years. Red Hat Rodale
Martha Stewart
Human Rights Watch
Penton Publishing
Sony Music and Sony Pictures
Sony Pictures Television
NBC Sports
So my background - I’ve been working with Drupal for 8 years. I did my first project in 2008, working on a project for Rodale, and over the years I’ve been lucky enough to work with a lot of great organizations. These are just a few of them.

5. Who am I? LAMP / MEAN stack focus
National Lead for Customer-facing applications
Includes retail experience and devices as well as traditional web and mobile applications.
Enterprise integrations and deployments
High-traffic, multi-availability zone scaling
So, beyond drupal, I have a general open source focus at BlueMetal, which was originally founded by ex-Microsoft consultants.
Let’s get to the good stuff.

6. What are we talking about today?
Brief overview of mobile applications
Considerations in building a native iOS application.
Where Drupal fits in.
Setting up your RESTful API.
Sending messages from iOS.
Q & A
What are we talking about today?
We’re going to be talking about mobile applications broadly and some of the components of an open source application.
We’re going to be talking about some of the considerations to keep in mind when you’re building a native iOS application,
And then we’re going to be talking about where Drupal fits in.
We’re going to talk about how you can set up a RESTful API for your drupal instance using core and contributed modules.
We’re also going to cover two methods for calling that API from within your application.
And then we’re going to have a few minutes at the end for Q&A. Please though, if you have any questions along the way, feel free to interrupt me.

7. iOS Application Components
Device Software and Connectivity
Authentication
Ok, so let’s talk about some of the components of a modern iOS application.
We start off with the software on the device and how it’s going to communicate with the world. Obviously, if you just have a stand-alone application that has all the data it needs and never needs to communicate outside of the device, then we can stop here, but most applications require more.
With any backend system we need some type of authentication. We have a user representation, and we need to make sure that the user of the application is authorized to access that representation.
We have data that the user generates, and then we have administrative analysis and visualization of the application.
This can be visualizations that show usage and behavior in the application, current state and health of the application, or a representation of data in the system.
What can Drupal be used for?
User generated Data
Analysis and Visualization

8. iOS Application Components
Device Software and Connectivity
Authentication
These three areas.
We could say that the device software itself could come from drupal because we have things like PhoneGap and DrupalGap, but today we’re going to be talking about native applications.
Let’s look at questions and recommendations in these three areas.
User generated Data
Analysis and Visualization

9. Authentication Use SAML, if possible
Don’t reinvent the wheel. Use a library.
Today we’ll use basic authentication…
So, authentication.
My recommendation here is to use SAML, if possible. Oauth is also a fine choice, and any decision between these two technologies is going to come down to what you currently have in place, what you and your teams are used to, and what role Authentication is going to play.
We’re not going to get into the particulars of SAML today, and in fact we’re going to see a couple of examples that use basic authentication.
My other recommendation is, like with a lot of areas, use a library. You can go and build a custom SAML integration, but you should do it for the right reasons.

10. User Generated Data Be careful of what you’re accepting.
Cleanse all data before it’s persisted. Don’t rely on the client to pass valid / safe content.
Log everything you can.
Use caching, but understand its limitations.
If you’re only storing comments, consider SaaS options.
Performance
Spam
User generated data.
This is really a bucket that contains any data that the user is sending to you deliberately. Site metrics don’t really fall into this area, but personal user data might, and for a lot of sites, there’s a definite need to allow users to contribute more complex kinds of content.
This could also be pictures, text, movies. The same rules are going to apply to any type of content.
1. Always be wary of anything coming from the user. You have good users, you have bad users, and you have malicious users. Take a stance of only allowing the types of content that you absolutely need to. If you’re just accepting comments and simple text, then don’t allow html. If you need to allow HTML, then only allow the tags you need. Don’t ever accept Javascript unless you’re running a Javascript tutorial site.
2. Clean any data before it gets persisted. Check it on the client side, just to make the user experience better, but make sure you check it on the server side, before it can ever touch a database. Because once it’s in the database then it’s going to quickly be available to other users.
3. Log everything and cache everything you can, but understand that caches are no good if they’re getting constantly invalidated.
4. And finally, if you’re only storing comments, give serious consideration to SaaS options. Running a commenting system is hard, especially if it’s open to the general public, just ask Youtube.
and you could spend your time doing something else.

11. Visualization and Analysis
Visualization module!
Consider contributing!
Consider offloading data to separate processes.
Distributes load
Allows post-processing and better normalization of data.
Vis.js can be a good option here.
And then finally we have visualization and analysis.
I’m not going to spend a lot of time here. It could really be it’s own talk or conference track. I will point out that we’re lucky enough to have the Visualization module and if you have time to contribute, please consider helping with this one.

12. Let’s get started
Ok, so let’s make an API.

13. Implementing the API Use JSON Don’t reinvent the wheel. Use a library.
Think about your RESTful API. You (and your users) are going to have to live with it.
Make appropriate use of request methods.
Today we’re going to be using Drupal core and a couple of contributed modules to make our API.
Obviously you could roll your own or create an API layer using something like Node, but those are deeper topics and outside the scope of today’s talk.
I have a couple of recommendations:
Use JSON instead of XML. This is more of a religious stance than anything else, but in today’s world there’s a lot more utility to JSON. It allows better communication with front-end frameworks, everything understands it, and database handling of JSON is robust.
As with authentication, use a library, if possible. Today we’re using drupal core modules.
Give some serious consideration to the RESTful API that you’re creating. People, including you, are going to have to live with it for a long time. Also, give some thought to how it relates to your data representation. Today’s API is going to use request methods to create nodes. Think seriously about whether you want to expose your node structure to your consumers. You should consider creating an abstraction for the API, then your API and your content types can evolve somewhat independently.

14. What do we use? Core Modules HAL HTTP Basic Authentication
RESTful Web Services
Serialization
Contrib Modules
Rest UI
Ok, so what are we using today?
We’re using four core modules and one contrib module.
We’re using HAL (Hypertext application language), HTTP Basic Authentication, the RESTful web services module, and the serialization module.
We’re also going to be using the REST UI module, which does exactly what it says it does.

15. Where do we start? Update rest.settings.yml
Look in sites/default/files/config_xxx/active
Set up permissions
Install Rest UI
Test!
So where do we start?
Enable the modules, and then update your rest.settings.yml file.
It should be in sites/default/files//config/active. If it’s not there, you can create it.
Set your permissions, install the REST UI, and that’s pretty much it!

16. Configuration! So let’s configure some things
In the REST UI config, you should get a Content resource right away. If you don’t, then you need to check your rest.settings file.
You can edit the resource and you’ll get…

17. Configuration! Something that looks like this.
Node that there are choices for supported formats and how authentication will be handled.
I recommend you use hal+json or json.
Note that Hal+Json is just a serialization of HAL. There are differences in how data is reprsented using the two approaches…

18. Configuration - Permissions
Just a reminder to make sure that the permissions for your site make sense.
You probably don’t want to allow certain methods from certain types of users. Make sure that your

19. Content List - Before
Ok, so this isn’t a very busy site. Let’s take a look and see what content we are starting with.

20. Testing – Let’s create a node
We’re going to use the REST tester in chrome to do our initial content creation.
Some things to keep in mind:
1. Make sure to set your content type to something appropriate. In this case we’re using HAL + JSON. You could also use JSON, if you wanted to make sure your drupal instance allowed that. Remember that you can set it in the REST UI.
2. Make sure your request method is set properly. With this tool if you set it to GET then you can’t create a body, which makes sense.
3. I’m using basic authentication and sending the username and password every time. I’d urge you to use SAML or Oauth instead, if you can.

21. Testing – Let’s get a node
And, then, to make sure we have everything, we can check to see if the node got saved.
Note, that we use a GET method instead.
In this case we’re still passing our username and password.
And we can see that we can successfully retrieve the node.

22. Content List - After
And, then let’s check the Content List, and we see that our node is in place.
You may want to tightly control how content is published, especially if you’re allowing nodes to be created that overlap with your main content types.
Maybe there’s an approval?
Questions?

23. On to iOS!
Ok, now let’s see what this looks like in iOS

24. iOS Questions
There’s lots of approaches to writing iOS apps. What’s the right one for my application?
Why not PhoneGap? Why not Xamarin?
Objective-C or Swift?
What devices should I target?
Do I build for the Apple Watch?
What about notifications?
There’s questions you’re going to ask yourself when creating iOS applications.
Why not phonegap? Maybe Xamarin is the right thing?
They certainly can be. The thing you want to always be thinking about is what type of experience do you want your users to have. There’s a tradeoff between experience and speed of development, and generally I think it’s worth it to get the experience right first.
Your first few users are your most important users and you want to leave a good first impression.
You’re also going to wonder what language is the right one to use.
What devices are we talking about? Providing a huge zoomed in UI on an iPad which was originally created for a phone might not be the great experience.
What about the watch?
And finally, what’s my notification strategy.
Well we have answers for some of these.

25. Our Approach Use libraries, when possible. Don’t reinvent the wheel.
Write native applications.
Swift, not Objective-C
Generally, our approach is similar to any development.
Don’t reinvent things that other people have built.
where possible, let’s write native applications
And, Let’s try and use Swift instead of objective-c. It’s more accessible and more people will be able to repurpose your code, if that’s your thing.

26. Alamofire Built on NSURLSession and Foundation URL Loading System
Top level methods like Alamofire.request use a shared instance of Alamofire.manager
Simplifies code drastically
One library I’d recommend you look at is Alamofire.
Who has rolled their own REST consumer? I didn’t include the code here because it wouldn’t fit on one page.
Alamofire is open source and gives you code simplification that you’ll appreciate.
Here we see some sample code for logging a user in. It’s short, it’s to the point, and it’s probably readable even if you’ve never looked at Alamofire or looked at Sift.

27. Alamofire (continued)
Here’s a longer version of what we did before. This is a node creation snippet that does what we did before in the REST tool
It provides the right headers, it creates the body, and it’s then posted to the right endpoint.

28. Other Options?
But do we have other options?

29. Drupal-ios-sdk https://github.com/kylebrowning/drupal-ios-sdk
It’s all Objective-C
Only for use with Drupal…
Yes. There’s another library called Drupal-ios-sdk
It’s all objective-c, and it really only allows integration with drupal. So, it might be a fit, but it comes with caveats.

30. Drupal-ios-sdk (continued)
Here’s a basic session with login info being created.

31. Drupal-ios-sdk (continued)
Create a user
Update a node
And here we have the creation of a user in the first example, and the update of a node in the second.

32. Drupal-ios-sdk (continued)
Create a comment
Get a user
Get a node
And here’s some additional examples.
We have the creation of a comment on a node
Then retrieving a user and getting a node.
It’s fairly straightforward, and if you’re building everything in Drupal, and it will always be in drupal, then this is a great choice. If you want to implement a more robust API, then it might not be the right choice for you.

33. Q & A
Questions

34. Thank You http://www.bshort.com/nyccamp2016 Twitter: @bshort
Thanks. I’ll be posting the updated presentation shortly!
| Boston / New York / Chicago | (866)