 So yeah, I guess we can go ahead and get this thing started. My name's Kyle Browning. This is the native mobile application development talk. I'm going to start off talking a lot more about some concepts for developing your applications and kind of what you should be focusing on when you start working on your app and the things that you should be aware of when you're working on them just in a general native sense, not so much as a direct connection to Drupal, but it does save you some time and energy in the end. So this is just kind of an overview of what I'm going to talk about today. I'll kind of explain some whys and why nots for native. I'm sure most of you are here because you want to do native application development. But it's good to know the ins and outs of the whys and the why nots for both sides of titanium and things like that. I'll go through some development process stuff. I'll kind of give you an idea of what the mobile stack looks like, where Drupal fits in, where the phone fits in, and I'm going to give you an overview of services, which is I'm going to cover it kind of lightly because there is a services talk right after this one that will go into much more detail about what exactly services is and how it works. But I will give you a good enough ground so that you can understand what's actually happening. I got some tools in libraries that I want to show you guys and then I'll get to the examples and sometime after that we'll do QA. So I wanted to start with why not native. I think that titanium and being able to support multiple devices and pushing to multiple devices, that's an absolute need and you need to do it really quickly. Developing natively might not be something that you want to do. Also, if you're rapidly prototyping something, it's a lot easier to write JavaScript than it is to do a bunch of memory management stuff. Again, it's just not as hard. When you're writing it with titanium or app accelerator or any of those, you just write a bunch of JavaScript and it builds down and pushes to all the other devices and it's just a lot easier. It makes you want to go down that route. Some of the problems that I've had with titanium are like just APIs didn't exist that existed in native code that you could write Objective-C with or Java. That was always kind of annoying that I couldn't have the latest and greatest stuff. Then there was memory management problems that they still haven't solved and things like that. I personally like to do native development. Why native? I've got a lot more talking points here, but it's faster performance on the device. I've always felt that way. You have a lot more control over what you do. The things that you're working on are actually supported by the operating system makers like Android or iOS. You can go on to their bulletin boards or their forums and make support requests. They'll actually help you with what's going on. Whereas titanium, you're kind of like with Drupal. We're left up to the community and sometimes that can be extremely frustrating, so it's nice to be able to pay for something and you actually get support. Like I said, you're not waiting on API updates. Maybe you're going to write a game that's OpenGL because I don't know why you would use Drupal as a backend for that. And then six, for me, it's obviously a personal preference. So just talking a little bit about the development process here, you want to get your idea onto a piece of paper and the reason for that is so you just kind of get it out there and try and figure out what exactly you're building. And then I move on to the wireframe space. Design is not really something that I do, but I think the design is a really important part and the engineer that's working on any app should be aware of what's going on there and then finally your actual development. Getting it on paper will basically help the entire process just go a lot more smoother because you know what you're building and it's not necessarily a moving target and that's why all of these are good ideas. It's way easier to fail on an app in your wireframe. I've built in so many apps that kind of didn't have wireframes. It was kind of like, oh, I want to work on this and I want to work on that, so I go build it and then I'm like, that doesn't really work, right? So if you do these things, you kind of lay it out. I have it easier to fail on wireframes twice because it's important. There's things like briefs, which is not necessarily a wireframing application, but it will allow you to write sort of a config file that will show images and you can actually walk through the entire app that you have with just images as opposed to building it out and actually taking all that time and then realizing that you don't want to do something a certain way. Examples are like, I don't know, logging a user in, like sometimes that's an important part of your application and you want that to happen first, but you've kind of buried it in the setting somewhere and it's not really usable, so you wouldn't really notice that unless you're actually on your device moving these things around and interacting with your app and that's why I have briefs here and things like Omnigrapher will definitely help because you can walk through the workflow of your application. I'm probably not going to spend too much time on design, but there's some concepts here that need to be thought out. Is it going to be on multiple devices? You need to attempt to create a user experience that's similar across your website and your mobile device, so that's an important part of the process and I think that you guys need to, like the developer needs to be involved in that because things change and sometimes the designer doesn't really understand the concepts behind the actual development. So yeah, you kind of want to figure out what your features are for the entire app when you start building and then you kind of have already done this step if you've done the wireframes and the design and all of that and you should have a pretty good idea of what kind of resources you might need and that's a services term that I'll explain when I get to services. But I personally like to build an API communication layer that is basically just all of the API calls that I'm probably ever going to make in a file or maybe some sort of hierarchical subclass type system on whatever environment you're developing be it Java or Objective-C. And that's always given me like a nice, just one place to go to change an API call, add parameters, whatever it's in one spot and they're all there so you can just kind of go through and change them. If things are constantly changing I highly encourage you writing tests for this API communication file that you've written and there are tools that write that for you for Drupal but I'll get into those later. And you want to tackle the larger, harder problems first because you can be like, oh, well we can just bang out all the easy stuff and then when you get to week three and it's the final week of the app and you don't really have any time to work on this large, hard problem because it needs to be on the store on Friday and so it can be on the store next week. So I highly encourage tackling the harder problems and those are usually like session management just being able to log in the user and things like that. Maybe you're doing more complex things like creating types of content on the fly like writing your own content types and stuff from an app. I mean, that's like a really complex thing so you want to make sure that you get that working first and then move on to the easier stuff because it's easier, right? So this is kind of the mobile stack as it stands right now. There's Drupal, you know, it's kind of on the bottom and then there's the services thing that sits in front of it and then you have your mobile app and that's pretty much it. There's some things that you can interject in between these if you need to, obviously, but that's more or less it. So I just wanted to talk about services a little bit which is it's basically, you know, an API for Drupal and it allows you to get all sorts of different response formats so if you have different devices or things that maybe you don't want to include well up until iOS 5 but pre-IOS 5 you didn't really want to use JSON because every JSON serializer was a piece of crap and would crash your phone. But that's fixed. So I just kind of listed some things here and this is actually taken from the module page but it gives you your connection into Drupal and you're going to be spending most of your time making calls and messing around with services and services module and so it's definitely a part of this talk. I'm just kind of going to go over what servers are, authentication, how that kind of works, end points and some versioning and then I'll just kind of touch on some things that might be of interest to you. So servers are kind of like this, they're kind of like you basically define what you want to accept response formats like for example you create a server and I'll go through and create one later but you create one and you say I only want to accept application slash JSON and I'm only ever going to return application slash JSON and then you say I want to do session authentication which is just basically PHP cookie session management and that's pretty easy to deal with or you can go with something more complex like I'll often get into those in a little bit and then it's the actual object that will execute the function call that you might be writing. Some of you will probably use the standard services resources and it's probably something to talk a little bit more about in the services talk but resources are for example we have a node resource and that takes care of everything that we want to do about a node. We can retrieve nodes, we can create, save, update, delete and those are your basic CRUD functionalities and when the server basically takes care of sending the call to whatever function that it is based on the path or the parameters that you've given it and things like that so it's kind of what makes things run. And then you know authentication is probably an important part of I'd say most apps. You might be writing some consumption based things that really only pull in views and nobody is really creating content or tagging content or uploading photos or things so you don't even have to select an authentication if you want and everything can remain anonymous. One of the gotchas with that though is you'll be making a call and you don't have session authentication turned on and you're like why am I getting 401 unauthorized and it's a permissions thing usually and sometimes it's not fun to track down. I mentioned singletons here because when you're writing these apps you're going to have a user object that's going to exist through the entire app so you want one instance of this object and you don't want to create any more otherwise you could have people that you might... it just kind of gets confusing and things like that so I've always told people that singletons are the best thing for authentication because your user object is not going to be changed and you don't really want it to. You might be doing some user update stuff but that's like the only time that you would update the user on this singleton object and so when you do that, when you attach this object most of your calls through your application can just pull that user object from that one thing and then you have a user anywhere inside of your application as opposed to making the call to Drupal and checking that they're logged in and things like that like you don't want to really be doing that so it's nice because you don't... like I said right here you don't... if you do it right which I will definitely go into you don't need to log in when the app opens. Endpoints are another services term and they're basically the URL that gets generated when you start setting all of this up it's basically a configuration object they have all of the resources enabled on them you actually enable the servers on them as well and what authentication methods you want what response formats that you're going to accept which ones you're going to return all those things are handled on the endpoint and that's kind of where you can start doing some cool things with like versioning and maybe you want to give some developers access to one thing and some developers access to another thing and you need to separate that out and endpoints allow you to do that so versioning is in a feature branch on versions and I just wanted to lightly touch on it because I think it's really important one of the problems that you'll run into when you're building this API or turning these resources on for your endpoints and stuff is that you'll break something your app that's on the app store will literally break because you added a required parameter or you'll just have unintended features I can't think of the word but basically you don't want that happening and versioning allows you to say hey this is API version 1.0 and in your client code your session management code which is all in that one doc that you wrote with all of your API calls you can just say hey I want to point at 1.0 and then when you're sure 1.1 is working and everything is good to go you update everything to 1.0 and your app will be good when you update to 1.1 everything will be good but these people that still have the 1.0 version they'll be able to access all of the old information that existed in the 1.0 state and it's kind of a complex thing that we do on the services side but it's in a feature branch and it's definitely going to be there and I highly recommend checking it out and we'll talk about more of that in the services talk these are just kind of some example calls I think that slide is kind of out of place but curl is something that you can kind of do in any programming language so this is just the curl command line and what it would look like to get all nodes by topic ID 8 or that's not supposed to say get by topic but the second example's supposed to be like user login and it's really neat when it's all working so some things to note views has been in like this weird services views has been in a weird experimental state for some time but it's actually been very cleaned up there's no issues in the issue queue and one of the things that I was talking about with versioning is if you start using views to manage the content for your apps you could break your app again by removing a field or maybe you turned on content permissions and now you no longer have access to that field and your users are like why the hell can't I see my content so when you're using views you really want to make sure it doesn't change and I suggest using something like features for lack of a better module there's just some problems with Dom and I were just talking about this actually with changes on production that kind of get overridden and things like that but features basically allows you to take that view and put it in some strong algorithm code and make sure that it's in code and not necessarily the database so that nobody really mucks with it and if anything ever breaks god forbid you just go hit the reverb button so you just have to really be careful with views another question I constantly get asked is images inline body content so let's say you're using like a wissy wig editor on your site and like your content editors are just like throwing their sunset picture that they took last weekend on the site so that HTML gets put into this into this node and then when you display that content body in the app you're like why are there HTML tags in here you know so what we have done on the services side is basically there's a module that's in the sandbox right now that I've been working on that basically is a solution that we worked out where we'll strip the images out of the content and basically attach it to the node as if it were a file actually attached to the node so that when you do like a node get those images are just attached to the node and you can like throw them on the sidebar or if you want you can put a little tag that you strip out and put the image in yourself with you know whatever but you get more control over where those images go you know a lot of the times you don't want them in the middle of your content body on like the iPhone or so I highly recommend using image cache you know just because it's awesome and I guess in 7 you don't really have to install anything because it's core these are just a couple of tools that I wanted to tell you guys about and talk about a little bit there's those URLs are kind of hard to read and I apologize but I'll leave the slide up for a bit while I talk about them there's the there's a the Drupal iOS SDK which is basically and I have a mobile stack picture here for it that just kind of sits right in front of services in your mobile app and Dios and Dandy are both libraries for the iPhone and Android so that you can natively communicate with Drupal extremely easily and they're there there to help you move things along faster so the iOS SDK has all this code written to do your session management and your user management I mean I'm sorry they're the same thing but do your user management get all of your nodes, get views basically everything that's in services core is supported by both of these libraries and you can get your app up and running in way at most time because you're not worrying about all of the things that I've been telling you that you need to do the majority of it I still write that API communication file but it just calls functions that exist inside of these libraries so another great one is services log which just kind of hooks into services and logs everything it it'll allow you to see that when you're you know getting a 401 unauthorized it's because you you know you don't have the permissions to access it or something along the lines of you know you sometimes you basically need to be able to see what's going on like you know you forgot a field and you can't figure out why so you turn logging on it's a lot easier to go through Drupal watchdog than it is to you know dump objects in an editor and crawl through them and stuff I like the way I raise look and watch dog personally so now I just kind of wanted to show you guys some of this stuff and maybe see if there's any questions yet there's a microphone in the middle of the room if anybody wants to walk up and ask a question otherwise I'll just continue on did everyone get a chance did anyone need to see this slide any longer so the examples that I'm going to be are all on the iPhone just because I don't have an Android emulator on my Mac but this is sort of you know you get into native development I don't know what you guys are familiar with and things like that but this is sort of you know your environment that you're in all day so I'll just go through and show you guys kind of what services looks like and stuff and what you need to do to kind of get your app up and running so I'll just go right here to services this tools example is actually supplied by a module but services API is one I wrote I'll just make a new one but I'll be using this one during the demo just because I know it works and I don't want things breaking while I'm showing you so when you add an endpoint it's pretty standard we give it a name so we'll just call it new endpoint and then you select your server like I was talking about you have multiple options this was REST or XMLRPC there are others like I said there's SOAP and multiple others but we're just going to stick to REST because it's a lot easier than XMLRPC in my opinion and we'll just do your path to the endpoint is and I realize that's kind of hard to read but your path to your endpoint is basically what you're going to call when you make these calls to your API this debug mode is add some zoom out here the debug mode basically adds on some extra watchdog functions that are useful it's kind of a work in progress I think services log does a much better job than services actually does and then you choose your session authentication methods and I guess I didn't really talk a little bit about OAuth it's something that you guys are interested in because in services 2x there was this API key that everybody loved but there was like we would just get security advisories like once a week because it was just a really complicated way of handling all of that so I highly recommend using OAuth you can use what's called the two-legged authentication method which is find your requests and send it off or if you want to get fancy and you have like a I mean it's a prime example Facebook does it, Twitter does it they all do it three-legged OAuth authentication which is hey this is who I am I want access on this other site and they send you to that site and then they say hey log in we need to verify that you're you and then when you log in yeah you were verified and now you have a user object and you don't really have to give your login credentials to like it basically was created so that you didn't have to give your login credentials to other people like a developer that wrote an app could be malicious and just record all of that information over the course of time whereas with OAuth it sends you to the original site and you don't really have to you trust that site obviously if that gets broken into then you have bigger problems but you basically trust that it's a lot like open ID but for APIs so I'm just going to choose session which is like I said standard PHP cookie stuff can't have spaces so let's just do new endpoint and so yeah this is all on C tools so you're probably pretty familiar with this if you use views the server settings here is basically your response formats and I can't get it all on the screen but actually there we go so you have your selection of response formats JSONP is not selected by default because it's kind of you have to know what you're doing there it allows you to do cross site requests with javascript and things like that so it's turned off by default same with application XWW formula code there's some security implications there that people need to be aware of but that's not for this talk I'm just going to leave on what's on but for the application we only need JSON so yeah I don't even need to do anything there there's no settings for session authentication if you were using OAuth this is where you would select your context for hey this is what consumer context that you want to use for this for this endpoint so you can say one endpoint is session authentication and that's trusted people and then everyone else gets to use OAuth these are a list of all the resources that I was talking about and this is kind of like where it gets into what you're actually how you're actually interjecting data interjecting data into Drupal I'm just going to expand this real quick and you can see the API version stuff because I have it checked out this is a list of everything that we can do with comments we can create, retrieve, update, delete and index them and then we can do give me a account of all of the numbers on a given node which you could argue that it should be in the node section it's just this is where we put it and then count new the number of new comments on a node you know pretty standard stuff here I usually just turn these all on but on a production site you probably don't need to turn on file maybe because they're not uploading something file is basically the same thing and one thing to note here there's a create raw function because currently the create function uses a base64 encode which is kind of bad on mobile devices really because you have to you have to base64 encode the entire file so if your file is like 5.5 megs you better hope you have that in memory available to base64 encode that and if you don't your apple crash so create raw function uses a multi-part forming code and you have to just another gotcha you have to enable that in the server down here so that's just an idea of what resources are I'm just going to go ahead and turn all of these on just for funsies and then there's obviously the export this is all based on ctools so you can do some hooks and get all of the stuff encode there's a little bit of work on the ol side to get that configuration management encode but services is all ctools based so it all works so here is just basically it's the site I'm going to clear cache just because I always do it let's clear it twice and I just have a question here that I did and I wanted to work a lot more on this app than I had the time to do but I tried to think of an app that might you know show a lot of things and what I came up with was a question app so that you guys could ask questions during the during the speech but unfortunately I didn't have time to get either of those on either store so that's not happening but I have an app here that I can show you on my emulator that's sort of those exact questions that you saw the test one is anonymous you can do all sorts of things register and log out and I'm going to go ahead and attach this to my Xcode real quick so yeah you know if we go in here and we delete that test node that I made that's pointless you can actually see that when we rerun the app here it's not there anymore so this is all using DOS the library that I was talking about earlier and it uses this file right here which let's see if I can have a much better screen resolution than this projector so I know this code probably looks like very scary but this is like the basis of the node object and this gives you all the things that you can do to communicate with Drupal so here's a node save you just basically pass the node and it will call your session it'll post to that path that gets generated based on some static variables that I have set it'll call it delegate I've actually updated this to use blocks a lot better but I didn't have time to do it for everything so that's kind of the heart of the DOS library and the node part of that I don't even know how to get that back really? alright so we'll use this so just looking at some other ones just like adding a content question which I'll do here in a moment this is the create a question function let me make that bigger for you it's pretty straight forward objective C code nothing fancy here just kind of creating a hashed array or a dictionary and sending the data off as you see here there's some tricks to filling in the content for services because it all uses Drupal form execute or form submit whatever it is in 7 now whatever it is in 6 so you have to basically build your node exactly like it looks on the develop screen if you have a where a lot of people get confused is if you have if you look in 7 at least if you look at field body which is a field now it has a language array an indexed array inside of that and then another hashed array inside of that that has like raw values and safe values and things like that you know so you have to actually build all of that and send it off but it's pretty straight forward if you just look at the develop tab and you know how to build basic array structures in whatever language you're using be it java or objective C you should be fine just making an array with objects with the question body text and setting some keys like let's see if I can go down there the value and you know the value and there's that UND that you see there is that easier to read you guys are awfully quiet anyways UND you see there that's that language variable that I was talking about that exists in 7 and it's kind of really annoying but it is what it is so yeah we just call our we instantiate our DOS node object and then we in it with our delegate which will basically that's going to change a little bit but for right now it'll call back node save did finish down here and that's kind of where I you know I could probably be doing a lot more things here but I hide the heads up display and then I I check that the status is true and if it was then I'd dismiss the screen let's just show that really quick like I said I'm not a designer so don't laugh at my program so since nobody had any questions I'll have to make one up we'll just do you know why does base64 encode how about why is base64 encode so lame and I added a session name just because I was going to try and make it usable for all of the sessions but I didn't want to start I basically didn't want to do all of the work of getting all of the session information and importing it into this Drupal site if I had DrupalConChicago.com's database or sorry DrupalCon Denver would have been a lot easier anyways and then the question would probably be this is just like an extended field so I'm just going to that's not what I copied whatever I wasn't logged in so my username is not showing up I apologize for that I should have logged in but as you can see it added the node it refreshed and did everything it was supposed to do and if we go back to Drupal there's our node so it's pretty straightforward thank you the same stuff exists for Android so don't worry about that but I just wanted to show you guys kind of an example of all of that and I think that that's kind of where I want to leave things off and see if there are any questions come right up we've got an app that we're building it's still in the in the wireframe design stage but we've got nodes that we're wanting to push that are going to have somewhere between 60 to 100 images and node and video and so one of the challenges that we're going to have is to try to push these things and handle the potential of a dropped connection or different things like that so I don't see that we're going to be able to push we've got to find a way to not atomically in the database sense of the word push especially the image and video data do you have thoughts on that challenge I mean obviously you can do all sort not necessarily with the images but one thing I didn't mention is caching and caching your responses and stuff like that but yeah I mean that's a tough problem and you definitely don't want to load all of that for every node every time it comes up you know and so I would probably write a custom resource to get to just basically you could probably use views to do it but I would write a custom resource that batch to those images and gave me the ones that I wanted I would try and solve it that way if you need all of the images for the node then you need to figure out how much you're going to display to the user and actually do the batching yourself I'm actually talking about pushing the images from the iOS device to that's my concern okay so this user is going to select 100 images on their phone right so they're doing an inspection of a piece of equipment for example I want to take pictures and we've done some tests with the challenge we were into and breaking connections just trying to figure out you know Drupal is kind of difficult to just upload a piece of information per node unless you get down to database or make the fields are required to do some kind of junk stuff yeah I mean that's a tough problem you're going to need to batch the sending basically and do it in the background you know unknown to the user and if anything fails just run it again later you know and make a note that it failed and try and figure out why and if it's just a network thing you know it sucks but we can't really do anything about that and compressing the images obviously helps do you have any thoughts or experience with exposing Drupal search or solar through a mobile app I have done some testing with exposing the search form which would give you basic search I don't know how that would work with with solar but I would imagine since solar does the same exact thing using the search form that the integration would be very very similar but services doesn't expose services does not expose by core there might be a contrib module that does and we're more than willing to support anything that's in core Drupal but we're not going to all of the maintainers agree that we're not going to support things like 5-star that's for 5-star to do they use our API to write the integration and the same can be said for solar but for core Drupal search we definitely want to have that in there and it's just not done so could you do something like exposing it through I know there's solar for views so you could maybe expose it that way yeah you could probably do that because all we do with views is a views execute and grab the results you know so can you mention two strategies either code generation from javascript or writing your own full native application what about native HTML HTML5 applications wouldn't that sort of solve the problem about missing libraries you can melt at least a non-nandroid you can melt the local APIs to javascript to have any experience with the native HTML5 applications I have done some native HTML5 application stuff the we just need to write a javascript library that does the same shit that deos and dandy do basically and then that problem will go away but yeah you can definitely make those same let's say you're using jQuery or whatever you can just make a request to the URL and it will return your response and I can show you some of those responses if you want I think I have one up right here this was I was changing stuff but I was going to create a node here so this last response here was I logged in and that was all of my information so you can see my session ID you can see the set cookie getting returned when it expires and all of that stuff I might be out of date here but could you give an update on OAuth and security I understand like OAuth 1.0 was hacked right and services originally supported so what is the status of OAuth OAuth 2.0 is not final so what is the status of using OAuth with services so it works I've tested it in both 6 and 7 7 is a little bit more wonky with OAuth because I actually just recently picked up maintainership and I haven't gone through the issue Q yet but it does work OAuth 2.0 will be supported when it comes out when that happens I don't know right now it's not in the pre-draft or whatever it is is not in and it's only OAuth 1.0 but they work in both 6 and 7 yeah so Friday my day consists of a documentation sprint for both services and OAuth hopefully we can get through most of that and if anyone is willing to come help that would be awesome because we're the developers of the stuff and sometimes we use the app because we know how it works and that kind of makes your documentation poor quality because you just using your app and using your code you kind of get accustomed to how it works and then you just kind of skip over that step when you're trying to explain it to other people so yeah yeah well the talk that's going on right now with Carl Larry Garfield Garfield the whole WSSCI initiative whatever it's called is trying to do that they haven't really been in communication with us about getting services into core using the same methodology or how did we solve these problems and we've tried to be involved in the past and we just kind of didn't really get it going anywhere so we just refocused our efforts on making sure that services is great quality code and that it works so I would love to see the basics of services in core but you know if that happens it's going to depend on the community yeah actually that was one of the questions I wanted to put in the app so the question was ASI HTTP request in DEOS and ASI HTTP request is no longer supported by the original developer of that CF networking library for iOS so the code that I have written actually rewritten that is in a feature branch for DEOS which is supposed to be DEOS 2.0 uses AF networking and they fully aim to support ARC and this fully supports ARC on iOS so I've already moved it all over to AF networking and gotten rid of ASI HTTP request so you can download that now and mess around with it it's all in a feature branch on this GitHub page yeah you're going to have to rewrite it I didn't really do any sort of backwards compatibility because session management is handled differently in AF networking and they kind of take care of the cookie stuff for you so I also wanted to get rid of I wanted to make it fully asynchronous and so DEOS 1.0 is not by default but you can do sort of things like network operation queues and things like that but yeah for sorry I lost my train of thought there but yeah does that answer your question or okay yeah so if you yeah you're going to have to rewrite it I'm sorry but that's why that's why I suggest putting it all in that one file because you really have to touch that that updates everything for your API and as long as the responses are the same you should be good to go anything else? alright well thanks for coming out guys I appreciate it