Android

Xamarin Forms, the MVVMLight Toolkit and I: Dependecy Injection

Xamarin Forms is not always able to call platform specific code without some additional work to do. Thanks to the MVVM pattern, we are already familiar with the solution for this problem: Dependency Injection (DI).

Recap

Let’s just do a small recap what Dependency Injection means. The DI pattern’s main goal is to decouple objects and their dependencies. To separate concerns, we are using this structure nearly every time:

  • interface which defines the provided functionality
  • service class which provides the functionality defined in the interface
  • container that allows client classes/objects to use the functionality defined in the interface

The interface, our helpful dictator

DI always involves an interface, which dictates the functionality of the implementation. In Xamarin Forms, the interface rests inside the PCL/common project:

public interface IOsVersionService
{
    string GetOsVersion { get; } 
}

This interface gets the current installed version of the operating system. The next step ist to create the platform implementation, which is commonly defined as a service class.

Platform Implementation (service class)

We need to implement the service class for each platform. The setup is pretty easy, just add a new class and implement the interface for each platform:

implement-interface-vs2017

Tip: I am using a separate folder for platform implementations and set it to be a namespace provider. This makes it easier to maintain and I keep the same structure in all platform projects.

Let’s have a look into the specific implementations:

Android

public string GetOsVersion
{
    get
    {
        var versionNb = Build.VERSION.Release;
        var codename = Build.VERSION.Codename;
 
        return $"Android {versionNb} ({codename})";
    }
}

iOS

public string GetOsVersion
{
    get
    {
        try
        {
            return $"iOS {UIDevice.CurrentDevice.SystemVersion} ({UIDevice.CurrentDevice.UserInterfaceIdiom})";
 
        }
        catch
        {
            return "This demo supports iOS only for the moment";
        }
    }
}

Windows

public string GetOsVersion
{
    get
    {
        var currentOS = AnalyticsInfo.VersionInfo.DeviceFamily;
 
        var v = ulong.Parse(AnalyticsInfo.VersionInfo.DeviceFamilyVersion);
        var v1 = (v & 0xFFFF000000000000L) >> 48;
        var v2 = (v & 0x0000FFFF00000000L) >> 32;
        var v3 = (v & 0x00000000FFFF0000L) >> 16;
        var v4 = v & 0x000000000000FFFFL;
        var versionNb = $"{v1}.{v2}.{v3}.{v4}";
 
        return $"{currentOS} {versionNb} ({AnalyticsInfo.DeviceForm})";
    }
}

Now that we are able to fetch the OS Version, we need to make the implemation visible outside of the platform assemblies. On Android and iOS, this one is pretty straigt forward by adding this Attribute on top of the class:

[assembly: Xamarin.Forms.Dependency(typeof(OsVersionService))]

Because Universal Windows projects compile differently, we need to go a different route on Windows. To make the implementation visible, we need to explicit declare the class as an assembly to remain included first (otherwise the .NET Toolchain is likely to strip it away):

protected override void OnLaunched(LaunchActivatedEventArgs e)
{
    //other code for initialization, removed for readabilty
 
    //modified for .NET Compile
    List<Assembly> assembliesToInclude = new List<Assembly>();
    assembliesToInclude.Add(typeof(OsVersionService).GetTypeInfo().Assembly);

    Xamarin.Forms.Forms.Init(e, assembliesToInclude); 
}

Now that we have our platform implementations in place, we can go ahead and use the interface to get the OS versions.

Xamarin Forms DependencyService

With the static DependencyService class, Xamarin Forms provides a static container that is able to resolve interfaces to their native platform implementations. Using it is, once again, pretty straight forward:

private string _osVersionViaDs;
public string OsVersionViaDs
{
    get { return _osVersionViaDs; }
    set { Set(ref _osVersionViaDs, value); }
}
 
private RelayCommand _getOSVersionViaDsCommand;
 
public RelayCommand GetOsVersionViaDsCommand => _getOSVersionViaDsCommand ?? (_getOSVersionViaDsCommand = new RelayCommand(() =>
{
    OsVersionViaDs = DependencyService.Get().GetOsVersion; 
}));

In my sample application, I am using a button that fetches the OS version via Xamarin Forms DependencyService and display it into a label in my view.

Special case UWP, once again

To make this acutally work in an UWP application, we need to register the Service manually. Xamarin recommends to do so in the OnLaunched event, after Xamarin Forms is initialized:

//in OnLaunched event (App.xaml.cs)
//manually register for DependencyService 
//AFTER Forms is initialized but BEFORE VMLocator is initialized:
Xamarin.Forms.DependencyService.Register<OsVersionService>();

Only with that extra line of code, it will actually work like it should. If you want to know more on the fact that UWP needs a separate solution, take a look here into the Xamarin docs.

Why use the MVVMLight Toolkit’s Ioc?

There are several reasons. First is of course, purely personal: because I am used to write code for it. But there are also technical reasons:

  • support for cunstroctor injection
  • interface implementations can have parametered constructors
  • MVVMLight supports additional features like named instances and immediate creation on registration
  • in MVVM(Light) applications, you are very likely using DI on Xamarin Forms level, anyway (like in a NavigationService)

You see, there are some (in my opinion) good reasons to use the built in Ioc of the MVVMLight Toolkit.

How to use SimpleIoc and DependencyService together

If you are not relying on the DI-System of Xamarin Forms, you will have to write a lot of code yourself to get the platform implementations. That is not necessary, though. As our ViewModelLocator normally is already part of the Xamarin Forms PCL project, it has access  to the DependencyService and can be used to get the right implementation:

//this one gets the correct service implementation from platform implementation
var osService = DependencyService.Get();
 
// which can be used to register the service class with MVVMLight's Ioc
SimpleIoc.Default.Register<IOsVersionService>(() => osService);

