Android with C# using Xamarin
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Dunn, Craig
Learn how to build an Android app with C# using Xamarin.Android. We'll create a new app, learn how Android-specific idioms work in C# and use Xamarin's tools to build a native UI, access platform-specific features and see how to deploy to Google Play. Using Xamarin and C# will also let us share code with Android and Windows apps.
 Okay, thanks for coming everyone. My name is Craig from Xamarin and we're going to talk a bit about developing apps for Android with C-Sharp using the Xamarin platform. So why Xamarin.Android? Why are you here listening to me this afternoon? Because I'm going to tell you how you can write C-Sharp apps for Android phones and tablets using the language and the tools and framework that you already know if you're a Windows developer. Also, that C-Sharp code that you write for your Xamarin.Android application can be reused for an iOS application, for a Windows phone application or for Windows Store apps. And also you can bring in code that you already have from Enterprise apps or from one of those platforms and use it in your Xamarin.Android project. You will be creating native Android user interfaces because Xamarin.Android uses the native widgets for the applications that you build. And because the application itself is running on top of a native implementation of the.NET framework, you're getting native performance. There's no translation, there's no cross-compiling, it's not running as Java under the covers, it's running as a.NET framework on top of the underlying Android operating system talking to the hardware. And if you really need to, you can access Java libraries as well. So if there's a third-party control widget or a third-party Java library or some existing Java code that you have, we also provide the tools that let you wrap that up in a C-Sharp API and include it in Xamarin.Android projects as well. So how does it work? Underneath the covers is mono, an open source implementation of the C-Sharp language and the.NET framework that was originally started to enable basically a programming environment and Windows Forms clone on Linux back in 2001, soon after Microsoft announced that they were going to submit it as an open standard. And the project itself didn't get released officially until 2004. And I'm pretty sure at that time no one realized that in less than 10 years we would have the computing power we do on our phones and that they would also be running the same sort of kernel enabling mono to be put on those phones and run C-Sharp on hundreds of millions of devices. So mono is.NET, it's a.NET you know, clean room implementation, but all of the same classes and frameworks that you're familiar with. To facilitate building Android applications in C-Sharp, we also need to give you access to the underlying Java widgets and the Android platform as well. So we expose those as bindings or projections to use Microsoft terminology from the Windows Store slash Windows phone 8 side, which basically exposes any Java object or class or whatever under the covers as something that looks and behaves like C-Sharp. So you can subclass, you know, you can new it up and implement anything that exists in the Android Java SDK from within the C-Sharp environment. So tying all that together is a compiler. And we're doing something on Android that's very similar to what you're expecting to happen on the desktop environment. So our compiler takes your C-Sharp code and whatever else that you've built into your application and produces IL, just the same as a desktop application for.NET framework exists as a set of IL. And we package that IL up with a native Android runtime. So it's the.NET framework that you have installed on your PC, but it's mono. We shrink it down by linking out all of the things you're not using. So strongly type language, we can do a map and we can trim out all of the classes and methods that aren't being accessed. So it's the.NET framework itself, linked down to the subset you need, packaged with the IL on top and put into an APK to run on Android. Visually, it looks kind of like this. So you've got your C-Sharp and the.NET APIs that you're using. We compile that to.NET IL. We package it into an APK, as I said, with the.NET framework, with the mono framework linked out to the smallest possible subset that you need, and then we ship that off to the Android device. Now on the Android device, the IL is running on top of the native.NET framework implementation, which is running on top of the operating system. In that stack, if you can visualize it, there's not really any Java involvement. So all of your math code, all of your business logic, anything that's pure C-Sharp that you've written for your Android application is running on top of the native framework, which is running on top of the operating system. Where the bindings fit in and where you're accessing Android widgets and user interface, it's a call across to Dalvik. Dalvik's sitting on the operating system as well, and Dalvik's sending screens and data to the user. But we sit side by side with that. The mono runtime and the Dalvik runtime coexist. They both have direct hardware and operating system access underneath them, and they're both effectively able to communicate to the user. But there's no performance penalty, there's no layers of indirection. It's running side by side. The key, I guess, issue that we have in terms of that interoperability is we're managing our garbage collector, and we're trying to manage Dalvik's garbage collector in a sense because we're creating and destroying objects on our behalf because we've subclassed them, we've implemented a wrapper for them in the C-sharp side. But it's a side by side, we don't sit on top of Java at all. So how do you get that working on your local machine? We have a simple unified installer. You only have to go to xamarin.com slash download and start. We'll pull down everything that we can for you and install it onto your local machine, whether it's a Mac or a PC, including the Android SDK and all of our tools that will enable you to get up and running for free, basically. We have a trial version that lets you start developing for free, all of Android's tools are free, and you can side load Android apps no problem so that you can distribute to your friends or within an enterprise without really any involvement from Google at all. If you want to deploy to Google Play, you can play to Google.com slash app slash publish. It's $25 a year, I think. And the application that the APK file that xamarin.android generates, uploads fine to Google Play and works on any devices that you can name. So development environment support once you have installed xamarin is the third line there. So on OSX, you can use our own development environment xamarin studio. On Windows, you have a choice. For Android development, you can use xamarin studio or if you have Visual Studio and the xamarin business edition license, you can work within Visual Studio to build Android applications, to build iOS applications, as well as your Windows phone and Windows store, et cetera. So you can choose to use our free IDE or if you already paid for Visual Studio, you can use that as well. This is what the two ID's look like. You'll be very familiar with if you're a Visual Studio user, xamarin studio won't take long to get used to. The solution structure, all of the file formats are the same. So you can open projects interchangeably in the two platforms. The ID feels the same. It's got IntelliSense, AutoComplete. It's visually similar. So really the only choice is have you paid for Visual Studio already? And do you need Resharper? In both Windows and on the Mac, you have a graphic or UI designer. So Android has its own XML format which is used to create screens. We've built our own designer that lets you do it graphically so you can drag and drop, edit properties, the same way you're familiar with dragging and dropping for xamarin blend or Windows forms way back when. And xamarin studio and our Visual Studio plugin also implements all of the customization, all of the property pains that you need to build an Android app. So if you opened an Android app in Eclipse, there's a few different things that you need to set to make things work. We expose those as a user-friendly API as a user-friendly user interface as well so that you can check a few boxes to get the configuration that you would like for your Android application. So there's a couple here that I want to highlight. We'll go from this one first. So you can choose the CPU architecture that you want to target. So you've got ARM or ARM v7 depending on the devices that you think users will have. And there's also an option there for x86. It might not be a platform that you're targeting for deployment, but there's an x86 emulator that's available for development. And if you're, you basically want the x86 emulator if you're doing development for Android because the ARM one can be slow and painful to work with. So you need to know about those settings so that you can enable x86 to get that emulator working. I mentioned linking earlier. So linking is a great feature of Xamarin.Android because it gives you a small APK to deploy to your users. The downside if you want a really fast compile test debug cycle is that it takes time to do that map of your code and to link out the stuff that you don't need. So we have an option that lets you turn linking on and off to speed up your development time. So you can change that setting. It's just important to remember to turn linking on for your production deployments to keep the APK you distribute to your users as small as possible. And finally, I want to point out the setting over here, use shared monoruntime. So this is a feature that we've enabled specifically again to help the compile test debug cycle be really fast. Because of how I explained earlier, on Android devices we put the monoruntime on there and have your IELS sitting on top. The immediate question might come to your mind is, well, on a PC there's only one instance of the.NET runtime and apps are just IEL. They can be really tiny and they all share it. That's possible for us to do on Android. So we can install the shared runtime like it's on a PC, one copy, and you can have 100 Xamarin.Android applications which adjust the application IEL. Maybe 20K, maybe 40K, maybe something really simple. And so we enable that ability for debugging because copying up a meg or two meg of runtime for every compile test debug cycle, you know, it's probably slowing you down unnecessarily. But we do not enable that for deployment to production. We don't want to be the gatekeepers of multiple or incompatible copies of a.NET framework on a user who's got Xamarin.Android apps from different places. So shared runtime is there and if you're using our product you'll notice it and you might think to yourself, why can't I just have one shared for users from our users? And the answer is basically that we want to protect them from themselves by having each application only ship with the runtime that it was developed on. So keep that in mind if you're using the product. And the other thing of course is Android manifest XML. So if you're an Android developer already and you've used Eclipse, you'll notice that there's very similar kind of options for speedily entering the most common things that people add to their Android manifest file which is loaded up by the operating system to determine certain things about the application. Most importantly the version and the required permission set. So Android has that concept of sandbox that your app runs in and can only access telephony or network or other things if you request it and then the user agrees when they install it. So we provide those settings in an accessible way just the same way as Eclipse or other IntelliJ provide for their Android application settings. The one thing that you won't see Android manifest happen do in Xamarin.Android for those of you that are familiar with Android development is you don't need to declare every activity manually in your Xamarin, in your Android manifest. And I'll show you when we look at some code how we achieve that using attributes in C sharp to have classes effectively put up their hand for participation as an activity in Android manifest rather than having to keep it in sync manually. We also have deployment options so that you can easily publish an Android application. We have a wizard that lets you find a key store and sign the app and compress the what is it called binary alignment and output an APK that's ready to either distribute to users or to upload to play. So that's just a quick overview of Xamarin.Android. Probably the easiest way to understand it is to see some code being written poorly. So we're going to build this app. If anyone's already familiar with Xamarin tools, you've probably seen our favorite to do list application as a sample already. It's useful because it's a really small application and can write in under 100 lines of code, but it utilizes a lot of different things about Android lists and navigation that help to show the platform off. Let's go over to going to use Xamarin Studio. I've got a Mac here obviously. So new up and Android application. Android to do. And the first thing you'll notice is we try and provide you with something that's going to work out of the box. So if you run this application up right now, it's you can see there's like a button that counts how many times it's clicked. It's the classic hello world working application. So it's given us a main activity. If you're not familiar with Android, an activity is kind of like a screen, it's kind of like a view controller. It is a class that is normally associated with a layout. So the activity class is where we write our code. And there's the concept of a layout, which is the XML that describes what widgets are on it that we reference and then connect to work with those elements. So let me go through where those things live. Resources folder is an Android standard location for certain sets of application parts, I guess. So drawable is a subfolder of that. It's always called drawable. And it always contains images or XML files that describe the way images should be used. So we've got an icon there. And we can just maybe add a new icon. Oops, target. And we'll copy that in there. So icon. The layout folder is where the XML lives that describes your screen. So if I open this main XML file, you'll see as I mentioned we've got our own custom designer, which lets you view source and work with the visual design. And a string's file, which is a lookup for string values that help you with managing them and also with localization, I guess. So I'm just going to start customizing this. So we have an add task button. And let's look down. We need a list view to display the list of tasks as per the mockup that I showed you guys a second ago. So we drag that on there. It's kind of non-visual. But if we look in the source, we can see the XML. So this is Android's native XML format. There's nothing really to do with Xamarin except that we provide the editor and let you work with it. So I'm going to just type in the IDs here because I can. We could also have done that in the layout editor. And you can see linear layout, if you're.NET person, that's like a stack panel. And we've created widgets in there with some layout metrics and some Android syntax there at plus ID slash and the name of the control. So just get used to seeing at plus ID slash and stuff after it is the stuff that you care about. Because we're in the process of building those two screens for the task list, I'm just going to rename this task list and add a new layout and call it task view. So let's just see what's there. It's given us a linear layout to start with. It's kind of default. And we want to add, let's say, some text. So our task is going to have some text, a checkbox, is it done or not, and a button. So let's just edit that to save. Let's just edit that to done. And yeah, we want to give these useful names. So rather than going right into the XML, let's just use the property pane over here to set those values, title text, done checkbox, or typo, and save button. So there's a lot of other properties that you can set for all of these controls. It's dependent obviously on the type of control. If we pop into the source now, it's keeping that in sync for us. The designer also lets you try out what the layout you're working on might look like on other devices. So I've picked the default Nexus one, but if we had a really tiny screen, it would look really tiny. And if we put it on a tablet, it would look kind of ridiculous. It's slightly more powerful than that though, because you can tick these locks and say, I want to keep this layout on this form factor, and then change the form factor and start making changes. And that's a feature of Android that Google's enabled to help with the fragmentation of screen sizes and device capabilities. So what will happen is a separate layout folder gets created for each different fragmentation vector, if you like, and it'll save a different copy of this layout with the various different changes that you've made. So if I went to the tablet, maybe rather than having it full width, I just push everything over to the left, for example. The control names remain the same, and when it's loaded on the device, Android takes care of loading the correct layout for me. I just have to make sure that I can manage all the control names that they all exist in all the various layouts that might be in use. But that stuff is all supported by a designer and helps you, gives you a big helping hand when you're trying to deal with devices, multiple screen sizes particularly. So we've just drawn these two layouts, named the controls. First thing you'll notice now is the layout reference in the code is broken. So I renamed main to task list. So let's just change that and fix it up. We don't want that button handler. I might just rename this as well to task list so it's simple. And while we're here, let's look at this activity attribute. If you're familiar with Android already, the Android manifest XML is a way or central location to define parts of the application that can be used. And one of those things is an entry in that XML file for every activity that you've declared that you want to be accessible so other activities can navigate to it. That's fine. Everyone's used to doing that. But it's a two-step process if you create a class and you want to go and then update the manifest. And other tools will help you do that automatically. The way we've chosen to do it is implement an attribute. One of the great things about.NET and C-Sharp is the metaprogramming capabilities of attributes. So anything that you could have added kind of weakly typed because you're just entering a string into Android manifest XML. In Xamarin.Android, you can do it strongly typed in the IDE directly in your code. So we can say, for example, that we want to set, let me zoom in there. We want to set the icon. So again, with the app drawable slash, it's an Android thing and you'll get used to it. But the label, which has got what the label of our application is going to appear on the home screen is set here. Main launcher equals true is an Androidism, which is saying to the operating system, this is the first activity that opens when this application is run. So it effectively gets an icon on the home screen. So at compile time, Xamarin.Android is taking that attribute along with various other things and updating the Android manifest so that what goes to the device or to the simulator is consistent. The activities all exist and they're referenceable. You can call them from each other. Let me just rename that as well. So I want to just quickly get the navigation working. So let's add some code here. We've already got that. And we need to declare the button. So this should look familiar to any.NET developer and it will probably look very unfamiliar to someone that's only done Java because there's like a whole anonymous class missing. One of the benefits of using C sharp to build Android applications is that we bought the C sharp isms to Android. So being able to just attach an event handler like this is quite a bit less code than the Android Java way of doing things of creating an anonymous class and implementing a method that you can use to perform the click. And we've also taken find view by ID. Again, if you're familiar with Android, returns an object. In Xamarin.Android, we've made that into a generic method so that you can always get back a strongly typed result which just saves a whole pile of casting perends every time you use that method. So little things like that, we've laid on top of the way Android works to try and make it more familiar for.NET developers. It would be unusual in.NET to have a method that you use almost every single day always returning an object. And you then have to cast it to something. Generics make much more sense for.NET developers to do that. So you'll see in the code I've just posted in there, I want my add button to start a new activity called task view. And we've already done the layout for that. But like I mentioned, layout and the actual activity itself are two different things. We need to create another class to load that activity, that layout, the task view layout. So I choose Android class, task view. And we've got, so like I said, I'm going to make it public. Because this is an activity, I need the activity attribute. And I'm going to give it a label. So again, this stuff is going straight into the Android manifest. And then I want to inherit from activity. So this is another great thing. Auto complete is auto completing for Java classes. Everything that's in the Android SDK, like I said, we surface it up as though it's C sharp. So when I'm doing partial completion, I know that that's activity. And it can just work with it. And then my auto complete is not working. Okay, let's go to the backup, which is over here and steal it. So we want to set content view. Oh, I don't know what I needed. Override on create. So again, on create methods, all the Android methods already there. That's still it. Content view. And we want to wire up the save button. And we haven't got that done yet. So what I've done so far is on the list view, we've got an add button at the top, which we drew in the layout. And on the detail view, the task view, we added a save button. And I've just added click hands to both. I'm just going to run it up so that we can see the user interface how it works with just the C sharp that we've written so far. Android emulator already running. It is not speedy. And there it is. We can add and save goes back. Nothing else is functional. But it's fairly easy to get an application up and running and start drawing widgets. Your typical hello world can be done with very little C sharp. So when I got to this stage in building the detail view, now that we've got a detail view, we need some object to display in the detail view. And for that, we're going to create a new business object class. I'm going to put it in a folder called core because I may want to reuse that. So let me just create an empty class called task. And so here we have a very simple class. It's got an ID, a title, and a done field. So this is my to-do list object. And I want to store it in a database because I want to have multiple tasks available at one time. And I want to be able to get them out of the list and mark them as complete. So if this were a database, I would probably want the ID field to be a primary key to auto-increment so I don't have to manage that and just have them automatically just work. Both the Android operating system since 2.2 and iOS for our other product already include SQLite database engine. So you can actually use the ADO.NET syntax you already know. It's available in Mono to access a database to do create table, to do select, insert, update, delete. You can write SQL for all of that in the product. But there's an alternative which is to maybe use an ORM or some way since we're working with objects, let's see if we can just load and save them without having to write any SQL. Which brings us to the Xamarin component store because the goal of the Xamarin tool set is not just to let you use C sharp to write applications that you could have written in another language. It's A to also be able to share code and be able to reach across platforms but also to speed up your development so that you're not writing the same code over and over again and also to make your development more attractive, pretty or whatever by providing components that are really easy to get for graphic widgets like charting libraries and that sort of thing, signature pad, cloud services back ends like Azure and Paz, but also SQLite library like SQLite.NET. So you can investigate the component from here. It's available for the three platforms, Windows, Android and iOS. If I choose add to app, it does a couple of things for me. It downloads the documentation. So the documentation is local. I can quickly see it supports things like primary key, auto increment, indexes and some other stuff. It also adds the component here so that I can track it. I can update it from there by returning to this screen and it also adds the reference straight into my project. So now I have SQLite.dll referenced and if I return to the task class, I can just add the namespace to get that working. The color coding may not be working there. I'm actually in an alpha version of this IDE, but I'm sure it'll work. So now we have a task class and we have some screens to implement it, but we haven't really tied it together. So let's go to task view and on create, see what we can add. So we need to, in this field, in this activity, we want a current task property. So it's a detailed view for tasks. Makes sense to have a property available where we can keep track of the task object that we're currently working with. And then we need to access more of the properties on this view. So this bit gets a little bit different to what you're used to in Windows. When you name the control in Windows in the designer, you kind of expect the IDE or something in the background to put something in a partial class or otherwise make that widget make its name available to you. So that automatically happens in SQL for a lot, automatically happens in Windows forms. In Android, it doesn't automatically happen. So we have this concept of the resource ID. So we've got done checkbox as a resource ID and we need to pull those things out manually into local fields before we can use them. So create local fields for the checkbox and the edit text. And then, so effectively what I'm doing here is what the IDE does for you on pretty much every other platform. And I'm using the resource ID that is generated behind the scenes from the view XML, getting that control and didn't notice I screwed that up. Checkbox and edit text. Auto complete is great. Title text. So now the combination of these properties or these fields and these two statements now let me manipulate the controls that are in the XML that have been displayed to the user on the screen. And what I'm going to do with that is assuming that a task object has been set, copy the title into the text field and done value into the check. So I don't know if you guys can see that. Keep forgetting. So that code there could be on any platform. It's classic, right to left assignment. We've got business object property. We want to display on the screen. We copy it up. Granted, WPF data binding does that for you manually, but everything before pretty much you're used to writing that kind of code. So now we've got that and we've got this save button. We can uncomment these lines of code here. And it's doing the reverse. So when we hit the save button, we're taking the user interface values, the values from the widget, the text and the check property and assigning them back to the task class. And then we want to save it. So we've got task, it's got some values that have been entered by the user. I've already written the code here. So there's some view model with a save property to save this object. So this is where we need to create the link between our task class and the SQLite database. To do that, we need a, I'm saying it's a view model, it's a repository. It's another class that we're going to be able to share across platforms. So task view model. And this is what it looks like. Using SQLite, using system collections.generic. So I've just, you know, quickly typed that out faster than you can see. This is the C sharp code that we need to wire up the component that I added. So we're creating a SQLite connection, an object that's going to let us talk to the database from within C sharp. In the constructor, we're doing just standard.NET file operations. So this is the beauty of having.NET framework on Android and having the.NET framework on iOS is that I can write environment, get folder path, get special folder. And on iOS it returns one thing, on Android it returns another. But in both cases, it returns me a valid path that I can write to within that application sandbox. So this code is portable, it will work on windows as well. We use that path, we're going to call it task DB, that doesn't matter. And a feature of the component is that we can just create the table with the generic parameter and that we now have a task table with three columns, just as a virtue of that call. It doesn't matter if you call it multiple times, it does its own checking to see whether the table already exists. If your task class has changed since the last time it's run, it will detect that and add additional columns if they're required. And then there's a couple of, you know, your standard crud methods, I've already implemented here just for a speed sake. Save method will detect if your object's primary key has been set, if it has been set it's an update, if it hasn't been set it's an insert. We get using some basic link syntax to make sure that the ID matches the ID that's passed in and the get all we're actually doing order by just because it's interesting using link syntax. So return all of the tasks in our database table ordered by their ID to a list that we can then just bind to something on the front end. So that's a pretty standard pattern. Those two classes, the task and the task view model, don't reference any anything. There's no using statements that are outside of what could also run on Windows, what could also run on iOS. So this code can be reused over and over again. Granted it's only 20 lines now. But if this was your business logic and your database logic and your web services logic, you would be reusing it on the other platforms. So now we can create an instance of that. And so there's the instance of it there. Actually I want that further up. So we're creating an instance of the view model that I just did. It's not really a view model, please forgive the abuse of that term. We're then using an Android feature which is how you pass information between screens. So this is not like an exhaustive introduction to Android development. But you know, activities are like screens. You can really only pass, let me editorialize, it's easier to pass just simple bits of data between them, so strings and ints. Those are called intents to the mechanism of passing from one activity to another. And the parameters or the data that you send with an intent to start an activity is called an extra. So here we've got intent, get in extra. This activity, the detail view has a parameter ID, which is the task ID. So this line of code here that you can see is just the Android way of saying what was the parameter for this screen. If it's zero, it's non-zero, sorry, we're going to grab that from the database. We're editing a task. If it is zero, we're newing up a task because we know we haven't got one and we're going to set some values on it and save it later. So that pretty much completes the editing part of the application. We've created a task class with some properties. We've created a view model or a repository that reads and writes to a database via component. And we've got an editing screen here where the view has some input controls and the code behind has code to populate that when the screen is loaded and to save it when a button is hit. So the only problem we have left now is that we haven't actually wired up the list view at the start of the application. So we won't see anything when we start. So let's go. And again, we need to manually wire up the user interface control. So create the local field, call get view by ID with the resource ID. And then again, assigning up, wiring up an item click using standard dot net syntax. It makes it really easy. We need to do the view model as well. So this is the initiation of creating a new screen. This is the type of the screen we want to create. Send this parameter. And right. And now we've got a screen. Now, not sure how many people were in the iOS talk, but one of the things that's important to understand when you're working with these mobile application frameworks, well, it's the same for Silverlight as well, I guess, is there's an activity life cycle for screens and for the application itself that helps you to deal with screen being created, a screen being visible to the user, a screen being tombstone or obscured or paused and then shown again, paused again, shown again before it's finally destroyed. They have different names like tombstone is a Windows phone specific kind of term, but on other platforms on Android they get paused on iOS, they go to the background. So you need to be able to handle that. And on resume is the Android equivalent of this screen is coming to the front, either for the first time or for some other time since it's been hidden. And that's going to happen every time you go to a task and you add a new task, you go to the edit screen and then come back. So you want those changes to be reflected, which means that on resume, we always want to grab the, grab the latest list of tasks from the database to display because something's happened, you know, this screen is coming back from being hidden and the data might have changed that we want to show. The final task we have to do to finish the application then is we've got a screen that saves tasks and we've got the task saved in a database and we've got this method here which is retrieving the task from the database, but we're not displaying them in the list view. So the final step is how do we take a list, an iList of type task and tell Android to render that? And the answer is with an adapter class, which is a very common pattern, you take something with a certain API and you kind of write a translation layer to expose it as something else. And in the case of Android, it's a really simple pattern and if you're in the iOS talk, it's really similar to the iOS data source that we wrote. So I'm going to add a new file, call it task list adapter and then just kill out a whole pile of stuff. I want to grab these just to speed things up. So the task list adapter is taking our list of tasks as a parameter, so in the constructor it's saying, look, here's the list of tasks I want you to display. And then it's overriding methods as the way of Google's API telling us this is the contract that we have with the list view for it to work. And so the stuff that the list view needs to know is pretty simple. An override that says count how many rows do I need to display. So the list view is going to ask that before it asks anything else. How big does the scroll bar need to be? How much space do I need to allocate in the scrolling portion of the list? Some other helpful information for using the data source like return the object for this position, return the position, item ID for this position. But the next most important method after count is get view. So the two things that the list view is doing when it's rendering is firstly asking the adapter how many rows do you want? And we tell it. And then it's going to loop through for each row. Okay, what do I put in this row? What do I put in this row? And that's answered by this method. So what we're going to return is a cell like a view with some text in a checkbox that represents the visual representation of each task. So I'm not going to go into the syntax in great detail. We grab the task for that row from our list. We inflate a view and just to point out we're using a built in view. So we're not creating one from scratch. It's basically just a text field with an optional tick next to it. We're then setting those values. So we're setting the text to the title and we're setting the visibility of the tick to whether the task is done or not. And we return that view to the list view. So we're basically feeding our custom C sharp class into the list view for rendering. And that should pretty much be it for our application. So let's run it up and see. Oh, typo. Let's try that again. Third time lucky. Nope. Okay, let's do, let's run this one. Here's one I prepared earlier. It's the same code except for the bit that doesn't work. And so yeah, this add task. And so let's say by milk save and by milk. If I click on that, hit done and save and it's checked. So there's an Android application in about 100 lines of code. It's very simple obviously, but we've taken, you know, what's effective, the Java SDK, exposed to C sharp and enable you to build an application where you can share your business logic, your application logic, files, storage, all that sort of stuff with other platforms. So let's skip back to the presentation. And yeah, we ended up with a working Android app in 100 lines of code. I talked a bit about sharing while we were coding. So the sharing can happen at multiple levels. The components on the Xamarin components store are often cross platform so that you can use the SQLite component, for example, on Windows, Android and iOS. You can share code that doesn't require user interface dependencies. So like system.net, system.io, web services, the database, all that stuff. You can just reuse verbatim. And I've just copied the source files across at the moment. That's the easiest way to do it. But we have PCL support coming which will simplify that even more. And you should also look at sharing the structure of your code so that it's easier for developers to maintain across different platforms. If your task screen is always called task, something, you know, you don't find yourself mixing metaphors, it will be easier for people to find their way around both solutions. And finally, sharing design. So if you find this code later on the net, you'll see that the application on iOS and on Android and on Windows Phone, it follows the same navigation metaphor where that makes sense. But it then also takes advantage of the individual platforms specialities. So there's no back button on Android because it's built into the OS and similarly on Windows. But on iOS, the back button is part of the navigation controller. So using Xamarin gives you that flexibility and lets you use the native widgets to present a native user interface which is an advantage over an HTML framework where you're sharing the same thing on every platform. We already touched on this. You can put a lot of stuff in the ShareCord library if you put your mind to it because the user interface is really the only thing you need to do. Wiring up, property assignments and validation messages is all you really need to have in your platform specific application code. Like I've already said, the web services, I.O., cloud access, storage should all be able to be written in such a way that you can just reuse it, share it, write unit tests against it in a platform agnostic way. So to recap, we built an Android app in C-Sharp with.NET. You can use Xamarin Studio as I showed you on the Mac. On Windows, you can use Xamarin Studio or Visual Studio. Visual Studio is great because then you can share your code with Windows apps really easily. You can use Resharper, you can use TFS, all the stuff you're used to within your Visual Studio environment. Apps will have the native look and feel because they're using native widgets. When Android includes new user interface components like the navigation draw, they just announced you can really quickly and easily incorporate that into your apps as well. They run natively, so I tried to explain earlier because our version, our framework is compiled and runs natively on the operating system. It's not cross-compiled or set on top of Java. You can share code and we have the Xamarin components store which lets you build applications more quickly as long as we've got some of that functionality that you need there for sale or for download for free. What's coming up next for Xamarin.Android? Probably the most exciting thing that people are waiting for is for our async await language support to catch up. The parallel task library has been available for a long time but the syntax changes around async await are currently available only in our beta platform. That stuff is going to be stable very soon and you'll be able to deploy applications with it. That will bring us back up to parity with the version of C-Sharp that Microsoft's making available on Windows Store, Windows RT apps. F-Sharp will be a first-class language for Xamarin which means you'll be able to write F-Sharp apps that run on Android and iOS. Portable class library support will make it even easier to share code across these two platforms and again also with Windows Store and Windows Phone apps. We're just in the process of finishing up the addition of the new Google Play services stuff that was announced at Google I.O. So the new in-app purchasing, location services, Maps v2 stuff is actually already available. That stuff brings the Android platform much more closely into line and in some cases exceeding what's on iOS. So the in-app purchasing in particular is a massive improvement and the support library additions as well so draw navigation stuff like that. So their platform is always growing along with Google in terms of the new functionality that they provide but also along with Microsoft and things like F-Sharp and async stuff along with the way that.NET is growing as well. That's an async screenshot if you haven't seen it. So it's really easy to get started. Go to Xamarin.com, getting started. A sample very similar to the one we walked through today is there. You can download the IDE and the tools from that one link at the bottom and run this sample for free. We've got documentation and recipes, we've got forums and all of our samples available on GitHub. And that's it for now. Have you got any questions? I've got two monkeys for the first two questions. Yep. Right. So the question is about different screen layouts when you're designing using the... So if you lock, for example, screen size and then change screen size and then you make some edits like add something or make that a different icon because of the container. So if you make changes here, what happens is under the covers, I don't know if it will have done it already, Android creates another folder, say layout, hdpi, I'm not sure that's exactly what it is. And it has another copy of your layout in there. So it effectively has two copies. And Android uses those dash qualifiers to decide and yeah, it has like a hierarchy. So it'll choose the best match. Sometimes it's really obvious because the qualifier will be for a specific screen size or a specific attribute of the device. Other times, I guess particularly for some screen size ones, it'll just be like a scale. So all devices smaller than this will get layout A and devices bigger will get layout B. So all you can do at this stage is pick a qualifier and you design for it and then the device will pick one based on what it's configured for. So if I just drop those down, some of them, so pixel density, that's going to be an easy one. Has touchscreen, probably not going to... That's an old Android hangover, I guess. But various things that you can target, some of them are more specific than others but you rely on the device to pick the one that is most appropriate for it. Yeah. So it's possible to do... It's possible to have... To write a Java library and bind it. So if you want to have a lot of Java code you've already got, you want to put it into a Xamarin.android application, you can pass things in, you can use the dependency injection to pass something in and then call back out. We don't currently support building a library in C-sharp, having a Java wrapper and then say including that in a Java Android application. But that's something that people request on our user voice site. Not currently possible... Yeah, I know what you mean. I mean technically there's probably ways of doing it but it's not part of the product that you can build that library with the tool chain as it stands. Yeah, so that question was about SDK targeting. Yes, we do. So if you go to the properties and choose a target framework and you can also set the stuff in Android manifest here as well. But yeah, so the auto complete and the compiler will tell you if you're accessing something that's not available. Is that... Everyone? Okay, well we're just two minutes early but that's fine. Thank you everyone for coming along. Can you two guys come and grab a monkey that you ask questions? Thank you.
 Okay, thanks for coming everyone. My name is Craig from Xamarin and we're going to talk  a bit about developing apps for Android with C-Sharp using the Xamarin platform. So why  Xamarin.Android? Why are you here listening to me this afternoon? Because I'm going to  tell you how you can write C-Sharp apps for Android phones and tablets using the language  and the tools and framework that you already know if you're a Windows developer. Also,  that C-Sharp code that you write for your Xamarin.Android application can be reused  for an iOS application, for a Windows phone application or for Windows Store apps. And  also you can bring in code that you already have from Enterprise apps or from one of those  platforms and use it in your Xamarin.Android project. You will be creating native Android  user interfaces because Xamarin.Android uses the native widgets for the applications that  you build. And because the application itself is running on top of a native implementation  of the.NET framework, you're getting native performance. There's no translation, there's  no cross-compiling, it's not running as Java under the covers, it's running as a.NET framework  on top of the underlying Android operating system talking to the hardware. And if you  really need to, you can access Java libraries as well. So if there's a third-party control  widget or a third-party Java library or some existing Java code that you have, we also  provide the tools that let you wrap that up in a C-Sharp API and include it in Xamarin.Android  projects as well. So how does it work? Underneath the covers is mono, an open source implementation  of the C-Sharp language and the.NET framework that was originally started to enable basically  a programming environment and Windows Forms clone on Linux back in 2001, soon after Microsoft  announced that they were going to submit it as an open standard. And the project itself  didn't get released officially until 2004. And I'm pretty sure at that time no one realized  that in less than 10 years we would have the computing power we do on our phones and that  they would also be running the same sort of kernel enabling mono to be put on those phones  and run C-Sharp on hundreds of millions of devices. So mono is.NET, it's a.NET you  know, clean room implementation, but all of the same classes and frameworks that you're  familiar with. To facilitate building Android applications in C-Sharp, we also need to give  you access to the underlying Java widgets and the Android platform as well. So we expose  those as bindings or projections to use Microsoft terminology from the Windows Store slash Windows  phone 8 side, which basically exposes any Java object or class or whatever under the  covers as something that looks and behaves like C-Sharp. So you can subclass, you know,  you can new it up and implement anything that exists in the Android Java SDK from within  the C-Sharp environment. So tying all that together is a compiler. And we're doing something  on Android that's very similar to what you're expecting to happen on the desktop environment.  So our compiler takes your C-Sharp code and whatever else that you've built into your  application and produces IL, just the same as a desktop application for.NET framework  exists as a set of IL. And we package that IL up with a native Android runtime. So it's  the.NET framework that you have installed on your PC, but it's mono. We shrink it down  by linking out all of the things you're not using. So strongly type language, we can do  a map and we can trim out all of the classes and methods that aren't being accessed. So  it's the.NET framework itself, linked down to the subset you need, packaged with the  IL on top and put into an APK to run on Android. Visually, it looks kind of like this. So you've  got your C-Sharp and the.NET APIs that you're using. We compile that to.NET IL. We package  it into an APK, as I said, with the.NET framework, with the mono framework linked out to the  smallest possible subset that you need, and then we ship that off to the Android device.  Now on the Android device, the IL is running on top of the native.NET framework implementation,  which is running on top of the operating system. In that stack, if you can visualize it, there's  not really any Java involvement. So all of your math code, all of your business logic,  anything that's pure C-Sharp that you've written for your Android application is running on  top of the native framework, which is running on top of the operating system. Where the  bindings fit in and where you're accessing Android widgets and user interface, it's a  call across to Dalvik. Dalvik's sitting on the operating system as well, and Dalvik's  sending screens and data to the user. But we sit side by side with that. The mono runtime  and the Dalvik runtime coexist. They both have direct hardware and operating system  access underneath them, and they're both effectively able to communicate to the user.  But there's no performance penalty, there's no layers of indirection. It's running side  by side. The key, I guess, issue that we have in terms of that interoperability is we're  managing our garbage collector, and we're trying to manage Dalvik's garbage collector  in a sense because we're creating and destroying objects on our behalf because we've subclassed  them, we've implemented a wrapper for them in the C-sharp side. But it's a side by side,  we don't sit on top of Java at all. So how do you get that working on your local machine?  We have a simple unified installer. You only have to go to xamarin.com slash download and  start. We'll pull down everything that we can for you and install it onto your local  machine, whether it's a Mac or a PC, including the Android SDK and all of our tools that  will enable you to get up and running for free, basically. We have a trial version that lets  you start developing for free, all of Android's tools are free, and you can side load Android  apps no problem so that you can distribute to your friends or within an enterprise without  really any involvement from Google at all. If you want to deploy to Google Play, you  can play to Google.com slash app slash publish. It's $25 a year, I think. And the application  that the APK file that xamarin.android generates, uploads fine to Google Play and works on any  devices that you can name. So development environment support once you have installed  xamarin is the third line there. So on OSX, you can use our own development environment  xamarin studio. On Windows, you have a choice. For Android development, you can use xamarin  studio or if you have Visual Studio and the xamarin business edition license, you can  work within Visual Studio to build Android applications, to build iOS applications, as  well as your Windows phone and Windows store, et cetera. So you can choose to use our free  IDE or if you already paid for Visual Studio, you can use that as well. This is what the  two ID's look like. You'll be very familiar with if you're a Visual Studio user, xamarin  studio won't take long to get used to. The solution structure, all of the file formats  are the same. So you can open projects interchangeably in the two platforms. The ID feels the same.  It's got IntelliSense, AutoComplete. It's visually similar. So really the only choice  is have you paid for Visual Studio already? And do you need Resharper? In both Windows  and on the Mac, you have a graphic or UI designer. So Android has its own XML format which is  used to create screens. We've built our own designer that lets you do it graphically so  you can drag and drop, edit properties, the same way you're familiar with dragging and  dropping for xamarin blend or Windows forms way back when. And xamarin studio and our  Visual Studio plugin also implements all of the customization, all of the property pains  that you need to build an Android app. So if you opened an Android app in Eclipse, there's  a few different things that you need to set to make things work. We expose those as a user-friendly  API as a user-friendly user interface as well so that you can check a few boxes to get the  configuration that you would like for your Android application. So there's a couple here  that I want to highlight. We'll go from this one first. So you can choose the CPU architecture  that you want to target. So you've got ARM or ARM v7 depending on the devices that you  think users will have. And there's also an option there for x86. It might not be a platform  that you're targeting for deployment, but there's an x86 emulator that's available for development.  And if you're, you basically want the x86 emulator if you're doing development for Android because  the ARM one can be slow and painful to work with. So you need to know about those settings  so that you can enable x86 to get that emulator working. I mentioned linking earlier. So linking  is a great feature of Xamarin.Android because it gives you a small APK to deploy to your  users. The downside if you want a really fast compile test debug cycle is that it takes  time to do that map of your code and to link out the stuff that you don't need. So we have  an option that lets you turn linking on and off to speed up your development time. So  you can change that setting. It's just important to remember to turn linking on for your production  deployments to keep the APK you distribute to your users as small as possible. And finally,  I want to point out the setting over here, use shared monoruntime. So this is a feature  that we've enabled specifically again to help the compile test debug cycle be really fast.  Because of how I explained earlier, on Android devices we put the monoruntime on there and  have your IELS sitting on top. The immediate question might come to your mind is, well,  on a PC there's only one instance of the.NET runtime and apps are just IEL. They can be  really tiny and they all share it. That's possible for us to do on Android. So we can  install the shared runtime like it's on a PC, one copy, and you can have 100 Xamarin.Android  applications which adjust the application IEL. Maybe 20K, maybe 40K, maybe something  really simple. And so we enable that ability for debugging because copying up a meg or  two meg of runtime for every compile test debug cycle, you know, it's probably slowing  you down unnecessarily. But we do not enable that for deployment to production. We don't  want to be the gatekeepers of multiple or incompatible copies of a.NET framework on  a user who's got Xamarin.Android apps from different places. So shared runtime is there  and if you're using our product you'll notice it and you might think to yourself, why can't  I just have one shared for users from our users? And the answer is basically that we  want to protect them from themselves by having each application only ship with the runtime  that it was developed on. So keep that in mind if you're using the product. And the  other thing of course is Android manifest XML. So if you're an Android developer already  and you've used Eclipse, you'll notice that there's very similar kind of options for speedily  entering the most common things that people add to their Android manifest file which is  loaded up by the operating system to determine certain things about the application. Most  importantly the version and the required permission set. So Android has that concept of sandbox  that your app runs in and can only access telephony or network or other things if you  request it and then the user agrees when they install it. So we provide those settings  in an accessible way just the same way as Eclipse or other IntelliJ provide for their  Android application settings. The one thing that you won't see Android manifest happen  do in Xamarin.Android for those of you that are familiar with Android development is you  don't need to declare every activity manually in your Xamarin, in your Android manifest.  And I'll show you when we look at some code how we achieve that using attributes in C  sharp to have classes effectively put up their hand for participation as an activity in  Android manifest rather than having to keep it in sync manually. We also have deployment  options so that you can easily publish an Android application. We have a wizard that  lets you find a key store and sign the app and compress the what is it called binary  alignment and output an APK that's ready to either distribute to users or to upload  to play. So that's just a quick overview of Xamarin.Android. Probably the easiest way  to understand it is to see some code being written poorly. So we're going to build this  app. If anyone's already familiar with Xamarin tools, you've probably seen our favorite to  do list application as a sample already. It's useful because it's a really small application  and can write in under 100 lines of code, but it utilizes a lot of different things  about Android lists and navigation that help to show the platform off. Let's go over to  going to use Xamarin Studio. I've got a Mac here obviously. So new up and Android application.  Android to do. And the first thing you'll notice is we try and provide you with something  that's going to work out of the box. So if you run this application up right now, it's  you can see there's like a button that counts how many times it's clicked. It's the classic  hello world working application. So it's given us a main activity. If you're not familiar  with Android, an activity is kind of like a screen, it's kind of like a view controller.  It is a class that is normally associated with a layout. So the activity class is where  we write our code. And there's the concept of a layout, which is the XML that describes  what widgets are on it that we reference and then connect to work with those elements.  So let me go through where those things live. Resources folder is an Android standard location  for certain sets of application parts, I guess. So drawable is a subfolder of that. It's  always called drawable. And it always contains images or XML files that describe the way  images should be used. So we've got an icon there. And we can just maybe add a new icon.  Oops, target. And we'll copy that in there. So icon. The layout folder is where the XML  lives that describes your screen. So if I open this main XML file, you'll see as I mentioned  we've got our own custom designer, which lets you view source and work with the visual  design. And a string's file, which is a lookup for string values that help you with managing  them and also with localization, I guess. So I'm just going to start customizing this.  So we have an add task button. And let's look down. We need a list view to display the list  of tasks as per the mockup that I showed you guys a second ago. So we drag that on there.  It's kind of non-visual. But if we look in the source, we can see the XML. So this is  Android's native XML format. There's nothing really to do with Xamarin except that we provide  the editor and let you work with it. So I'm going to just type in the IDs here because  I can. We could also have done that in the layout editor. And you can see linear layout,  if you're.NET person, that's like a stack panel. And we've created widgets in there  with some layout metrics and some Android syntax there at plus ID slash and the name  of the control. So just get used to seeing at plus ID slash and stuff after it is the  stuff that you care about. Because we're in the process of building those two screens  for the task list, I'm just going to rename this task list and add a new layout and call  it task view. So let's just see what's there. It's given us a linear layout to start with.  It's kind of default. And we want to add, let's say, some text. So our task is going  to have some text, a checkbox, is it done or not, and a button. So let's just edit that  to save. Let's just edit that to done. And yeah, we want to give these useful names.  So rather than going right into the XML, let's just use the property pane over here to set  those values, title text, done checkbox, or typo, and save button. So there's a lot of  other properties that you can set for all of these controls. It's dependent obviously  on the type of control. If we pop into the source now, it's keeping that in sync for  us. The designer also lets you try out what the layout you're working on might look like  on other devices. So I've picked the default Nexus one, but if we had a really tiny screen,  it would look really tiny. And if we put it on a tablet, it would look kind of ridiculous.  It's slightly more powerful than that though, because you can tick these locks and say,  I want to keep this layout on this form factor, and then change the form factor and start  making changes. And that's a feature of Android that Google's enabled to help with the fragmentation  of screen sizes and device capabilities. So what will happen is a separate layout folder  gets created for each different fragmentation vector, if you like, and it'll save a different  copy of this layout with the various different changes that you've made. So if I went to  the tablet, maybe rather than having it full width, I just push everything over to the  left, for example. The control names remain the same, and when it's loaded on the device,  Android takes care of loading the correct layout for me. I just have to make sure that  I can manage all the control names that they all exist in all the various layouts that  might be in use. But that stuff is all supported by a designer and helps you, gives you a big  helping hand when you're trying to deal with devices, multiple screen sizes particularly.  So we've just drawn these two layouts, named the controls. First thing you'll notice now  is the layout reference in the code is broken. So I renamed main to task list. So let's  just change that and fix it up. We don't want that button handler. I might just rename this  as well to task list so it's simple. And while we're here, let's look at this activity attribute.  If you're familiar with Android already, the Android manifest XML is a way or central location  to define parts of the application that can be used. And one of those things is an entry  in that XML file for every activity that you've declared that you want to be accessible so  other activities can navigate to it. That's fine. Everyone's used to doing that. But it's  a two-step process if you create a class and you want to go and then update the manifest.  And other tools will help you do that automatically. The way we've chosen to do it is implement  an attribute. One of the great things about.NET and C-Sharp is the metaprogramming capabilities  of attributes. So anything that you could have added kind of weakly typed because you're  just entering a string into Android manifest XML. In Xamarin.Android, you can do it strongly  typed in the IDE directly in your code. So we can say, for example, that we want to set,  let me zoom in there. We want to set the icon. So again, with the app drawable slash, it's  an Android thing and you'll get used to it. But the label, which has got what the label  of our application is going to appear on the home screen is set here. Main launcher equals  true is an Androidism, which is saying to the operating system, this is the first activity  that opens when this application is run. So it effectively gets an icon on the home screen.  So at compile time, Xamarin.Android is taking that attribute along with various other things  and updating the Android manifest so that what goes to the device or to the simulator  is consistent. The activities all exist and they're referenceable. You can call them from  each other. Let me just rename that as well. So I want to just quickly get the navigation  working. So let's add some code here. We've already got that. And we need to declare the  button. So this should look familiar to any.NET developer and it will probably look very  unfamiliar to someone that's only done Java because there's like a whole anonymous class  missing. One of the benefits of using C sharp to build Android applications is that we bought  the C sharp isms to Android. So being able to just attach an event handler like this is  quite a bit less code than the Android Java way of doing things of creating an anonymous  class and implementing a method that you can use to perform the click. And we've also taken  find view by ID. Again, if you're familiar with Android, returns an object. In Xamarin.Android,  we've made that into a generic method so that you can always get back a strongly typed result  which just saves a whole pile of casting perends every time you use that method. So little  things like that, we've laid on top of the way Android works to try and make it more  familiar for.NET developers. It would be unusual in.NET to have a method that you  use almost every single day always returning an object. And you then have to cast it to  something. Generics make much more sense for.NET developers to do that. So you'll see  in the code I've just posted in there, I want my add button to start a new activity called  task view. And we've already done the layout for that. But like I mentioned, layout and  the actual activity itself are two different things. We need to create another class to  load that activity, that layout, the task view layout. So I choose Android class, task view.  And we've got, so like I said, I'm going to make it public. Because this is an activity,  I need the activity attribute. And I'm going to give it a label. So again, this stuff is  going straight into the Android manifest. And then I want to inherit from activity. So  this is another great thing. Auto complete is auto completing for Java classes. Everything  that's in the Android SDK, like I said, we surface it up as though it's C sharp. So when  I'm doing partial completion, I know that that's activity. And it can just work with  it. And then my auto complete is not working. Okay, let's go to the backup, which is over  here and steal it. So we want to set content view. Oh, I don't know what I needed. Override  on create. So again, on create methods, all the Android methods already there. That's still  it. Content view. And we want to wire up the save button. And we haven't got that done yet.  So what I've done so far is on the list view, we've got an add button at the top, which  we drew in the layout. And on the detail view, the task view, we added a save button. And  I've just added click hands to both. I'm just going to run it up so that we can see the  user interface how it works with just the C sharp that we've written so far. Android  emulator already running. It is not speedy. And there it is. We can add and save goes  back. Nothing else is functional. But it's fairly easy to get an application up and running  and start drawing widgets. Your typical hello world can be done with very little C sharp.  So when I got to this stage in building the detail view, now that we've got a detail view,  we need some object to display in the detail view. And for that, we're going to create  a new business object class. I'm going to put it in a folder called core because I may  want to reuse that. So let me just create an empty class called task. And so here we  have a very simple class. It's got an ID, a title, and a done field. So this is my to-do  list object. And I want to store it in a database because I want to have multiple tasks available  at one time. And I want to be able to get them out of the list and mark them as complete.  So if this were a database, I would probably want the ID field to be a primary key to auto-increment  so I don't have to manage that and just have them automatically just work. Both the Android  operating system since 2.2 and iOS for our other product already include SQLite database  engine. So you can actually use the ADO.NET syntax you already know. It's available in  Mono to access a database to do create table, to do select, insert, update, delete. You  can write SQL for all of that in the product. But there's an alternative which is to maybe  use an ORM or some way since we're working with objects, let's see if we can just load  and save them without having to write any SQL. Which brings us to the Xamarin component  store because the goal of the Xamarin tool set is not just to let you use C sharp to  write applications that you could have written in another language. It's A to also be able  to share code and be able to reach across platforms but also to speed up your development  so that you're not writing the same code over and over again and also to make your development  more attractive, pretty or whatever by providing components that are really easy to get for  graphic widgets like charting libraries and that sort of thing, signature pad, cloud services  back ends like Azure and Paz, but also SQLite library like SQLite.NET. So you can investigate  the component from here. It's available for the three platforms, Windows, Android and  iOS. If I choose add to app, it does a couple of things for me. It downloads the documentation.  So the documentation is local. I can quickly see it supports things like primary key, auto  increment, indexes and some other stuff. It also adds the component here so that I can  track it. I can update it from there by returning to this screen and it also adds the reference  straight into my project. So now I have SQLite.dll referenced and if I return to the task class,  I can just add the namespace to get that working. The color coding may not be working there.  I'm actually in an alpha version of this IDE, but I'm sure it'll work. So now we have a  task class and we have some screens to implement it, but we haven't really tied it together.  So let's go to task view and on create, see what we can add. So we need to, in this field,  in this activity, we want a current task property. So it's a detailed view for tasks. Makes  sense to have a property available where we can keep track of the task object that we're  currently working with. And then we need to access more of the properties on this view.  So this bit gets a little bit different to what you're used to in Windows. When you name  the control in Windows in the designer, you kind of expect the IDE or something in the  background to put something in a partial class or otherwise make that widget make its name  available to you. So that automatically happens in SQL for a lot, automatically happens in  Windows forms. In Android, it doesn't automatically happen. So we have this concept of the resource  ID. So we've got done checkbox as a resource ID and we need to pull those things out manually  into local fields before we can use them. So create local fields for the checkbox and  the edit text. And then, so effectively what I'm doing here is what the IDE does for you  on pretty much every other platform. And I'm using the resource ID that is generated behind  the scenes from the view XML, getting that control and didn't notice I screwed that up.  Checkbox and edit text. Auto complete is great. Title text. So now the combination of these  properties or these fields and these two statements now let me manipulate the controls that are  in the XML that have been displayed to the user on the screen. And what I'm going to  do with that is assuming that a task object has been set, copy the title into the text  field and done value into the check. So I don't know if you guys can see that. Keep  forgetting. So that code there could be on any platform. It's classic, right to left  assignment. We've got business object property. We want to display on the screen. We copy  it up. Granted, WPF data binding does that for you manually, but everything before pretty  much you're used to writing that kind of code. So now we've got that and we've got this save  button. We can uncomment these lines of code here. And it's doing the reverse. So when  we hit the save button, we're taking the user interface values, the values from the widget,  the text and the check property and assigning them back to the task class. And then we want  to save it. So we've got task, it's got some values that have been entered by the user.  I've already written the code here. So there's some view model with a save property to save  this object. So this is where we need to create the link between our task class and the SQLite  database. To do that, we need a, I'm saying it's a view model, it's a repository. It's  another class that we're going to be able to share across platforms. So task view model.  And this is what it looks like. Using SQLite, using system collections.generic. So I've  just, you know, quickly typed that out faster than you can see. This is the C sharp code  that we need to wire up the component that I added. So we're creating a SQLite connection,  an object that's going to let us talk to the database from within C sharp. In the constructor,  we're doing just standard.NET file operations. So this is the beauty of having.NET framework  on Android and having the.NET framework on iOS is that I can write environment, get folder  path, get special folder. And on iOS it returns one thing, on Android it returns another.  But in both cases, it returns me a valid path that I can write to within that application  sandbox. So this code is portable, it will work on windows as well. We use that path,  we're going to call it task DB, that doesn't matter. And a feature of the component is  that we can just create the table with the generic parameter and that we now have a task  table with three columns, just as a virtue of that call. It doesn't matter if you call  it multiple times, it does its own checking to see whether the table already exists. If  your task class has changed since the last time it's run, it will detect that and add  additional columns if they're required. And then there's a couple of, you know, your standard  crud methods, I've already implemented here just for a speed sake. Save method will detect  if your object's primary key has been set, if it has been set it's an update, if it hasn't  been set it's an insert. We get using some basic link syntax to make sure that the ID  matches the ID that's passed in and the get all we're actually doing order by just because  it's interesting using link syntax. So return all of the tasks in our database table ordered  by their ID to a list that we can then just bind to something on the front end. So that's  a pretty standard pattern. Those two classes, the task and the task view model, don't reference  any anything. There's no using statements that are outside of what could also run on  Windows, what could also run on iOS. So this code can be reused over and over again. Granted  it's only 20 lines now. But if this was your business logic and your database logic and  your web services logic, you would be reusing it on the other platforms. So now we can create  an instance of that. And so there's the instance of it there. Actually I want that further  up. So we're creating an instance of the view model that I just did. It's not really a  view model, please forgive the abuse of that term. We're then using an Android feature  which is how you pass information between screens. So this is not like an exhaustive  introduction to Android development. But you know, activities are like screens. You can  really only pass, let me editorialize, it's easier to pass just simple bits of data between  them, so strings and ints. Those are called intents to the mechanism of passing from one  activity to another. And the parameters or the data that you send with an intent to start  an activity is called an extra. So here we've got intent, get in extra. This activity, the  detail view has a parameter ID, which is the task ID. So this line of code here that you  can see is just the Android way of saying what was the parameter for this screen. If  it's zero, it's non-zero, sorry, we're going to grab that from the database. We're editing  a task. If it is zero, we're newing up a task because we know we haven't got one and we're  going to set some values on it and save it later. So that pretty much completes the editing  part of the application. We've created a task class with some properties. We've created  a view model or a repository that reads and writes to a database via component. And we've  got an editing screen here where the view has some input controls and the code behind  has code to populate that when the screen is loaded and to save it when a button is  hit. So the only problem we have left now is that we haven't actually wired up the list  view at the start of the application. So we won't see anything when we start. So let's  go. And again, we need to manually wire up the user interface control. So create the  local field, call get view by ID with the resource ID. And then again, assigning up,  wiring up an item click using standard dot net syntax. It makes it really easy. We need  to do the view model as well. So this is the initiation of creating a new screen. This  is the type of the screen we want to create. Send this parameter. And right. And now we've  got a screen. Now, not sure how many people were in the iOS talk, but one of the things  that's important to understand when you're working with these mobile application frameworks,  well, it's the same for Silverlight as well, I guess, is there's an activity life cycle  for screens and for the application itself that helps you to deal with screen being created,  a screen being visible to the user, a screen being tombstone or obscured or paused and  then shown again, paused again, shown again before it's finally destroyed. They have different  names like tombstone is a Windows phone specific kind of term, but on other platforms on Android  they get paused on iOS, they go to the background. So you need to be able to handle that. And  on resume is the Android equivalent of this screen is coming to the front, either for  the first time or for some other time since it's been hidden. And that's going to happen  every time you go to a task and you add a new task, you go to the edit screen and then  come back. So you want those changes to be reflected, which means that on resume, we  always want to grab the, grab the latest list of tasks from the database to display because  something's happened, you know, this screen is coming back from being hidden and the data  might have changed that we want to show. The final task we have to do to finish the application  then is we've got a screen that saves tasks and we've got the task saved in a database  and we've got this method here which is retrieving the task from the database, but we're not displaying  them in the list view. So the final step is how do we take a list, an iList of type task  and tell Android to render that? And the answer is with an adapter class, which is a very  common pattern, you take something with a certain API and you kind of write a translation  layer to expose it as something else. And in the case of Android, it's a really simple  pattern and if you're in the iOS talk, it's really similar to the iOS data source that  we wrote. So I'm going to add a new file, call it task list adapter and then just kill  out a whole pile of stuff. I want to grab these just to speed things up. So the task  list adapter is taking our list of tasks as a parameter, so in the constructor it's saying,  look, here's the list of tasks I want you to display. And then it's overriding methods  as the way of Google's API telling us this is the contract that we have with the list  view for it to work. And so the stuff that the list view needs to know is pretty simple.  An override that says count how many rows do I need to display. So the list view is going  to ask that before it asks anything else. How big does the scroll bar need to be? How  much space do I need to allocate in the scrolling portion of the list? Some other helpful information  for using the data source like return the object for this position, return the position, item  ID for this position. But the next most important method after count is get view. So the two  things that the list view is doing when it's rendering is firstly asking the adapter how  many rows do you want? And we tell it. And then it's going to loop through for each row.  Okay, what do I put in this row? What do I put in this row? And that's answered by this  method. So what we're going to return is a cell like a view with some text in a checkbox  that represents the visual representation of each task. So I'm not going to go into the  syntax in great detail. We grab the task for that row from our list. We inflate a view  and just to point out we're using a built in view. So we're not creating one from scratch.  It's basically just a text field with an optional tick next to it. We're then setting those  values. So we're setting the text to the title and we're setting the visibility of the tick  to whether the task is done or not. And we return that view to the list view. So we're  basically feeding our custom C sharp class into the list view for rendering. And that  should pretty much be it for our application. So let's run it up and see. Oh, typo. Let's  try that again. Third time lucky. Nope. Okay, let's do, let's run this one. Here's one I  prepared earlier. It's the same code except for the bit that doesn't work. And so yeah,  this add task. And so let's say by milk save and by milk. If I click on that, hit done and  save and it's checked. So there's an Android application in about 100 lines of code. It's  very simple obviously, but we've taken, you know, what's effective, the Java SDK, exposed  to C sharp and enable you to build an application where you can share your business logic, your  application logic, files, storage, all that sort of stuff with other platforms. So let's  skip back to the presentation. And yeah, we ended up with a working Android app in 100  lines of code. I talked a bit about sharing while we were coding. So the sharing can happen  at multiple levels. The components on the Xamarin components store are often cross platform  so that you can use the SQLite component, for example, on Windows, Android and iOS. You  can share code that doesn't require user interface dependencies. So like system.net, system.io,  web services, the database, all that stuff. You can just reuse verbatim. And I've just  copied the source files across at the moment. That's the easiest way to do it. But we have  PCL support coming which will simplify that even more. And you should also look at sharing  the structure of your code so that it's easier for developers to maintain across different  platforms. If your task screen is always called task, something, you know, you don't find  yourself mixing metaphors, it will be easier for people to find their way around both solutions.  And finally, sharing design. So if you find this code later on the net, you'll see that  the application on iOS and on Android and on Windows Phone, it follows the same navigation  metaphor where that makes sense. But it then also takes advantage of the individual platforms  specialities. So there's no back button on Android because it's built into the OS and  similarly on Windows. But on iOS, the back button is part of the navigation controller.  So using Xamarin gives you that flexibility and lets you use the native widgets to present  a native user interface which is an advantage over an HTML framework where you're sharing  the same thing on every platform. We already touched on this. You can put a lot of stuff  in the ShareCord library if you put your mind to it because the user interface is really  the only thing you need to do. Wiring up, property assignments and validation messages  is all you really need to have in your platform specific application code. Like I've already  said, the web services, I.O., cloud access, storage should all be able to be written in  such a way that you can just reuse it, share it, write unit tests against it in a platform  agnostic way. So to recap, we built an Android app in C-Sharp with.NET. You can use Xamarin  Studio as I showed you on the Mac. On Windows, you can use Xamarin Studio or Visual Studio.  Visual Studio is great because then you can share your code with Windows apps really easily.  You can use Resharper, you can use TFS, all the stuff you're used to within your Visual  Studio environment. Apps will have the native look and feel because they're using native  widgets. When Android includes new user interface components like the navigation draw, they just  announced you can really quickly and easily incorporate that into your apps as well.  They run natively, so I tried to explain earlier because our version, our framework is compiled  and runs natively on the operating system. It's not cross-compiled or set on top of  Java. You can share code and we have the Xamarin components store which lets you build applications  more quickly as long as we've got some of that functionality that you need there for  sale or for download for free. What's coming up next for Xamarin.Android? Probably the most  exciting thing that people are waiting for is for our async await language support to  catch up. The parallel task library has been available for a long time but the syntax changes  around async await are currently available only in our beta platform. That stuff is going  to be stable very soon and you'll be able to deploy applications with it. That will  bring us back up to parity with the version of C-Sharp that Microsoft's making available  on Windows Store, Windows RT apps. F-Sharp will be a first-class language for Xamarin  which means you'll be able to write F-Sharp apps that run on Android and iOS. Portable  class library support will make it even easier to share code across these two platforms and  again also with Windows Store and Windows Phone apps. We're just in the process of finishing  up the addition of the new Google Play services stuff that was announced at Google I.O. So  the new in-app purchasing, location services, Maps v2 stuff is actually already available.  That stuff brings the Android platform much more closely into line and in some cases exceeding  what's on iOS. So the in-app purchasing in particular is a massive improvement and the  support library additions as well so draw navigation stuff like that. So their platform  is always growing along with Google in terms of the new functionality that they provide  but also along with Microsoft and things like F-Sharp and async stuff along with the way  that.NET is growing as well. That's an async screenshot if you haven't seen it. So it's  really easy to get started. Go to Xamarin.com, getting started. A sample very similar to  the one we walked through today is there. You can download the IDE and the tools from  that one link at the bottom and run this sample for free. We've got documentation and recipes,  we've got forums and all of our samples available on GitHub. And that's it for now. Have you  got any questions? I've got two monkeys for the first two questions.  Yep.  Right. So the question is about different screen layouts when you're designing using the...  So if you lock, for example, screen size and then change screen size and then you make  some edits like add something or make that a different icon because of the container.  So if you make changes here, what happens is under the covers, I don't know if it will  have done it already, Android creates another folder, say layout, hdpi, I'm not sure that's  exactly what it is. And it has another copy of your layout in there. So it effectively  has two copies. And Android uses those dash qualifiers to decide and yeah, it has like  a hierarchy. So it'll choose the best match. Sometimes it's really obvious because the  qualifier will be for a specific screen size or a specific attribute of the device. Other  times, I guess particularly for some screen size ones, it'll just be like a scale. So  all devices smaller than this will get layout A and devices bigger will get layout B. So  all you can do at this stage is pick a qualifier and you design for it and then the device  will pick one based on what it's configured for. So if I just drop those down, some of  them, so pixel density, that's going to be an easy one. Has touchscreen, probably not  going to... That's an old Android hangover, I guess. But various things that you can target,  some of them are more specific than others but you rely on the device to pick the one  that is most appropriate for it. Yeah. So it's possible to do... It's possible to have...  To write a Java library and bind it. So if you want to have a lot of Java code you've  already got, you want to put it into a Xamarin.android application, you can pass things in, you can  use the dependency injection to pass something in and then call back out. We don't currently  support building a library in C-sharp, having a Java wrapper and then say including that  in a Java Android application. But that's something that people request on our user  voice site. Not currently possible... Yeah, I know what you mean. I mean technically there's  probably ways of doing it but it's not part of the product that you can build that library  with the tool chain as it stands. Yeah, so that question was about SDK targeting. Yes,  we do. So if you go to the properties and choose a target framework and you can also  set the stuff in Android manifest here as well. But yeah, so the auto complete and the  compiler will tell you if you're accessing something that's not available. Is that...  Everyone? Okay, well we're just two minutes early but that's fine. Thank you everyone  for coming along. Can you two guys come and grab a monkey that you ask questions? Thank  you.
Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_0_59.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_60_107.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_108_371.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_372_2207.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_2208_2651.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_2652_6515.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_6516_9275.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_9276_10775.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_10776_11807.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_11808_12551.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_12552_13211.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_13212_18383.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_18384_20483.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_20484_20951.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_20952_21119.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_21120_21779.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_21780_21827.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_21828_22355.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_22356_22403.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_22404_22463.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_22464_22607.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_22608_24995.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_24996_25115.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_25116_25667.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_25668_28031.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_28032_28583.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_28584_29075.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_29076_29315.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_29316_30215.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_30216_30767.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_30768_31043.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_31044_33311.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_33312_33407.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_33408_33455.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_33456_33623.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_33624_33731.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_33732_34055.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_34056_35243.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_35244_35327.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_35328_35627.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_35628_35675.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_35676_35771.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_35772_35843.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_35844_35927.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_35928_35999.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_36000_36071.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_36072_36395.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_36396_36503.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_36504_36671.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_36672_36827.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_36828_36899.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_36900_37043.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_37044_37127.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_37128_37247.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_37248_41723.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_41724_51023.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_51024_51755.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_51756_51803.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_51804_52703.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_52704_53735.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_53736_55571.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_55572_56651.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_56652_59387.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_59388_59843.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_59844_60527.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_60528_61799.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_61800_62639.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_62640_62963.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_62964_63167.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_63168_67259.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_67260_67523.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_67524_67571.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_67572_67619.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_67620_70127.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_70128_71495.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_71496_72623.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_72624_72767.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_72768_75095.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_75096_75947.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_75948_77495.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_77496_79847.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_79848_79919.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_79920_80519.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_80520_81143.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_81144_81251.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_81252_86435.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_86436_86495.png Craig_Dunn_-_Android_with_C__using_Xamarin-68383292_86496_86537.png