Xamarin.ios on Visual studio (beginners)
I am sure, You already know the Visual studio and and ios. Now I am planing to give the guide to create ios application on visual studio using xamarin.ios.
iOS development with Xamarin requires:
1) A Mac running macOS
2) Latest version of Xcode and iOS SDK
This walkthrough describes how to create an Hello world application in xamarin.ios project.
First of all you need to open the visual studio. You can open Spotlight and search visual studio or you can find visual studio inside the application folder.
On the Launch Screen, click New Project… to create a new Xamarin.iOS solution:
From the New Solution dialog, choose the iOS > App > Single View Application template, ensuring that C# is selected.
See the configure form
App Name: Enter your app name (My example is “HelloWorld”).
Organization Identifier: Bundle Identifier (see the next line) will be organization identifier and app name
Bundle Identifier: Bundle Identifier should be unique among the apps on the App Store (if you want to distribute your app on Apple’s App Store). Therefore, one way to ensure this uniqueness is to choose a unique organization Identifier.
Team: this is required for run app on real device or submit app to app store. For the movement keep it as it is. We will talk later about this.
Devices: You need to select ios devices type. ipad/iphone or both.
Target:Minimum ios version you want to support (for my version I have selected ios 10.0)
Now Click Next: (You will see another configure view)
Project name: It’s project name that you entered
Solution Name: This will be same with project name. You can change it if you want.
Location: the location that you want to save on your mac
Version Controller: By default git is supporting for it. For the movement you can ignore this.
Xamain Test Cloud: If you put a tick for this add an automated ui test project into the current project.
Now your solution is ready for code.
Review the Source Code
Find the AppDelegate.cs from solution and double click.
The AppDelegate.cs source file has two primary functions:
It defines your AppDelegate class. The app delegate creates the window where your app’s content is drawn and provides a place to respond to state transitions within the app.
It creates the entry point to your app and a run loop that delivers input events to your app. This work is done by the UIApplicationMain attribute, which appears toward the top of the file.
Using the UIApplicationMain attribute is equivalent to calling the UIApplicationMain function and passing your AppDelegate class’s name as the name of the delegate class. In response, the system creates an application object. The application object is responsible for managing the life cycle of the app. The system also creates an instance of your AppDelegate class, and assigns it to the application object. Finally, the system launches your app.
The AppDelegate class is automatically created whenever you create a new project. Unless you are doing something highly unusual, you should use this class to initialize your app and respond to app-level events. The AppDelegate class adopts the UIApplicationDelegate protocol. This protocol defines a number of methods you use to set up your app, to respond to the app’s state changes, and to handle other app-level events.
The AppDelegate class contains a single property: window.
This property stores a reference to the app’s window. This window represents the root of your app’s view hierarchy. It is where all of your app content is drawn. Note that the window property is an optional, which means it may have no value (be nil) at some point.
The AppDelegate class also contains stub implementations of the following delegate methods:
public override bool FinishedLaunching(UIApplication application, NSDictionary launchOptions)
// Override point for customization after application launch.
// If not required for your application you can safely delete this method
public override void OnResignActivation(UIApplication application)
// Invoked when the application is about to move from active to inactive state.
// This can occur for certain types of temporary interruptions (such as an incoming phone call or SMS message)
// or when the user quits the application and it begins the transition to the background state.
// Games should use this method to pause the game.
public override void DidEnterBackground(UIApplication application)
// Use this method to release shared resources, save user data, invalidate timers and store the application state.
// If your application supports background exection this method is called instead of WillTerminate when the user quits.
public override void WillEnterForeground(UIApplication application)
// Called as part of the transiton from background to active state.
// Here you can undo many of the changes made on entering the background.
public override void OnActivated(UIApplication application)
// Restart any tasks that were paused (or not yet started) while the application was inactive.
// If the application was previously in the background, optionally refresh the user interface.
public override void WillTerminate(UIApplication application)
// Called when the application is about to terminate. Save data, if needed. See also DidEnterBackground.
These methods let the application object communicate with the app delegate. During an app state transition—for example, app launch, transitioning to the background, and app termination—the application object calls the corresponding delegate method, giving your app an opportunity to respond. You don’t need to do anything special to make sure these methods get called at the correct time—the application object handles that job for you.
Each of the delegate methods has a default behavior. If you leave the template implementation empty or delete it from your AppDelegate class, you get the default behavior whenever that method is called. Alternatively, you can add your own code to the stub methods, defining custom behaviors that are executed when the methods are called.
The template also provides comments for each of the stub methods. These comments describe how these methods can be used by your app. You can use the stub methods and comments as a blueprint for designing many common app-level behaviors.
In this lesson, you won’t be using any custom app delegate code, so you don’t have to make any changes to the AppDelegate.cs file.
The View Controller Source File
The Single View Application template has another source code file: ViewController.cs and ViewController.designer.cs . Open ViewController.cs
This file defines a custom subclass of UIViewController named ViewController. Right now, this class simply inherits all the behavior defined by UIViewController. To override or extend that behavior, you override the methods defined on UIViewController.
As you can see in the ViewController.cs file, the template’s implementation overrides both the viewDidLoad() and didReceiveMemoryWarning() methods; however, the template’s stub implementation doesn’t do anything yet, except call the UIViewController version of these methods. You can add your own code to customize the view controller’s response to these events.
Although the template comes with the didReceiveMemoryWarning() method, you won’t need to implement it in these lessons, so go ahead and delete it.
So leave as it is this file
Open Your Storyboard
You’re ready to start working on a storyboard for your app. A storyboard is a visual representation of the app’s user interface, showing screens of content and the transitions between them. You use storyboards to lay out the flow—or story—that drives your app. You see exactly what you’re building while you’re building it, get immediate feedback about what’s working and what’s not, and make instantly visible changes to your user interface.
At this point, the storyboard in your app contains one scene, which represents a screen of content in your app. The arrow that points to the left side of the scene on the canvas is the storyboard entry point, which means that this scene is loaded first when the app starts. This scene contains a single view that’s managed by a view controller. You’ll learn more about the roles of views and view controllers soon.
When you ran your app in the iPhone 7 Simulator app, the view in this scene is what you saw on the device screen. However, the scene on the canvas may not have the same dimensions as the simulator’s screen. You can select the screen size and orientation at the bottom of the canvas. In this case, it’s set to iPhone 7 in a portrait orientation, so the canvas and the simulator are the same.
Even though the canvas shows a specific device and orientation, it is important to create an adaptive interface—an interface that automatically adjusts so that it looks good on any device and in any orientation. As you develop your interface, you can change the canvas’s view, letting you see how your interface adapts to different size screens.
Now time is to change your view
In the Toolbox Pad, type “label” into the search bar and drag a Label onto the design surface (the area in the center):
With the Label selected on the design surface, use the Properties Pad to change the Text property of the Label to “Hello world”
That’s it. You can run it now..
Stay tune for the next tutorial
Reference : https://developer.apple.com/library/content/referencelibrary/GettingStarted/DevelopiOSAppsSwift/BuildABasicUI.html