Code Archives - HangZone

How to Make a Location Check-In App in Xamarin.Forms Part One

Tyler Bandy — Tue, 31 Mar 2020 14:49:42 +0000

It’s been about ten years since Foursquare launched their mobile check-in app. In case you missed out on that trend, the original Foursquare app was all about checking into locations to earn badges. Whoever logged the most activity at a location over a trailing month earned the title of mayor. Sometimes restaurants gave special offers to the mayor, like free guacamole on a burrito, so this was serious business!

These were the early days of gamification of mundane activities, so there was a pretty low bar to get people excited. Eventually, people got tired of having to check-in everywhere, and the app lost popularity.

Let’s Bring it Back

They say fads come in cycles though. Maybe it’s time to bring the check-in trend back to the masses. Let’s start with your immediate group of friends anyway. We’ll pick one place you guys all like to go. Everyone will have the ability to check-in once every 12 hours. Whoever has the most check-ins is the mayor. We’ll build the app with Xamarin.Forms. This will be a two part series. We’ll handle the location based functionality in part one. We’ll take care of the server functionality in part 2.

Start a Xamarin Forms Project

Fire up Visual Studio. I’m using a Windows computer, but feel free to use a Mac. Some of the menus will be a bit different though. Create a new project. Select a Xamarin.Forms template. I’m going to call this project “Mayor”. Go with the blank template option, and select Android and iOS for the platforms.

Set-up Location Libraries and Permissions

For starters, the Xamarin Essentials NuGet package houses all of the location functionality that we need. Fortunately, it’s already added to our project by default, along with the necessary start-up code.

That just leaves us with permissions. We’ll start with Android. Open up your AndroidManifest.xml file. It’s in the Properties folder in case you can’t find it. Inside the manifest node, add the following code.

Now let’s do iOS. Right click your Info.plist and select View Code. Inside the dictionary, add the following key value pair.

NSLocationWhenInUseUsageDescription
We need to verify your location when you check-in.

This will show the user a prompt for why we’re requesting to track their location.

The Interface

Let’s put together a basic interface now. We want a label that shows how many times you’ve checked-in during the past month. We also want a button to check-in. Finally, we want a label that displays a confirmation or error code for your check-in attempt.

Open up MainPage.xaml and remove the default label inside of the StackLayout. Let’s put our own interface elements inside of the StackLayout.



Local Security Measures in Xamarin.Forms
Judson Bandy — Fri, 28 Feb 2020 14:32:24 +0000
There are many types of mobile apps where security is of the utmost importance. When dealing with banking, payment, health, or other sensitive information, it is crucial to keep data safe. There may even be legal ramifications for exposing user data. This conversation typically begins with a secure login, protecting data in transit, and data access. While these are the most important aspect, we’re going to look at a different aspect of protection.
How can we best protect users from exposing data locally? Yes, a secure login is the first step, but what if a user logs in, and then exits the app without hard closing it. If someone else uses their phone, are we able to protect the data? Also, what if they put their phone down with the app still up? There are several little steps that can be done to help the user protect their data. Let’s look at a few ways to help further secure your apps.
Create the Xamarin.Forms Project
First, we will create a Xamarin.Forms project. I am doing it on a Windows computer, but it can also be done on Visual Studio for Mac. Open Visual Studio and click to create a new project. Select Mobile App (Xamarin.Form) in C# and press Next. I’m going to name my project, “XamarinSecurityExample.” Then, press Create. On the template selection, we are going with Blank, and Android and iOS for platforms. The app is now created. Now, we are just going to make a simple two page application to show how our security features can be plugged in.
Open MainPage.xaml. This is the first page that opens when you start the app and it will be our mock login page. Start by deleting everything inside the StackLayout and add the following.

    
    
This code simply puts a title of Login Page in the top half of the screen, and a button in the bottom half of the page. The button has a function that we will define in the codebehind when it is clicked.
Let’s do that now. Open the MainPage.xaml.cs. Define our new method like this.
private void LoginButton_Clicked(object sender, EventArgs e)
{
    Application.Current.MainPage = new SecurePage();
}
This will navigate to our a new page when the button is pressed. Now, we have to create the new page.
Right click on our shared project, and click Add->New Item… Select Content Page, and name it, “SecurePage.xaml.” Let’s add some content to SecurePage.xaml. Replace the StackLayout with the following.

    
    
The UI on this page is just like our login page. There is a label at the top that talks about all of our secure data, and then, a button at the bottom. Again, we need to go to the codebehind to define our Clicked method. Open SecurePage.xaml.cs, and add the following method.
private void LogoutButton_Clicked(object sender, EventArgs e)
{
    Application.Current.MainPage = new MainPage();
}
Our base app is now finished. It’s clearly nothing to write home about, but it will get the job done for our example. There is a login page, and a page that you navigate to after “logging in” that has secure information.
Auto Logout When Returning to App
The first thing we’ll tackle is auto logout when returning to the app. This will happen if a user is logged in, exits the app (but does not hard close), then clicks to reopen the app. If the user is only gone for a short period of time, it should be fine to keep the user logged in. Otherwise, we certainly want to auto logout the user. Let’s jump back into the code. This one should be fairly straightforward. First, open App.xaml.cs. Add the following code.
public static bool IsUserLoggedIn = false;
private DateTime? SleepTime = null;

protected override void OnSleep()
{
    SleepTime = DateTime.Now;
}

protected override void OnResume()
{
    if (SleepTime != null)
    {
        if (DateTime.Now.Subtract((DateTime)SleepTime) > TimeSpan.FromSeconds(120))
        {
            LogOutUser();
        }
    }
}

public static void LogOutUser()
{
    if (!IsUserLoggedIn)
        return;

    Application.Current.MainPage = new MainPage();
}
To start with, we added two variables. One is SleepTime, which keeps track of time away from the app, and the other is IsUserLoggedIn, which tracks if the user is logged in. Then, we override the OnSleep method to set the SleepTime variable to the time that the app went to sleep. Next, we override OnResume. There, we check to see how long we have been away from the app, and if it was longer than 2 minutes, we call the LogOutUser method. In that method, we check to see that the user is logged in, and if so, we return the app to the login page.
Finally, we need to adjust the IsUserLoggedIn method when the user logs in and out. In LoginButton_Clicked in MainPage.xaml.cs, add the following.
App.IsUserLoggedIn = true;
Then, in LogoutButton_Clicked in SecurePage.xaml.cs, add this.
App.IsUserLoggedIn = false;
That’s it! The user will be able to resume their session if they return to the app within 2 minutes of closing it. Otherwise, they will be auto logged out and have to log in again to access their data.
Auto Logout for Inactivity
That is an excellent solution for a user that exits the app and then returns, but what if the user leaves their phone with the app still up? Sensitive data could easily be exposed. To try to prevent this, we would like to auto logout the user after a certain amount of inactivity. Unfortunately, this code is a little more complicated. This is due to the fact that user input is detected in the Android and iOS sections, respectively, depending on your device type. Let’s get started and try the Android version first.
Android Inactivity
Open MainActivity.cs in the Android section of the project. Our strategy will be to throw a popup after a certain amount of inactivity, and then if there is no activity, log the user out. Let’s start by defining variables for those amounts of time and for a handler.
public static long DISCONNECT_WARNING = 240000; // 4 min = 4 * 60 * 1000ms = 240000
public static long DISCONNECT_TIMEOUT = 60000; // 1 min = 1 * 60 * 1000ms = 60000
public Handler DisconnectWarningHandler;
We create 2 static variables. First, the warning amount of time will be 4 minutes, and then the actual logout will occur if there is no activity for another minute. Next, add the following code to the OnCreate method.
DisconnectWarningHandler = new Handler(new WarningHandlerICallback(this));
Now, we need to define the WarningHandlerICallback class. This is still inside the MainActivity class. Then, we will add our code to start and stop the inactivity handlers.
public Handler disconnectWarningHandler;

public class WarningHandlerICallback : Java.Lang.Object, Handler.ICallback
{
    private MainActivity mainActivity;

    public WarningHandlerICallback(MainActivity mainActivity)
    {
        this.mainActivity = mainActivity;
    }

    public bool HandleMessage(Message msg)
    {
        App.WarnUserAboutInactivity();
        mainActivity.resetDisconnectTimer();
        return true;
    }
}

System.Action LogoutAction = () =>
{
    App.LogOutUser();
};

public void resetWarningTimer()
{
    DisconnectWarningHandler.RemoveMessages(1);
    DisconnectWarningHandler.SendEmptyMessageDelayed(1, DISCONNECT_WARNING);
}

public void stopWarningTimer()
{
    DisconnectWarningHandler.RemoveMessages(1);
}

public void resetDisconnectTimer()
{
    DisconnectWarningHandler.RemoveCallbacks(LogoutAction);
    DisconnectWarningHandler.PostDelayed(LogoutAction, DISCONNECT_TIMEOUT);
}

public void stopDisconnectTimer()
{
    DisconnectWarningHandler.RemoveCallbacks(LogoutAction);
}

protected override void OnStop()
{
    base.OnStop();
    stopWarningTimer();
    stopDisconnectTimer();
}

protected override void OnResume()
{
    base.OnResume();
    resetWarningTimer();
    stopDisconnectTimer();
}

public override void OnUserInteraction()
{
    resetWarningTimer();
    stopDisconnectTimer();
}
That’s a lot to take in, but we’ll try to explain it. OnUserInteraction is where we are able to register user activity. When the user does anything, we reset our warning timer and stop our disconnect timer. Only one of these timers is ever actually on a once, but this does a full reset if one or none of the timers are running. The ResetWarningTimer method calls to send an empty delayed message for the disconnect warning length of time that we set. If that time passes with no activity, HandleMessage in our WarningHandlerICallback class gets called. There, we call the App.xaml.cs file to throw a warning popup, and we start our disconnect timer.
The disconnect timer does a PostDelayed for the length of time that we set for disconnect. This performs an action that we call LogoutAction, which calls the App.xaml.cs LogOutUser method that we created earlier. OnStop and OnResume are also overridden so that the timers are reset when you exit and reenter the app.
Finally, go back to App.xaml.cs. We have to add the inactivity warning method that we called from MainActivity.
public static async void WarnUserAboutInactivity()
{
    if (!IsUserLoggedIn)
        return;

    await Application.Current.MainPage.DisplayAlert("Inactivity Warning", "Are you still there? If you don't return to the application, you will be logged out.", "OK");
}
As you can see, if the user is logged in, they will receive a popup warning that they will soon be logged out for inactivity. That’s it. The Android solution is done.
***A quick word of warning. I would strongly suggest using custom popups instead of the built in DisplayAlert popups. There is no way to programmatically close these popups, which can be problematic in a number of different situations. For instance, you would likely want to close the warning popup about the impending logout once the user is actually logged out. There also can be issues with multiple popups being displayed at once. Finally, clicking the button on the system popup doesn’t register through OnUserInteraction (you can easily use MessagingCenter to alert the MainActivity class when/if the popup is dismissed though).
iOS Inactivity
Next, we’ll set up the iOS inactivity check. In the iOS section of the project, open AppDelegate.cs. Add the following code.
public override bool FinishedLaunching(UIApplication app, NSDictionary options)
{
    …

    return base.FinishedLaunching(app, options);
    var success = base.FinishedLaunching(app, options);

    var allGesturesRecognizer = new AllGesturesRecognizer(delegate
    {
        ResetIdleTimer();
    });

    this.Window.AddGestureRecognizer(allGesturesRecognizer);

    if (IdleTimer == null)
    {
        IdleTimer = NSTimer.CreateRepeatingScheduledTimer(TimeSpan.FromSeconds(10), delegate
        {
            LogOutMethod();
        });
    }

    return success;
}