This works pretty well for most implementations and provides us the possibility to use all the features MVVMLight provides. The usage then matches to what we are already familiar with:

private string _osVersionViaSimpleIoc;
public string OsVersionViaSimpleIoc
{
    get { return _osVersionViaSimpleIoc; }
    set { Set(ref _osVersionViaSimpleIoc, value); }
} 
 
private RelayCommand _getOSVersionViaSimpleIocCommand;
 
public RelayCommand GetOsVersionViaSimpleIocCommand => _getOSVersionViaSimpleIocCommand ?? (_getOSVersionViaSimpleIocCommand = new RelayCommand(() =>
{
    OsVersionViaSimpleIoc = SimpleIoc.Default.GetInstance().GetOsVersion; 
}));

If you do not want (or it is not possible due to complexity) register the platform implementation directly in the ViewModelLocator, you  can go down another route. You could create a new interface in the Xamarin Forms PCL which references the interface with the platform implentation as a member. Your implementation of this new interface (in Xamarin Forms) will be responsible for the getting the instance of the platform implementation via the built in DepenencyService.

I already used both ways in my recent Xamarin projects, but I prefer the first way that I described above.

Conclusion

Due to the fact that we know the DI pattern already as we (of course) follow the MVVM pattern in our applications, there is no big mystery about using the built in DependencyService of Xamarin Forms. We can easily integrate it into the MVVMLight Toolkit and combine the best of both worlds this way.

Nonetheless, I know that also some beginners are following my posts, so I tried to describe everything a bit more extended. As always, I hope this post is helpful for some of you. In my next post, I will show you how I solved the Navigation “problem” in my Xamarin Forms applications. In the meantime, you can already have a look at the sample code on Github.

Happy coding, everyone!

Posted by msicc in Android, Dev Stories, iOS, UWP, Xamarin, 3 comments

Xamarin Forms, the MVVMLight Toolkit and I (new series)

Like some of you may have already registered, I have been doing the next step and went cross platform with my personal projects. I am primarily using Xamarin Forms, because I eventually like XAML a little too much. I took a break from round about 2 years on my Xamarin usage, and I am happy to see that it has improved a lot in the meantime. While Xamarin Forms still has room for improvementes, one can do already real and serious projects with it. As I like the lightweight MVVMLight toolkit as much as I like XAML, it was a no-brainer for me to start also my recent Xamarin projects with it.

There is quite some setup stuff to do if you want get everything working from the Xamarin Forms PCL, and this post will be the first in a series to explain the way I am currently using. Some of the things I do may be against good practice for Xamarin Forms, but sometimes one has to break out of them to write code more efficiently and also maintain it easier.

Installing MVVM Light into a Xamarin Forms PCL project

Of course, we will start with a new Xamarin Forms project. After selecting the type Cross Platform App in the New Project Dialog in Visual Studio, you’ll be presented with this screen, which was introduced in the Cycle 9 Release of Xamarin:

Select Xamarin Forms as UI Technology and PCL as Code Sharing Strategy to start the solution creation. As it creates several projects, this may take some time, so you may be able to refill your coffee cup in the meantime. Once the project is created, you’ll see 4 projects:

Before we are going to write some code, we will update and add the additional packages from within the NuGet Package Manager. If your are not targeting the Android versions 7.x , Xamarin Forms is not able to use the latest Android Support libraries, so you’ll have to stick with version 23.3.0 of them (see release notes of Xamarin Forms). Since it makes sense for a new app to target the newest Android version, we’ll be updating the Android Support packages for our sample app as well.

If the NuGet Package manager demands you to restart, you’ll better follow its advise. To verify everything is ok with the updated NuGet packages, set the Android project as Startup project and let Visual Studio compile it.

If all goes well, let’s make sure we are using the right UWP compiler version for Visual Studio 2015. The .NETCORE package for the UWP needs to be of Version 5.2.x, as 5.3 is only compatible with Visual Studio 2017.

Once the packages are up to date, we’ll finally download and install MVVMLight. As we will host all of our ViewModel Logic in Xamarin Forms, together with their Views, we just need to install it into the Portable library and into the UWP project:

There will be no changes to the project except adding the reference. We need to set up the structure ourselves. First, create two new folders, View and ViewModel:

Move the MainPage into the View Folder and adjust the Namespace accordingly. The next step is to setup a ViewModelLocator class, which takes a central part of our MVVM structure. Here is what you need for the base structure:

    public class ViewModelLocator
    {
        private static ViewModelLocator _instance;
        public static ViewModelLocator Instance => _instance ?? (_instance = new ViewModelLocator());

        public void Initialize()
        {
            ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
            RegisterServices();        

        }

        private static void RegisterServices()
        {
            //topic of another blog post
        }

        #region ViewModels  
        #endregion

        #region PageKeys
        #endregion
    }

You may notice some things. First, I am using the singleton pattern for the ViewModelLocator to make sure I have just one instance. I had some problems with multiple instances on Android, and using a singleton class helped to fix them. The second part of the fix is to move everything that is normally in the constructor into the Initialize() method. Now let’s go ahead, add a MainViewModel to the project and to the ViewModelLocator:

 

        public void Initialize()
        {
            ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
            RegisterServices();
            SimpleIoc.Default.Register<MainViewModel>();
        }

        #region ViewModels
        public MainViewModel MainVm => ServiceLocator.Current.GetInstance<MainViewModel>();
        #endregion

Let’s give the MainViewModel just one property which is not subject to change (at least for now):

public string HelloWorldString { get; private set; } = "Hello from Xamarin Forms with MVVM Light";

The next step is to get the App.xaml file code right, it should look like this:

