iOS with C# using Xamarin
Dunn, Craig
Learn how to build an iPhone app with C# using Xamarin.iOS. We'll write a native iOS app using familiar tools like Xamarin Studio and Visual Studio, plus new features like the UI Designer, Component Store and the latest C# syntax. Along the way we will structure the code for easy sharing with Android and Windows apps.
 Hey. Welcome, everyone. Thank you for coming down to hear about how iOS apps can be built with C-sharp using Xamarin. My name is Craig. I work at Xamarin as a developer evangelist, and today we're going to have a quick introduction to what Xamarin is and see how it works. So why Xamarin.ios? Why are you here at this session? Xamarin lets you write C-sharp apps for iPhone, iPad, and for the iPod. So if you're a Microsoft developer and you're a no C-sharp, it gives you a vector into a massive ecosystem of devices and apps that's really easy to monetize through with your existing skills and potentially with some existing code. That code that you write with Xamarin.ios can also potentially be shared with other platforms. So you can target Android as well with Xamarin.Android, and you can also use the C-sharp code that you write that's not directly user interface related on Windows phone, on Windows Store apps, and potentially also desktop enterprise apps anywhere else that you've got C-sharp doing calculations or database access or network access, really anything that's not directly touching the UI. The reason that you don't reuse the C-sharp that's directly touching the UI with Xamarin is because you write a custom UI for each platform. So the benefit of that is that using native UI widgets and your apps look and feel native. They look and feel native because they are native. There's no interpretation, there's no cross compiling. What we build is an actual ARM binary that runs natively on the device at full speed. The entire iOS SDK is available to you in C-sharp. So there's no features that aren't available because they haven't been provided by us as a tool provider. We've got complete coverage of everything that's available to normal objective C developers. So things like StoreKit, things like iCloud, all that stuff is supported by us. When new iOS releases come out, so iOS 7 is in beta at the moment, we do our best to get that stuff available to you as quickly as possible during the beta period, which we couldn't talk about anyway. When it's released, we generally have the same or next day availability. When iOS was released last year, we released the full production quality support for iOS 6 on the same day. Finally, Xamarin.io doesn't limit you to just using C-sharp. So if you've got objective C libraries that already exist or you find an objective C component on the web, you can also still bring that in to your Xamarin project, create a linking or binding file that we call it, and access that objective C code as well. So it gives you really unlimited power to develop iOS apps using C-sharp and then expanding out into objective C if you ever needed to. How does it work? Xamarin is based on Mono. So you may have heard of Mono. It started out in 2001 as a project, super quickly after Microsoft announced the existence of.NET and the fact that they were going to open, well, submit it to ECMSA as a standard so that other people could implement it. It was released in 2004 and its original goal was simply to be a C-sharp and.NET implementation that runs on Linux. And it's been around since that time, so the platform itself is very mature. But I don't think anyone realized in 2004 that less than 10 years later, the two major mobile platforms would also be based on a similar kernel and would provide a way for us to use Mono to host applications on mobile devices. So we've got Mono,.NET framework in a C-sharp language. How do we get that onto the phone and enable iOS development? We have a layer which we call bindings. Microsoft calls some projections in Windows RT. And what it does is it exposes the underlying objective C SDK as C-sharp. So any public class or object that's available in iOS for objective C developers is available to you in Xamarin and it looks and acts just like a C-sharp implementation. So you can subclass, you can override, you can treat the iOS SDK as a C-sharp framework. And as I mentioned earlier, you can also incorporate your own objective C, creating your own bindings similar to the ones that we ship for the native SDK. And finally, bringing together the.NET framework and the bindings and your code is a compiler. So for iOS, we compile to native ARM binary, which means that what you submit to the Apple App Store is to Apple pretty much indistinguishable from what an objective C app would look like. It's compiled down to exactly the same stuff. Because we're shipping a Mono runtime as part of your app, we also include a linker so that unused code, one of the beauties of strongly typed languages, can be detected and removed from the final application that you distribute. So we keep the size of your final app down as small as we can. Visually what I just said kind of looks like this. So you start with your C-sharp and the.NET framework that's running on Mono. We compile that to.NET IL just the same as you're familiar with for desktop.NET or for Windows, phone.NET. Then we ahead of time compile that entire set. So the.NET framework and your code sitting on top of it, linking out the stuff that's not being used into a native ARM binary, that goes to the App Store, you know, it goes to your device during testing and runs natively on Apple's hardware. So how can you get Xamarin to give it a try? We have a really simple installer. You can download it here. It will put everything on your Mac and or on your PC that you need to start development except for Apple's tools. So we can't redistribute them on their behalf for obvious reasons. So install our stuff, go to developer.apple.com slash iOS and download Xcode or actually you can get Xcode from the Mac App Store. Join the developer program and once you've installed those two things, you're ready to go building C-sharp apps for iOS devices. So Xamarin's development environment support encompasses a couple of different options. If you're on Mac OS, we have our own IDE called Xamarin Studio and it runs on iOS. It also runs for Android development which I talk about in a session later today. But if you scan across this line for iOS development, you can also develop iOS apps for iPhone and for iPad within Visual Studio. The Xamarin Business Edition includes a Visual Studio plugin and with a Mac sitting somewhere else on the network, you can do all of your development within Visual Studio, share code with other projects. It's the same project, the same file format and the Mac sits in the background and does the compilation and stuff that we need to do with Apple's compiler and software. So that looks kind of like this. We've got Windows, Visual Studio running on that and the Xamarin iOS Visual Studio plugin running inside Visual Studio. It provides Visual Studio with all of the bits and pieces that it needs to know about to build an iOS application. So it's a special project type. It has special project settings for iOS specific features, a special debug pane, deployment panes, output coming from the iOS device that you might be testing on. And that stuff talks to a Mac, somewhere on the network. So you do need to have a Mac available where you've installed Xcode and where we remote all of the compilation and all of the code signing, anything else that must be Mac specific because that's Apple. But you get a complete development experience within Visual Studio. So here's a quick screenshot of what the two IDs look like. Xamarin Studio and Visual Studio, they should feel very familiar for your Visual Studio user and you just want to work on a Mac. You'll feel right at home with Xamarin Studio. It looks a bit XCode-y in terms of the way we've got a simplified toolbar, but the solution structure is the same. References work the same way. The code editor works the same way. IntelliSense, all that stuff. If you want to work within Visual Studio, there's an iOS application inside Visual Studio being developed. So you can have very sharper, you can have what other tools you like. You can use TFS for source control and still be building an app that's going to run on Apple's hardware. One of the caveats for that running everywhere right now is that if you want to do drag and drop user interface design, we currently integrate with XCode for that. So if you want to do drag and drop UIs, you really need to be doing it on the Mac. What we are doing and what we've already announced at our conference earlier this year is an alpha version of our own drag and drop user interface designer. So that's XCode, a bit of skew it on your left. And this is the alpha of Xamarin's own user interface designer on the right. So when that user interface designer that we're building is complete, it will also be available on Visual Studio. So from within Windows, within Visual Studio, you'll be able to design and build iOS apps from start to finish. For the moment, it's in alpha like I said. So if you're in Visual Studio, your options for building your user interface is basically all code. You'd be familiar with that, particularly if you've done Windows Forms, newing up controls, setting their coordinates and adding event handlers to them manually. So a lot of developers do that anyway, even when they've got a visual designer available to them. So that's your main option for Visual Studio at this stage. The things that we add to Visual Studio and that our own IDE has on top of your normal.NET development are things that Apple needs to know about. So iOS specific options. The first one is code signing. So part of Apple's requirements for getting code onto a physical device is that it's signed. You manage that on a Mac through the Keychain app and through Apple's website. And we provide an interface that lets you choose the certificates or allow us to choose one for you based on certain criteria. And that's available on both platforms, obviously. And like I said, the code signing is delegated to the Mac host if you're running in Visual Studio. We also completely duplicate, sounds bad, we completely duplicate all of the configuration settings that Apple provides in Xcode. So things like the app name and version number, but also supported device orientations, splash screens, icons, all sorts of other stuff that's specific to iOS apps. You can set it all visually from within either Xamarin Studio or Visual Studio because we've provided the same user interface that Objective C developers are used to. And also deployment. So you can deploy to the simulator for testing, you can deploy to a device for testing, and you can also package up an app for distribution to the app store or from within Visual Studio or from within Visual Studio. So rather than just talk about Xamarin Studio and show you some slides, we're going to do a demo, live coding, what could go wrong. We're going to build a really simple app. If you've ever looked at the Xamarin website before, you will recognize that they're really simple to do list application. The main reason we use it as a demo is because I can build it in less than 100 lines of code. It has a database and it uses a couple of different aspects of the operating system that will help you get a little bit familiar with it, but also understand how easy it is to build iOS applications with C sharp. So we're going to just run up Xamarin Studio and do file new project or hit the new button. That seems big. So we're going to choose to do a storyboard application because I'm going to show you how the drag and drop editing works. So new in-competit application gives you what you'd expect. A few files and directories that if you hit run, will actually start something up right now. So that's a working minimal application. The things that it gives you that you never really need to look at or change are a main file. So static void main, common entry point for any sort of application. You never need to look at that. And an app delegate class, which is the first iOS specific thing that you're going to see. When you're building more complex applications, you will override some of these methods in the app delegate, but we're not going to need to do that for today. Just be aware that the app delegate is the first thing that's really starting up. That's the first part of the app, the first time that you get to write custom code for doing things like parsing inputs that might come if your application's been started from a link or from another application. For now, we don't need to know anything about it. The application does have another startup parameter though, and that is the main interface storyboard here. And this is just to give you a quick preview. This is some of the settings that we provide, which are equivalent to the Objective C slash X code user interface settings. So some of the folders, references folder you're familiar with. It's exactly the same as if we're in Visual Studio. We can reference only DLLs that have been compiled for Xamarin.ios. They're not their IEL, just the same as what you would expect, but they need to be compiled for Xamarin.ios so that we know that we're providing the same features that that DLL supports. We are in the process of fully supporting portable class libraries, and at that point, you'll also be able to reference a portable class library DLL from your application, which brings a whole host of options for the types of code that you can import. So a Visual Basic DLL that was compiled for portable class libraries would be able to be included in your IOS application. I'll skip the components directory because we're going to come back to that later. And just have a quick look at resources. Resources is an Xamarin.ios concept that we use to provide a simple place for developers to add media and, you know, any non-code assets to your app and keep them sort of organized in one place. So I'm going to just quickly dump in all the icons and splash screens that we need. And most of those get picked up by the application because there's a naming scheme, which we don't need to talk about now, but trust me, it works. So that's going to bring us down to the storyboard because that's the user interface. The first thing that's going to happen in this app is the storyboard is going to get run. So let me open it first in Xcode. And first thing I'm going to do is delete the whole thing so we can start from scratch. This is what Objective C developers are used to when they build applications using this tool. So I'm just going to drag on a navigation controller, which is a frame that enables that back and forth user interface paradigm that people with iPhones will be familiar with. And it's dropped on a table view, which is that scrolling list that also everyone's familiar with as the default initial screen. And I'm going to, because we're building the to-do app with a list and a detail view, just going to add another screen next to that and kind of try and lay them out nicely. So the user and face works pretty much as you'd expect. You can edit these values. I'm going to change the type to basic type so that it's got a title because we want to set that text. I think we need, based on our design, a button to create new tasks. So plus icon is going to be cool for that. So that's the design finished for the first screen of our application. It's going to have a list of cells that we can scroll and touch and also a button to create a new task. So to wire these buttons up so they actually do something, we can just drag to the screen we want it to go. So we want the new button to go straight into the detail screen so we can start adding a new task. And similarly, if we touch on something in the list, we want that to go to the same screen because we'll be editing that task. So I've got two arrows here now that indicate indicating that we can move from one screen to the next. Apple calls them segways. So not the thing that you lean forward with wheels, but the definition is like moving from one discussion point to another. Anyway, segway makes sense. We need to name that, I'll give it a call that one new task and that one edit task. And now we need to design the second screen of the app, which is going to be editing a task. So once again, it's going to be about dragging on a couple of controls. And trust me, we will get to some C sharp at some point. A switch, whether this task has been done or not. And let's say a button. And it's going to, the button is going to be the save button. And that's pretty much all the UI work we need to do. The last thing I almost forgot was to give our cell a name, task cell. You guys, I'm not sure if you can see that. There's a few different settings you can make. And also, I want to get rid of that chevron. So I'm going to just change that to none. Because we're going to have a tick there when the tasks are complete. So the last thing we're going to do is give the classes themselves names. So this is going to be task list view controller. And I'm going to call the next one task view controller. View controller is optional. You don't need to use Apple's naming conventions for stuff like that. What we're doing is saying that we're giving a name to this class so that that's what we can refer to these screens as when we have them in code. I think I've wired everything up. So let me close that. And when we come back to Xamarin Studio, yeah, I really wanted to see an error. We'll see how we go here. That class was the default one, so I can delete that. And you'll see it's created two new classes for me. These are the two classes that relate to those two screens that we've just created. And they've got a backing file which is really similar to a designer.g.cs in XAML. It's a way for partial classes to support adding controls which you can refer to in code later. If we hit run, there's the application. It doesn't actually do anything yet except the controls work as expected. But you can navigate between those two screens. So let's actually do some C sharp. To finish off the user interface, one thing that we will need to do is give the controls themselves names. So we've created a save button and a text input. But we have no way of referring to them in code yet. So I'm going to do that from within our Xamarin designer. So what you're seeing here is not X code. It's the custom Xamarin designer which in the future will be the preferred way to work with these things. And I'm going to give that, I can zoom in a bit here, title text. And I want to call the switch. Done. Done switch. So this, you know, you're designing an iOS screen here. But really the way you're selecting things and setting properties is really just like any other iOS, other windows. User interface designer, dragging stuff around and using the properties pane to manage the way things look. So let me save that. And let's go now and just have a look at the designer file. And we should see all the switches done switch save button. Title text. Wait for that to appear. So now we've got a user interface. It's basically a wide up. It's time to start doing some C sharp. So we'll start with the task view controller, which was the detail view. And at the moment, it's a partial class. It's got those controls in the back in class. And I'm just going to that safe button still isn't there. Did I mention this is in alpha and it's worked three times today. But there we go. Now we've got all three backing fields there. So this is the cool thing about override view load. And when you're using Xamarin Studio, you don't even have to code most of the stuff because the autocomplete you used to from visual studio is there. It's the same, but it's providing autocomplete over the objective C class library. So when I do view override there, it tells me that a view controller has all these options, including view did load, which is the one that I want. It tells me based off view did load should be in there already puts it there for me. And then I'm just going to do save button dot touch up inside, which is their version of on click. We're not going to go into all the details. And then I can just add an event handler. And I can implement it. So for now, I'm just going to put to do need to save task here. And then navigation controller. So basically, that's a very dot net way of making a button do something. There's an event handler, we sign an expression to it. And all it's done now is a to do. And then the navigation pop to root is basically just go back to the previous screen. That's a 100% C sharp thing working on this iOS stuff that's underneath the covers that doesn't have event handlers doesn't know anything about C sharp. But this, this just works. So that's one way that, you know, C sharp familiarity comes right into any sort of iOS development. We'll come back to implementing save later. In the task list screen, we also drag those two arrows which were called segways to help with navigation. But you might have started to wonder already, how do I know which row was clicked on when that that segue happens? You know, I've just dragged from some, some undefined row across to say this is the screen that you open. So there's a method which I'm just going to quickly make appear called prepare for segue. So we actually named those segways for a reason. This screen is going to get a message every time a segue is triggered. And this little if statement gives us the structure to react to, to which segue has been hit. So the new task one, we're going to start the new screen, we can probably just start it because we don't know what the task is anywhere. We'll new one up later. And the edit task there, I'm going to add some code there to find out which row was clicked. Find that task object that we're going to create and then send it on to the next screen so that we're actually editing the task that we that we clicked on. So I just said the task object, we don't have a task object yet. So let's quickly create a business object that we can start to work with. I'm going to put it in a file called core, because the code that we're going to write now, and it's not much code, could be shared. So there's the task class. And I'll just quickly added a couple of properties. So our task has an ID, a title, and a done. That's all that we need to represent. And we want to save this in a database because it's going to be more than one task to fill that list. So I've thrown in a couple of things. If this was a database, I would want that to be the primary key. I would want it to auto increment and become a table somehow. That's where the Xamarin component store comes in. So SQLite is built into both of the platforms that Xamarin supports, iOS and Android. And you can write ADO.NET code that accesses that SQLite database. You can write SQL to create the table, do all of your model language stuff. Or you can add a really simple RMRapper called SQLite.net. So that's the Xamarin component store. Just quickly go in there. We can look at some more components later. And there's some instructions in there that tell you how to use it. But basically what's happened is that it's added the component here, which we can always access to reference the samples and the documentation and to get upgrades when the version number is incremented. But it's also added a DLL reference directly to the project so that it's ready to use. So if I go back to our task now, it can resolve those things, primary key auto increment as being in the SQLite namespace. Now we have a task that we're going to be a task class that we're going to be a push instances into the database without SQL, without using any SQL. So now I'm going to go back to the task view controller, which is the detail screen. And add an instance public task current task. So now this instance, this detail view has a property that we can set that this is the current task that we're going to be working on. And create a view will appear. And so once that's been set, we want to also populate the fields on the screen with information from the task object that we've created. So view will appear. iOS and Android as well and Windows phone all have a life cycle for applications and for screens when they're being created, when they're being shown to the user, when they're being paused or backgrounded or tombstoneed, when they're being re-displayed, and finally when they're being destroyed. Each of them uses slightly different semantics, but they all have a very, very similar goal of creation, loading, appearing, pausing or going to the background, appearing again, going to the background again, and then finally getting destroyed. So for Apple, for iOS, we've got view did load. The first time the thing is coming into memory. View will appear and did disappear to capture when things are going back and forth in front of the user. So that you know when you need to refresh something, if something's happened in the background, and then view will appear comes, you know it's coming forward and you need to check again. So basically what we're going to do in view will appear is just check that, I might name those with caps I think. So the current task, assuming the current task has been set before this method is called, we're going to populate the title text and the done switch with the values from the task, and that task is going to come from the database when we get to this detail screen. So those two lines of code there, that could be any.NET UI, that could be WPF, that could be Visual Basic 6. It's taking properties out of an object and assigning them to a visual widget's property so that it's displayed to the user. Now we want to go to, now that we've got that I guess, the question is where's the database? So let's go back to the core code because we can write database access code that is shared. I'm going to call it task view model. It probably could be task repository. Please don't get offended by my misuse of the view model pattern. So there's a bit of code here that's happening. I'm just going to resolve, again same as you can do in Visual Studio, resolve these two things to add the using statements at the top. So this is our C sharp code that is going to let that task object that we annotated with a couple of properties be persisted in the database and be able to get those values back as task objects from the database. So the important things are create table. So we're finding a location on the device which we have which is within the sandbox for iOS applications of sandbox and they can only write within a certain part of the system. We are calling it task dot DB system IO path. Every dot net framework feature or file handling whatever is available to you within Xamarin.ios. So we're just using regular dot net file operations to build up a directory name creating the SQL like connection and then creating a table called task. That is you can call that any time under the hood it's checking whether it exists and if it doesn't it creates it. If your object definition has changed since the last time you've called create table so the next version of your application it will automatically do migrations as well of the schema. It will only do additions. It won't delete columns so you have to be a bit wary of that but then it's a simple ORM. So every time we construct one of these task view models which we'll do it's going to just make sure that the database is there and then it's configured. Then we've got some really simple methods. You're going to recognize the CRUD code. Saving a task if the ID is not set or it's zero that was the auto increment column so we're pretty confident that it's going to have an ID greater than zero. We're going to update the object so we're passing in a task. We can update it and return the new ID that's been assigned. If it's not we can insert it and I think that's rather wrong. Then we're returning the ID that was generated. Get we're using first-order fault so you recognize that from, oh I haven't resolved that. You know link syntax and if we want to get a list of all the tasks we're again using link to get the collection of tasks from the table and link order by and select to send the collection back up to our user interface. So that's a really simple API I guess to load and save data without writing any SQL based on a set or based on an annotated task model, a class. The cool thing about this is that all of the using statements are cross-platform. So that cork bit of code and we could have 10 or 100 classes in there. We could have multiple database tables. We could also do web access. We can take that and put it into Windows Phone 8 app. We can put it into an Android app. So the more business logic and data access and validation that you can fit in stuff where the usings are limited to.NET or could be in a portable class library, the more code you can reuse across multiple platforms. So let's save that. So now we need to actually do something here. Save the code. So we had it to do there earlier. And again I've given these the wrong case. So to implement the save on the detail screen, assuming the user's done some input, we haven't got any validation happening. We're doing the reverse of populating the screen, taking the user interface widget value, assigning it to this current task object. Here when you're up a view model, I could have done that at the class level actually. And then we're just calling save. So there's user input coming into a class and being pushed down into the SQLite database in a couple of lines of code. And then again pop to view controllers just taking us back to the list screen. So at this point we've got a working detail screen which when it's loaded with a task object, copies its properties out onto the screen with a save button wired up with an event handler that will take those text input and the button value and push them back down into the database. So what we need to do now is make the list view work so that all of those new tasks that we save go back into the database and we've got a list that we can select from. So let's go back to the list view and we'll add some code here. So basically what I'm doing here, adding the view model. So the list view is just going to keep a copy of the view model around. We can use that to get data whenever we need to and we're just going to new it up in the constructor. Then view will appear, again that concept of the life cycle. Every view did load happens once. So if I was to call something and view did load then go off to another screen and create a task and then come back, the list is not going to show it. View will appear is called every time we come back to this screen. So that's the place where we want to say oh there might be new data here because the user has been off doing stuff. Again let's try and load the data in and display what the user wants to see. So the syntax for that is there's a table view, that's an intrinsic part of this control, we didn't need to declare it, that's what the control, this screen is a table screen. We need to assign a data source which is an adapter class if you're familiar with that kind of pattern. It's going to take something and turn it into like an API, wrap it in an API that can be used by something else. So the table view is a user interface control. Apple's built it, you don't want to implement that yourself, you just want to take advantage of its features so you need to tell it the data to display in the table view. What we've got is a list of task objects, an eye list of them. The table view doesn't know what to do with that. So we need an adapter that's going to take our list of objects and tell the table view this is what you need to do with it. So we're going to add the adapter class, it's called a data source, so task data source. And I'm just going to add the code. So again I'm just going to quickly cheat, resolve these. So here's what a data source looks like. It inherits from an objective C class which again is amazing. Like there's a whole pile of infrastructure underneath the covers there to make that objective C thing look and act like it's a C sharp thing so that we can override methods and change its behavior. It's going to take our collection. So the code that we just saw from the view model is going to load up a list of tasks from the database. Great. Now we need to show them to the user. So here's our data source taking that list of tasks and then the overrides in this class is the minimum API that Apple says the table source needs to be able to show stuff. So the first method rows in section, super simple. When the table is about to display some data, I guess one of the things it's doing is figuring out what the scroll bar needs to look like, how big it is, it's proportional. So you tell it how many rows you need to display. The second thing you need to do now that it knows how many rows and it's going to render for that number of rows is what do I put in each row. And so we implement a method get cell to shift up every time it asks us, give me the information for row one, give me the information for row two. We're just going to write a little bit of code that does that adapting of our data to the table views expected stuff which is actually a complete visual cell that it can display on the screen. So there's some boilerplate code here. The table view control supports virtualization if you're familiar with that concept from WPF as well. So if you've got a million rows, it doesn't create a million cell objects in memory. It just creates like 12 which is about the height of the screen plus two and it reuses them. So as they go off the screen, they go into a queue and you just grab the next one and smash over all the properties to keep the table performance scrolling quickly. So it's that pattern. You'll see it everywhere. We're using a custom, well we're using the default cell. We actually said that back in the storyboard. I changed the type to just use a default cell. I don't want to draw one. I don't want to make anything pretty. I could do right here. I could use a cell subclass that was pink and had italic font and all sorts of stuff. But for now, we're using the default cell. We know it's got a text label. We're getting the task list item for this row and displaying the title in the cell. We're then checking the done property for the task in this row and turning the check mark on or off. And check mark and a few other accessories are default things that the iOS cell supports. And again, if you want to do more, you can make this as custom as you like. And we return that cell back up to the table view and it's going to show it in position one and position two and position n. And finally, we're implementing a helper method for ourselves, get item, so that it can provide a shortcut for us to get back the task that's being displayed for particular row, which we're using a touch event or something like that. So let's go back to the task list view controller now, uncomment that and it's ready. The final thing we need to do, we've just implemented the database. We've just implemented an adapter that takes the output from the database and shows it in the list. And we have a working detail screen that loads data and saves it. Those two segues that we drew at the start don't do anything. I've just had these placeholders here the whole time. So I'm just going to quickly wire them up. So the destination view controller, we're going to quickly cast and get an instance of the control we're about to hit. So we're about to visit the task view controller screen. It should be, should exist. And I'm going to set the current task to a new task. I could do something tricky in here like set the default text to angle new task or some other prompt. But we're just setting that and then we're doing the equivalent thing here. Oops, that's what happens when, oops. For edit task, we actually need to do a bit more work. So we're going to first cast the destination of the segue to the screen that we know about. And then we're going to, from the data source, which is the adapter from our database to the table, we're going to find the index for the selected row. We're going to get that task object using that row. And we're going to set the screen that we're about to display. We've set its current task property to this task object. Now we already set up the detail screen to expect that to be set. So that's pretty much all we need to do. And I'm going to hit, just debug property there. So hit run again now. What have I done here? I'm just going to comment that out. And here it is starting up in simulator. So we'll add by milk. And I couldn't buy it. So there is the task there. Let's add another one by eggs. Save. Now that popped root you can control. I'm not sure why that's not working right now. But if I set that on, so that's it. That's less than 100 lines of code. It's a C sharp application with database access running on an iOS device. We can put it on the hardware if we had time to play around with it. If I go into this and set a breakpoint here, let's hit, let's say we're going to buy eggs. Breakpoint gets hit. You can explore these objects just like you would explore anything else. You can explore native objective C objects. And there's a massive stuff there because it's surfacing all of the stuff that's happening in objective C in the background. But yeah, you can debug. You can step through. You can run just like any other C sharp development environment. So that's a complete, it's 100 lines of code. You can take that model and build a very basic database, a couple of navigation controllers that zoom into details of the screen. So this monkey space app, which is another conference that's happening back in the States is the pretty much the same concept that little ever this whole thing is a list of data going to a detail screen. You can hit favorites. You can scroll. These are custom cells. We're not using the default cell, but they're really easy to draw. You can include map control. There's favorites list. You can draw speakers. So that code is open source as well. And if you have a look at it, you'll see there's very little difference. Certainly it's not complex from the really simple we looked at today, simple example we looked at today to something like that conference app. It's just in terms of adding detail, creating some custom views rather than using the default, adding a bit more data to the classes. But you've got in terms of foundation, pretty much how everything works from this to do example. So we go back to slides now that we've done that. Hopefully, yep, the result was as we expected, we built an application with C sharp that runs on iOS. I talked a little bit about sharing. Like I said, there's multiple things that you can share so using Xamarin.OS is great for getting an app on to a phone. So if you just want to build for iOS with C sharp, it's a great story. If you want to build for iOS and Android and Windows phone and Windows store apps, it's an even better story because you can share components. So the SQL like component that we put in runs on all those platforms, which means that the core data that you write, the business logic, the database access, validation rules, you can also share that code across all of those four platforms. If you've got bigger teams, you want to look at sharing the structure of the code too. You want to keep the screen names kind of the same. And you want to maybe structure the code the same in folders or however you structure it. Because you can do it all in Visual Studio, you can easily validate by looking at it that they're the same and really utilize the fact that you've got C sharp everywhere to keep things common and help people that are working on the code be able to understand it. And also the design. So you can share the design. That app that we just built here, we're going to build again in an hour in Android. And with respect to some of the platform's differences in terms of navigation, you can really get some leverage from building stuff similar. There's also a version of this for Windows Phone on the net. There's some code available for that as well. And you can see the core of it's the same, but because you're doing native interface on every platform, you can respect the different navigation paradigms where you need to. So you don't add a back button on Android because it's there. You do things slightly differently in Windows Phone because you might want to panorama, et cetera. You can put a lot of code in the core library. So system net stuff can live there. You can access web services. You can parse the web services. You can use the file system. We've got an implementation of isolated storage even so that if you want to be sharing with Windows Phone 7, you can do that. The more stuff you put in there, the easier it is to test because you can actually write unit tests that hit that layer on their own. But you also get testing on each of the vertical platforms. So you can test it when you write the iOS app and be pretty confident when you get to Android or Windows Phone or Windows Store that the core library works. It works on one platform, but it's the exact same code that will be able to run on all the others. So to recap, you can build iOS applications in C-Sharp with.NET. You can use Xamarin Studio, which is nice. That's what I spend all my time in. Or you can use Visual Studio even for building stuff for iOS. The apps have native look and feel because it is native widgets. And because they are native, they also have native performance. You can share code with Android, with Windows Phone, with Windows Store. And we have a component store that makes available a lot of different components that will let you enhance your application in other ways. So if I go to components.xamarin.com, you can browse it on the website. You don't even need to download anything else. So there's an Azure Mobile Services component that Microsoft has published. So you can add that the way we just added SQLite, get your key, your authentication keys from Microsoft, and pretty much the same way we just added some attributes for that to do class to save it to the local database. You can push that stuff out to an Azure Web Service. It's really simple. There's signature pad, like there's user interface controls like signature pad. There's encryption controls, charting libraries, themes, a whole pile of stuff. And like I said, there's stuff available on the components store for iOS, for Android, and for Windows. Yeah. There is an independent, Xamarin Studio is based on an open source product called MonoDevelop. And both products have the same plugin architecture. And there is already an independently developed NuGet plugin that runs in both MonoDevelop and Xamarin Studio. So you can now currently grab NuGet and incorporate them into your projects. It would sit side by side with the components that we support. Xamarin components store supports paid as well as free components. And it's also super easy for you to write and publish components to the components store and sell them. And we reimburse you after selling it on your behalf. Quickly, we've got a few minutes left. What's next for Xamarin.ios? We're currently beta testing async await support. So the parallel task library's been in the product for a while. But the async await keywords were just added to Mono, the underlying Mono Core late last year. And we're just in the process of finishing up incorporating them into the iOS mobile product right now. F-sharp is going to be a first class language for development in Xamarin products. You can download and give that a try right now as well. Portable class library support is coming. So where I had that core library before, it was actually putting those C-sharp files in the core folder. And currently the preferred way to actually share those C-sharp files if you did have four projects would be to file link them across the four projects, which is a bit of a pain. Portable class library support will be in Xamarin Studio. It's already in Visual Studio. And that will let you have another option for writing and sharing code more easily. I mentioned and showed you the Xamarin.ios designer that's currently in alpha. So you can play with that now as well by downloading it from our alpha channel. But when that comes to the stable channel, it will be available in Visual Studio as well as on the Mac. And of course, iOS 7, two days old, we're doing our best to get that into the hands of registered Apple developers that are allowed to look at it and make it available to all of our developers once Apple releases the final version. That's a quick screenshot of Async Away. You've probably already seen it, but we're really excited to have it in the product. And that's the iOS designer. Again, we've looked at that briefly today. So with that, you could go back to your computers and start now. We have a free trial version that's limited by the size of the application you produce. But it's otherwise lets you put stuff on a device or test on a simulator. We've got piles of documentation, user forums for support, samples on GitHub, and you can download it from our website. I've got probably five minutes if anyone has any questions. First two questions, get a monkey. After that, sorry. I guess you already had a question, so maybe you should come and get a monkey. Anyone else? I can't give you exact dates. The Async Away support is already in our beta channel. So we have three channels available for download so that you can participate in the testing process. And you can switch between them from within the tools. Async Away has been in the beta channel since Evolve with our conference in April. So it's still going through testing. Obviously, we want to get out as quickly as possible. PCL will be in the alpha channel kind of any time now, and then it will move through beta and into production once we're happy with it. PCL kind of already works. The problem with PCL is not our support for the IL because it's actually all IL under the covers. It's implementing the complete support for recognized profiles and managing it within the IDE when you try and step outside the profile while you're coding a PCL library. So that stuff is in progress. You could come and get a monkey at the end. Getting rid of the save button. Maybe you could implement the shake gesture and when you shake it, it saves. There's a couple of things I guess you could do. You could just when they go back. So you could respond to hitting the back button or you could have when they swipe back implement save there. There's a lot of... iOS has a really powerful gesture recognition system. If you could compare it to what Android has historically had. You can do a lot of stuff just by doing add gesture recognizer to a view and you can have taps, multiple taps, swipes, swipe directions, custom gestures. So you could really easily do something where if they swipe across, it would just work. But I don't know. Anyone else? Oh. I guess in Facebook terms, it's complicated. We love Apple and they approve all of our apps. We do our very best to fit within all of Apple's licensing terms and restrictions. Things like the Visual Studio tool where we support developing a Visual Studio but compiling on a Mac. We purposefully ensure that we're complying with their terms which is that you must have a Mac for compiling. You must have one Mac per developer. So when you're using Visual Studio, you can't have a team of people hitting the same Mac. So we do our best to make sure that we are a good citizen within Apple's developer community. And in return, we don't get any special access to anything. We wait until WDC just like everyone else and then we work our butts off to get everything ready for our customers. But, you know, everyone's in San Francisco. You see and hear things. But it's really just like everyone else. I guess that's it. Thank you very much for coming, guys. I hope that was interesting. And, yeah, like I said, I'm about to do this whole thing again in an hour except for Android. If you come along, you can just sleep through the first ten minutes.
 Hey. Welcome, everyone. Thank you for coming down to hear about how iOS apps can be built  with C-sharp using Xamarin. My name is Craig. I work at Xamarin as a developer evangelist,  and today we're going to have a quick introduction to what Xamarin is and see how it works.  So why Xamarin.ios? Why are you here at this session? Xamarin lets you write C-sharp apps  for iPhone, iPad, and for the iPod. So if you're a Microsoft developer and you're  a no C-sharp, it gives you a vector into a massive ecosystem of devices and apps that's  really easy to monetize through with your existing skills and potentially with some  existing code. That code that you write with Xamarin.ios can also potentially be shared  with other platforms. So you can target Android as well with Xamarin.Android, and you can also  use the C-sharp code that you write that's not directly user interface related on Windows  phone, on Windows Store apps, and potentially also desktop enterprise apps anywhere else  that you've got C-sharp doing calculations or database access or network access, really  anything that's not directly touching the UI. The reason that you don't reuse the C-sharp  that's directly touching the UI with Xamarin is because you write a custom UI for each  platform. So the benefit of that is that using native UI widgets and your apps look and feel  native. They look and feel native because they are native. There's no interpretation,  there's no cross compiling. What we build is an actual ARM binary that runs natively  on the device at full speed. The entire iOS SDK is available to you in C-sharp. So there's  no features that aren't available because they haven't been provided by us as a tool  provider. We've got complete coverage of everything that's available to normal objective  C developers. So things like StoreKit, things like iCloud, all that stuff is supported by  us. When new iOS releases come out, so iOS 7 is in beta at the moment, we do our best  to get that stuff available to you as quickly as possible during the beta period, which  we couldn't talk about anyway. When it's released, we generally have the same or next  day availability. When iOS was released last year, we released the full production quality  support for iOS 6 on the same day. Finally, Xamarin.io doesn't limit you to just using  C-sharp. So if you've got objective C libraries that already exist or you find an objective  C component on the web, you can also still bring that in to your Xamarin project, create  a linking or binding file that we call it, and access that objective C code as well.  So it gives you really unlimited power to develop iOS apps using C-sharp and then expanding  out into objective C if you ever needed to. How does it work? Xamarin is based on Mono.  So you may have heard of Mono. It started out in 2001 as a project, super quickly after  Microsoft announced the existence of.NET and the fact that they were going to open, well,  submit it to ECMSA as a standard so that other people could implement it. It was released  in 2004 and its original goal was simply to be a C-sharp and.NET implementation that  runs on Linux. And it's been around since that time, so the platform itself is very  mature. But I don't think anyone realized in 2004 that less than 10 years later, the  two major mobile platforms would also be based on a similar kernel and would provide a way  for us to use Mono to host applications on mobile devices.  So we've got Mono,.NET framework in a C-sharp language. How do we get that onto the phone  and enable iOS development? We have a layer which we call bindings. Microsoft calls some  projections in Windows RT. And what it does is it exposes the underlying objective C SDK  as C-sharp. So any public class or object that's available in iOS for objective C developers  is available to you in Xamarin and it looks and acts just like a C-sharp implementation.  So you can subclass, you can override, you can treat the iOS SDK as a C-sharp framework.  And as I mentioned earlier, you can also incorporate your own objective C, creating your own bindings  similar to the ones that we ship for the native SDK. And finally, bringing together the.NET  framework and the bindings and your code is a compiler. So for iOS, we compile to native  ARM binary, which means that what you submit to the Apple App Store is to Apple pretty  much indistinguishable from what an objective C app would look like. It's compiled down  to exactly the same stuff. Because we're shipping a Mono runtime as part of your app, we also  include a linker so that unused code, one of the beauties of strongly typed languages,  can be detected and removed from the final application that you distribute. So we keep  the size of your final app down as small as we can.  Visually what I just said kind of looks like this. So you start with your C-sharp and the .NET framework that's running on Mono. We compile that to.NET IL just the same as  you're familiar with for desktop.NET or for Windows, phone.NET. Then we ahead of  time compile that entire set. So the.NET framework and your code sitting on top of  it, linking out the stuff that's not being used into a native ARM binary, that goes  to the App Store, you know, it goes to your device during testing and runs natively on  Apple's hardware.  So how can you get Xamarin to give it a try? We have a really simple installer. You can  download it here. It will put everything on your Mac and or on your PC that you need to  start development except for Apple's tools. So we can't redistribute them on their behalf  for obvious reasons. So install our stuff, go to developer.apple.com slash iOS and download  Xcode or actually you can get Xcode from the Mac App Store. Join the developer program  and once you've installed those two things, you're ready to go building C-sharp apps for  iOS devices.  So Xamarin's development environment support encompasses a couple of different options.  If you're on Mac OS, we have our own IDE called Xamarin Studio and it runs on iOS. It also  runs for Android development which I talk about in a session later today. But if you  scan across this line for iOS development, you can also develop iOS apps for iPhone and  for iPad within Visual Studio.  The Xamarin Business Edition includes a Visual Studio plugin and with a Mac sitting somewhere  else on the network, you can do all of your development within Visual Studio, share code  with other projects. It's the same project, the same file format and the Mac sits in the  background and does the compilation and stuff that we need to do with Apple's compiler and  software.  So that looks kind of like this. We've got Windows, Visual Studio running on that and  the Xamarin iOS Visual Studio plugin running inside Visual Studio. It provides Visual Studio  with all of the bits and pieces that it needs to know about to build an iOS application.  So it's a special project type. It has special project settings for iOS specific features,  a special debug pane, deployment panes, output coming from the iOS device that you might  be testing on.  And that stuff talks to a Mac, somewhere on the network. So you do need to have a Mac  available where you've installed Xcode and where we remote all of the compilation and  all of the code signing, anything else that must be Mac specific because that's Apple.  But you get a complete development experience within Visual Studio.  So here's a quick screenshot of what the two IDs look like. Xamarin Studio and Visual  Studio, they should feel very familiar for your Visual Studio user and you just want  to work on a Mac. You'll feel right at home with Xamarin Studio. It looks a bit XCode-y  in terms of the way we've got a simplified toolbar, but the solution structure is the  same. References work the same way. The code editor works the same way. IntelliSense, all  that stuff.  If you want to work within Visual Studio, there's an iOS application inside Visual Studio  being developed. So you can have very sharper, you can have what other tools you like. You  can use TFS for source control and still be building an app that's going to run on Apple's  hardware.  One of the caveats for that running everywhere right now is that if you want to do drag and  drop user interface design, we currently integrate with XCode for that. So if you want to do  drag and drop UIs, you really need to be doing it on the Mac.  What we are doing and what we've already announced at our conference earlier this year is an  alpha version of our own drag and drop user interface designer. So that's XCode, a bit  of skew it on your left. And this is the alpha of Xamarin's own user interface designer  on the right. So when that user interface designer that we're building is complete, it will also  be available on Visual Studio. So from within Windows, within Visual Studio, you'll be able  to design and build iOS apps from start to finish.  For the moment, it's in alpha like I said. So if you're in Visual Studio, your options  for building your user interface is basically all code. You'd be familiar with that, particularly  if you've done Windows Forms, newing up controls, setting their coordinates and adding event  handlers to them manually. So a lot of developers do that anyway, even when they've got a visual  designer available to them. So that's your main option for Visual Studio at this stage.  The things that we add to Visual Studio and that our own IDE has on top of your normal .NET development are things that Apple needs to know about. So iOS specific options. The  first one is code signing. So part of Apple's requirements for getting code onto a physical  device is that it's signed. You manage that on a Mac through the Keychain app and through  Apple's website. And we provide an interface that lets you choose the certificates or allow  us to choose one for you based on certain criteria. And that's available on both platforms,  obviously. And like I said, the code signing is delegated to the Mac host if you're running  in Visual Studio. We also completely duplicate, sounds bad, we completely duplicate all of  the configuration settings that Apple provides in Xcode. So things like the app name and  version number, but also supported device orientations, splash screens, icons, all sorts  of other stuff that's specific to iOS apps. You can set it all visually from within either  Xamarin Studio or Visual Studio because we've provided the same user interface that Objective  C developers are used to. And also deployment. So you can deploy to the simulator for testing,  you can deploy to a device for testing, and you can also package up an app for distribution  to the app store or from within Visual Studio or from within Visual Studio. So rather than  just talk about Xamarin Studio and show you some slides, we're going to do a demo, live  coding, what could go wrong. We're going to build a really simple app. If you've ever  looked at the Xamarin website before, you will recognize that they're really simple  to do list application. The main reason we use it as a demo is because I can build it  in less than 100 lines of code. It has a database and it uses a couple of different aspects  of the operating system that will help you get a little bit familiar with it, but also  understand how easy it is to build iOS applications with C sharp. So we're going to just run up  Xamarin Studio and do file new project or hit the new button. That seems big. So we're  going to choose to do a storyboard application because I'm going to show you how the drag  and drop editing works. So new in-competit application gives you what you'd expect. A  few files and directories that if you hit run, will actually start something up right  now. So that's a working minimal application. The things that it gives you that you never  really need to look at or change are a main file. So static void main, common entry point  for any sort of application. You never need to look at that. And an app delegate class,  which is the first iOS specific thing that you're going to see. When you're building  more complex applications, you will override some of these methods in the app delegate,  but we're not going to need to do that for today. Just be aware that the app delegate  is the first thing that's really starting up. That's the first part of the app, the  first time that you get to write custom code for doing things like parsing inputs that  might come if your application's been started from a link or from another application. For  now, we don't need to know anything about it. The application does have another startup  parameter though, and that is the main interface storyboard here. And this is just to give  you a quick preview. This is some of the settings that we provide, which are equivalent to  the Objective C slash X code user interface settings. So some of the folders, references  folder you're familiar with. It's exactly the same as if we're in Visual Studio. We  can reference only DLLs that have been compiled for Xamarin.ios. They're not their IEL, just  the same as what you would expect, but they need to be compiled for Xamarin.ios so that  we know that we're providing the same features that that DLL supports. We are in the process  of fully supporting portable class libraries, and at that point, you'll also be able to  reference a portable class library DLL from your application, which brings a whole host  of options for the types of code that you can import. So a Visual Basic DLL that was  compiled for portable class libraries would be able to be included in your IOS application.  I'll skip the components directory because we're going to come back to that later. And  just have a quick look at resources. Resources is an Xamarin.ios concept that we use to provide  a simple place for developers to add media and, you know, any non-code assets to your  app and keep them sort of organized in one place. So I'm going to just quickly dump in  all the icons and splash screens that we need. And most of those get picked up by the application  because there's a naming scheme, which we don't need to talk about now, but trust me,  it works. So that's going to bring us down to the storyboard because that's the user  interface. The first thing that's going to happen in this app is the storyboard is going  to get run. So let me open it first in Xcode. And first thing I'm going to do is delete  the whole thing so we can start from scratch. This is what Objective C developers are used  to when they build applications using this tool. So I'm just going to drag on a navigation  controller, which is a frame that enables that back and forth user interface paradigm  that people with iPhones will be familiar with. And it's dropped on a table view, which  is that scrolling list that also everyone's familiar with as the default initial screen.  And I'm going to, because we're building the to-do app with a list and a detail view,  just going to add another screen next to that and kind of try and lay them out nicely.  So the user and face works pretty much as you'd expect. You can edit these values. I'm  going to change the type to basic type so that it's got a title because we want to set  that text. I think we need, based on our design, a button to create new tasks. So plus icon  is going to be cool for that. So that's the design finished for the first screen of our  application. It's going to have a list of cells that we can scroll and touch and also  a button to create a new task. So to wire these buttons up so they actually do something,  we can just drag to the screen we want it to go. So we want the new button to go straight  into the detail screen so we can start adding a new task. And similarly, if we touch on something  in the list, we want that to go to the same screen because we'll be editing that task.  So I've got two arrows here now that indicate indicating that we can move from one screen  to the next. Apple calls them segways. So not the thing that you lean forward with wheels,  but the definition is like moving from one discussion point to another. Anyway, segway  makes sense. We need to name that, I'll give it a call that one new task and that one edit  task. And now we need to design the second screen of the app, which is going to be editing  a task. So once again, it's going to be about dragging on a couple of controls. And trust  me, we will get to some C sharp at some point. A switch, whether this task has been done  or not. And let's say a button. And it's going to, the button is going to be the save button.  And that's pretty much all the UI work we need to do. The last thing I almost forgot  was to give our cell a name, task cell. You guys, I'm not sure if you can see that. There's  a few different settings you can make. And also, I want to get rid of that chevron. So  I'm going to just change that to none. Because we're going to have a tick there when the  tasks are complete. So the last thing we're going to do is give the classes themselves  names. So this is going to be task list view controller. And I'm going to call the next  one task view controller. View controller is optional. You don't need to use Apple's  naming conventions for stuff like that. What we're doing is saying that we're giving a  name to this class so that that's what we can refer to these screens as when we have  them in code. I think I've wired everything up. So let me close that. And when we come  back to Xamarin Studio, yeah, I really wanted to see an error. We'll see how we go here.  That class was the default one, so I can delete that. And you'll see it's created two new classes  for me. These are the two classes that relate to those two screens that we've just created.  And they've got a backing file which is really similar to a designer.g.cs in XAML. It's a  way for partial classes to support adding controls which you can refer to in code later.  If we hit run, there's the application. It doesn't actually do anything yet except the  controls work as expected. But you can navigate between those two screens. So let's actually  do some C sharp. To finish off the user interface, one thing that we will need to do is give  the controls themselves names. So we've created a save button and a text input. But we have  no way of referring to them in code yet. So I'm going to do that from within our Xamarin  designer. So what you're seeing here is not X code. It's the custom Xamarin designer which  in the future will be the preferred way to work with these things. And I'm going to give  that, I can zoom in a bit here, title text. And I want to call the switch. Done. Done  switch. So this, you know, you're designing an iOS screen here. But really the way you're  selecting things and setting properties is really just like any other iOS, other windows.  User interface designer, dragging stuff around and using the properties pane to manage the  way things look. So let me save that. And let's go now and just have a look at the designer  file. And we should see all the switches done switch save button. Title text. Wait for that  to appear. So now we've got a user interface. It's basically a wide up. It's time to start  doing some C sharp. So we'll start with the task view controller, which was the detail  view. And at the moment, it's a partial class. It's got those controls in the back in class.  And I'm just going to that safe button still isn't there. Did I mention this is in alpha  and it's worked three times today. But there we go. Now we've got all three backing fields  there. So this is the cool thing about override view load. And when you're using Xamarin Studio,  you don't even have to code most of the stuff because the autocomplete you used to from  visual studio is there. It's the same, but it's providing autocomplete over the objective  C class library. So when I do view override there, it tells me that a view controller  has all these options, including view did load, which is the one that I want. It tells  me based off view did load should be in there already puts it there for me. And then I'm  just going to do save button dot touch up inside, which is their version of on click.  We're not going to go into all the details. And then I can just add an event handler.  And I can implement it. So for now, I'm just going to put to do need to save task here.  And then navigation controller. So basically, that's a very dot net way of making a button  do something. There's an event handler, we sign an expression to it. And all it's done  now is a to do. And then the navigation pop to root is basically just go back to the previous  screen. That's a 100% C sharp thing working on this iOS stuff that's underneath the covers  that doesn't have event handlers doesn't know anything about C sharp. But this, this just  works. So that's one way that, you know, C sharp familiarity comes right into any sort  of iOS development. We'll come back to implementing save later. In the task list screen, we also  drag those two arrows which were called segways to help with navigation. But you might have  started to wonder already, how do I know which row was clicked on when that that segue happens?  You know, I've just dragged from some, some undefined row across to say this is the screen  that you open. So there's a method which I'm just going to quickly make appear called prepare  for segue. So we actually named those segways for a reason. This screen is going to get  a message every time a segue is triggered. And this little if statement gives us the  structure to react to, to which segue has been hit. So the new task one, we're going  to start the new screen, we can probably just start it because we don't know what the task  is anywhere. We'll new one up later. And the edit task there, I'm going to add some code  there to find out which row was clicked. Find that task object that we're going to create  and then send it on to the next screen so that we're actually editing the task that  we that we clicked on. So I just said the task object, we don't have a task object yet.  So let's quickly create a business object that we can start to work with. I'm going  to put it in a file called core, because the code that we're going to write now, and it's  not much code, could be shared. So there's the task class. And I'll just quickly added  a couple of properties. So our task has an ID, a title, and a done. That's all that we  need to represent. And we want to save this in a database because it's going to be more  than one task to fill that list. So I've thrown in a couple of things. If this was a database,  I would want that to be the primary key. I would want it to auto increment and become  a table somehow. That's where the Xamarin component store comes in. So SQLite is built  into both of the platforms that Xamarin supports, iOS and Android. And you can write ADO.NET  code that accesses that SQLite database. You can write SQL to create the table, do all  of your model language stuff. Or you can add a really simple RMRapper called SQLite.net.  So that's the Xamarin component store. Just quickly go in there. We can look at some more  components later. And there's some instructions in there that tell you how to use it. But  basically what's happened is that it's added the component here, which we can always access  to reference the samples and the documentation and to get upgrades when the version number  is incremented. But it's also added a DLL reference directly to the project so that  it's ready to use. So if I go back to our task now, it can resolve those things, primary  key auto increment as being in the SQLite namespace. Now we have a task that we're going  to be a task class that we're going to be a push instances into the database without  SQL, without using any SQL. So now I'm going to go back to the task view controller, which  is the detail screen. And add an instance public task current task. So now this instance,  this detail view has a property that we can set that this is the current task that we're  going to be working on. And create a view will appear. And so once that's been set, we want  to also populate the fields on the screen with information from the task object that  we've created. So view will appear. iOS and Android as well and Windows phone all have  a life cycle for applications and for screens when they're being created, when they're being  shown to the user, when they're being paused or backgrounded or tombstoneed, when they're  being re-displayed, and finally when they're being destroyed. Each of them uses slightly  different semantics, but they all have a very, very similar goal of creation, loading, appearing,  pausing or going to the background, appearing again, going to the background again, and  then finally getting destroyed. So for Apple, for iOS, we've got view did load. The first  time the thing is coming into memory. View will appear and did disappear to capture when  things are going back and forth in front of the user. So that you know when you need to  refresh something, if something's happened in the background, and then view will appear  comes, you know it's coming forward and you need to check again. So basically what we're  going to do in view will appear is just check that, I might name those with caps I think.  So the current task, assuming the current task has been set before this method is called,  we're going to populate the title text and the done switch with the values from the task,  and that task is going to come from the database when we get to this detail screen. So those  two lines of code there, that could be any.NET UI, that could be WPF, that could be  Visual Basic 6. It's taking properties out of an object and assigning them to a visual  widget's property so that it's displayed to the user. Now we want to go to, now that we've  got that I guess, the question is where's the database? So let's go back to the core  code because we can write database access code that is shared. I'm going to call it  task view model. It probably could be task repository. Please don't get offended by my  misuse of the view model pattern. So there's a bit of code here that's happening. I'm just  going to resolve, again same as you can do in Visual Studio, resolve these two things  to add the using statements at the top. So this is our C sharp code that is going to  let that task object that we annotated with a couple of properties be persisted in the  database and be able to get those values back as task objects from the database. So the  important things are create table. So we're finding a location on the device which we  have which is within the sandbox for iOS applications of sandbox and they can only write within a  certain part of the system. We are calling it task dot DB system IO path. Every dot net  framework feature or file handling whatever is available to you within Xamarin.ios. So  we're just using regular dot net file operations to build up a directory name creating the  SQL like connection and then creating a table called task. That is you can call that any  time under the hood it's checking whether it exists and if it doesn't it creates it.  If your object definition has changed since the last time you've called create table so  the next version of your application it will automatically do migrations as well of the  schema. It will only do additions. It won't delete columns so you have to be a bit wary  of that but then it's a simple ORM. So every time we construct one of these task view models  which we'll do it's going to just make sure that the database is there and then it's configured.  Then we've got some really simple methods. You're going to recognize the CRUD code. Saving  a task if the ID is not set or it's zero that was the auto increment column so we're  pretty confident that it's going to have an ID greater than zero. We're going to update  the object so we're passing in a task. We can update it and return the new ID that's  been assigned. If it's not we can insert it and I think that's rather wrong. Then we're  returning the ID that was generated. Get we're using first-order fault so you recognize  that from, oh I haven't resolved that. You know link syntax and if we want to get a list  of all the tasks we're again using link to get the collection of tasks from the table  and link order by and select to send the collection back up to our user interface. So that's a  really simple API I guess to load and save data without writing any SQL based on a set  or based on an annotated task model, a class. The cool thing about this is that all of the  using statements are cross-platform. So that cork bit of code and we could have 10 or 100  classes in there. We could have multiple database tables. We could also do web access. We can  take that and put it into Windows Phone 8 app. We can put it into an Android app. So  the more business logic and data access and validation that you can fit in stuff where  the usings are limited to.NET or could be in a portable class library, the more code  you can reuse across multiple platforms. So let's save that. So now we need to actually  do something here. Save the code. So we had it to do there earlier. And again I've given  these the wrong case. So to implement the save on the detail screen, assuming the user's  done some input, we haven't got any validation happening. We're doing the reverse of populating  the screen, taking the user interface widget value, assigning it to this current task object.  Here when you're up a view model, I could have done that at the class level actually.  And then we're just calling save. So there's user input coming into a class and being pushed  down into the SQLite database in a couple of lines of code. And then again pop to view  controllers just taking us back to the list screen. So at this point we've got a working  detail screen which when it's loaded with a task object, copies its properties out onto  the screen with a save button wired up with an event handler that will take those text  input and the button value and push them back down into the database. So what we need to  do now is make the list view work so that all of those new tasks that we save go back  into the database and we've got a list that we can select from. So let's go back to the  list view and we'll add some code here. So basically what I'm doing here, adding the  view model. So the list view is just going to keep a copy of the view model around. We  can use that to get data whenever we need to and we're just going to new it up in the  constructor. Then view will appear, again that concept of the life cycle. Every view did load  happens once. So if I was to call something and view did load then go off to another screen  and create a task and then come back, the list is not going to show it. View will appear  is called every time we come back to this screen. So that's the place where we want to say oh  there might be new data here because the user has been off doing stuff. Again let's try  and load the data in and display what the user wants to see. So the syntax for that is there's  a table view, that's an intrinsic part of this control, we didn't need to declare it,  that's what the control, this screen is a table screen. We need to assign a data source which  is an adapter class if you're familiar with that kind of pattern. It's going to take something  and turn it into like an API, wrap it in an API that can be used by something else. So  the table view is a user interface control. Apple's built it, you don't want to implement  that yourself, you just want to take advantage of its features so you need to tell it the  data to display in the table view. What we've got is a list of task objects, an eye list  of them. The table view doesn't know what to do with that. So we need an adapter that's  going to take our list of objects and tell the table view this is what you need to do  with it. So we're going to add the adapter class, it's called a data source, so task  data source. And I'm just going to add the code. So again I'm just going to quickly  cheat, resolve these. So here's what a data source looks like. It inherits from an objective  C class which again is amazing. Like there's a whole pile of infrastructure underneath  the covers there to make that objective C thing look and act like it's a C sharp thing  so that we can override methods and change its behavior. It's going to take our collection.  So the code that we just saw from the view model is going to load up a list of tasks  from the database. Great. Now we need to show them to the user. So here's our data source  taking that list of tasks and then the overrides in this class is the minimum API that Apple  says the table source needs to be able to show stuff. So the first method rows in section,  super simple. When the table is about to display some data, I guess one of the things it's  doing is figuring out what the scroll bar needs to look like, how big it is, it's proportional.  So you tell it how many rows you need to display. The second thing you need to do now that it  knows how many rows and it's going to render for that number of rows is what do I put in  each row. And so we implement a method get cell to shift up every time it asks us, give  me the information for row one, give me the information for row two. We're just going  to write a little bit of code that does that adapting of our data to the table views expected  stuff which is actually a complete visual cell that it can display on the screen. So there's  some boilerplate code here. The table view control supports virtualization if you're  familiar with that concept from WPF as well. So if you've got a million rows, it doesn't  create a million cell objects in memory. It just creates like 12 which is about the height  of the screen plus two and it reuses them. So as they go off the screen, they go into  a queue and you just grab the next one and smash over all the properties to keep the  table performance scrolling quickly. So it's that pattern. You'll see it everywhere. We're  using a custom, well we're using the default cell. We actually said that back in the storyboard.  I changed the type to just use a default cell. I don't want to draw one. I don't want to  make anything pretty. I could do right here. I could use a cell subclass that was pink  and had italic font and all sorts of stuff. But for now, we're using the default cell.  We know it's got a text label. We're getting the task list item for this row and displaying  the title in the cell. We're then checking the done property for the task in this row  and turning the check mark on or off. And check mark and a few other accessories are  default things that the iOS cell supports. And again, if you want to do more, you can  make this as custom as you like. And we return that cell back up to the table view and it's  going to show it in position one and position two and position n. And finally, we're implementing  a helper method for ourselves, get item, so that it can provide a shortcut for us to get  back the task that's being displayed for particular row, which we're using a touch event or something  like that. So let's go back to the task list view controller now, uncomment that and it's  ready. The final thing we need to do, we've just implemented the database. We've just  implemented an adapter that takes the output from the database and shows it in the list.  And we have a working detail screen that loads data and saves it. Those two segues that we  drew at the start don't do anything. I've just had these placeholders here the whole  time. So I'm just going to quickly wire them up. So the destination view controller, we're  going to quickly cast and get an instance of the control we're about to hit. So we're  about to visit the task view controller screen. It should be, should exist. And I'm going  to set the current task to a new task. I could do something tricky in here like set the default  text to angle new task or some other prompt. But we're just setting that and then we're  doing the equivalent thing here. Oops, that's what happens when, oops. For edit task, we  actually need to do a bit more work. So we're going to first cast the destination of the  segue to the screen that we know about. And then we're going to, from the data source,  which is the adapter from our database to the table, we're going to find the index for  the selected row. We're going to get that task object using that row. And we're going  to set the screen that we're about to display. We've set its current task property to this  task object. Now we already set up the detail screen to expect that to be set. So that's  pretty much all we need to do. And I'm going to hit, just debug property there. So hit run  again now. What have I done here? I'm just going to comment that out. And here it is  starting up in simulator. So we'll add by milk. And I couldn't buy it. So there is the  task there. Let's add another one by eggs. Save. Now that popped root you can control.  I'm not sure why that's not working right now. But if I set that on, so that's it. That's  less than 100 lines of code. It's a C sharp application with database access running on  an iOS device. We can put it on the hardware if we had time to play around with it. If I  go into this and set a breakpoint here, let's hit, let's say we're going to buy eggs. Breakpoint  gets hit. You can explore these objects just like you would explore anything else. You  can explore native objective C objects. And there's a massive stuff there because it's  surfacing all of the stuff that's happening in objective C in the background. But yeah,  you can debug. You can step through. You can run just like any other C sharp development  environment. So that's a complete, it's 100 lines of code. You can take that model and  build a very basic database, a couple of navigation controllers that zoom into details  of the screen. So this monkey space app, which is another conference that's happening back  in the States is the pretty much the same concept that little ever this whole thing  is a list of data going to a detail screen. You can hit favorites. You can scroll. These  are custom cells. We're not using the default cell, but they're really easy to draw. You  can include map control. There's favorites list. You can draw speakers. So that code  is open source as well. And if you have a look at it, you'll see there's very little  difference. Certainly it's not complex from the really simple we looked at today, simple  example we looked at today to something like that conference app. It's just in terms of  adding detail, creating some custom views rather than using the default, adding a bit  more data to the classes. But you've got in terms of foundation, pretty much how everything  works from this to do example. So we go back to slides now that we've done that. Hopefully,  yep, the result was as we expected, we built an application with C sharp that runs on iOS.  I talked a little bit about sharing. Like I said, there's multiple things that you can  share so using Xamarin.OS is great for getting an app on to a phone. So if you just want  to build for iOS with C sharp, it's a great story. If you want to build for iOS and Android  and Windows phone and Windows store apps, it's an even better story because you can  share components. So the SQL like component that we put in runs on all those platforms,  which means that the core data that you write, the business logic, the database access, validation  rules, you can also share that code across all of those four platforms. If you've got  bigger teams, you want to look at sharing the structure of the code too. You want to  keep the screen names kind of the same. And you want to maybe structure the code the same  in folders or however you structure it. Because you can do it all in Visual Studio, you can  easily validate by looking at it that they're the same and really utilize the fact that  you've got C sharp everywhere to keep things common and help people that are working on  the code be able to understand it. And also the design. So you can share the design. That  app that we just built here, we're going to build again in an hour in Android. And with  respect to some of the platform's differences in terms of navigation, you can really get  some leverage from building stuff similar. There's also a version of this for Windows  Phone on the net. There's some code available for that as well. And you can see the core  of it's the same, but because you're doing native interface on every platform, you can  respect the different navigation paradigms where you need to. So you don't add a back  button on Android because it's there. You do things slightly differently in Windows  Phone because you might want to panorama, et cetera.  You can put a lot of code in the core library. So system net stuff can live there. You can  access web services. You can parse the web services. You can use the file system. We've  got an implementation of isolated storage even so that if you want to be sharing with  Windows Phone 7, you can do that. The more stuff you put in there, the easier it is to  test because you can actually write unit tests that hit that layer on their own. But you  also get testing on each of the vertical platforms. So you can test it when you write the iOS  app and be pretty confident when you get to Android or Windows Phone or Windows Store  that the core library works. It works on one platform, but it's the exact same code that  will be able to run on all the others.  So to recap, you can build iOS applications in C-Sharp with.NET. You can use Xamarin  Studio, which is nice. That's what I spend all my time in. Or you can use Visual Studio  even for building stuff for iOS. The apps have native look and feel because it is native  widgets. And because they are native, they also have native performance. You can share  code with Android, with Windows Phone, with Windows Store. And we have a component store  that makes available a lot of different components that will let you enhance your application  in other ways. So if I go to components.xamarin.com, you can browse it on the website. You don't  even need to download anything else. So there's an Azure Mobile Services component that Microsoft  has published. So you can add that the way we just added SQLite, get your key, your  authentication keys from Microsoft, and pretty much the same way we just added some attributes  for that to do class to save it to the local database. You can push that stuff out to an  Azure Web Service. It's really simple. There's signature pad, like there's user interface  controls like signature pad. There's encryption controls, charting libraries, themes, a whole  pile of stuff. And like I said, there's stuff available on the components store for iOS,  for Android, and for Windows. Yeah. There is an independent, Xamarin Studio is based  on an open source product called MonoDevelop. And both products have the same plugin architecture.  And there is already an independently developed NuGet plugin that runs in both MonoDevelop  and Xamarin Studio. So you can now currently grab NuGet and incorporate them into your  projects. It would sit side by side with the components that we support. Xamarin components  store supports paid as well as free components. And it's also super easy for you to write  and publish components to the components store and sell them. And we reimburse you after selling  it on your behalf. Quickly, we've got a few minutes left. What's next for Xamarin.ios?  We're currently beta testing async await support. So the parallel task library's been in the  product for a while. But the async await keywords were just added to Mono, the underlying Mono  Core late last year. And we're just in the process of finishing up incorporating them  into the iOS mobile product right now. F-sharp is going to be a first class language for  development in Xamarin products. You can download and give that a try right now as well. Portable  class library support is coming. So where I had that core library before, it was actually  putting those C-sharp files in the core folder. And currently the preferred way to actually  share those C-sharp files if you did have four projects would be to file link them across  the four projects, which is a bit of a pain. Portable class library support will be in  Xamarin Studio. It's already in Visual Studio. And that will let you have another option  for writing and sharing code more easily. I mentioned and showed you the Xamarin.ios designer  that's currently in alpha. So you can play with that now as well by downloading it from  our alpha channel. But when that comes to the stable channel, it will be available in  Visual Studio as well as on the Mac. And of course, iOS 7, two days old, we're doing our  best to get that into the hands of registered Apple developers that are allowed to look  at it and make it available to all of our developers once Apple releases the final version.  That's a quick screenshot of Async Away. You've probably already seen it, but we're really  excited to have it in the product. And that's the iOS designer. Again, we've looked at that  briefly today. So with that, you could go back to your computers and start now. We have  a free trial version that's limited by the size of the application you produce. But  it's otherwise lets you put stuff on a device or test on a simulator. We've got piles of  documentation, user forums for support, samples on GitHub, and you can download it from our  website. I've got probably five minutes if anyone has any questions. First two questions,  get a monkey. After that, sorry. I guess you already had a question, so maybe you should  come and get a monkey. Anyone else? I can't give you exact dates. The Async Away support  is already in our beta channel. So we have three channels available for download so that  you can participate in the testing process. And you can switch between them from within  the tools. Async Away has been in the beta channel since Evolve with our conference  in April. So it's still going through testing. Obviously, we want to get out as quickly as  possible. PCL will be in the alpha channel kind of any time now, and then it will move  through beta and into production once we're happy with it. PCL kind of already works.  The problem with PCL is not our support for the IL because it's actually all IL under  the covers. It's implementing the complete support for recognized profiles and managing  it within the IDE when you try and step outside the profile while you're coding a PCL library.  So that stuff is in progress. You could come and get a monkey at the end. Getting rid of  the save button. Maybe you could implement the shake gesture and when you shake it, it  saves. There's a couple of things I guess you could do. You could just when they go  back. So you could respond to hitting the back button or you could have when they swipe  back implement save there. There's a lot of... iOS has a really powerful gesture recognition  system. If you could compare it to what Android has historically had. You can do a lot of  stuff just by doing add gesture recognizer to a view and you can have taps, multiple  taps, swipes, swipe directions, custom gestures. So you could really easily do something where  if they swipe across, it would just work. But I don't know. Anyone else? Oh. I guess  in Facebook terms, it's complicated. We love Apple and they approve all of our apps. We  do our very best to fit within all of Apple's licensing terms and restrictions. Things like  the Visual Studio tool where we support developing a Visual Studio but compiling on a Mac. We  purposefully ensure that we're complying with their terms which is that you must have a  Mac for compiling. You must have one Mac per developer. So when you're using Visual Studio,  you can't have a team of people hitting the same Mac. So we do our best to make sure that  we are a good citizen within Apple's developer community. And in return, we don't get any  special access to anything. We wait until WDC just like everyone else and then we work  our butts off to get everything ready for our customers. But, you know, everyone's in San  Francisco. You see and hear things. But it's really just like everyone else. I guess that's  it. Thank you very much for coming, guys. I hope that was interesting. And, yeah, like  I said, I'm about to do this whole thing again in an hour except for Android. If you come  along, you can just sleep through the first ten minutes.
Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_0_107.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_108_659.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_660_9839.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_9840_10751.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_10752_12287.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_12288_13703.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_13704_16811.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_16812_19523.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_19524_20243.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_20244_22931.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_22932_22979.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_22980_23051.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_23052_23195.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_23196_23327.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_23328_23423.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_23424_23627.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_23628_23747.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_23748_23843.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_23844_23903.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_23904_23951.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_23952_24047.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_24048_24203.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_24204_24299.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_24300_24791.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_24792_24923.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_24924_24971.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_24972_25127.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_25128_25259.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_25260_29939.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_29940_31091.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_31092_31355.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_31356_31439.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_31440_31595.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_31596_31655.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_31656_31703.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_31704_32351.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_32352_32543.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_32544_32615.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_32616_32795.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_32796_33167.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_33168_33515.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_33516_33851.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_33852_35315.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_35316_39719.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_39720_42023.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_42024_48227.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_48228_50171.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_50172_51143.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_51144_51599.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_51600_53267.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_53268_53447.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_53448_53567.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_53568_54671.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_54672_54767.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_54768_54947.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_54948_54995.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_54996_55187.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_55188_55295.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_55296_55343.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_55344_55463.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_55464_55931.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_55932_58547.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_58548_58967.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_58968_59207.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_59208_59951.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_59952_63791.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_63792_64583.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_64584_64739.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_64740_68387.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_68388_69179.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_69180_69347.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_69348_70379.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_70380_70955.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_70956_71159.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_71160_74855.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_74856_75767.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_75768_75911.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_75912_75959.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_75960_76607.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_76608_76667.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_76668_76835.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_76836_78227.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_78228_86855.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_86856_87335.png Craig_Dunn_-_iOS_with_C__using_Xamarin-68378928_87336_87435.png
Hey. Welcome, everyone. Thank you for coming down to hear about how iOS apps can be built with C-sharp using Xamarin. My name is Craig. I work at Xamarin as a developer evangelist, and today we're going to have a quick introduction to what Xamarin is and see how it works. So why Xamarin.ios? Why are you here at this session? Xamarin lets you write C-sharp apps for iPhone, iPad, and for the iPod. So if you're a Microsoft developer and you're a no C-sharp, it gives you a vector into a massive ecosystem of devices and apps that's really easy to monetize through with your existing skills and potentially with some existing code. That code that you write with Xamarin.ios can also potentially be shared with other platforms. So you can target Android as well with Xamarin.Android, and you can also use the C-sharp code that you write that's not directly user interface related on Windows phone, on Windows Store apps, and potentially also desktop enterprise apps anywhere else that you've got C-sharp doing calculations or database access or network access, really anything that's not directly touching the UI. The reason that you don't reuse the C-sharp that's directly touching the UI with Xamarin is because you write a custom UI for each platform. So the benefit of that is that using native UI widgets and your apps look and feel native. They look and feel native because they are native. There's no interpretation, there's no cross compiling. What we build is an actual ARM binary that runs natively on the device at full speed. The entire iOS SDK is available to you in C-sharp. So there's no features that aren't available because they haven't been provided by us as a tool provider. We've got complete coverage of everything that's available to normal objective C developers. So things like StoreKit, things like iCloud, all that stuff is supported by us. When new iOS releases come out, so iOS 7 is in beta at the moment, we do our best to get that stuff available to you as quickly as possible during the beta period, which we couldn't talk about anyway. When it's released, we generally have the same or next day availability. When iOS was released last year, we released the full production quality support for iOS 6 on the same day. Finally, Xamarin.io doesn't limit you to just using C-sharp. So if you've got objective C libraries that already exist or you find an objective C component on the web, you can also still bring that in to your Xamarin project, create a linking or binding file that we call it, and access that objective C code as well. So it gives you really unlimited power to develop iOS apps using C-sharp and then expanding out into objective C if you ever needed to. How does it work? Xamarin is based on Mono. So you may have heard of Mono. It started out in 2001 as a project, super quickly after Microsoft announced the existence of.NET and the fact that they were going to open, well, submit it to ECMSA as a standard so that other people could implement it. It was released in 2004 and its original goal was simply to be a C-sharp and.NET implementation that runs on Linux. And it's been around since that time, so the platform itself is very mature. But I don't think anyone realized in 2004 that less than 10 years later, the two major mobile platforms would also be based on a similar kernel and would provide a way for us to use Mono to host applications on mobile devices. So we've got Mono,.NET framework in a C-sharp language. How do we get that onto the phone and enable iOS development? We have a layer which we call bindings. Microsoft calls some projections in Windows RT. And what it does is it exposes the underlying objective C SDK as C-sharp. So any public class or object that's available in iOS for objective C developers is available to you in Xamarin and it looks and acts just like a C-sharp implementation. So you can subclass, you can override, you can treat the iOS SDK as a C-sharp framework. And as I mentioned earlier, you can also incorporate your own objective C, creating your own bindings similar to the ones that we ship for the native SDK. And finally, bringing together the.NET framework and the bindings and your code is a compiler. So for iOS, we compile to native ARM binary, which means that what you submit to the Apple App Store is to Apple pretty much indistinguishable from what an objective C app would look like. It's compiled down to exactly the same stuff. Because we're shipping a Mono runtime as part of your app, we also include a linker so that unused code, one of the beauties of strongly typed languages, can be detected and removed from the final application that you distribute. So we keep the size of your final app down as small as we can. Visually what I just said kind of looks like this. So you start with your C-sharp and the.NET framework that's running on Mono. We compile that to.NET IL just the same as you're familiar with for desktop.NET or for Windows, phone.NET. Then we ahead of time compile that entire set. So the.NET framework and your code sitting on top of it, linking out the stuff that's not being used into a native ARM binary, that goes to the App Store, you know, it goes to your device during testing and runs natively on Apple's hardware. So how can you get Xamarin to give it a try? We have a really simple installer. You can download it here. It will put everything on your Mac and or on your PC that you need to start development except for Apple's tools. So we can't redistribute them on their behalf for obvious reasons. So install our stuff, go to developer.apple.com slash iOS and download Xcode or actually you can get Xcode from the Mac App Store. Join the developer program and once you've installed those two things, you're ready to go building C-sharp apps for iOS devices. So Xamarin's development environment support encompasses a couple of different options. If you're on Mac OS, we have our own IDE called Xamarin Studio and it runs on iOS. It also runs for Android development which I talk about in a session later today. But if you scan across this line for iOS development, you can also develop iOS apps for iPhone and for iPad within Visual Studio. The Xamarin Business Edition includes a Visual Studio plugin and with a Mac sitting somewhere else on the network, you can do all of your development within Visual Studio, share code with other projects. It's the same project, the same file format and the Mac sits in the background and does the compilation and stuff that we need to do with Apple's compiler and software. So that looks kind of like this. We've got Windows, Visual Studio running on that and the Xamarin iOS Visual Studio plugin running inside Visual Studio. It provides Visual Studio with all of the bits and pieces that it needs to know about to build an iOS application. So it's a special project type. It has special project settings for iOS specific features, a special debug pane, deployment panes, output coming from the iOS device that you might be testing on. And that stuff talks to a Mac, somewhere on the network. So you do need to have a Mac available where you've installed Xcode and where we remote all of the compilation and all of the code signing, anything else that must be Mac specific because that's Apple. But you get a complete development experience within Visual Studio. So here's a quick screenshot of what the two IDs look like. Xamarin Studio and Visual Studio, they should feel very familiar for your Visual Studio user and you just want to work on a Mac. You'll feel right at home with Xamarin Studio. It looks a bit XCode-y in terms of the way we've got a simplified toolbar, but the solution structure is the same. References work the same way. The code editor works the same way. IntelliSense, all that stuff. If you want to work within Visual Studio, there's an iOS application inside Visual Studio being developed. So you can have very sharper, you can have what other tools you like. You can use TFS for source control and still be building an app that's going to run on Apple's hardware. One of the caveats for that running everywhere right now is that if you want to do drag and drop user interface design, we currently integrate with XCode for that. So if you want to do drag and drop UIs, you really need to be doing it on the Mac. What we are doing and what we've already announced at our conference earlier this year is an alpha version of our own drag and drop user interface designer. So that's XCode, a bit of skew it on your left. And this is the alpha of Xamarin's own user interface designer on the right. So when that user interface designer that we're building is complete, it will also be available on Visual Studio. So from within Windows, within Visual Studio, you'll be able to design and build iOS apps from start to finish. For the moment, it's in alpha like I said. So if you're in Visual Studio, your options for building your user interface is basically all code. You'd be familiar with that, particularly if you've done Windows Forms, newing up controls, setting their coordinates and adding event handlers to them manually. So a lot of developers do that anyway, even when they've got a visual designer available to them. So that's your main option for Visual Studio at this stage. The things that we add to Visual Studio and that our own IDE has on top of your normal.NET development are things that Apple needs to know about. So iOS specific options. The first one is code signing. So part of Apple's requirements for getting code onto a physical device is that it's signed. You manage that on a Mac through the Keychain app and through Apple's website. And we provide an interface that lets you choose the certificates or allow us to choose one for you based on certain criteria. And that's available on both platforms, obviously. And like I said, the code signing is delegated to the Mac host if you're running in Visual Studio. We also completely duplicate, sounds bad, we completely duplicate all of the configuration settings that Apple provides in Xcode. So things like the app name and version number, but also supported device orientations, splash screens, icons, all sorts of other stuff that's specific to iOS apps. You can set it all visually from within either Xamarin Studio or Visual Studio because we've provided the same user interface that Objective C developers are used to. And also deployment. So you can deploy to the simulator for testing, you can deploy to a device for testing, and you can also package up an app for distribution to the app store or from within Visual Studio or from within Visual Studio. So rather than just talk about Xamarin Studio and show you some slides, we're going to do a demo, live coding, what could go wrong. We're going to build a really simple app. If you've ever looked at the Xamarin website before, you will recognize that they're really simple to do list application. The main reason we use it as a demo is because I can build it in less than 100 lines of code. It has a database and it uses a couple of different aspects of the operating system that will help you get a little bit familiar with it, but also understand how easy it is to build iOS applications with C sharp. So we're going to just run up Xamarin Studio and do file new project or hit the new button. That seems big. So we're going to choose to do a storyboard application because I'm going to show you how the drag and drop editing works. So new in-competit application gives you what you'd expect. A few files and directories that if you hit run, will actually start something up right now. So that's a working minimal application. The things that it gives you that you never really need to look at or change are a main file. So static void main, common entry point for any sort of application. You never need to look at that. And an app delegate class, which is the first iOS specific thing that you're going to see. When you're building more complex applications, you will override some of these methods in the app delegate, but we're not going to need to do that for today. Just be aware that the app delegate is the first thing that's really starting up. That's the first part of the app, the first time that you get to write custom code for doing things like parsing inputs that might come if your application's been started from a link or from another application. For now, we don't need to know anything about it. The application does have another startup parameter though, and that is the main interface storyboard here. And this is just to give you a quick preview. This is some of the settings that we provide, which are equivalent to the Objective C slash X code user interface settings. So some of the folders, references folder you're familiar with. It's exactly the same as if we're in Visual Studio. We can reference only DLLs that have been compiled for Xamarin.ios. They're not their IEL, just the same as what you would expect, but they need to be compiled for Xamarin.ios so that we know that we're providing the same features that that DLL supports. We are in the process of fully supporting portable class libraries, and at that point, you'll also be able to reference a portable class library DLL from your application, which brings a whole host of options for the types of code that you can import. So a Visual Basic DLL that was compiled for portable class libraries would be able to be included in your IOS application. I'll skip the components directory because we're going to come back to that later. And just have a quick look at resources. Resources is an Xamarin.ios concept that we use to provide a simple place for developers to add media and, you know, any non-code assets to your app and keep them sort of organized in one place. So I'm going to just quickly dump in all the icons and splash screens that we need. And most of those get picked up by the application because there's a naming scheme, which we don't need to talk about now, but trust me, it works. So that's going to bring us down to the storyboard because that's the user interface. The first thing that's going to happen in this app is the storyboard is going to get run. So let me open it first in Xcode. And first thing I'm going to do is delete the whole thing so we can start from scratch. This is what Objective C developers are used to when they build applications using this tool. So I'm just going to drag on a navigation controller, which is a frame that enables that back and forth user interface paradigm that people with iPhones will be familiar with. And it's dropped on a table view, which is that scrolling list that also everyone's familiar with as the default initial screen. And I'm going to, because we're building the to-do app with a list and a detail view, just going to add another screen next to that and kind of try and lay them out nicely. So the user and face works pretty much as you'd expect. You can edit these values. I'm going to change the type to basic type so that it's got a title because we want to set that text. I think we need, based on our design, a button to create new tasks. So plus icon is going to be cool for that. So that's the design finished for the first screen of our application. It's going to have a list of cells that we can scroll and touch and also a button to create a new task. So to wire these buttons up so they actually do something, we can just drag to the screen we want it to go. So we want the new button to go straight into the detail screen so we can start adding a new task. And similarly, if we touch on something in the list, we want that to go to the same screen because we'll be editing that task. So I've got two arrows here now that indicate indicating that we can move from one screen to the next. Apple calls them segways. So not the thing that you lean forward with wheels, but the definition is like moving from one discussion point to another. Anyway, segway makes sense. We need to name that, I'll give it a call that one new task and that one edit task. And now we need to design the second screen of the app, which is going to be editing a task. So once again, it's going to be about dragging on a couple of controls. And trust me, we will get to some C sharp at some point. A switch, whether this task has been done or not. And let's say a button. And it's going to, the button is going to be the save button. And that's pretty much all the UI work we need to do. The last thing I almost forgot was to give our cell a name, task cell. You guys, I'm not sure if you can see that. There's a few different settings you can make. And also, I want to get rid of that chevron. So I'm going to just change that to none. Because we're going to have a tick there when the tasks are complete. So the last thing we're going to do is give the classes themselves names. So this is going to be task list view controller. And I'm going to call the next one task view controller. View controller is optional. You don't need to use Apple's naming conventions for stuff like that. What we're doing is saying that we're giving a name to this class so that that's what we can refer to these screens as when we have them in code. I think I've wired everything up. So let me close that. And when we come back to Xamarin Studio, yeah, I really wanted to see an error. We'll see how we go here. That class was the default one, so I can delete that. And you'll see it's created two new classes for me. These are the two classes that relate to those two screens that we've just created. And they've got a backing file which is really similar to a designer.g.cs in XAML. It's a way for partial classes to support adding controls which you can refer to in code later. If we hit run, there's the application. It doesn't actually do anything yet except the controls work as expected. But you can navigate between those two screens. So let's actually do some C sharp. To finish off the user interface, one thing that we will need to do is give the controls themselves names. So we've created a save button and a text input. But we have no way of referring to them in code yet. So I'm going to do that from within our Xamarin designer. So what you're seeing here is not X code. It's the custom Xamarin designer which in the future will be the preferred way to work with these things. And I'm going to give that, I can zoom in a bit here, title text. And I want to call the switch. Done. Done switch. So this, you know, you're designing an iOS screen here. But really the way you're selecting things and setting properties is really just like any other iOS, other windows. User interface designer, dragging stuff around and using the properties pane to manage the way things look. So let me save that. And let's go now and just have a look at the designer file. And we should see all the switches done switch save button. Title text. Wait for that to appear. So now we've got a user interface. It's basically a wide up. It's time to start doing some C sharp. So we'll start with the task view controller, which was the detail view. And at the moment, it's a partial class. It's got those controls in the back in class. And I'm just going to that safe button still isn't there. Did I mention this is in alpha and it's worked three times today. But there we go. Now we've got all three backing fields there. So this is the cool thing about override view load. And when you're using Xamarin Studio, you don't even have to code most of the stuff because the autocomplete you used to from visual studio is there. It's the same, but it's providing autocomplete over the objective C class library. So when I do view override there, it tells me that a view controller has all these options, including view did load, which is the one that I want. It tells me based off view did load should be in there already puts it there for me. And then I'm just going to do save button dot touch up inside, which is their version of on click. We're not going to go into all the details. And then I can just add an event handler. And I can implement it. So for now, I'm just going to put to do need to save task here. And then navigation controller. So basically, that's a very dot net way of making a button do something. There's an event handler, we sign an expression to it. And all it's done now is a to do. And then the navigation pop to root is basically just go back to the previous screen. That's a 100% C sharp thing working on this iOS stuff that's underneath the covers that doesn't have event handlers doesn't know anything about C sharp. But this, this just works. So that's one way that, you know, C sharp familiarity comes right into any sort of iOS development. We'll come back to implementing save later. In the task list screen, we also drag those two arrows which were called segways to help with navigation. But you might have started to wonder already, how do I know which row was clicked on when that that segue happens? You know, I've just dragged from some, some undefined row across to say this is the screen that you open. So there's a method which I'm just going to quickly make appear called prepare for segue. So we actually named those segways for a reason. This screen is going to get a message every time a segue is triggered. And this little if statement gives us the structure to react to, to which segue has been hit. So the new task one, we're going to start the new screen, we can probably just start it because we don't know what the task is anywhere. We'll new one up later. And the edit task there, I'm going to add some code there to find out which row was clicked. Find that task object that we're going to create and then send it on to the next screen so that we're actually editing the task that we that we clicked on. So I just said the task object, we don't have a task object yet. So let's quickly create a business object that we can start to work with. I'm going to put it in a file called core, because the code that we're going to write now, and it's not much code, could be shared. So there's the task class. And I'll just quickly added a couple of properties. So our task has an ID, a title, and a done. That's all that we need to represent. And we want to save this in a database because it's going to be more than one task to fill that list. So I've thrown in a couple of things. If this was a database, I would want that to be the primary key. I would want it to auto increment and become a table somehow. That's where the Xamarin component store comes in. So SQLite is built into both of the platforms that Xamarin supports, iOS and Android. And you can write ADO.NET code that accesses that SQLite database. You can write SQL to create the table, do all of your model language stuff. Or you can add a really simple RMRapper called SQLite.net. So that's the Xamarin component store. Just quickly go in there. We can look at some more components later. And there's some instructions in there that tell you how to use it. But basically what's happened is that it's added the component here, which we can always access to reference the samples and the documentation and to get upgrades when the version number is incremented. But it's also added a DLL reference directly to the project so that it's ready to use. So if I go back to our task now, it can resolve those things, primary key auto increment as being in the SQLite namespace. Now we have a task that we're going to be a task class that we're going to be a push instances into the database without SQL, without using any SQL. So now I'm going to go back to the task view controller, which is the detail screen. And add an instance public task current task. So now this instance, this detail view has a property that we can set that this is the current task that we're going to be working on. And create a view will appear. And so once that's been set, we want to also populate the fields on the screen with information from the task object that we've created. So view will appear. iOS and Android as well and Windows phone all have a life cycle for applications and for screens when they're being created, when they're being shown to the user, when they're being paused or backgrounded or tombstoneed, when they're being re-displayed, and finally when they're being destroyed. Each of them uses slightly different semantics, but they all have a very, very similar goal of creation, loading, appearing, pausing or going to the background, appearing again, going to the background again, and then finally getting destroyed. So for Apple, for iOS, we've got view did load. The first time the thing is coming into memory. View will appear and did disappear to capture when things are going back and forth in front of the user. So that you know when you need to refresh something, if something's happened in the background, and then view will appear comes, you know it's coming forward and you need to check again. So basically what we're going to do in view will appear is just check that, I might name those with caps I think. So the current task, assuming the current task has been set before this method is called, we're going to populate the title text and the done switch with the values from the task, and that task is going to come from the database when we get to this detail screen. So those two lines of code there, that could be any.NET UI, that could be WPF, that could be Visual Basic 6. It's taking properties out of an object and assigning them to a visual widget's property so that it's displayed to the user. Now we want to go to, now that we've got that I guess, the question is where's the database? So let's go back to the core code because we can write database access code that is shared. I'm going to call it task view model. It probably could be task repository. Please don't get offended by my misuse of the view model pattern. So there's a bit of code here that's happening. I'm just going to resolve, again same as you can do in Visual Studio, resolve these two things to add the using statements at the top. So this is our C sharp code that is going to let that task object that we annotated with a couple of properties be persisted in the database and be able to get those values back as task objects from the database. So the important things are create table. So we're finding a location on the device which we have which is within the sandbox for iOS applications of sandbox and they can only write within a certain part of the system. We are calling it task dot DB system IO path. Every dot net framework feature or file handling whatever is available to you within Xamarin.ios. So we're just using regular dot net file operations to build up a directory name creating the SQL like connection and then creating a table called task. That is you can call that any time under the hood it's checking whether it exists and if it doesn't it creates it. If your object definition has changed since the last time you've called create table so the next version of your application it will automatically do migrations as well of the schema. It will only do additions. It won't delete columns so you have to be a bit wary of that but then it's a simple ORM. So every time we construct one of these task view models which we'll do it's going to just make sure that the database is there and then it's configured. Then we've got some really simple methods. You're going to recognize the CRUD code. Saving a task if the ID is not set or it's zero that was the auto increment column so we're pretty confident that it's going to have an ID greater than zero. We're going to update the object so we're passing in a task. We can update it and return the new ID that's been assigned. If it's not we can insert it and I think that's rather wrong. Then we're returning the ID that was generated. Get we're using first-order fault so you recognize that from, oh I haven't resolved that. You know link syntax and if we want to get a list of all the tasks we're again using link to get the collection of tasks from the table and link order by and select to send the collection back up to our user interface. So that's a really simple API I guess to load and save data without writing any SQL based on a set or based on an annotated task model, a class. The cool thing about this is that all of the using statements are cross-platform. So that cork bit of code and we could have 10 or 100 classes in there. We could have multiple database tables. We could also do web access. We can take that and put it into Windows Phone 8 app. We can put it into an Android app. So the more business logic and data access and validation that you can fit in stuff where the usings are limited to.NET or could be in a portable class library, the more code you can reuse across multiple platforms. So let's save that. So now we need to actually do something here. Save the code. So we had it to do there earlier. And again I've given these the wrong case. So to implement the save on the detail screen, assuming the user's done some input, we haven't got any validation happening. We're doing the reverse of populating the screen, taking the user interface widget value, assigning it to this current task object. Here when you're up a view model, I could have done that at the class level actually. And then we're just calling save. So there's user input coming into a class and being pushed down into the SQLite database in a couple of lines of code. And then again pop to view controllers just taking us back to the list screen. So at this point we've got a working detail screen which when it's loaded with a task object, copies its properties out onto the screen with a save button wired up with an event handler that will take those text input and the button value and push them back down into the database. So what we need to do now is make the list view work so that all of those new tasks that we save go back into the database and we've got a list that we can select from. So let's go back to the list view and we'll add some code here. So basically what I'm doing here, adding the view model. So the list view is just going to keep a copy of the view model around. We can use that to get data whenever we need to and we're just going to new it up in the constructor. Then view will appear, again that concept of the life cycle. Every view did load happens once. So if I was to call something and view did load then go off to another screen and create a task and then come back, the list is not going to show it. View will appear is called every time we come back to this screen. So that's the place where we want to say oh there might be new data here because the user has been off doing stuff. Again let's try and load the data in and display what the user wants to see. So the syntax for that is there's a table view, that's an intrinsic part of this control, we didn't need to declare it, that's what the control, this screen is a table screen. We need to assign a data source which is an adapter class if you're familiar with that kind of pattern. It's going to take something and turn it into like an API, wrap it in an API that can be used by something else. So the table view is a user interface control. Apple's built it, you don't want to implement that yourself, you just want to take advantage of its features so you need to tell it the data to display in the table view. What we've got is a list of task objects, an eye list of them. The table view doesn't know what to do with that. So we need an adapter that's going to take our list of objects and tell the table view this is what you need to do with it. So we're going to add the adapter class, it's called a data source, so task data source. And I'm just going to add the code. So again I'm just going to quickly cheat, resolve these. So here's what a data source looks like. It inherits from an objective C class which again is amazing. Like there's a whole pile of infrastructure underneath the covers there to make that objective C thing look and act like it's a C sharp thing so that we can override methods and change its behavior. It's going to take our collection. So the code that we just saw from the view model is going to load up a list of tasks from the database. Great. Now we need to show them to the user. So here's our data source taking that list of tasks and then the overrides in this class is the minimum API that Apple says the table source needs to be able to show stuff. So the first method rows in section, super simple. When the table is about to display some data, I guess one of the things it's doing is figuring out what the scroll bar needs to look like, how big it is, it's proportional. So you tell it how many rows you need to display. The second thing you need to do now that it knows how many rows and it's going to render for that number of rows is what do I put in each row. And so we implement a method get cell to shift up every time it asks us, give me the information for row one, give me the information for row two. We're just going to write a little bit of code that does that adapting of our data to the table views expected stuff which is actually a complete visual cell that it can display on the screen. So there's some boilerplate code here. The table view control supports virtualization if you're familiar with that concept from WPF as well. So if you've got a million rows, it doesn't create a million cell objects in memory. It just creates like 12 which is about the height of the screen plus two and it reuses them. So as they go off the screen, they go into a queue and you just grab the next one and smash over all the properties to keep the table performance scrolling quickly. So it's that pattern. You'll see it everywhere. We're using a custom, well we're using the default cell. We actually said that back in the storyboard. I changed the type to just use a default cell. I don't want to draw one. I don't want to make anything pretty. I could do right here. I could use a cell subclass that was pink and had italic font and all sorts of stuff. But for now, we're using the default cell. We know it's got a text label. We're getting the task list item for this row and displaying the title in the cell. We're then checking the done property for the task in this row and turning the check mark on or off. And check mark and a few other accessories are default things that the iOS cell supports. And again, if you want to do more, you can make this as custom as you like. And we return that cell back up to the table view and it's going to show it in position one and position two and position n. And finally, we're implementing a helper method for ourselves, get item, so that it can provide a shortcut for us to get back the task that's being displayed for particular row, which we're using a touch event or something like that. So let's go back to the task list view controller now, uncomment that and it's ready. The final thing we need to do, we've just implemented the database. We've just implemented an adapter that takes the output from the database and shows it in the list. And we have a working detail screen that loads data and saves it. Those two segues that we drew at the start don't do anything. I've just had these placeholders here the whole time. So I'm just going to quickly wire them up. So the destination view controller, we're going to quickly cast and get an instance of the control we're about to hit. So we're about to visit the task view controller screen. It should be, should exist. And I'm going to set the current task to a new task. I could do something tricky in here like set the default text to angle new task or some other prompt. But we're just setting that and then we're doing the equivalent thing here. Oops, that's what happens when, oops. For edit task, we actually need to do a bit more work. So we're going to first cast the destination of the segue to the screen that we know about. And then we're going to, from the data source, which is the adapter from our database to the table, we're going to find the index for the selected row. We're going to get that task object using that row. And we're going to set the screen that we're about to display. We've set its current task property to this task object. Now we already set up the detail screen to expect that to be set. So that's pretty much all we need to do. And I'm going to hit, just debug property there. So hit run again now. What have I done here? I'm just going to comment that out. And here it is starting up in simulator. So we'll add by milk. And I couldn't buy it. So there is the task there. Let's add another one by eggs. Save. Now that popped root you can control. I'm not sure why that's not working right now. But if I set that on, so that's it. That's less than 100 lines of code. It's a C sharp application with database access running on an iOS device. We can put it on the hardware if we had time to play around with it. If I go into this and set a breakpoint here, let's hit, let's say we're going to buy eggs. Breakpoint gets hit. You can explore these objects just like you would explore anything else. You can explore native objective C objects. And there's a massive stuff there because it's surfacing all of the stuff that's happening in objective C in the background. But yeah, you can debug. You can step through. You can run just like any other C sharp development environment. So that's a complete, it's 100 lines of code. You can take that model and build a very basic database, a couple of navigation controllers that zoom into details of the screen. So this monkey space app, which is another conference that's happening back in the States is the pretty much the same concept that little ever this whole thing is a list of data going to a detail screen. You can hit favorites. You can scroll. These are custom cells. We're not using the default cell, but they're really easy to draw. You can include map control. There's favorites list. You can draw speakers. So that code is open source as well. And if you have a look at it, you'll see there's very little difference. Certainly it's not complex from the really simple we looked at today, simple example we looked at today to something like that conference app. It's just in terms of adding detail, creating some custom views rather than using the default, adding a bit more data to the classes. But you've got in terms of foundation, pretty much how everything works from this to do example. So we go back to slides now that we've done that. Hopefully, yep, the result was as we expected, we built an application with C sharp that runs on iOS. I talked a little bit about sharing. Like I said, there's multiple things that you can share so using Xamarin.OS is great for getting an app on to a phone. So if you just want to build for iOS with C sharp, it's a great story. If you want to build for iOS and Android and Windows phone and Windows store apps, it's an even better story because you can share components. So the SQL like component that we put in runs on all those platforms, which means that the core data that you write, the business logic, the database access, validation rules, you can also share that code across all of those four platforms. If you've got bigger teams, you want to look at sharing the structure of the code too. You want to keep the screen names kind of the same. And you want to maybe structure the code the same in folders or however you structure it. Because you can do it all in Visual Studio, you can easily validate by looking at it that they're the same and really utilize the fact that you've got C sharp everywhere to keep things common and help people that are working on the code be able to understand it. And also the design. So you can share the design. That app that we just built here, we're going to build again in an hour in Android. And with respect to some of the platform's differences in terms of navigation, you can really get some leverage from building stuff similar. There's also a version of this for Windows Phone on the net. There's some code available for that as well. And you can see the core of it's the same, but because you're doing native interface on every platform, you can respect the different navigation paradigms where you need to. So you don't add a back button on Android because it's there. You do things slightly differently in Windows Phone because you might want to panorama, et cetera. You can put a lot of code in the core library. So system net stuff can live there. You can access web services. You can parse the web services. You can use the file system. We've got an implementation of isolated storage even so that if you want to be sharing with Windows Phone 7, you can do that. The more stuff you put in there, the easier it is to test because you can actually write unit tests that hit that layer on their own. But you also get testing on each of the vertical platforms. So you can test it when you write the iOS app and be pretty confident when you get to Android or Windows Phone or Windows Store that the core library works. It works on one platform, but it's the exact same code that will be able to run on all the others. So to recap, you can build iOS applications in C-Sharp with.NET. You can use Xamarin Studio, which is nice. That's what I spend all my time in. Or you can use Visual Studio even for building stuff for iOS. The apps have native look and feel because it is native widgets. And because they are native, they also have native performance. You can share code with Android, with Windows Phone, with Windows Store. And we have a component store that makes available a lot of different components that will let you enhance your application in other ways. So if I go to components.xamarin.com, you can browse it on the website. You don't even need to download anything else. So there's an Azure Mobile Services component that Microsoft has published. So you can add that the way we just added SQLite, get your key, your authentication keys from Microsoft, and pretty much the same way we just added some attributes for that to do class to save it to the local database. You can push that stuff out to an Azure Web Service. It's really simple. There's signature pad, like there's user interface controls like signature pad. There's encryption controls, charting libraries, themes, a whole pile of stuff. And like I said, there's stuff available on the components store for iOS, for Android, and for Windows. Yeah. There is an independent, Xamarin Studio is based on an open source product called MonoDevelop. And both products have the same plugin architecture. And there is already an independently developed NuGet plugin that runs in both MonoDevelop and Xamarin Studio. So you can now currently grab NuGet and incorporate them into your projects. It would sit side by side with the components that we support. Xamarin components store supports paid as well as free components. And it's also super easy for you to write and publish components to the components store and sell them. And we reimburse you after selling it on your behalf. Quickly, we've got a few minutes left. What's next for Xamarin.ios? We're currently beta testing async await support. So the parallel task library's been in the product for a while. But the async await keywords were just added to Mono, the underlying Mono Core late last year. And we're just in the process of finishing up incorporating them into the iOS mobile product right now. F-sharp is going to be a first class language for development in Xamarin products. You can download and give that a try right now as well. Portable class library support is coming. So where I had that core library before, it was actually putting those C-sharp files in the core folder. And currently the preferred way to actually share those C-sharp files if you did have four projects would be to file link them across the four projects, which is a bit of a pain. Portable class library support will be in Xamarin Studio. It's already in Visual Studio. And that will let you have another option for writing and sharing code more easily. I mentioned and showed you the Xamarin.ios designer that's currently in alpha. So you can play with that now as well by downloading it from our alpha channel. But when that comes to the stable channel, it will be available in Visual Studio as well as on the Mac. And of course, iOS 7, two days old, we're doing our best to get that into the hands of registered Apple developers that are allowed to look at it and make it available to all of our developers once Apple releases the final version. That's a quick screenshot of Async Away. You've probably already seen it, but we're really excited to have it in the product. And that's the iOS designer. Again, we've looked at that briefly today. So with that, you could go back to your computers and start now. We have a free trial version that's limited by the size of the application you produce. But it's otherwise lets you put stuff on a device or test on a simulator. We've got piles of documentation, user forums for support, samples on GitHub, and you can download it from our website. I've got probably five minutes if anyone has any questions. First two questions, get a monkey. After that, sorry. I guess you already had a question, so maybe you should come and get a monkey. Anyone else? I can't give you exact dates. The Async Away support is already in our beta channel. So we have three channels available for download so that you can participate in the testing process. And you can switch between them from within the tools. Async Away has been in the beta channel since Evolve with our conference in April. So it's still going through testing. Obviously, we want to get out as quickly as possible. PCL will be in the alpha channel kind of any time now, and then it will move through beta and into production once we're happy with it. PCL kind of already works. The problem with PCL is not our support for the IL because it's actually all IL under the covers. It's implementing the complete support for recognized profiles and managing it within the IDE when you try and step outside the profile while you're coding a PCL library. So that stuff is in progress. You could come and get a monkey at the end. Getting rid of the save button. Maybe you could implement the shake gesture and when you shake it, it saves. There's a couple of things I guess you could do. You could just when they go back. So you could respond to hitting the back button or you could have when they swipe back implement save there. There's a lot of... iOS has a really powerful gesture recognition system. If you could compare it to what Android has historically had. You can do a lot of stuff just by doing add gesture recognizer to a view and you can have taps, multiple taps, swipes, swipe directions, custom gestures. So you could really easily do something where if they swipe across, it would just work. But I don't know. Anyone else? Oh. I guess in Facebook terms, it's complicated. We love Apple and they approve all of our apps. We do our very best to fit within all of Apple's licensing terms and restrictions. Things like the Visual Studio tool where we support developing a Visual Studio but compiling on a Mac. We purposefully ensure that we're complying with their terms which is that you must have a Mac for compiling. You must have one Mac per developer. So when you're using Visual Studio, you can't have a team of people hitting the same Mac. So we do our best to make sure that we are a good citizen within Apple's developer community. And in return, we don't get any special access to anything. We wait until WDC just like everyone else and then we work our butts off to get everything ready for our customers. But, you know, everyone's in San Francisco. You see and hear things. But it's really just like everyone else. I guess that's it. Thank you very much for coming, guys. I hope that was interesting. And, yeah, like I said, I'm about to do this whole thing again in an hour except for Android. If you come along, you can just sleep through the first ten minutes.
the UI with Xamarin is because you write a custom that using native UI widgets and your apps look look like. Xamarin Studio and Visual Studio, they easy it is to build iOS applications with C build for iOS and Android and Windows phone and sharing the structure of the code too. You want published. So you can add that the way we just