private NSTimer IdleTimer = null;
private bool TouchDetected = false;
private int LogoutCounter = 0;
private bool IsInactivityPopupDisplayed = false;

[Export("applicationWillResignActive:")]
override public void OnResignActivation(UIApplication uiApplication)
{
    IdleTimer.Invalidate();
    IdleTimer = null;
    LogoutCounter = 0;

    base.OnResignActivation(uiApplication);
}

[Export("applicationDidBecomeActive:")]
override public void OnActivated(UIApplication uiApplication)
{
    if (IdleTimer == null)
    {
        IdleTimer = NSTimer.CreateRepeatingScheduledTimer(TimeSpan.FromSeconds(10), delegate
        {
            LogOutMethod();
        });
    }

    base.OnActivated(uiApplication);
}

private void ResetIdleTimer()
{
    TouchDetected = true;
}

private void LogOutMethod()
{
    if (TouchDetected)
    {
        if (IsInactivityPopupDisplayed)
        {
            IsInactivityPopupDisplayed = false;
        }

        LogoutCounter = 0;
        TouchDetected = false;
        return;
    }

    LogoutCounter++;

    if (LogoutCounter == 24) //24 4 min = 4 * (6 * 10sec)
    {
        App.WarnUserAboutInactivity();
    }
    else if (LogoutCounter >= 30) //30 5 min = 5 * (6 * 10sec)
    {
        App.LogOutUser();
        LogoutCounter = 0;
    }
}

class AllGesturesRecognizer : UIGestureRecognizer
{
    public delegate void OnTouchesEnded();

    private OnTouchesEnded touchesEndedDelegate;

    public AllGesturesRecognizer(OnTouchesEnded touchesEnded)
    {
        this.touchesEndedDelegate = touchesEnded;
    }

    public override void TouchesEnded(NSSet touches, UIEvent evt)
    {
        this.State = UIGestureRecognizerState.Failed;
        this.touchesEndedDelegate();

        base.TouchesEnded(touches, evt);
    }
}
This is all of the iOS code at once. Let’s try to break it down. In the FinishedLaunching method, we create a GestureRecognizer that calls ResetIdleTimer whenever touch is detected. The ResetIdleTimer method sets TouchDetected, an instance variable, to true. Next in FinishedLaunching, a timer is created that calls LogOutMethod every ten seconds. If TouchDetected is true, the LogoutCounter is reset. Otherwise, the inactivity warning method in App.xaml.cs is called after 4 minutes, and the logout method is called after an additional minute of inactivity.
Test it out, and you’ll see an inactivity warning after you sit around on the secure page for a while. Start interacting with the application and nothing will happen. Otherwise, you will be auto logged out after another minute of inactivity.
Obscure Information When Looking at Recent Apps
The final issue we want to tackle is the view that shows recently open apps. On iOS this is called the App Switcher, and on new iPhone and iPad devices, you get to this screen by swiping up from the bottom to the middle of the screen and holding. On Android, it’s the recent apps overview, and you get there by pressing the square button on older devices or a quick swipe from the bottom on newer devices.
Regardless of platform, this view shows recently open apps that are currently in the background. Each app shows a picture of your last screen in the app. You are able to click on the picture to reenter an app or you can hard close the app. The issue here is information potentially shown on the picture. If we were on a page containing sensitive information when we exited the app, that sensitive information would now be visible. To prevent this, we are going to obscure what the user sees.
Obscure Display in Android
Let’s start with Android. This time it’s the simple option. In the OnCreate method in MainActivity.cs, add the following line.
Window.SetFlags(WindowManagerFlags.Secure, WindowManagerFlags.Secure);
That’s it. If you go to the recent apps overview, you will see that it shows a white screen with no content, which you can see below. We’ve done it! Besides hiding the display, this flag also prevents the user from taking screenshots inside the app.

Obscure Display in iOS App Switcher
Open the AppDelegate.cs file, and we will get started with the iOS version. First add a private instance variable of UIView.
private UIView _view;
Next, we will add lines to the OnResignActivation and OnActivated methods that we overrode for the inactivity check.
override public void OnResignActivation(UIApplication uiApplication)
{
    var window = UIApplication.SharedApplication.KeyWindow;
    var rect = UIScreen.MainScreen.Bounds;
    _view = new UIView { Frame = rect };
    _view.BackgroundColor = UIColor.FromRGB(60,179,113);
    window.AddSubview(_view);

    …
}

override public void OnActivated(UIApplication uiApplication)
{
    …

    if (_view != null)
    {
        _view.RemoveFromSuperview();
        _view.Dispose();
    }

    …
}
When we resign active, we instantiate our UIView, make it the size of the screen, give it a green color, and then add it as a subview over our app. When the app is activated, we remove the view. That’s it. Test it out and you will see a solid green color covering the app’s screen when the App Switcher is up.
Conclusion
Great work! We were able to look at several ways to improve local security in our apps. First, we added an auto logout for when the app is in the background for too long. Then, we added an auto logout if the user is inactive inside the app for five minutes. Finally, we secured any sensitive information that could be displayed when the App Switcher is displayed. Good luck implementing these security concepts into your next app that requires dealing with delicate information. As always, thanks for reading the HangZone blog.
The post Local Security Measures in Xamarin.Forms appeared first on HangZone.



Custom Renderers in Xamarin.Forms Part 2
Judson Bandy — Wed, 27 Nov 2019 18:25:13 +0000
In part 2 of our custom renderer blog post, we will continue to look at uses for custom renderers in Xamarin.Forms. In part 1, we made a navigation page in Xamarin.Forms. The toolbar item on the page used an icon from material.io for the Android version and used a system icon for the iOS version. We were able to use the system icon thanks to a custom renderer. If you have not read it, you can find part 1 here. We will start this project where part 1 left off.
Extending an Element
Let’s continue with the same Xamarin.Forms solution, which I named CustomRendererSample. The next thing that we want to add is a gradient underneath the toolbar. A shadow can be added to the Android project by adding an elevation property definition under the Resources->layout->Toolbar.axml file. This is not what we’re after though. We are going to add a loud, slightly obnoxious gradient on both iOS and Android under the toolbar. 
The Xamarin.Forms control that we want to use is the BoxView. Unfortunately, we only have the ability to give it a single uniform color. To add our desired functionality, we will subclass BoxView and add additional properties to our new control. Then, we will create custom renderers for iOS and Android that will tell the system how to use our new properties. Hopefully, it won’t be too hard.
Create our Custom BoxView
Let’s start by creating our new BoxView class. Right click on the Shared Project and select Add->New Item… Add a new class called GradientBoxView.cs. We could create our properties simply as public properties, but instead, we are going to use BindableProperty. This will allow us to set these properties in a style. Styles do not make much sense if you are only using them once, but they can be quite helpful for maintaining and updating your code if objects with the same appearance are used multiple times.
Add the following code to your GradientBoxView class.
public class GradientBoxView : BoxView
{
    public static readonly BindableProperty StartColorProperty = BindableProperty.Create("StartColor", typeof(Color), typeof(GradientBoxView), Color.Transparent);
    public static readonly BindableProperty EndColorProperty = BindableProperty.Create("EndColor", typeof(Color), typeof(GradientBoxView), Color.Transparent);
    public static readonly BindableProperty IsVerticalProperty = BindableProperty.Create("IsVertical", typeof(bool), typeof(GradientBoxView), true);

    public Color StartColor
    {
        get { return (Color)GetValue(StartColorProperty); }
        set { SetValue(StartColorProperty, value); }
    }

    public Color EndColor
    {
        get { return (Color)GetValue(EndColorProperty); }
        set { SetValue(EndColorProperty, value); }
    }

    public bool IsVertical
    {
        get { return (Color)GetValue(IsVerticalProperty); }
        set { SetValue(IsVerticalProperty, value); }
    }
}
You can see that the class inherits from BoxView, so that we retain all of the functionality of that class. Then, we added variables for StartColor, EndColor, and IsVertical. As the names suggest, these will define the starting color, ending color, and direction of the gradient.
Implementing the GradientBoxView
Now, let’s head over to App.xaml to create a style. Like we said, a style is nice in case we want to use the same gradient on a number of pages. In the Application.Resources section, add the following code. 

    

As you can see, a style is added that sets all of our properties for the GradientBoxView. App.xaml will have to add “xmlns:customrendersample=“clr-namespace:CustomRendererSample” so that GradientBoxView will be imported into this class.
Now, we can jump over to MainPage.xaml to add GradientBoxView to the page. Change the ContentPage.Content to look like this.

    
        
            
            
        
        
        
    