<?xml version="1.0" encoding="utf-8"?>
<Application xmlns="http://xamarin.com/schemas/2014/forms" 
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" 
             x:Class="XfMvvmLight.App" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
             d1p1:Ignorable="d" 
             xmlns:d1p1="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:forms="http://xamarin.com/schemas/2014/forms" 
             xmlns:vm="clr-namespace:XfMvvmLight.ViewModel" >
  <Application.Resources>
    <!-- Application resource dictionary -->
    <forms:ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
      <vm:ViewModelLocator x:Key="Locator" d:IsDataSource="True" />
    </forms:ResourceDictionary>
  </Application.Resources>
</Application>

Now that we have set up the baisc MVVM structure, we are going to connect our MainViewModel to our MainPage. There are two ways to do so.

In Xaml:

<ContentPage.BindingContext>
    <Binding Path="MainVm" Source="{StaticResource Locator}" />
</ContentPage.BindingContext>

in Code:

        public MainPage()
        {
            InitializeComponent();

            this.BindingContext = ViewModelLocator.Instance.MainVm;
        }

After that, just use the HelloWorldString property of the MainViewModel as Text in the already existing Label:

    <Label Text="{Binding HelloWorldString}"
           VerticalOptions="Center"
           HorizontalOptions="Center" />

Before we are able to test our code, we need to make sure our ViewModelLocator is initialized properly:

Android:

    public class MainActivity : global::Xamarin.Forms.Platform.Android.FormsAppCompatActivity
    {
        protected override void OnCreate(Bundle bundle)
        {
            //TabLayoutResource = Resource.Layout.Tabbar;
            //ToolbarResource = Resource.Layout.Toolbar;

            base.OnCreate(bundle);

            global::Xamarin.Forms.Forms.Init(this, bundle);

            ViewModelLocator.Instance.Initialize();

            LoadApplication(new App());
        }
    }

iOS:

    [Register("AppDelegate")]
    public partial class AppDelegate : global::Xamarin.Forms.Platform.iOS.FormsApplicationDelegate
    {
        //
        // This method is invoked when the application has loaded and is ready to run. In this 
        // method you should instantiate the window, load the UI into it and then make the window
        // visible.
        //
        // You have 17 seconds to return from this method, or iOS will terminate your application.
        //
        public override bool FinishedLaunching(UIApplication app, NSDictionary options)
        {
            global::Xamarin.Forms.Forms.Init();

            ViewModelLocator.Instance.Initialize();

            LoadApplication(new App());

            return base.FinishedLaunching(app, options);
        }
    }

UWP:

//in App.xaml.cs:
        protected override void OnLaunched(LaunchActivatedEventArgs e)
        {

#if DEBUG
            if (System.Diagnostics.Debugger.IsAttached)
            {
                this.DebugSettings.EnableFrameRateCounter = true;
            }
#endif

            Frame rootFrame = Window.Current.Content as Frame;

            // Do not repeat app initialization when the Window already has content,
            // just ensure that the window is active
            if (rootFrame == null)
            {
                // Create a Frame to act as the navigation context and navigate to the first page
                rootFrame = new Frame();

                rootFrame.NavigationFailed += OnNavigationFailed;

                Xamarin.Forms.Forms.Init(e);

                ViewModelLocator.Instance.Initialize();

                if (e.PreviousExecutionState == ApplicationExecutionState.Terminated)
                {
                    //TODO: Load state from previously suspended application
                }

                // Place the frame in the current Window
                Window.Current.Content = rootFrame;
            }

            if (rootFrame.Content == null)
            {
                // When the navigation stack isn't restored navigate to the first page,
                // configuring the new page by passing required information as a navigation
                // parameter
                rootFrame.Navigate(typeof(MainPage), e.Arguments);
            }
            // Ensure the current window is active
            Window.Current.Activate();
        }

Let’s test our app on all platforms by building and deploying them:

Android

 

iOS Screenshot – post will be updated 

 

UWP

If you get the same screens, you are all set up to use Xamarin Forms with MVVMLight.

Conclusion

I know there are several specialized MVVM frameworks/toolkits floating around, which are commonly used for Xamarin Forms. As I am quite used to the MVVMLight toolkit, I prefer it over them. It is a lightweight solution, and I have more control over the code that is running than with the other options. I know I have to handle a lot of things in this case on my own (Navigation for example), but these will get their own blog posts. Starting with one of the future posts in this series, I will provide a sample app on my Github account.

If you have feedback or questions, feel free to get in contact with me via comments or on my social accounts. Otherwise, I hope this post and the following ones are helpful for some of you.

Happy coding, everyone!

Posted by msicc in Android, Dev Stories, iOS, Xamarin, 2 comments

Editorial: Why the app gap on Windows Phone/10 Mobile is a bigger problem than I thought

Note: as this is an editorial, this blog post reflects my own experience and thoughts. You will agree with some points, but disagree with others. Feel free to leave a comment to start a discussion below.

Recently, I received a Nexus 5x as development device for a project I am about to start. As tech enthusiast, I could not resist to start using it as my daily driver.

As you might guess, I started with an install orgy of all the apps I am using on my Lumia 950 XL and set them up. It may be surprising, but I immediately recognized huge differences between the platform versions.

Take the Facebook app for example. Animations are smooth like butter, almost all settings are in app instead of leading to a mobile page, even loading content and scrolling is a whole lot better than on Windows 10 Mobile.

Another example is the Path app. Never been updated since its launch on Windows Phone, I was truly surprised when I opened It on Android. It is an app that really is fun to use on Android. I bet they would have a lot more users on Windows if they align the app… sadly, they abanonded the platform completely a few month ago.

The last example is the WordPress app. It exists on Windows (Phone) for existing users, but the experience on Android is galaxies away from the one the one in Windows (Phone) has/had. I am even writting this post with it, because it feels just right to do this (I only did that once on Windows Phone).

