Introduction to Xamarin and iOS app development using Xamarin
Introduction to Xamarin
Xamarin is a cross-platform tool that helps building of Android and iOS apps using C# as the language of coding. Xamarin opens up a way for C# programmers to build Android and iOS apps. Xamarin includes Xamarin.iOS for iOS app development and Xamarin.Android for Android app development.
2. iOS app development using Xamarin
Depicting the two IDEs available for Xamarin.iOS app development.
Developing iPhone, iPad, iPod and Mac apps have been made possible using XCode IDE and using Objective-C, from a long time. Building iOS applications i.e. applications for iPhones and iPads using C# language on .NET platform can be made possible by making use of Xamarin.iOS. The only key entity in building iOS apps using Xcode is the use of Objective-C as the language to develop these iOS apps. Currently, C# developers who are interested in iOS development don't have to learn Objective-C to develop iOS apps. They are only required to know the basic concepts of Xamarin.iOS. Xamarin.iOS is a part of Xamarin. Xamarin is a cross-platform mobile application development software which aids in building iOS, Android and Windows apps using C# .NET platform. Xamarin provides Xamarin Studio and Xamarin plugin to Visual Studio to develop applications.
Developing iOS apps using Xamarin.iOS on different platforms
In order to deploy the developed iOS app on iOS devices or to submit it to the app store, you need an Apple Developer Account. Deploying and debugging an iOS app requires generating the development certificate and creating the provision profile for the particular device in which the app will be deployed to. Provisioning is nothing but configuring the app to run on devices. Here, while creating provision profile, you will set the devices that can run your iOS app. Here, you need to provide them with the generated .ipa file.
1. Development in Windows environment
Always remember that we don't have an iOS simulator available for Windows. The iOS simulator works only on Mac OSX and therefore it is a mandate to have a Mac for testing and simulations of apps on a Mac screen using iOS simulator. Therefore, though we are developing iOS apps on Windows, we need a Mac for development. However Mac need not necessarily be placed beside you! You need a Mac on your network (i.e. Network to which your Windows machine is connected to) and you should able to connect to Xamarin Build Host present on the Mac by connecting to the Mac (Assuming that Xamarin development tools and iOS development tools are already installed on the Mac).
If you are planning to develop iOS apps using Xamarin.iOS in Windows environment, then, you have two choices. One is to use Xamarin plugin with visual studio and writing the C# programs in Visual Studio IDE to build your iOS apps using Xamarin library. If you are intended to develop Xamarin.iOS application using Visual Studio, then, see to it that you use Visual Studio 2010 or higher versions. Also see to it that you don't use Visual Studio Express edition. Another option is to have Xamarin Studio installed on Windows to develop Xamarin.iOS applications. However, both these options require a Xamarin.iOS Build Host. This Xamarin.iOS Build Host should be installed and setup on the Mac machine. In fact, this certifies that though we don't use the Mac directly to write the code in it, we need a Mac machine for iOS development using Xamarin. We cannot deploy iOS applications without Apple's certificates and the iOS simulator can only be run on Mac. This dependency has led to the fact that though we don't use Mac directly for coding, we still need to rely on Mac for iOS development. Therefore, in this scenario, Mac only acts as a build host.
Some of the key criteria to discuss before you connect your Windows machine enabled with Xamarin (i.e. Xamarin plug-in to Visual Studio or Xamarin Studio) to the Mac (i.e. Mac with Xamarin Build Host) are listed below:
As shown in the preceding figure, both Windows machine and Mac machine should be in the same network. This is represented by placing both Windows and Mac inside Network-X as represented in the figure. 'X' can stand for any name of the network.
Using Xamain Studio for Xamarin.iOS development.
Preceding figure represents the communication between Xamarin.iOS present on Windows (Which is a part of Xamarin Studio) and Xamarin.iOS Build Host present on the Mac.
2. Development in Mac environment
To build applications using Xamarin.iOS in Mac, you need to have Mac OS 10.8 or above. You need to have iOS SDK with XCode installed on Mac as a prerequisite. In order to build user interfaces, you have to select either Storyboard or XIB. Storyboard file will have .storyboard extension and XIB file will have .xib extension. Storyboard and XIB files are purely UI files where you can drag and drop different controls from the toolbox on top of the View Controller placed in the Storyboard or XIB. The toolbox itself contains different View Controllers. Latest version of iOS SDK and XCode IDE can be downloaded from Apple's App Store.
There are two ways to develop iOS apps using Xamarin.iOS in Mac machines. One method is to use Xamarin Studio directly, and another is to use Visual Studio with Xamarin plug-in passively as illustrated below.
Using Xamarin Studio for iOS app development on Mac is pretty simple. It is just a matter of installing the Xamarin Studio for Mac available and installing other necessary software like iOS SDK, XCode IDE etc. Thereafter, directly using Xamarin Studio to develop iOS applications is made possible.
If you are using Visual Studio with Xamarin plug-in for Xamarin.iOS development and you are intended to use the same on Mac machine, then, it's a mandate to install the virtual machine (VM) software for Mac and then install Windows within this Virtual Machine created out of VM software. Thereafter, you can install all the tools including Visual Studio and Xamarin plug-in into the Windows operating system present inside the Virtual Machine. You must have to install the Xamarin.iOS development tools including Xamarin Studio, and other tools like iOS SDK and XCode IDE into the Mac. Setting up the Xamarin.iOS Build Host on the Mac is necessary as the Xamarin plug-in to Visual Studio communicates with Xamarin.iOS Build Host during the build phase of the Xamarin.iOS application.
Using Windows virtually inside Mac to use Visual Studio with Xamarin plug-in.
MonoTouch
There is something called as Mono which is an open source version of Microsoft .NET. Ahead of Time (AOT) compiler belongs to Mono runtime code generator. Open source Mono architecture comprises of class library and Common Language Runtime (CLR).
Mono runtime code generator.
JIT is Just In Time compiler and AOT is Ahead of Time compiler. Commanding Mono runtime to generate AOT code is possible as AOT is a part of Mono runtime. MonoTouch (which is based on Mono) aids C# developers to create iOS applications using C# language. Remember that MonoTouch deals only with iOS and Mono for Android deals with Android. MonoTouch SDK which is a part of Mono empowers the development of iOS devices including iPhones, iPads, iPods etc. A C# binding to native iOS APIs is nothing but monotouch.dll, which is a part of MonoTouch.
iOS developer library provides Foundation Framework. This Foundation Framework is written in Objective-C as Objective-C classes. Apple's Foundation Framework classes include classes each of which target more functionality such as Object Creation and Disposal, OS services, Data Storage, Texts and Strings, Date and Time etc. All these functionalities are either individual classes or group of classes, which fall under the Foundation Framework. Apple's Foundation Framework offers a root class named "NSObject" class. Along with this, the Foundation framework also offers other group/individual classes that come under this NSObject. As I mentioned before, we have groups of classes or individual classes to perform all the functionalities specified previously. MonoTouch.Foundation mocks Apple's Foundation Framework. The NSObject of Apple's Foundation Framework (In Objective-C) could be utilized into Xamarin.iOS base C# application by utilizing MonoTouch.Foundation.NSObject. Even though we use Objective-C's Foundation Framework functionalities by means of utilizing MonoTouch.Foundation namespace, when it comes to the matter of using data types such as arrays and strings, the namespace (MonoTouch.Foundation) automatically maps to basic .NET types (i.e. arrays and strings in .NET) instead of mapping to the data types of Objective-C's Foundation Framework.
After reading the above paragraph with certain set of facts, we shouldn't consider Xamarin.iOS as just a binding to Objective-C because it mixes C# and Objective-C and extends .NET runtime to bind C# objects to Objective-C objects. A typical scenario is when we don't use NSString provided by NSObject in C# while working with Xamarin.iOS. Rather, we would use C# "string" type. Probably this is the best example which certifies the fact that Xamarin.iOS is not just binding to Objective-C library. Rather, it mixes both Objective-C and C#.
Note:
Managed binding to Apple's CocoaTouch library is available and it is known as CoCoaTouch.NET.Xamarin.iOS Overview
There is something called as Cocoa Touch SDK. It contains many frameworks which help in building your iOS apps. Example framework UIkit is also part of Cocoa Touch SDK frameworks. UIkit framework aids in implementation of graphics and event driven facilities in your iOS apps. Xamarin.iOS gives us Cocoa Touch SDK framework features as namespaces. Therefore we can use features provided by Cocoa Touch SDK to build iOS apps in C# using Xamarin.iOS by making use of appropriate namespaces according to the need. We took the example of UIkit framework previously. So, within Xamarin.iOS, we can use UIkit by adding namespace MonoTouch.UIkit. The statement to add/use the namespace in a C# application would be as shown below
Using MonoTouch.UIkit;
Remember that the Cocoa Touch Frameworks are specially meant for touch based user interfaces. So, it is built to aid in accomplishment of the same. While designing your iOS app it is important to follow the design guidelines provided by Apple. Each time when you build the Xamarin.iOS application in Xamarin Studio or Visual Studio with Xamarin plug-in, it will in turn call a tool named "mtouch". Basically, mtouch is the tool responsible for bundling your iOS application and it also helps the simulator to launch your iOS app as well as to deploy it to iOS mobile devices. mtouch includes a linker to managed code (Here managed code is C# code as it requires Microsoft .NET runtime for its execution). mtouch can aid in reducing the Xamarin.iOS application size by means of removing the unnecessary features i.e. removing class library features which are not used by the current Xamarin.iOS application.
You have to change the linker behavior to "Link SDK assemblies only" by clicking on the project properties > Build > iOS Build > Linker > Options > Linker Behavior, and then setting "Linker Behavior to Link SDK assemblies only". This results in removal of things that your iOS application doesn't need. Changing the Linker Behavior to Link SDK assemblies only results in removal of everything that your iOS app doesn't need. This will result in smaller application size than that of when we select "Link all assemblies" option. This is because Link all assemblies option results in including all assemblies some of which are not used by the current application. This results in an unnecessary increase of the application size. However, setting "Linker Behavior to Link SDK assemblies only" option, results in leaving/skipping the unutilized assemblies that are not utilized by your current application. In fact this removes all that your iOS app doesn't need/use. So, we can easily predict and claim that changing linker behavior to Link SDK assemblies only will result in speeding up of the Ahead of Time compilation by reducing the application size.
Working of AOT Compiler.
Here, C# compiler converts C# code into Common Intermediate Language (CIL) code. Once C# code is compiled to the Intermediate Language (IL), it is used as input to the Ahead of Time (AOT) compiler. Here AOT compiler converts IL code into native code. Here, IL code is nothing but byte code. This CIL byte code can be found in .exe files or .dll files. AOT compiler converts this CIL code to native machine code. Here AOT compiler converts .NET Common Intermediate Language (CIL) code into native machine code i.e. native ARM assembly code. One main advantage of Ahead of Time (AOT) compilation is that it increases the app performance as compilation of CIL code happens prior to the app execution rather than doing the CIL code compilation to machine code during app execution (which happens in Just In Time (JIT) compilation). In simple words, Just In Time (JIT) compiler compiles CIL code to machine code during program execution (i.e. runtime, which is dynamic) whereas Ahead of Time (AOT) compiler carries out the compilation prior to program execution.
Assembly contain CIL/IL code. Therefore all Dynamic Link Libraries (DLLs) and Executables (EXEs) are examples for assembly files. CIL or IL in .NET is equivalent to Java Byte codes. CIL is also called Intermediate Language (IL) or Microsoft Intermediate Language (MSIL). CIL is human readable code. Consider that you have two same applications, one written completely using C# and another using Visual Basic. As both C# and VB are .NET languages, if you compile both codes using C# and VB compilers respectively, then, you will get IL codes generated for both. If you check the IL codes of both applications that are written in different languages, you will find that both these codes look similar as both the applications point out to the same logic although written in different languages.
Finally, when you build a Xamarin.iOS application, you will get the .ipa extension file, which can be installed on iOS devices (iPhone/iPad/iPod). This .ipa file is a compressed file which contains binary for ARM architecture. Here, machine code means code which is designed to run on a particular architecture. Ex: ARM machine code runs on ARM architecture based processors, x86 machine code runs on x86 based processors. This machine code itself is sometimes called by the name "binary", which actually means the code contains a stream of 0's and 1's which can only be understood by machines (hence, the name - "machine code") and are in a non-readable format for humans. We can also call ARM machine code as native ARM code because native code implies the code compiled to run specifically on a particular platform. Native ARM code means code compiled specifically to run on ARM architecture machines.
Process of converting C# code to Native ARM Code for iPhone.
Comments
Post a Comment