You can see that we adjusted our grid to put the gradient underneath the toolbar at the top of the page, and our SearchLabel is still in the middle. Again, we need the same CustomRendererSample definition and prefix to use the class. That wraps up the code in our Shared Project. Let’s move on to our custom renderers and set our new GradientBoxView properties in motion.
iOS Custom Renderer
Let’s start with the iOS renderer. Its code is a little simpler, so it should be an easier place to begin. Navigate to the iOS project, right click and select Add->New Item… Choose a class and name it GradientBoxViewRenderer.cs. Click the Add button, and we’re ready to get started.
First, we need to add an assembly line so that this code will be used. Above the line that defines the namespace, add:
[assembly: ExportRenderer(typeof(GradientBoxView), typeof(GradientBoxViewRenderer))]
This line tells our code to use this renderer whenever GradientBoxView occurs in the code. If you get errors in this code, or anywhere else in the custom renderers, you should be able to hover over the error and select for Visual Studio to add the appropriate using directive. Next, we will make this class a subclass of BoxRenderer.
class GradientBoxViewRenderer : BoxRenderer
To add our gradient to the boxview, we only need to override one method, the Draw function.
public override void Draw(CGRect rect)
{
    base.Draw(rect);

    var stack = Element as GradientBoxView;
    var topColor = stack.StartColor.ToCGColor();
    var bottomColor = stack.EndColor.ToCGColor();
    var gradientLayer = new CAGradientLayer
    {
        Frame = rect,
        Colors = new CGColor[] { topColor, bottomColor }
    };

    if (!stack.IsVertical)
    {
        gradientLayer.StartPoint = new CGPoint(0, 0.5);
        gradientLayer.EndPoint = new CGPoint(1, 0.5);
    }

    NativeView.Layer.InsertSublayer(gradientLayer, 0);
}
Let’s walk through what is going on. First, we are getting our GradientBoxView and setting it to a local variable, stack. Next, we are getting the start color and end color from it, and converting the colors to CGColors. Then, we create a CAGradientLayer to the size of our BoxView with the gradient colors. Finally, we adjust the direction if horizontal is desired, and we add the gradient to the native iOS BoxView. That’s it! It is fairly straightforward, and just like that, the iOS version is good to go. Now, let’s move to Android.
Android Custom Renderer
This custom renderer is a little more involved, but we can do it. Go to the Android project in the Solution Explorer, and add a new class just like we did for the iOS renderer. We will also name this class GrandientBoxViewRenderer.cs. Add the same assembly directive above the namespace definition so that this renderer will be used for all GradientBoxViews when running on Android. Then, add the code so that this class will be a subclass of BoxRenderer. That’s where the same code ends.
First, we’ll add instance variables for our GradientBoxView properties at the top of the renderer class definition and an empty initializer for the class.
public class GradientBoxViewRenderer : BoxRenderer
{
    private Color StartColor { get; set; }
    private Color EndColor { get; set; }
    private bool IsVertical { get; set; }

    public GradientBoxViewRenderer(Context context) : base(context)
    {

    }
}
Then, we will override OnElementChanged. We will use this to set the values of our instance variables.
protected override void OnElementChanged(ElementChangedEventArgs e)
{
    base.OnElementChanged(e);

    if (e.OldElement != null || Element == null)
    {
        return;
    }

    try
    {
        var stack = e.NewElement as GradientBoxView;

        this.StartColor = stack.StartColor;
        this.EndColor = stack.EndColor;
        this.IsVertical = stack.IsVertical;
    }
    catch (Exception ex)
    {
        System.Diagnostics.Debug.WriteLine(@"ERROR:", ex.Message);
    }
}
Now that we have our variables from GradientBoxView, it’s time to do our drawing code to create the gradient on the Android BoxView.
protected override void DispatchDraw(global::Android.Graphics.Canvas canvas)
{
    if (global::Android.OS.Build.VERSION.SdkInt > global::Android.OS.BuildVersionCodes.O)
    {
        var orientation = GradientDrawable.Orientation.TopBottom;

        if (!this.IsVertical)
        {
            orientation = GradientDrawable.Orientation.LeftRight;
        }

        var specialGradient = new GradientDrawable(orientation, new[] { this.StartColor.ToAndroid().ToArgb(), this.EndColor.ToAndroid().ToArgb() });
        ViewCompat.SetBackground(this, specialGradient);
        return;
    }

    global::Android.Graphics.LinearGradient gradient = null;

    if (this.IsVertical)
    {
        gradient = new global::Android.Graphics.LinearGradient(0, 0, 0, Height, this.StartColor.ToAndroid(),this.EndColor.ToAndroid(), global::Android.Graphics.Shader.TileMode.Clamp);
    }
    else
    {
        gradient = new global::Android.Graphics.LinearGradient(0, 0, Width, 0, this.StartColor.ToAndroid(), this.EndColor.ToAndroid(), global::Android.Graphics.Shader.TileMode.Clamp);
    }

    var paint = new global::Android.Graphics.Paint()
    {
        Dither = true,
    };
    paint.SetShader(gradient);
    canvas.DrawPaint(paint);
    base.DispatchDraw(canvas);
}
As you can see, the technique is different for Android versions greater than O. For the newer versions, we simply get our orientation, then create a GradientDrawable with our colors. Then, we set it as the background on the native ViewCompat. For the older Android versions, we create a LinearGradient based on the gradient direction. Then, we DrawPaint the gradient onto the canvas. That’s it for Android and our GradientBoxView. Run the project and see your custom GradientBoxView in action! You can easily change the color, direction, or size if you so desire.

Conclusion
Great job! We successfully created a custom control in Xamarin.Forms—a GradientBoxView. This is a nice tool for adding gradients under objects in your projects to further set them off or provide separation of sections. Not only that, but you should now have a good idea of how to create other custom controls using custom renderers. It’s not always simple, but you can usually use custom renderers to accomplish any visual look or action that would natively be available on the platform. As always, thanks for reading the HangZone blog!
The post Custom Renderers in Xamarin.Forms Part 2 appeared first on HangZone.



Custom Renderers in Xamarin.Forms Part 1
Judson Bandy — Mon, 30 Sep 2019 16:06:38 +0000
Xamarin.Forms is a great tool for cross platform app development. It gives you the ability to write shared code that is used by different operating systems. Not only are you able to write shared logic, but you are also able to write shared UI code. This allows you to save time in initial development and makes it much more maintainable since there is only one version of the code. Not only this, but Xamarin.Forms is able to use native elements of each platform so that you are still able to get a native look and feel for each device.
Although this shared code is fast and works well, it doesn’t always provide the granularity that we are looking to use for each platform. Sometimes a finer brush is needed to paint our masterpiece. This is no reason to fret, though. Xamarin.Forms allows us to create custom renderers so that we are able to extend controls to take advantage of native specific elements for each platform. In this blog post, we will create a couple of custom renderers in a Xamarin.Forms project to make elements that are more robust than what comes out of the box.
Create Xamarin.Forms Project
Let’s start by creating a new Xamarin.Forms project. I am developing on a Windows computer in Visual Studio 2019. You can do this just as well on Visual Studio for Mac. We are are going to write this app to run for both iOS and Android.
First, open Visual Studio, and create a new project. Select Mobile App (Xamarin.Forms), and click Next. Give your project a name, mine is called “CustomRendererSample,” choose a location, and create the project. Select a Blank template, and for platforms, we are doing Android and iOS. You can certainly do UWP as well, but we are only targeting iOS and Android in this example. Press OK, and our project is now created.
Toolbar Buttons
For this example, we are going to make an app with a hierarchical navigation scheme. This has the toolbar at the top, and pages are added to and popped off the stack as you navigate. We are only going to have one page for our example, though. With the toolbar at the top, it is common to have toolbar buttons. These can be save, cancel, back, refresh, and so on. You will find these in many of the first party phone apps (like Settings) or pretty much any native enterprise style app. Toolbar buttons can be created through Xamarin.Forms, but as an extension to the control, we are going to have the app use System toolbar buttons on iOS to get a totally native look.
First, let’s get the navigation page set up for the app. Open App.xaml.cs in the Shared Project of your Solution. Make the following edit to the constructor.
MainPage = new NavigationPage(new MainPage());
This creates a NavigationPage as the root page of the app, and then adds MainPage as the content of the navigation page. Feel free to go ahead and run the app. You should now see a blank toolbar at the top of your screen, and the Xamarin.Forms welcome label displayed in the middle of it. We’re off to a good start!
Now, open MainPage.xaml. Start by deleting the entire StackLayout and the welcome label that is inside it. We are going to make our own content later.

    
    

Next, we’ll give the page a title to go on the toolbar. Set the title property on ContentPage to “Awesome Page.”
Title=“Awesome Page”>
Android Toolbar Buttons
We don’t have to add images to our project for iOS since we are using system buttons, but we do need them for Android. We are able to download Android buttons without any problem from the material.io website. All Android icons are open source and are available to be used in any project. We are going to use the search icon in our project. Go to this page, select the “search” icon, and download the SVG 24 file. 
I like to open this file in Inkscape (use can use any vector drawing program to edit the file without losing image quality). The image, which is a little larger than 17×17, is designed to be centered on a transparent 24×24 background. Once you do that, we want to change the color of the icon to white, and create 3 different sizes—24×24, 48×48, and 72×72. Now, they are ready to export and add to our project. Please see the image below for what my icons look like.

Let’s go back to Visual Studio. Inside the Android project, open the Resource folder. Drag the 24×24, 48-48, and 72×72 icons into the drawable, drawable-hdpi, and drawable-xxhdpi folders, respectively. All three of my icons are named “searchIconDroid.png.” Now that the icons are created and added to the project, we can return to the code.
On a side note, these drawable folders are currently not working in the Microsoft version of Visual Studio. You can look through the File Explorer and see that the folders do not actually exist. To fix it, simply delete the fake folders that are currently shown, and re-add folders with the same names.
Create the Toolbar Item in XAML
Open MainPage.xaml again, and add the following code.

    
        
            
                
                
            
        
    

This code creates a ToolbarItem named “SearchButton.” We aren’t going to reference the button in this project, but it can still be helpful to give a name to your elements. We set the “Text” to “Search.” This is what our iOS custom renderer is going to use to identify what kind of system bar button should be used. Finally, we set the IconImageSource. We use platform specific code where the Android version is set to the name of the search icon that we created, and the iOS version is left empty. You can run this code on an Android device and see our beautiful search icon, but the iOS version still needs a custom renderer.
iOS Toolbar Button Custom Renderer
It’s finally time to create our first custom renderer. Right click on the iOS Project in your Solution and select Add->New Item… Add a new class called CustomNavigationRenderer.cs. To set up the page, we have to add an assembly directive to the top. This line makes all instances of the Xamarin control referenced flow through this custom renderer. Add the following line (note: many of the lines will require additional using namespaces to be added. Visual Studio should show errors and tell you which namespaces need to be added).
[assembly: ExportRenderer(typeof(ContentPage), typeof(CustomNavigationRenderer))]
You can see that this names ContentPage, which is the page type that we are using in the Shared Project, and the name of this renderer. Next, add that our new renderer class inherits from PageRenderer.
class CustomNavigationRenderer : PageRenderer
Now we add the logic to the page.
protected override void OnElementChanged(VisualElementChangedEventArgs e)
{
    base.OnElementChanged(e);
    CreateNativeToolbarItems();
}