These were only three examples, but they show pretty much how different official apps can be between platforms (and how they are supported). And they all show, that Windows really has no priority anywhere (sadly).
The quality of apps that are available on Windows is not all, though. Of course, I downloaded also some apps that aren’t available for my Lumia 950 XL as well. And it does make a difference.

On my Lumia, I often use the mobile page for things to do/achieve. On Android, I have a whole lot more apps to choose from, so I never had to open the browser for:

  • my mobile carrier
  • my landline & tv carrier
  • the communal page of Winterthur (where I live)
  • swiss auction page of ricardo.ch
  • swiss page tutti.ch
  • Amazon (Bonus: the apps are connected, needed to log in only on one and all others had my account)
  • eat.ch, a swiss food order service
  • Imgur
  • Giphy
  • and more…

Some say a good mobile page is as good as an app. That’s wrong for most cases. A good written app is always handier than a website. On any platform (at least in my experience).

Android app quality has improved a lot in the last two and a half years (that’s how long it took me to deeply test the OS and the ecosystem again). They are equal to the high level on iOS (which I saw also recently, as my son broke out of the Windows world I created at home).

On Windows, we have a lot of third party apps that are trying to fill the gap. I respect those developers (at least those that use legal, public APIs), but it is just not the same. And even on Android (or iOS), there is room for third party apps besides the official ones.

The Android OS itself feels also grown up, and it is difficult to say if iOS or Android are better. It is more a question of who you prefer – Google or Apple.

Microsoft’s Windows (Phone/10 Mobile) is on a good way to get on par. Lots of the functionality is also there. But… as long as the provider of a service, no matter which kind, do not use them (for whatever reason), Windows will never grow up. The Universal App approach is a good idea, and it may pay off one day – or it may be too late already. The recent switch to focus on enterprise users does not really help. Because also enterprise users tend to have only one device. And also enterprise users tend to use apps on their mobile device.

As a WinPhan, writting this honest post deeply hurts. Even more, as I really am thinking about switching platforms for mobile things. Not as a developer, but as a user (at least until Windows has grown up).

Posted by msicc in Editorials, 3 comments

Goodbye Telefónica (Germany), Hello ShareCommService (Switzerland)

Yes, you read that right. Today was my last work day at Telefónica, where I worked since June 2007. During that time, I learned a lot about how good customer service should be, and even more about mobile networks and mobile devices (phones, tablets and more). During that time, I also started my dev story in my spare time – all because there was not a single fishing knots application available for Windows Phone (read more here).

This lead to get recognized also within Telefónica as a developer, and so I was asked to concept and develop the application Friends & You (nope, you can’t download it as it is an internal app).  I learned a lot about how corporate apps aren’t that easy to concept and build during that time, as well as as how restrictive corporate rules can be. After all, I had a few challenges to complete. Thanks to Friends & You, I was also able to dive into the world of Xamarin, where I learned a lot about the application structures of Android and iOS (which will be helpful for eventually porting some of my Windows Phone apps to those two).

I want to say thanks to my colleagues, you´re awesome! Keep up the great work you´re doing in Customer Service.

Back in September then, I opened up my Twitter app and the first tweet I read was this one:

image

I opened the attached document and read the job description. As an self-thought developer, I first was about to close it and put it aside as “read and done”.

Due to the head count freeze at Telefónica after acquiring e-Plus from KPN, there are no chances to become a real full time developer within Telefónica for the next time. But that is what I want to do. After reopening the document and reading it again, I decided to get in contact with Roman Mueller (who I knew from Twitter already).

We talked about the job itself and the circumstances behind the announcement. After a few talks and a visit in Switzerland, the decision was made. I am starting the next chapter of my developer story in January, moving to Switzerland, where I will add deeper SQL knowledge, WPF and a lot more to my development knowledge.

At this point, I want to thank ShareCommService and especially Roman for all the help I received already to make this all happen and get started.

It is going to be an exciting journey for me (and my family), and we are ready to go.

Happy coding everyone!

Posted by msicc in Dev Stories, 1 comment

Xamarin: Android Activities, Context, Intents and Views

xamandroid

If you are coming from C#/Silverlight, Android can be a little diffusing. Android does not have the same structure than a Windows or Windows Phone app.

Activities

Android has Activities. Activities are the key classes of Android were all actions take place. Unlike other apps or programs, you do not have a “Main” program that is your starting point when launched.

In Android, the starting point is an Activity. The Activity needs to be declared as the starting point. When you start a new project in Xamarin, an Activity called “MainActivity” gets created automatically.

This Activity has some attributes:

[Activity (Label = "gettingstarted", MainLauncher = true)]

The ‘Label’ attribute is what you will see in the Title bar when launching the app. The attribute ‘MainLauncher=true’ tells the application to start from here. Think of this as your MainPage.xaml.cs in a Windows Phone app.

Every Activity has its own OnCreate event, where you can put all your starting, button handlers, stylings etc. in.

But an Activity still has more. It has events like OnStart(), OnPause(), OnRresume() and OnStop() and OnDestroy() and OnRestart(). I won’t get into deep this time, as the Xamarin documentation has already a very good overview of those events: http://docs.xamarin.com/guides/android/application_fundamentals/activity_lifecycle/.

Those events are important to understand for a lot of your application logic, like:

  • saving data that has to be persistent
  • starting and pausing animations
  • register and unregister external events
  • fetch data that are passed from other Activities
  • and more (we will cover some of them in my further posts)

I absolutely recommend to go to the link above to read and understand those events.

Context

The Context is often needed in an Android application and allows your code to be run within an Activity.

The Context allows you for example:

  • to access Android services,
  • to access Application resources like images or styles,
  • to create views
  • to assign gestures to an Activity

Without Context, often code does not get accepted by the IDE or makes your code getting ignored while running the app. Luckily, all methods that I used so far have been telling me if they want a Context, so you need only learn to find out if you need Context for the Activity resources or Application resources.

Intents