private void CreateNativeToolbarItems()
{
    if (this.NavigationController == null)
        return;
    if (this.NavigationController.TopViewController == null)
        return;
    if (this.NavigationController.TopViewController.NavigationItem == null)
        return;
    if (this.NavigationController.TopViewController.NavigationItem.RightBarButtonItems == null)
        return;

    var rightList = new List();
    foreach (var item in this.NavigationController.TopViewController.NavigationItem.RightBarButtonItems)
    {
        if (string.IsNullOrEmpty(item.Title))
        {
            continue;
        }
        if (item.Title.ToLower() == "search")
        {
            var newItem = new UIBarButtonItem(UIBarButtonSystemItem.Search)
            {
                Action = item.Action,
                Target = item.Target
            };
            rightList.Add(newItem);
        }
        else
        {
            rightList.Add(item);
        }
    }
    if (rightList.Count > 0)
    {
        this.NavigationController.TopViewController.NavigationItem.RightBarButtonItems = rightList.ToArray();
    }
}
We override the OnElementChanged method, which is defined in the parent class. This is called when the ContentPage is created or changed. We use this method to call our CreateNativeToolbarItems method. After checking that the NavigationController and toolbar pieces exist, we cycle through the toolbar buttons that have been created. If the title is set to “search,” which we did in the xaml code by setting the text property, we create a new UIBarButtonItem. This bar button is the system search icon and we put it into our RightBarButtonItems array instead of the button that was created by the XAML.
Run the project on iOS and you will find a system search icon nestled on the right side of the toolbar. Good job!
Toolbar Action
It’s not necessary, but we might as well have something happen when we press the toolbar button. Go back to MainPage.xaml, and add the following property to our ToolbarItem.
Clicked=“SearchButton_Clicked”
We will also add a label to be manipulated when the button is pressed. Below the ToolbarItems code, add the following.

    
        
    

Now, let’s go to the MainPage.xaml.cs file to define the click method. Add the following.
private void SearchButton_Clicked(object sender, EventArgs e)
{
    if (SearchLabel.TextColor == Color.Black)
    {
        SearchLabel.TextColor = Color.Green;
    }
    else
    {
        SearchLabel.TextColor = Color.Black;
    }
}
This code will change the color of the label on the middle of the screen each time you click the search icon. Run the code and watch it in action. The label changes to black, then green, then black again on subsequent clicks.
Conclusion
Great job! In this tutorial, we put a toolbar item on a page in Xamarin.Forms. For Android, we used icons from material.io, sized them properly, and added them to our project. For iOS, we used a custom renderer to display system icons in the project. Even though we are using Xamarin.Forms, we were able to display a completely native look on each device. Feel free to further extend our iOS custom renderer to have left side toolbar buttons, different colored toolbar buttons, or anything else you can think of. As always, thanks for reading the HangZone blog.
The post Custom Renderers in Xamarin.Forms Part 1 appeared first on HangZone.



How to Fetch Stock and Currency Quotes for iPhone
Tyler Bandy — Fri, 30 Aug 2019 21:01:41 +0000
When I’m not writing apps, I like to follow stocks. I’ve even had the opportunity to combine those interests in the past with quantitative trading strategies. We’ll keep things simple today and just query stock and currency quotes from our iPhone.
Get an Alpha Vantage API Key
There are a lot of financial datasources, and many of them cost a good bit of money. That’s no surprise considering the massive budgets successful hedge funds have to spend on these products. Yahoo Finance was traditionally the most popular free source for stock price data, but that’s no longer an option. Fortunately, other free alternatives have emerged to fill the void.
Today, we’ll use Alpha Vantage. They have realtime and historical data for stocks and currencies, including cryptos. The assortment of technical indicator data is also quite robust. Head on over there and get a free API key, and let’s get started.
Create an Xcode Project
Open up Xcode and create a new tabbed app. Call the app Quotes, and set the language as Swift. Open up Main.Storyboard. You should see a tab bar controller and two view controllers. We’ll use one view controller for stocks and the other for currency.
Stock Storyboard
The first controller will be for getting stock quotes. In fact, we actually want more than just the current price of the stock. We’d like all sorts of valuable peripherals. You can see I’ve added quite a few labels on my storyboard to cover all the data.

To recap, the fields are Symbol, Open, High, Low, Price, Volume, Latest Trading Day, Previous Close, Change, and Change Percent. With that in mind, go ahead and drag 20 labels onto your storyboard, positioned in 2 columns of 10. The left column has the field names, and the right column has the values. You won’t actually see those filler names for the values in the app. That’s just for readability in the storyboard. We’ll clear them in the code. Now embed each column of labels into a stack view. Then you can use constraints to get the left stack view away from the top and left edges of the device. Center the right stack view vertically with the left one, and use a standard amount of leading space.
At the bottom of the view controller, I added an instructional label (“Enter Stock Ticker”), a text field, and a search button. They’re all centered horizontally with about 40 vertical spacing between each object. Remember to set your text field to capitalize all characters and not autocorrect anything. That’s important for dealing with stock tickers. You can set those properties in the attributes inspector.
Once you’ve finished with the objects and constraints, tap the tab bar item at the bottom of the view controller, and go to the attributes inspector. Change its title to “Stocks”. That takes care of this view controller on the storyboard!
Currency Storyboard
The currency view controller is laid out basically the same way, only it has fewer fields. We only need pairs of labels for the following: Currency Code, Currency Name, Exchange Rate, Last Refreshed, Bid, and Ask. Here’s a picture for reference.

The instructional label should say “Enter Currency Code”. The tab bar title will say “Currency”.
Linking Storyboard
There are quite a few labels to link from out storyboard to the code. Let’s get started. Hook-up the following IBOutlets using the value labels in our stock view controller. These will all link to the code in FirstViewController. Please note that these are from the value column on the right. We don’t need to hook-up the labels on the left.
@IBOutlet weak var stockSymbolLabel: UILabel
@IBOutlet weak var stockOpenLabel: UILabel!
@IBOutlet weak var stockHighLabel: UILabel!
@IBOutlet weak var stockLowLabel: UILabel!
@IBOutlet weak var stockPriceLabel: UILabel!
@IBOutlet weak var stockVolumeLabel: UILabel!
@IBOutlet weak var stockLastTradingDayLabel: UILabel!
@IBOutlet weak var stockPreviousCloseLabel: UILabel!
@IBOutlet weak var stockChangeLabel: UILabel!
@IBOutlet weak var stockChangePercentLabel: UILabel!

While we’re here, let’s do the text field as well.
@IBOutlet weak var stockTextField: UITextField!

We need to link the button too, but this one is an IBAction.
@IBAction func stockSearchTapped(_ sender: Any) {

}

The pattern is similar for the currency view controller. These storyboard objects will link with SecondViewController.
@IBOutlet weak var currencyCodeLabel: UILabel!
@IBOutlet weak var currencyNameLabel: UILabel!
@IBOutlet weak var currencyExchangeRateLabel: UILabel!
@IBOutlet weak var currencyLastRefreshedLabel: UILabel!
@IBOutlet weak var currencyBidValue: UILabel!
@IBOutlet weak var currencyAskValue: UILabel!
@IBOutlet weak var currencyTextField: UITextField!
@IBAction func currencySearchButtonTapped(_ sender: Any) {

}

Query a Stock Quote
In FirstViewController, we’ll add a function to query the stock data.
func getStockQuote() {
    let session = URLSession.shared
    
    let quoteURL = URL(string: "https://www.alphavantage.co/query?function=GLOBAL_QUOTE&symbol=\(stockTextField.text ?? "")&apikey=APIKEY")!
    
    let dataTask = session.dataTask(with: quoteURL) {
        (data: Data?, response: URLResponse?, error: Error?) in
        
        if let error = error {
            print("Error:\n\(error)")
        } else {
            if let data = data {
                
                let dataString = String(data: data, encoding: String.Encoding.utf8)
                print("All the quote data:\n\(dataString!)")
                    
                if let jsonObj = try? JSONSerialization.jsonObject(with: data, options: .allowFragments) as? NSDictionary {
                        
                    if let quoteDictionary = jsonObj.value(forKey: "Global Quote") as? NSDictionary {
                        DispatchQueue.main.async {
                            if let symbol = quoteDictionary.value(forKey: "01. symbol") {
                                self.stockSymbolLabel.text = symbol as? String
                            }
                            if let open = quoteDictionary.value(forKey: "02. open") {
                                self.stockOpenLabel.text = open as? String
                            }
                            if let high = quoteDictionary.value(forKey: "03. high") {
                                self.stockHighLabel.text = high as? String
                            }
                            if let low = quoteDictionary.value(forKey: "04. low") {
                                self.stockLowLabel.text = low as? String
                            }
                            if let price = quoteDictionary.value(forKey: "05. price") {
                                self.stockPriceLabel.text = price as? String
                            }
                            if let volume = quoteDictionary.value(forKey: "06. volume") {
                                self.stockVolumeLabel.text = volume as? String
                            }
                            if let latest = quoteDictionary.value(forKey: "07. latest trading day") {
                                self.stockLastTradingDayLabel.text = latest as? String
                            }
                            if let previous = quoteDictionary.value(forKey: "08. previous close") {
                                self.stockPreviousCloseLabel.text = previous as? String
                            }
                            if let change = quoteDictionary.value(forKey: "09. change") {
                                self.stockChangeLabel.text = change as? String
                            }
                            if let changePercent = quoteDictionary.value(forKey: "10. change percent") {
                                self.stockChangePercentLabel.text = changePercent as? String
                            }
                        }
                    } else {
                        print("Error: unable to find quote")
                        DispatchQueue.main.async {
                            self.resetLabels()
                        }
                    }
                } else {
                    print("Error: unable to convert json data")
                    DispatchQueue.main.async {
                        self.resetLabels()
                    }
                }
            } else {
                print("Error: did not receive data")
                DispatchQueue.main.async {
                    self.resetLabels()
                }
            }
        }
    }
    
    dataTask.resume()
}

Most of this is UI code to update the labels, so don’t get too intimidated by the length. Let’s start at the top and make some sense of this. The URLSession and dataTask code launch the API call. Our API call is spelled out in quoteURL constant. There are 3 properties that we are passing to the server. The first is the function name, “GLOBAL_QUOTE”. This is Alpha Vantage’s function for getting stock quotes. The second is the symbol. We’re passing in whatever text the user has entered in the text field. The last parameter is the API key. In the code above, I set the API key equal to “APIKEY”. Put your own API key into your code.
All of this effort nets us a JSON package full of data for our requested stock ticker. We’ll convert that JSON into a dictionary. I’ve included a print to the console which helps you visualize the dictionary data. It’s basically a dictionary with one key, “Global Quote”. The value for that key is another dictionary, this time with keys “01. symbol”, “02. open”, “03. high”, “04. low”, etc. There’s one key for each piece of data we’d like. Our code simply checks each of these keys for a value and updates our labels. If there’s an error for whatever reason, most likely due to entering an invalid ticker, we log the error to the console and reset the labels. For a production app, you should show the user some sort of error, but this will be fine for a tutorial.
Query a Currency Exchange Rate
In SecondViewController, we need a similar function to query currency. Here it is.
func getCurrencyQuote() {
    let session = URLSession.shared
    
    let quoteURL = URL(string: "https://www.alphavantage.co/query?function=CURRENCY_EXCHANGE_RATE&from_currency=\(currencyTextField.text ?? "")&to_currency=USD&apikey=APIKEY")!
    
    let dataTask = session.dataTask(with: quoteURL) {
        (data: Data?, response: URLResponse?, error: Error?) in
        
        if let error = error {
            print("Error:\n\(error)")
        } else {
            if let data = data {
                
                let dataString = String(data: data, encoding: String.Encoding.utf8)
                print("All the quote data:\n\(dataString!)")
                
                if let jsonObj = try? JSONSerialization.jsonObject(with: data, options: .allowFragments) as? NSDictionary {
                    
                    if let quoteDictionary = jsonObj.value(forKey: "Realtime Currency Exchange Rate") as? NSDictionary {
                        DispatchQueue.main.async {
                            if let code = quoteDictionary.value(forKey: "1. From_Currency Code") {
                                self.currencyCodeLabel.text = code as? String
                            }
                            if let name = quoteDictionary.value(forKey: "2. From_Currency Name") {
                                self.currencyNameLabel.text = name as? String
                            }
                            if let rate = quoteDictionary.value(forKey: "5. Exchange Rate") {
                                self.currencyExchangeRateLabel.text = "$\(rate)"
                            }
                            if let date = quoteDictionary.value(forKey: "6. Last Refreshed") {
                                self.currencyLastRefreshedLabel.text = date as? String
                            }
                            if let bid = quoteDictionary.value(forKey: "8. Bid Price") {
                                self.currencyBidValue.text = "$\(bid)"
                            }
                            if let ask = quoteDictionary.value(forKey: "9. Ask Price") {
                                self.currencyAskValue.text = "$\(ask)"
                            }
                        }
                    } else {
                        print("Error: unable to find quote")
                        DispatchQueue.main.async {
                            self.resetLabels()
                        }
                    }
                } else {
                    print("Error: unable to convert json data")
                    DispatchQueue.main.async {
                        self.resetLabels()
                    }
                }
            } else {
                print("Error: did not receive data")
                DispatchQueue.main.async {
                    self.resetLabels()
                }
            }
        }
    }
    
    dataTask.resume()
}

This is very similar, so I’ll only touch on the differences. The quoteURL calls a different function, “CURRENCY_EXCHANGE_RATE”. In addition to the Api key, there are parameters for “from_currency” and “to_currency”. I’m only interested in converting to US dollars, so I hardcoded “USD” as the “to_currency”. The “from_currency” is pulled from our text field. Once we get our data, we unpackage the JSON and update our labels. We don’t need to use all of the data this time, mostly since we’re using a fixed “to_currency”.
Finishing up the Code
The query code was the heavy lifting. We just need to make everything works gracefully now. It’s time to implement the resetLabels function that we called in case of an error. Here it is for FirstViewController.
func resetLabels() {
    stockSymbolLabel.text = "";
    stockOpenLabel.text = "";
    stockHighLabel.text = "";
    stockLowLabel.text = "";
    stockPriceLabel.text = "";
    stockVolumeLabel.text = "";
    stockLastTradingDayLabel.text = "";
    stockPreviousCloseLabel.text = "";
    stockChangeLabel.text = "";
    stockChangePercentLabel.text = "";
}

Now go to SecondViewController and add the equivalent code.
func resetLabels() {
    currencyCodeLabel.text = "";
    currencyNameLabel.text = "";
    currencyExchangeRateLabel.text = "";
    currencyLastRefreshedLabel.text = "";
    currencyBidValue.text = "";
    currencyAskValue.text = "";
}

We also need some code to make sure the keyboard dismisses appropriately and shifts the screen up so we can view what we’re typing. Make sure both of our view controllers are UITextFieldDelegates by adding UITextFieldDelegate at the top of the class.
class FirstViewController: UIViewController, UITextFieldDelegate {

Here’s the other one.
class SecondViewController: UIViewController, UITextFieldDelegate {

Put these keyboard functions in both view controllers.
@objc func dismissKeyboard() {
    //Causes the view (or one of its embedded text fields) to resign the first responder status.
    view.endEditing(true)
}

@objc func keyboardWillShow(notification: NSNotification) {
    if let keyboardSize = (notification.userInfo?[UIResponder.keyboardFrameBeginUserInfoKey] as? NSValue)?.cgRectValue {
        if self.view.frame.origin.y == 0 {
            self.view.frame.origin.y -= keyboardSize.height
        }
    }
}

@objc func keyboardWillHide(notification: NSNotification) {
    if self.view.frame.origin.y != 0 {
        self.view.frame.origin.y = 0
    }
}

We need to set up notifications for these functions in viewDidLoad and establish each class as its text field’s delegate. This is also a good chance to clear out the placeholder text in our value labels. Here’s the entirety of viewDidLoad for the stock view controller.
override func viewDidLoad() {
    super.viewDidLoad()
    // Do any additional setup after loading the view.
    resetLabels()
    
    self.stockTextField.delegate = self
    
    let tap: UITapGestureRecognizer = UITapGestureRecognizer(target: self, action: #selector(UIInputViewController.dismissKeyboard))
    view.addGestureRecognizer(tap)
    NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillShow), name: UIResponder.keyboardWillShowNotification, object: nil)
    NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillHide), name: UIResponder.keyboardWillHideNotification, object: nil)
}

Click on over to the currency view controller to do something similar.
override func viewDidLoad() {
    super.viewDidLoad()
    // Do any additional setup after loading the view.
    resetLabels()
        
    self.currencyTextField.delegate = self
        
    let tap: UITapGestureRecognizer = UITapGestureRecognizer(target: self, action: #selector(UIInputViewController.dismissKeyboard))
    view.addGestureRecognizer(tap)
    NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillShow), name: UIResponder.keyboardWillShowNotification, object: nil)
    NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillHide), name: UIResponder.keyboardWillHideNotification, object: nil)
}

We’d like to fire off queries from either tapping the search button or hitting return on the keyboard. We’ll handle the former by filling out our IBAction functions and the latter is a delegate method for the keyboard. Here’s the code for the stock view controller.
@IBAction func stockSearchTapped(_ sender: Any) {
    getStockQuote()
    dismissKeyboard()
}

func textFieldShouldReturn(_ textField: UITextField) -> Bool {
    getStockQuote()
    self.view.endEditing(true)
    return false
}

Here’s the equivalent code for the currency.

@IBAction func currencySearchButtonTapped(_ sender: Any) {
    getCurrencyQuote()
    dismissKeyboard()
}

func textFieldShouldReturn(_ textField: UITextField) -> Bool {
    getCurrencyQuote()
    self.view.endEditing(true)
    return false
}

That should cover everything! Run the app and check your favorite stock. Check your least favorite stock. How about a currency? Remember to use codes for the currency, like EUR for euro or JPY for yen. You can even do digital currencies likes BTC for bitcoin.

Conclusion
We’re just scratching the surface of investment app possibilities. You can fetch all sorts of historical data and technical indicators. Take a look around the documentation at Alpha Vantage and see if anything catches your eye. If you see something you like, just amend the quoteURL in your code and do a test run to see what sort of data you get back. Once you’ve had a look at the structure of the data, you can figure out what keys to use to unpack the dictionaries. Good luck and thanks for reading the HangZone blog!
The post How to Fetch Stock and Currency Quotes for iPhone appeared first on HangZone.



How to Add Core Location to our Weather App
Tyler Bandy — Tue, 28 May 2019 14:35:27 +0000
It’s been over a year since we tackled weather on the HangZone blog. Longtime readers may recall our original weather app tutorial, followed by our five day forecast tutorial. In those apps, we called the OpenWeatherMap API to get the weather information for our city. Next, we unpacked the JSON results to display the appropriate information on the screen. The end result works…but there’s a catch.
Since we hard-coded a specific city into our API call, the data is only useful if we’re in the right city. If you tend to stay in the same place, no problem! You don’t need to worry about this. Perhaps you find yourself traveling around a bit though. Maybe you’ve even moved to a new city since you originally built your own weather app. Wouldn’t it be nice if your app just automatically detected your location?
Today we’ll use Apple’s Core Location framework to upgrade our 5 day forecast app to automatically query results for the user’s location. Go make a copy of your old weather project, and fire up Xcode.
Choose the Right Level of Privacy
In order to track a user’s location automatically, we first have to convince the user to grant our app permission to do so. These days, users are more concerned about privacy than ever, so they don’t want to give apps more information than absolutely necessary. Furthermore, location tracking can drain your iPhone’s battery relatively quickly if you use it constantly. Consequently, users are all the more reluctant to enable location tracking.
Fortunately, Apple has multiple degrees of location tracking that apps can use. Although this can make things more confusing for the developer, the upside is that users shouldn’t have to grant excessive tracking abilities to apps that don’t need them.
For our purposes, When-in-use authorization will suit our needs perfectly, plus it’s more efficient than Always authorization. The names are fairly self-explanatory. The primary difference is that Always authorization can continue to track location data while the app is in the background. Each authorization level supports various Core Location services. Always authorization does support more services, but When-in-use authorization covers the Standard Location Service that we’ll need for this app.
Set-up info.plist for Core Location
Now that we’ve decided what sort of tracking we want to do, it’s time to set-up our Core Location code. We’ll start with the info.plist file. In an effort to better educate users on why apps need to infringe on users’ privacy, Apple makes developers offer an explanation for the use of various services, including Core Location.
The key we’re looking for is NSLocationWhenInUseUsageDescription. The more human-readable version of the key displayed in Xcode is Privacy – Location When In Use Usage Description. You can write whatever you want for the description. I used the following.
We need to check your location in order to let you know the weather forecast.