But what if we want to have another page (like a separate about page for example)? How can we navigate between pages or call external functions?

This is what Intents are for. Intents are sending messages through the application if another function needs to be started, like the launch of a second page. Within these intents, we have declare the actions that the app needs to do, and if we need a callback, this will also be passed with an Intent.

Let’s hold this high level, here are some lines of code that navigate to a second page (Activity):

var second = new Intent(this, typeof(SecondActivity)); StartActivity(second);

With this code, we are creating an new Intent with Context to our current running Activity to launch the SecondActivity.

To send data between Activities, we use the PutExtra() method of Intents:

var second = new Intent(this, typeof(SecondActivity)); 

second.PutExtra("FirstPage", "Data from First Page"); 

StartActivity(second);

Of course, we need also some code to read the passed data on our second page:

Intent.GetStringExtra("FirstPage") ?? “Data not available”;

We could now use this data on our second page by assigning it to a control or function.

Passing data between activities works similar to passing QueryStrings in NavigationsService.Navigate() method on WindowsPhone, so you should get familiar with it very fast.

Views

The last part that is very important are Views. In a View you declare how the Activity looks like. Think of it as your MainPage.xaml page in a Windows Phone app.

Views can be very different, too. Let’s start with the simple View. In our getting started project, we also have a Layout file that holds our first View:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
<Button
android:id="@+id/myButton"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="@string/hello" />
</LinearLayout>

The View has a main LinearLayout which is acts as  ContentPanel. All other controls like Buttons, TextViews etc. are going into this. There are a lot of properties that can be set, we’ll leave it this easy for now. If you want to know more about those properties, you can have a look at the Android documentation here: http://developer.android.com/guide/topics/ui/declaring-layout.html

This part is totally the same as with the one matching part in the Android SDK, so you will need to get familiar with the Android documentation as well.

To make a View visible, we need to assign it to an Activity. In our sample app, we are doing this with this line of code in our OnCreate event:

SetContentView (Resource.Layout.Main);

This is the easy way for Views. But there are more complex Views in Android, too.

Views are also used in ListViews, where you declare the look of the items and the list in a Layout file, or also if you use the ActionBar with a tab navigation, and also in the menu of an ActionBar. I will cover all of these in my further blog posts, as we also need Adapters to get data binded to Views.

I hope you this post helps you to understand  the high level structure of an Android application.

Until the next time, happy coding!

Posted by msicc in Dev Stories, Xamarin, 0 comments

A year in the like of MSicc – my review of 2013

dev smurf

2013 was a year with a lot of surprises. It was a year full of community work for me as well as a huge learning year in development. But my year had also dark clouds on heaven. This post is my personal review of 2013 – you can like my impressions or not.

I started the year with releasing my first Windows 8 app ever, along with an huge update to my blog reader app for Windows Phone. I wrote several blog posts and started also development of my NFC Toolkit app for Windows Phone (Archive: January). I also ran a beta test for my NFC Toolkit, and finished my series about the parts that should help other developers  to write a blog reader app for both Windows and Windows Phone (Archive February & Archive March).

Then in April, the first time I had dark clouds hanging deeply in my life, affecting all parts – family, community work and also my 9to5 job. My wife had once again problems with her back, caused by slipped discs. It went as far as she needed to rest in hospital for a pain therapy. Luckily this therapy was helping her and our life went back to normality (knocking on wood).

I also started a new series on the WinPhanDev blog – Why we started developing (WWSDEV). We are collecting stories from developers, and posting them over there to motivate other developers and keep the community spirit alive. Just have a look, we have really great stories over there.

In the last days of April/beginning of May, Iljia engaged me to start using Windows Azure Mobile Services to make an app idea reality: TweeCoMinder was born. It is a very special and unique app, interesting for those that don’t want to miss their special counts on Twitter, supported by real push notifications via WAMS for both Live Tiles and Toast Notifications. I learned a lot during setting up my WAMS for the app, and I did also write some blog posts about that (AzureDev posts).

Because of TweeCoMinder, I stopped developing my NFC app for that time, and did only bug fixing updates to my other apps.

In August (at least in the spare time I had), I moved my blog completely to run in a Windows Azure VM. I did it to get more control over the whole system and to learn more about running a web service. I still need to write my blog posts about setting the VM with LAMP on Azure, but I just didn’t have time for that until now. In August/September I also had again very very dark clouds hanging around, with my wife was very ill (you can’t even imagine how happy I am about the fact she has this part behind her). But our daily live is still affected by this – we just learned to arrange us with the new situation.

In October, I got back to my NFC Toolkit to finish it finally. The app has some cool and unique features utilizing NFC tags, and I am quite satisfied with my download numbers. NFC Toolkit is my main project for the moment.

But also on my 9to5 job I came to write code. I was asked to write an internal app for Windows Phone (Telefónica has a partnership with Microsoft, and so the company is flooded with Windows Phones). I used this to learn more about speech recognition on Windows Phone, as this is part of the application (Make your app listening to the user’s voice).

And finally, I also started with my very first Android app using Xamarin while porting the Windows Phone app I wrote before. I recently started to blog about my experiences with Xamarin (read more here).

In between all those projects, I made a basic reader app for the fan blog “This is Nokia”, using a PCL project for both Windows Phone 8 and Windows 8. I also wrote a simple car dashboard app to integrate it in my NFC Toolkit app as well as Mix, Play & Share, which was written on a lonely Saturday night while my kids where sleeping an my wife was at her best friend.

Through the year, I learned a lot of coding, but also a lot about people. I made some very positive experiences – but also bad ones. I am always willing to help (if my still growing knowledge enables me to do so) – but sharing a feature rich app to another person isn’t helping – if you want to learn about development, there are plenty ways to do so. We have really great developers that blog about their experiences in our community, and by understanding how to code, you truly learn. Just using an already working app and restyling it, is the wrong way.