Seems like a reasonable request, right? With that out of the way, let’s write some code!
Request the User’s Location
The first thing we need to do is get the user’s approval to use their location. Normally, it’s best to wait until you absolutely need whatever data you’re requesting before asking the user for it. Again, users are reluctant to allow anything that seems like overreaching, so it’s nice to onboard them in the app a little bit before asking about a tracking service.
Considering this a weather app and tracking is obviously necessary, we’re going to jump the gun and ask for tracking permission immediately. Open ViewController.swift and make our view controller a Core Location Manager Delegate by adjusting the class line at the top.
class ViewController: UIViewController, CLLocationManagerDelegate {

Now we can receive callbacks on Core Location events. Let’s go ahead and define the Location Manager, so we can get some events. Put the following constant just below our IBOutlets.
let locationManager = CLLocationManager()

Now we’ll add some functions to go with it. You can put them anywhere inside the class braces.
func enableBasicLocationServices() {
    locationManager.delegate = self

    switch CLLocationManager.authorizationStatus() {
    case .notDetermined:
        // Request when-in-use authorization initially
        locationManager.requestWhenInUseAuthorization()
        break

    case .restricted, .denied:
        // Disable location features
        clearWeather()
        break

    case .authorizedWhenInUse, .authorizedAlways:
        // Enable location features
        getWeather()
        break
    }
}

func locationManager(_ manager: CLLocationManager,
didChangeAuthorization status: CLAuthorizationStatus) {
    switch status {
    case .notDetermined, .authorizedAlways:
        locationManager.requestWhenInUseAuthorization()
        break

    case .restricted, .denied:
        clearWeather()
        break

    case .authorizedWhenInUse:
        getWeather()
        break
    }
}

We’ll call our enableBasicLocationServices function manually to get the user’s tracking permission. If we haven’t asked the user before, they’ll get a prompt with our request. Otherwise, we’ll use their previous answer. If they allow us to get their location, we’ll get the weather. Otherwise, we’ll call a new function—clearWeather. We also have a similar switch statement in our locationManagerDidChangeAuthorization function. Users are capable of changing authorization whenever they want through settings, so we have to adjust accordingly.
Go ahead and define clearWeather.
func clearWeather() {
    self.weatherLabel1.text = "Day 1: ?"
    self.weatherLabel2.text = "Day 2: ?"
    self.weatherLabel3.text = "Day 3: ?"
    self.weatherLabel4.text = "Day 4: ?"
    self.weatherLabel5.text = "Day 5: ?"
}

Five question marks is about the best we can do for a forecast if they won’t give us a location! Now replace the call to getWeather in viewDidLoad with a call to enableBasicLocationServices.
override func viewDidLoad() {
    super.viewDidLoad()

    // Do any additional setup after loading the view, typically from a nib.
    enableBasicLocationServices()
}

That will set cogs in motion!
Interpret the Location
Assuming the user approves location tracking, we still need to get their location and pass it into the OpeanWeatherMap API. Our previous API call used a city name, but we can also use latitude and longitude coordinates. That’s more convenient and precise since we have them readily available with Core Location. Our getWeather function will look the same, other than we now get our weatherURL in the following manner.
var currentLocation: CLLocation!

if( CLLocationManager.authorizationStatus() == .authorizedWhenInUse || CLLocationManager.authorizationStatus() == .authorizedAlways){

    currentLocation = locationManager.location

} else {
    clearWeather()
    return
}

let latitude = currentLocation.coordinate.latitude
let longitude = currentLocation.coordinate.longitude

let session = URLSession.shared

let weatherURL = URL(string: “http://api.openweathermap.org/data/2.5/forecast?lat=\(latitude)&lon=\(longitude)&units=imperial&APPID=XXX")!

The coordinate property on currentLocation is an optional, so I put in one more check to make sure the user has granted proper authorization. This also covers us if the user reloads the forecast with the onscreen button, which currently calls getWeather without checking on the Core Location authorization. Latitude and longitude are available off the coordinate property, and then all we do is plug them into our slightly modified API string. I replaced my API key with XXX. Use whatever your API key is, just as in the previous iterations of this app.
Run the app and see what happens!

Did your message from earlier convince you to grant yourself tracking privileges? I hope so! Try driving a few states over and reloading the data. Pretty nifty, right!
Conclusion
This is just a taste of what you can do with Core Location, but it’s a very practical taste and often all you need. Our weather app is moving on up in the world. Maybe we’ll add another feature to it next year! Until next time, have fun thinking of the crazy things you can do with Core Location’s Always authorization!
The post How to Add Core Location to our Weather App appeared first on HangZone.



How to Transfer Data More Efficiently with DTOs
Tyler Bandy — Mon, 29 Apr 2019 13:53:29 +0000
Let’s say you’re building an application with a SQL database stored in the cloud. You’ve written a web API which you can call from you app to interact with the database. As you start to populate your database with test data, you realize your queries aren’t processing as fast as you like. You go to check out your database metrics and you realize the amount of data transferred out of the database is much higher than you expected. Not only is this slow—it’s going to get expensive! This can be a scary experience, but fear not! There may be multiple problems in play, but we can (hopefully) remedy most of them with data transfer objects (DTOs).
What’s Causing the Problem
If your outgoing data is is dramatically more than you expected, you should stop and consider what exactly your queries are returning. Imagine a database with two tables: Customers and Orders. The corresponding classes look like this (we’ll use C# today):
public class Customer
{
    public Customer() { }

    public int ID { get; set; }

    public string FirstName { get; set; }

    public string LastName { get; set; }

    public string Address { get; set; }

    public string City { get; set; }

    public string State { get; set; }

    public string ZipCode { get; set; }

    public string Phone { get; set; }

    public string Email { get; set; }
}

public class Order
{
    public Order() { }

    public int ID { get; set; }

    public int CustomerID { get; set; }

    public DateTime Date { get; set; }

    public decimal Cost { get; set; }
}

The Customer class holds several pieces of information about each customer. Whenever a customer places an order, we get a new Order object that has some information about the order. Among the information stored in each Order is a CustomerID foreign key, which we can use to get the related customer information for that order.
After storing some data, we might like to query all of the Orders. Let’s say we want to display them in a table that includes a Customer Name column. Unfortunately, we don’t have the customer’s name stored directly in the Order model. In addition to querying the Orders, we’ll also have to query the Customer table for the CustomerIDs found on our Orders.
If you’re using an Object Relational Mapper (ORM) like Entity Framework to execute your database actions, you’ll probably use a navigation property to get the extra Customer information. You just add a new Customer property on the Order model with the following format.
public class Order
{
    public Order() { }

    public int ID { get; set; }

    public int CustomerID { get; set; }

    public Customer Customer { get; set; }

    public DateTime Date { get; set; }

    public decimal Cost { get; set; }
}

The Customer property isn’t stored in the database as a field on Order. It’s merely added to the Order object if you choose to include it as part of your query. If you’re using Entity Framework, the code in your web API might look like this.
return await _db.Orders
    .Include(Order => Order.Customer)
    .AsNoTracking()
    .ToListAsync();

Now if we want to get the customer’s name off of the order, we can easily get it as follows.
string customerName = order.Customer.FirstName + " " + order.Customer.LastName;

That’s all good and well. It works. It’s just really inefficient. We’re returning all sorts of address and contract information for the customer on each Order object that we don’t need. If a customer has multiple orders, we’re returning all of that excess information multiple times!
This example only has one include, but things can get much worse if you layer more includes on top of includes. It’s time to rethink this approach with DTOs.
What’s a DTO?
Data Transfer Objects—DTOs for short—are objects that are optimized for sending information efficiently over the wire. Essentially, they cut out extra information. Your web API grabs the regular objects that you know and love out of the database. Before it sends them to your local application, the web api converts the objects to DTOs. Once your local application receives the DTOs, it converts the objects into a suitable format for display within the project’s UI.
This final UI form of the object may resemble the original model you got out of the database before the DTO conversion. It might also have some extra business logic on it. There are some people with very strong opinions about the stylebook surrounding DTO conversions, but there isn’t a definitive answer here. As long as the DTO carries an efficient amount of information and doesn’t have business logic, we’re doing just fine.
Implementing a DTO solution
Let’s return to our Customer and Order models. In order to avoid returning an entire Customer object along with each Order object, let’s write an OrderDTO model.
public class OrderDTO
{
    public OrderDTO() { }

    public int ID { get; set; }

    public int CustomerID { get; set; }

    public string CustomerName { get; set; }

    public DateTime Date { get; set; }

    public decimal Cost { get; set; }

    OrderDTO(Order model)
    {
        ID = model.ID,
        CustomerID = model.CustomerID,
        Date = model.Date,
        Cost = model.Cost,
        CustomerName = model.Customer.FirstName + model.Customer.LastName;
    }
}

Notice that this model only has a string for CustomerName instead of an entire Customer property. We’ve also added a constructor to convert our Orders to OrderDTOs. Let’s see how that works with an Entity Framework call on the web API with orders of $100 or more.
return await _db.Orders
    .Include(Order => Order.Customer)
    .AsNoTracking()
    .Where(Order => Order.Cost >= 100)
    .Select(Order => new OrderDTO(Order))
    .ToListAsync();

We still do the same include as last time, so our initial Order object does have an entire Customer property on it. This version adds the conversion before we return the list, however, which flattens out our Orders to more efficient OrderDTOs. When we receive the OrderDTOs, we can go to town with them however we see fit. If we have a different Order model we want to use for the UI, we just write a constructor in our UI version of the model to convert the DTOs. We can even use the DTOs directly in the UI if we’re not worried about some stylebook vigilantes raising an eyebrow!
Conclusion
It’s easy to get carried away with queries that start compounding more queries and returning gigantic objects. These are the sort of situations where sending DTOs can be literally thousands of times more efficient from a data transfer standpoint than sending the original objects. I’ve primarily focused on flattening data with DTOs, but they’re also used for combining data into a single object that would otherwise require querying your API multiple times, effectively eliminating some roundtrips. Be creative. The fewer calls made and less data transferred, the better your app will perform!
The post How to Transfer Data More Efficiently with DTOs appeared first on HangZone.



How to Make Your First Apple TV App
Tyler Bandy — Fri, 29 Mar 2019 13:20:09 +0000
We’ve written extensively on iPhone and iPad development in the past, but never covered the Apple TV. As you may know, you can mirror the screen of your iPhone or iPad onto your television using Apple TV. That’s a cool way to get your app on the big screen, but what if you want to build something native for Apple TV?  After all, the Apple TV 4K and Apple TV 4th generation have that fancy Siri Remote that would be fun to utilize. Today, we’ll start with the obligatory Hello World app, and highlight how to program for Apple TV’s unique control scheme.
Initial Set-up
I’m going to use an Apple TV 4K with Siri Remote for this tutorial. Fire up Xcode and select tvOS from the template categories. We’ll do a Single View App to keep things simple. I’m calling my project HelloAppleTV. Let’s use Swift for the language. Save the project wherever you like. You’ll see a familiar file structure on your left, similar to a typical iOS project. This is promising!
The next step is to hook up your Apple TV to your Mac so you can deploy apps to a real device. You’ll notice our only deployment options right now are simulators. This step is marginally trickier than hooking up your mobile devices since we can’t use a cable. First, turn on your Apple TV. Open the Settings app, choose Remotes and Devices, then drill down into Remote App and Devices. In Xcode, click the Window drop-down menu, and select Devices and Simulators. Assuming your devices are close enough, you’ll see a prompt on your Mac to pair your Apple TV. Click the pair button and enter the code displayed on your television. Your Mac now knows about your Apple TV!
Go ahead and close the Devices and Simulators window. In addition to the default simulators you can now select your actual Apple TV. Nice work! Let’s code something to celebrate.
Hello World App
Despite today’s contentious political climate, at least we can all agree that your first app on a new platform is supposed to display “Hello World”. Head over to Main.Storyboard, and you’ll find a blank view. This is basically the same thing you would expect in an iOS storyboard, only this view is shaped like a TV screen. Click the Library button to reveal the list of objects we can use. Drag a label out to the middle of the screen and write “Hello World”.
Sounds like a complete app to me. Go ahead and run the project. Xcode will give you some prompts about registering the Apple TV as a development device, assuming this is your first time using it. Fortunately, Xcode is good about handling these sort of things automatically now. Did you get the classic “Hello World” in black against a white background? Excellent. Time to try some more unique features of the platform. 
Add Some Buttons
Normally, you physically tap buttons on an iPhone or iPad. That’s not an option on the TV, so let’s see for ourselves how this activity is handled by default. Add two buttons below your label. For this exercise, you can place them however you like. I placed them at the bottom of the screen, aligned horizontally with each other. I embedded them in a horizontal stack view, then used constraints to center the stack view horizontally and give it standard spacing relative to the bottom of the screen. I also used a constraint to make the buttons’ widths equal to each other. To round off the constraints, I went back and centered our “Hello World” label for good measure. In the left button, I set the text to Background. The right one says Text. My storyboard looks like this.

Now open up Assistant Editor mode, and link your label to ViewController.swift as helloWorldLabel. Link the buttons as actions—backgroundButtonTapped and textButtonTapped. Just use the default options when setting the outlet and actions.
We want to make the background button toggle the background’s color, while the text button toggles the text’s color. Inside backgroundButtonTapped, add the following code.
let colorIndex = Int.random(in: 0 ... 5)

switch colorIndex {
    case 0:
        view.backgroundColor = UIColor.red;
    case 1:
        view.backgroundColor = UIColor.blue;
    case 2:
        view.backgroundColor = UIColor.yellow;
    case 3:
        view.backgroundColor = UIColor.green;
    case 4:
        view.backgroundColor = UIColor.orange;
    case 5:
        view.backgroundColor = UIColor.purple;
    default:
        view.backgroundColor = UIColor.white;
}

Clicking the button will give us one of 6 random colors for the background. Let’s do something similar inside textButtonTapped.
let colorIndex = Int.random(in: 0 ... 5)

switch colorIndex {
    case 0:
        helloWorldLabel.textColor = UIColor.red;
    case 1:
        helloWorldLabel.textColor = UIColor.blue;
    case 2:
        helloWorldLabel.textColor = UIColor.yellow;
    case 3:
        helloWorldLabel.textColor = UIColor.green;
    case 4:
        helloWorldLabel.textColor = UIColor.orange;
    case 5:
        helloWorldLabel.textColor = UIColor.purple;
    default:
        helloWorldLabel.textColor = UIColor.black;
}

Give the app a run. You’ll find the you can shift your focus from one button to the other by sliding your thumb left and right on the the remote’s Touch Surface. You can then tap the Touch Surface to press the button. Perhaps you’ll also find that the blue background with the green text looks pretty nice! 
Gesture Recognizers
You’ve got a good feel for the basic user interaction now. Sliding around the focus and tapping buttons is the key to most menus. That Siri Remote has some other buttons on it though. We should make them do something in our app! If we want to harness the action of the Play/Pause button, we can use a tap gesture recognizer.
Add some tap gesture recognizer code in viewDidLoad inside your ViewController.swift file.
let tapRecognizer = UITapGestureRecognizer(target: self, action: #selector(tapped))
tapRecognizer.allowedPressTypes = [NSNumber(value: UIPress.PressType.playPause.rawValue)];
self.view.addGestureRecognizer(tapRecognizer)

Now we need to define the function tapped down at the bottom of ViewController.swift.
@objc func tapped(gestureRecognizer: UITapGestureRecognizer) {
    view.backgroundColor = UIColor.white;
    helloWorldLabel.textColor = UIColor.black;
}

Whenever the user taps the Play/Pause button, we will reset the background to white and the text to black. Run the app and give it a try!
Conclusion
Today we made a Hello World app for Apple TV and learned how to handle basic user interaction. Most of the tools available to you in iOS are also available in tvOS. Now that we’ve demystified the user interaction a bit, you should be off to the races! Look out for more Apple TV tutorials in the future. Until then, thanks for reading the HangZone blog!
The post How to Make Your First Apple TV App appeared first on HangZone.



Data Binding and Model-View-ViewModel in UWP Part 2
Judson Bandy — Thu, 28 Feb 2019 16:18:48 +0000
This tutorial starts where Part 1 leaves off. If you haven’t read it, you can find it here.
As a quick refresher, we are creating an application that highlights data binding and the MVVM architectural design pattern in UWP. There is a clear separation of concerns in our code, and data binding is used for the UI to communicate with the data. So far, we have created a model, view, and viewmodel. We will continue to add code (including data binding code) to each of these classes to achieve our desired functionality. Remember, we have a one page application with two pivots. The “All Foods” pivot allows you to select your favorite foods from a list of all foods. The “Favorite Foods” pivot will then show a list of your favorite foods. Let’s jump back in by finishing up our view!
Finishing our View
Now that we have collections to work with in the viewmodel and some data, let’s go back and complete our view. If you remember, we laid out a simple structure, but we need to finish our pivot sections for all foods and favorite foods.
First, we need to go to the code-behind file of the view to add our viewmodel as the data context for the view. At the top of the FoodView.xaml.cs file, add “using MyFavoriteFoods.ViewModel.”
Next, we will add the viewmodel as an instance variable, and set it as the datacontext in the constructor.
public FoodViewModel ViewModel { get; set; } = new FoodViewModel();

public FoodView()
{
    DataContext = ViewModel;
    this.InitializeComponent();
}
Now, back to the .xaml file. We first choose a control that includes ItemTemplate to be used to display the data. ListView, GridView, ListBox, and ItemsControl are all potential options. I will use ItemsControl since it does less manipulation to the view than the other options (no highlighting, selecting, etc). Inside ItemTemplate, we will have a DataTemplate that defines the datatype and the UI layout for each instance of the object. We are using data templates of type FoodModel so we need to add our model namespace to the definitions. In the definitions at the top, add:
xmlns:models=“using:MyFavoriteFoods.Model”
Now, fill in the pivot items as follows.

    
        
            
                
                    
                  
            
        
    


    
        
            
                
                    
                        
                        
                    
                    
                    
                
            
        
    

Explanation of Data Binding Code
You will notice that on the data binding for the ItemsControl.ItemSource in the favorite foods section, we used “Mode=OneWay.” Also, for the toggle switch in the all foods section, we used “Mode=TwoWay.” There are three different modes for binding: one time (the default if not specified), one way, and two way. For one way, the view reads the property when the view is created and uses that value going forward. With one way, the view will update its display if the value that it is bound to changes. For two way, the view will update the display if the bound property is changed, like with one way, but it will also update the bound property if the view is manipulated. For instance, if a toggle switch is toggled or a text box changed by the user, the property that is bound to that control will be updated with the information entered by the user.
We need to use one way binding for our favorite foods item source because the bound collection will be modified when we add or remove foods as favorites. The ToggleSwitch.IsOn binding needs two way because the IsFavorite property for the FoodModel object needs to be updated when the user toggles the switch.
Feel free to run the project and take a look at our progress. All of our data and controls should now be displayed correctly. Congratulations! The only problem is that the favorite foods list does not update when the switches are toggled on the all foods pivot.
Using INotifyPropertyChanged
With our two way binding, the IsFavorite property on the corresponding FoodModel object is updated when a switch is toggled. We need to be notified when the property is changed so that we can either add or remove the FoodModel from the favorite foods collection. To do this, we need to implement INotifyPropertyChanged for the IsFavorite property in the FoodModel class. Then, we can add code to the FoodViewModel to execute code whenever the property’s value changes.
Go to FoodModel.cs. Add “using System.ComponentModel” to the class. Now, we are going to change the IsFavorite property so that you can subscribe to be notified when the property changes.
public bool IsFavorite { get; set; }

private bool _isFavorite;
public bool IsFavorite
{
    get { return _isFavorite; }
    set
    {
        _isFavorite = value;
        RaisePropertyChanged(“IsFavorite”);
    }
}

public event PropertyChangedEventHandler PropertyChanged;
protected void RaisePropertyChanged(string name)
{
    if (PropertyChanged != null)
    {
        PropertyChanged(this, new PropertyChangedEventArgs(name));
    }
}
Now, whenever the IsFavorite property is modified, the PropertyChanged event handler is called. This handler will be used to trigger a method to adjust our favorite foods collection in the viewmodel. Let’s go to the FoodViewModel.
Subscribing to Property Changed
We need to subscribe to the PropertyChanged event on each FoodModel in the AllFoods collection so that we can adjust our FavoriteFoods collection. The action is rather simple. First, add “using System.ComponentModel” at the top of the page. In the LoadFoodData method, where we loop through each FoodModel in AllFoods, we add the following line.
foreach(FoodModel eachFood in AllFoods)
{
    eachFood.PropertyChanged += IsFavoritePropertyChanged;
    if (eachFood.IsFavorite)
    {
        FavoriteFoods.Add(eachFood)
   }
}
Now, we define that method to handle the addition or removal of the toggled FoodModel.
public void IsFavoritePropertyChanged(object sender, PropertyChangedEventArgs e)
{
    FoodModel toggledFood = sender as FoodModel;
    if (toggledFood.IsFavorite)
    {
        FavoriteFoods.Add(toggledFood);
    }
    else
    {
        FavoriteFoods.Remove(toggledFood);
    }
}
That’s it. Our code is notified when the IsFavorite property changes for each instance of FoodModel in the viewmodel, and the FavoriteFoods collection is adjusted accordingly. Run the project and see your work in action!

Conclusion
In this project, we used data binding and the Model-View-ViewModel pattern to create an application. Our code is nicely segregated so that the view deals only with UI display and the data and logic are handled in the model and viewmodel. Data binding is done to allow the UI to properly communicate with the data to display proper values and relay any user inputs or changes. We use fairly simple binding concepts in this project, but it is a good introduction to how they work. As always, thanks for reading the HangZone blog!
The post Data Binding and Model-View-ViewModel in UWP Part 2 appeared first on HangZone.



Data Binding and Model-View-ViewModel in UWP Part 1
Judson Bandy — Thu, 31 Jan 2019 17:07:52 +0000
Data Binding is a powerful and important tool in Windows development. Whether targeting UWP, WPF, Xamarin.Forms, or something else, binding is crucial to your app design. The idea of binding is simple. It is used to connect a binding target to a binding source. The binding target is typically the property of a control or some type of UI element. This could be the text of a label, whether a switch is on, or a selection in a combo box. The binding source is a property from another class, usually a viewmodel or model. This is the data that tells the binding target what to display. 
Now, we have a high level understanding of data binding, but why are we using it? The main purpose is to decouple our UI code from our non-UI code. This strategy is utilized in Microsoft’s recommended UI architectural design pattern, Model-View-ViewModel (MVVM), and has a number of benefits. Decoupling different sections of your code creates a separation of concerns. Testing becomes easier since your code is more isolated, different programmers can focus on different parts of the project (front end and back end programmers can simultaneously work on different aspects), and the code is much more maintainable and reusable. 
Model-View-ViewModel
Although somewhat self-explanatory, let’s take a quick look at the 3 layers of the MVVM paradigm. The model is the first layer. This houses all of your software’s business data. Core app logic, class definitions, and data can all typically be found here. The view is the user interface of your project. In UWP, which we are using for this project, this is done with XAML files that define your views and controls. Code-behind files can also be used to further define elements of the view. The viewmodel binds and processes information between the model and view classes. Now that we have a quick idea of the elements of MVVM and data binding, let’s jump into a project and see it in action.
Our Test Project
Let’s quickly lay out what we want to do for our project. We are going to create a UWP application. It is going to be a single page with tabs on it. One tab will have a list of our favorite foods. The other tab will have a list of all included foods with a toggle switch to tag them as a favorite.
The project will need one model class where we will define our food model, one view class where we layout the UI for the page, and one viewmodel class where we get everything to work together. Let’s get started!
Create Our Project
I am going to do this project in Visual Studio on a Windows device targeting UWP. You could easily do this project in Visual Studio for Mac and target Xamarin.Forms, although some of the UI code will be slightly different.
Open Visual Studio and go to File->New->Project… Select Windows Universal in the left pane under Visual C#, and select Blank App (Universal Windows). Feel free to name the app anything you want (I’ll call mine MyFavoriteFoods), and click OK. I’m going to target Windows 10, version 1809 and set the minimum version to Windows 10 Creators Update. Press OK. Our project is now created. 
Start by deleting MainPage.xaml and its code-behind file, MainPage.xaml.cs. I want to create my own view file inside a folder to better delineate the layers of the project. 
Creating our Model
Right click on the MyFavoriteFoods project, and click Add->New Folder. Name the folder “Model” and press enter. Right click your new model folder and select Add->New Item… Select Class and name it FoodModel.cs. Press Add. We will start by just adding the bare bones properties to this class. Make the class public and add properties to make it look like this.
public class FoodModel
{
    public string Name { get; set; }
    public bool IsFavorite { get; set; }
}
You can see, we have a string property for the name of the each food and a bool for whether this is a favorite food or not. Let’s move on to our View.
Creating our View
Create another folder in the project; this time called View. Create a Blank Page inside the folder named FoodView.xaml. 
Before we make any changes on this page, let’s set this new view as our first page for startup. Open the App.xaml.cs file. At the top, add the view namespace: “using MyFavoriteFoods.View”. Then change the following line to set the first page as our new view, FoodView.xaml. 
rootFrame.Navigate(typeof(MainPage), e.Arguments);
rootFrame.Navigate(typeof(FoodView), e.Arguments);
Let’s go back to FoodView.xaml. We’re going to put a large title at the top, and then a pivot to swap between our favorite foods and all foods. Add the following code to the page.

    
        
        
    
    
    
        

        
        

        
    

As you can see, we created two rows inside our grid. The first has an auto height so that it is allocated the amount of space that its contents need. The second row is set to height “*” so that it is allocated the remaining height of the grid. We use a text block in the first row of the grid to set a title of “Food” for the page. We use a pivot in the second row with two pivot items. The first is given a header of “Favorite Foods” and the second is “All Foods.” Feel free to run the project. You will see what we laid out and be able to select the pivots. We still need to fill out their content. Let’s move on to our viewmodel, and then, we will come back to finish the view.
Creating Our ViewModel
We need to create another folder in our project. This one should be called “ViewModels.” Create a new class file inside the folder and call it “FoodViewModel.cs.” This will be the viewmodel for our FoodView class.
Let’s start by creating two instance variables for the class. One will be a list that will house all of the foods that are in our universe. The second will be an ObservableCollection of all of our favorite foods. It is helpful to use an ObservableCollection as the type for our favorite foods because we will be adding and removing foods from this collection. The all foods collection will remain constant as there is currently no way to add new foods while the project is running. The ObservableCollection provides a notification to its binding target when items get added, removed, or when a whole list is refreshed. This is helpful for updating our view as selections get manipulated.
First, we need to add the Model namespace to the class, and another namespace to use ObservableCollection objects. At the top of the page, add the following lines.
using MyFavoriteFoods.Model;
using System.Collection.ObjectModel;
Then, make the class public like this.
public class FoodViewModel
Next, create the instance variables in a manner like this.
public List AllFoods = new List();

public ObservableCollection FavoriteFoods = new ObservableCollection();
ViewModel Methods
Now, we need to load initial data into these collections. This data would normally come from either a local or external server, but that is far beyond the scope of this tutorial. We could create a data section to house this data, as well, but again, the purpose of this is to focus on MVVM and binding. We are simply going to load the data in a method in the viewmodel. This is not typical work for a viewmodel in a larger scale project, and if this project was more than one page, we would certainly want to move the data elsewhere. Let’s add a constructor method for the viewmodel and call another method inside it.
public FoodViewModel()
{
    LoadFoodData();
}
Now, let’s define that method to populate data in the collections.
private void LoadFoodData()
{
    AllFoods.Add(new FoodModel()
    {
        Name = “Apple”,
        IsFavorite = false
    };

    AllFoods.Add(new FoodModel()
    {
        Name = “Banana”,
        IsFavorite = false
    };

    AllFoods.Add(new FoodModel()
    {
        Name = “Pizza”,
        IsFavorite = true
    };

    AllFoods.Add(new FoodModel()
    {
        Name = “Spinach”,
        IsFavorite = false
    };

    AllFoods.Add(new FoodModel()
    {
        Name = “Turnip”,
        IsFavorite = false
    };

}

foreach(FoodModel eachFood in AllFoods)
{
    if (eachFood.IsFavorite)
    {
        FavoriteFoods.Add(eachFood);
    }
}
Conclusion
Now, we have our collections of data defined and available to use. In part 2 of this tutorial, we will bind these collections to their corresponding pivots so that each collection is displayed in the user interface. On the all foods pivot, you will be able to select whether a particular food is one of your favorites. Upon selecting or unselecting a food, the binding change will alert our code to update the collection of favorite foods. We set up a great MVVM structure in part 1, but there is a lot of exciting coding to look forward to in part 2. As always, thanks for reading the HangZone blog!
The post Data Binding and Model-View-ViewModel in UWP Part 1 appeared first on HangZone.

Code Archives - HangZone

How to Make a Location Check-In App in Xamarin.Forms Part One

Let’s Bring it Back

Start a Xamarin Forms Project

Set-up Location Libraries and Permissions

The Interface

The Check-In Code

Hook it Up to the Check-In Button

Prompt the User for Location Permission

Count the Check-ins

Limit Check-In Frequency

Conclusion

Local Security Measures in Xamarin.Forms

Create the Xamarin.Forms Project

Auto Logout When Returning to App

Auto Logout for Inactivity

Android Inactivity

iOS Inactivity

Obscure Information When Looking at Recent Apps

Obscure Display in Android

Obscure Display in iOS App Switcher

Conclusion

Custom Renderers in Xamarin.Forms Part 2

Extending an Element

Create our Custom BoxView

Implementing the GradientBoxView

iOS Custom Renderer

Android Custom Renderer

Conclusion

Custom Renderers in Xamarin.Forms Part 1

Create Xamarin.Forms Project

Toolbar Buttons

Android Toolbar Buttons

Create the Toolbar Item in XAML

iOS Toolbar Button Custom Renderer

Toolbar Action

Conclusion

How to Fetch Stock and Currency Quotes for iPhone

Get an Alpha Vantage API Key

Create an Xcode Project

Stock Storyboard

Currency Storyboard

Linking Storyboard

Query a Stock Quote

Query a Currency Exchange Rate

Finishing up the Code

Conclusion

How to Add Core Location to our Weather App

Choose the Right Level of Privacy

Set-up info.plist for Core Location

Request the User’s Location

Interpret the Location

Conclusion

How to Transfer Data More Efficiently with DTOs

What’s Causing the Problem

What’s a DTO?

Implementing a DTO solution

Conclusion

How to Make Your First Apple TV App

Initial Set-up

Hello World App

Add Some Buttons

Gesture Recognizers

Conclusion

Data Binding and Model-View-ViewModel in UWP Part 2

Finishing our View

Explanation of Data Binding Code

Using INotifyPropertyChanged

Subscribing to Property Changed

Conclusion

Data Binding and Model-View-ViewModel in UWP Part 1

Model-View-ViewModel

Our Test Project

Create Our Project

Creating our Model

Creating our View

Creating Our ViewModel

ViewModel Methods

Conclusion