Well, that is what my year was about – a lot of coding, learning and again coding.

Dear followers, friends, WinPhans & WinPhanDevs – thank you for being with me this year. Let’s make 2014 an even more exciting year.

I wish you all “a good slide into the new year”, as we say here in Germany. May god bless you and your families also in the new year.

Posted by msicc in Dev Stories, 0 comments

Xamarin: Resources of an Android app project

As I mentioned already in my first blog post about Xamarin, Android has a different project structure – even if you use Xamarin.

A very important part of this structure are resources. We have different kind of resources in an Android app:

  • Icons & Images
  • Layout (XML files)
  • Values (string resource files)

Let’s start with Icons & Images.

As you can see in the solution window, there is a folder called ‘Resources’. Here you will put all kind of resources, like images, icons, layouts and so on.

The corresponding class for images in Android is called ‘drawable’, that holds a reference to’ Icon.png’. The project structure is based on that, that’s why the resources folder has all images inside the folder ‘drawable’. As Android has various screen sizes, you may have a folder for structure like ‘drawable’, ‘drawable-hdpi, ‘drawable-ldpi’ and so on. Android scales your image resources to match the screen automatically if you do not define alternate layouts.

To make your files available in your app, you need to set the Build Action to ‘Android Resource’:

Screenshot (278)

Let’s have a look to the Layout files:

Layout files are XML files that contain the UI of a page, control or a view. You can use these XML files for example to define items of a ListView or simply the application page. Every new project has a ‘Main.axml’ file.

There are two ways to create a layout. The first one is using the visual designer:

Screenshot (280)

This works for basic layouts like adding the button above. Also, if you don’t know the properties of a control you added, you will be able to add it here to get started.

If you are familiar with writing your UI in code (like XAML)  and want to do so in your Android app, just click the ‘Source’ tab at the bottom in the visual designer. You will see something like this:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
<Button
android:id="@+id/myButton"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="@string/hello" />
</LinearLayout>

If you want to add and modify a control, but don’t know how the properties are, this page has a list of all controls, which are called ‘widgets’ in Android. That’s also the corresponding namespace: android.widget.

Like in an Windows Phone app, you also have a string resource file in Android projects. This file is once again a XML file, but with a different structure:

<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="hello">Hello World, Click Me!</string>
<string name="app_name">gettingstarted</string>
</resources>

All strings need to be declared inside the <resources> tag. The definition is always like <string name=”yourstringname”>stringcontent</string>. Empty strings are not supported and will throw an error at building your project.

Let’s have a look on how we can work with our resources, based on our gettingstarted project. We have the following code inside our MainActivity class:

int count = 1;

		protected override void OnCreate (Bundle bundle)
		{
			base.OnCreate (bundle);

			// Set our view from the "main" layout resource
			SetContentView (Resource.Layout.Main);

			// Get our button from the layout resource,
			// and attach an event to it
			Button button = FindViewById<Button> (Resource.Id.myButton);
			button.Text = GetString (Resource.String.hello);

			button.Click += delegate {
				button.Text = string.Format ("{0} clicks!", count++);
			};
		}

As you can see, the we are defining our view from our Layout file ‘Main.axml’ by using the SetContentView() method. The file is added to our resources list as Layout with the name we defined.

Our MainActivity does not know that we have a button inside our layout. To make the button visible to our MainActivity, we need to reference it. This is done by declaring a Button instance and using the FindViewById<T>(ResourceName) method.

If you have not given your button a name, now is the right time to do so. In our example the button has the name “myButton”.  The syntax is very important, make sure you add “@+id/” to the name.

android:id="@+id/myButton"

Now our button is visible to our MainActivity code page and can be accessed. The sample project references the button content in the Layout file:

android:text="@string/hello"

After referencing our button, we could also use the following code to get the button content from the resource file:

button.Text = GetString (Resource.String.hello);

Whenever your want to get a string from the resource file in an Activity, the GetString() method is used.

I hope this post helps you to understand how resources are used in an Android app and how to handle it a Xamarin project.

Happy coding everyone!

Posted by msicc in Dev Stories, Xamarin, 0 comments

Xamarin: how to set up an Android device for Debugging

Xamarin comes with some emulators for development of an Android app. While these emulators are working and are also available in all supported screen sizes, the performance of them is really bad.

That’s why I chose debugging via device, which is a lot faster than the emulators once you have the required Xamarin extensions installed.

Here is how to set up an Android device for debugging. First thing you need to know is which OS version is running. On most Android devices, you will find this information under Settings/About (or Info)/Software information. If you don’t have the result there, you should check the manual where to find this information on your device.

Screenshot_2013-12-29-07-03-31

Activate Debugging until Android 3.2

  • go to Settings from your Application Menu
  • choose Applications
  • open the Development item
  • you will see now the option to activate USB debugging:

Android_debug_until_32

Activate Debugging on Android 4.0, 4.1

  • go to the Settings Menu
  • choose Developer options and activate USB debugging:

Android_debug_until_32

Activate Debugging on Android 4.2 and higher

  • go to the Settings Menu
  • select About
  • tap the Build Number 7 times (after the 4th tap a notification will appear that counts down the required taps)

Screenshot_2013-12-29-07-04-36

 

Installing drivers

Now our devices are ready to be connected to our PC, where we need to install the corresponding USB drivers. Normally you just need to plug in your Android device, Windows will search for the right driver and install it for you. If you want to install the driver manually, here is a list of OEM driver packages: http://developer.android.com/tools/extras/oem-usb.html#Drivers

Deploying an App for debugging

After the drivers have been installed, your device should now be recognized by Windows and also by Xamarin Studio.

Using our gettingstarted project from my first blog post, you should have now two options to deploy the application to your device:

Run With…

Screenshot (273)

Just hit ‘Debug’…

Screenshot (275)

Xamarin Studio installs now the required packages for debugging, and after that, you will be able to debug you application.

Speeding up re-deployments

Xamarin will install all developing packages including your app from scratch every time you deploy the app. To speed things up, there is an option to speed things a little up.

To activate/check if this option is already activated, click on the ‘options’ button of your project and select ‘Options’ in the context menu:

Screenshot (276)

Select ‘Android Build’ and activate these two options:

Screenshot (276)

 

This way, Xamarin will deploy only changes that have been made to your code, while keeping the required packages on your device. Xamarin Studio will detect if an update to those packages is required.

However, sometimes you will need to clean your solution and do a complete re-deploy (like you are doing with a Windows Phone project sometimes, too).

In very seldom cases (happened 3 times to me by now), you will need to uninstall your app and all of the Xamarin packages from your device. To do so, go to Settings/Apps on your device. In the application list, you will find some apps that start with ‘Mono’:

Screenshot_2013-12-29-07-57-13

To uninstall them, tap the items and select ‘Uninstall’ in the App info screen:

Screenshot_2013-12-29-07-58-43

 

Xamarin Studio will now re-deploy all required packages to your device, and your app should run again for debugging.

Like always, I hope this post is helpful for some of you.

Happy coding!

Posted by msicc in Dev Stories, Xamarin, 2 comments

New Series: developing for Android with Xamarin

xamandroid

Prolog

In the last few month I was developing not only my personal projects, but also on my daily 9to5 job. I am working on an internal app that will help to improve the customer experience amongst the customers of my employer Telefónica.

The project has a simple setup in phase I, with collecting data and sending them via mail. The challenge for me was how to get the Windows Phone app (yes, Windows Phone was first!) to Android.

I knew it would take some time to get started with Android development, and was searching for possible solutions to speed things up. I knew from Xamarin already, and was able to obtain a 1-year license for Android (maybe iOS will follow later).

Some of my fellow WinPhans and WinPhanDevs will scream out very loud at the moment. I understand that. But honestly, I could not let go away this huge opportunity for me – as it touches both my daily job and my private developer story. To calm you down: I will always love Windows Phone and Windows and develop for it first. I will always remain a WinPhanDev. But I need to go forward, and this is a big step.

Let’s go back to the topic.

With this blog post, I am kicking off a new blogging series for Android development with Xamarin. The huge advantage of using Xamarin is that I am able to use my C# knowledge to develop apps for other platforms – which makes it a little easier to get things done.

However, if you start with another platform, you still have to learn the platform structure. Without knowing or be willing to learn it, you will be lost very fast. Every OS has its own specific UI rules, save handling and so on. This is what I will blog about.

The Windows Phone app I ported to Android has a item Pivot, which I ported over to Android. It has a little different appearance, but it works in a similar way with tapping the header or a swiping gesture to move between the items/pages.

To get there, I had to learn a lot about Android – and I will share it all with you out there.

My series will cover the following topics:

Installing Xamarin

Installing Xamarin is pretty easy – but will take some time. Click on this link to download the Xamarin IDE. The IDE will ask you for which platform you want to develop for (let’s choose only Android for the moment) and then download a huge amount of additional SDKs like the Java and the Android SDK (Android apps are Java based, if you didn’t knew).

Screenshot (267)

On the screenshot above you can see the starting page of Xamarin Studio. On the left side you have the list of recent solutions, in the middle you see Xamarin news and finally the pre-built apps section.

Xamarin Studio has a lot together with Visual Studio, and you also can take a lot of settings to adjust the appearance for your needs. Let’s start a new project by clicking on the ‘New’ button

Screenshot (270)

Xamarin will set up a .sln file with everything we need for the moment. After creating the project has been created, you’ll see these lines of code:

using System;
using Android.App;
using Android.Content;
using Android.Runtime;
using Android.Views;
using Android.Widget;
using Android.OS;

namespace gettingstarted
{
	[Activity (Label = "gettingstarted", MainLauncher = true)]
	public class MainActivity : Activity
	{
		int count = 1;

		protected override void OnCreate (Bundle bundle)
		{
			base.OnCreate (bundle);

			// Set our view from the "main" layout resource
			SetContentView (Resource.Layout.Main);

			// Get our button from the layout resource,
			// and attach an event to it
			Button button = FindViewById<Button> (Resource.Id.myButton);

			button.Click += delegate {
				button.Text = string.Format ("{0} clicks!", count++);
			};
		}
	}
}

 

These few lines should help to get started with the basic structure of an Android App.

Android has Activities. Activities can be seen as the code behind files in a C# project. Here begins all the action of an Android app. Xamarin automatically ads the Label (project name) and in this case, also the MainLauncher property, which will run this code on app start up.

To get something displayed in our app, we need to load a Layout or create the view from the code. This is what the SetContentView() method is about. Without this, the app will compile but displays nothing. In this demo app, a basic layout with a button inside is created:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
    <Button
        android:id="@+id/myButton"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:text="@string/hello" />
</LinearLayout>

 

We already have the first difference to other C# projects here. In order to make the button visible for our code in the Activity, we need to search our resources for the button. This is done by the FindViewById<T>() method. As soon as it is visible to our code, we are able to create a delegate for our button Click event.

The button counts then the clicks on it and changes the text based on the number of clicks.

To understand more about the structure of an Android App, I highly recommend to read the documentation. For me, especially these links were helpful:

There are some more resources that are helpful, but for getting started those four links should be enough. I will cover some of the topics above also with my upcoming posts and link additional resources as well.

As with the Windows Phone development, also StackOverflow is a big help as well as the Xamarin  Android forums.

Until the next post, happy coding!

Posted by msicc in Dev Stories, Xamarin, 0 comments

Tap+Send: The Love Story of 2 NFC Devices

NFC1

Innovation in technology is hit and miss for a number of reasons. To prognosticate what advances in technology will be accepted by the general public is by no means, an exact science. There’s a constant barrage of new expensive toys with exclusive features that are “sure” to turn the world upside down, only to hit the market and fade into oblivion as a “niche market” concept. There are more than a handful of these types of advancements in the devices we all use on a day-to-day basis now, regardless of preferred OS. Yet for all intent and purpose, most don’t get utilized because of a lack of end users with similar features. NFC is one of those exclusive features and having 2 devices with it, I’ll explain why I see this being a feature that is here to stay.

nokia-speakers

I won’t spend much time explaining NFC as most of you know about it. Quickly, NFC(near field communication) is a set of standards for devices to establish radio communication with each other by touching them together or bringing them into close proximity. Up to this point, most of the NFC ado has been made about NFC tags and the Qi wireless charging capabilities with our Windows Phone 8’s: Charging plates, charging stands, phone covers with Qi, the JBL PowerUp speaker that can charge your device while playing. Being such a new innovation in smartphones, there are limited accessories to aid in this new technology, even HTC used JBL’s speaker for Nokia to advertise its most recent Android device. In addition to the lack of accessories currently available for NFC enabled devices, there are a lack of end users who actually own a NFC enabled device. NFC is about sharing and if you have no one to share with, it becomes one of those “niche market” features fading into the past, full potential never being realized.

tap-send-wp8

My wife and I both have Nokia Lumia 920’s which has led to a unique experience among smartphone users, being able to utilize many aspects of the NFC’s features and that is what I’ll focus on now. One of the drawbacks to WP7 was the inability to share via Bluetooth. This was remedied in Windows Phone 8 allowing for the next evolutionary stage is sharing photos, videos, songs, documents, contacts, or websites…via NFC. No more waiting while you tried to get your Bluetooth to find the other incompatible device right next to you, no more waiting for the other person to email you with that important file or pic even though they’re standing next to you, no more waiting for file to download when opening your email, no…things have changed. Tap your phone and give or get that info now in a fun and engaging manner! I am beginning to see the Tap and Share feature as perhaps the most innovative feature with the largest amount of potential to the end-user. Of course like most new technologies this is assuming it can make it onto enough devices and into enough hands, driving the hardware cost down and finding its way onto lower cost devices for the masses to use. Without “the masses”, NFC, aside from wireless charging, losses its luster. In some sense, I’m actually rooting for HTC and Samsung to have some success with their Android devices utilizing NFC, the better they do, the better results all OS’s with this feature will do. Again, NFC’s success really does rely upon the masses.

Share1

My wife and I use the Tap+Send feature frequently. We’re constantly sharing pictures and with Tap+Send, it’s always much faster and a sure bet the recipient gets the file! I’ve found that we’re both more likely to share pics when it’s as simple as Tap+Send. Send 1 or send multiple, it doesn’t matter. Honestly, I’m finding myself impatient now when I know someone is sending me a file and I have to wait for it to arrive in my inbox and still have to download it! Another added benefit to sharing your pics or videos via NFC is the data aspect. I avoid having to use up my allotted data both with my carrier and at home on WiFi, for those of you with shared family plans or have data limits because of satellite internet, you understand.

App

A close 2nd in utilization when it comes to Tap+Send: App Sharing, we do this at least once a day! As many of you know sharing apps via your WP8 was made easier by Microsoft when they gave us the ability to share it directly from the app side of your device. By pressing and holding an app, “Share” is now listed as on option and even better…you can do it via Tap+Send! Lightning fast access to the app’s direct link in the Windows Phone Store! Again, no waiting for it to show up in your inbox, it’s just there! I actually transferred all my apps this way when switching over from my old 920 to my new 920 to see how arduous it was. I’ve used App Reinstaller and it can take quite a long time to auto-populate your entire app history. I was blown away at how fast I was able to get my new 920 up and running with all my old apps!

sharing

We also share music via Tap+Send. I’m going to start by saying that neither of us has a music pass of any sort. When we see something we like we purchase it, so I’m not sure how sharing music on a pass will work. My experience with music and Tap+Share has been sending and receiving music from my computer or music purchased from Zune and Xbox Music, all which has transferred and played without a hitch! It’s a relatively quick process, taking about 30 seconds from share to play!

Contacts1

My wife and I have busy schedules between our marriage, kids, friends, activities, and work. We have many people who are friends in common and some aren’t for one reason or another, thus our people hubs are similar but not an exact match. There are many apps that help share contacts and WP does a pretty good job at giving you ways to share contacts as well, however none come close to the efficiency and speed with which you can do it when shared using Tap+Share! 2 taps and a phone “high-five” and the info is waiting to be saved.

Ready-for-enterprise

The last way I’ll look at is actually tied into the “Gold Mine” Microsoft sees in enterprise, sharing your documents via Tap+Send. The ways I’ve talked about using Tap+Send have been for the average user, but we all know that Microsoft is targeting businesses globally with WP8. The ability to share documents as simply as touching phones can be a game changer. Running late and can’t wait for that file to get to your inbox…need it now…phone “high five” and off you go! Not a gimmick, time is money and that makes dollars and sense!

I hope in time that we’ll see more and more devices showing up on the market NFC enabled at every level of phone: high, mid, and low range. This will take time but it’s time well worth it. When I stop and think back 2 years ago, I think about my Windows Mobile HTC Touch Pro 2, it could share via Bluetooth but it was a disaster of a process to get it to pair or be paired with not to mention the inability to retrieve most of the files types being sent! Our beloved Windows Phone has come a million miles from its predecessor, not without bumps in the road. Without those bumps though, many would forget all the amazing feats accomplished and adversity Microsoft/Windows Phone has managed to overcome!

Posted by TheWinPhan in App Reviews, Windows Phone, 1 comment