Xamarin HttpClient NameResolutionFailure exception

 

If you look on internet there are plenty of people reporting this error.

Xamarin is somehow aware of this error, and it marked it as fixed but it doesn’t seem like it is.

Fortunately, this exception appears only in debug mode, not in release mode.

Android–deployment error - INSTALL_FAILED_UPDATE_INCOMPATIBLE

 

When trying to deploy on device I got this error:

Deployment failed because of an internal error: Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE]

Deployment failed. Internal error.

To fix it, run:

C:\Users\[YourUserName]\AppData\Local\Android\android-sdk\platform-tools>adb uninstall com.xxx.yyy

Don’t include the .apk file extension

Publish empty folders

 

If you need to include an empty folder when deploying using MSDeploy (either manually from Visual Studio or calling msdeploy from scripts) you can do that by:

1. create a Web Publishing Pipeline file (.wpp.targets)

   Create a new XML file in the project folder (the same folder that holds the .csproj or .vbproj file) and name it <projectname>.wpp.targets.

2. Add the following

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <AfterAddIisSettingAndFileContentsToSourceManifest>MakeEmptyFolders</AfterAddIisSettingAndFileContentsToSourceManifest>
  </PropertyGroup>
  <Target Name="MakeEmptyFolders">
    <Message Text="Adding empty folder to hold downloads" />
    <MakeDir Directories="$(_MSDeployDirPath_FullPath)\Survey\responses"/>
  </Target>
</Project>

In my case I needed an empty folder called ‘responses’ inside an existing ‘Survey’ folder.

The folder will be created no matter which configuration or publishing profile is run.

More info:

http://msdn.microsoft.com/en-us/library/ff398069(v=vs.110).aspx

http://blog.alanta.nl/2011/02/web-deploy-customizing-deployment.html

A busy MvxViewController for MvvmCross + iOS

In my MVVMCross apps, in the shared PCL core library, I usually have a MvxViewModel derived class called ViewModelBase with a IsBusy property:

    public class ViewModelBase : MvxViewModel
    {
        bool isBusy; 
        public bool IsBusy 
        { 
            get { return this.isBusy; } 
            set { if (this.isBusy != value) { this.isBusy = value; this.RaisePropertyChanged("IsBusy"); } } 
        }

        // other base stuff in ViewModelBase
    }

The property is to update a progress indicator control in the view.
For iOS the control can be UIActivityIndicatorView.

But instead of placing a UIActivityIndicatorView on each view, we can dynamically create it at run-time when IsBusy property changes to true.
We can have this implemented in a ViewController base class like this:

using System;
using System.ComponentModel;
using MonoTouch.ObjCRuntime;
using MonoTouch.UIKit;
using Cirrious.MvvmCross.Touch.Views;
using Cirrious.CrossCore.WeakSubscription;
using YourApp.Core.ViewModels;

namespace YourApp.Touch
{
    public abstract class MvxViewControllerBase : MvxViewController
    {
        // weak subscription to NotifyProperty event
        IDisposable npSubscription;

        public override void ViewDidLoad()
        {
            base.ViewDidLoad();

            // subscribe to view-model's PropertyChanged 
            this.npSubscription = ((INotifyPropertyChanged)this.ViewModel).WeakSubscribe<bool>("IsBusy", (s, e) => { this.UpdateActivityIndicatorView(); });
            
            // at this point view-model exists, so update the indicator view
            this.UpdateActivityIndicatorView();

            // add other common UIViewController stuff
        }

        protected override void Dispose(bool disposing)
        {
            if (disposing && this.npSubscription != null)
            {
                this.npSubscription.Dispose();
                this.npSubscription = null;
            }
            base.Dispose(disposing);
        }

        void UpdateActivityIndicatorView()
        {
            // get the activity indicator
            var activityIndicatorView = (UIActivityIndicatorView)this.View.ViewWithTag(1000);

            var vm = (ViewModelBase)this.ViewModel;
            if (vm.IsBusy)
            {
                // show busy indicator. create it first if it doesn't already exists
                if (activityIndicatorView == null)
                {
                    activityIndicatorView = new UIActivityIndicatorView(this.View.Frame)
                    {
                        ActivityIndicatorViewStyle = UIActivityIndicatorViewStyle.Gray,
                        Tag = 1000
                    };

                    this.Add(activityIndicatorView);
                    this.View.BringSubviewToFront(activityIndicatorView);
                    activityIndicatorView.StartAnimating();
                }

                // show the activity indicator
                activityIndicatorView.Hidden = false;
            }
            else
            {
                // hide the activity indicator
                if (activityIndicatorView != null)
                {
                    activityIndicatorView.Hidden = true;
                }
            }
        }
    }
}

Instead of having a base class we can delegate the implementation to an extension class which has the same implementation.

Please let me know if you see any possible issues.

I am thinking to do a similar implementation for other platforms as well.
Maybe MVVMCross could support out of the box a similar implementation. A built in implementation in MVVMCross would probably require to be able to override the style for the indicator.

Sharing library project across solutions and NuGet

UPDATE:
Latest NuGet doesn't rely on 'Enable NuGet Package Restore’ feature: http://docs.nuget.org/docs/reference/package-restore
So instead I recommend checking this: http://www.damirscorner.com/CategoryView,category,DevelopmentNuGet.aspx

I have several applications using one library where communication to the backend API is implemented.
Here’s how the folder hierarchy for projects looks like
Api
  Api.csproj
  Api.sln
App1
  App1.csproj
  App1.sln
App2
  App2.csproj
  App2.sln
Each app solution (App1, App2) has Api.csproj added.
The main reason why Api project is added to app solutions is we want to debug and step into the code of Api library easily.
But this might not be a good idea because each app can depend on a specific version of the Api library. If something needs to be changed in the Api which affects all applications, all applications would need to be updated and sometimes the impact of the changes in the app is complex.
For this reason, we might want to have each app depending on a specific version of the Api, so instead of adding the project as reference, we could add the compiled library as reference.
We can solve the problem to step into the library source code by also having library.pdb files along with the .dll.
More info:
http://www.xavierdecoster.com/how-to-nuget-package-restore-when-sharing-projects-between-solutions
http://blog.stangroome.com/2013/11/26/nuget-reference-paths-for-projects-in-multiple-solutions/ (see comment)
http://blog.stangroome.com/2013/12/05/visual-studio-solutions-projects-and-shared-code/
http://www.xavierdecoster.com/post/2011/11/16/why-everyone-should-be-using-a-symbol-server
http://www.edsquared.com/2011/02/12/Source+Server+And+Symbol+Server+Support+In+TFS+2010.aspx

However, suppose we still want to add the library as source code to app solutions.
There’s a problem with NuGet that it’s creating ‘packages’ folder per solution.
http://stackoverflow.com/questions/18376313/setting-up-a-common-nuget-packages-folder-for-all-solutions-when-some-projects-a
Here’s how to do it:

1. delete existing ‘package’ folder in each solution folder
2. for each solution, right-click on the solution file in the solution explorer > ‘Enable NuGet Package Restore’
3. this will create a .nuget folder. open the NuGet.config
4. add the following under <configuration> node:
   <config>
     <add key="repositoryPath" value="../../packages" />
   </config> (NOTE: if you're using Xamarin, you MUST use forward slashes, otherwise on Mac you will get a folder with the name '..\..\packages' !)
   it instructs NuGet to use ‘packages’ folder located at the same level with Api and apps solution folders.
   note that this path is relative to the location of NuGet.config file
5. go to each .csproj and make sure all paths which reference ‘packages’ folder are set to “..\..\packages’
6. delete each ‘.suo’ file in solution folders
7. reopen Visual Studio
8. open each app solution and build it.
   for the first solution being built, NuGet brings the packages in the new ‘packages’ folder.
   all other solutions will reference the already downloaded packages

References:

http://forums.xamarin.com/discussion/17783/add-manage-nuget-packages-per-solution

http://lastexitcode.com/blog/2014/08/10/NuGetSupportInXamarinStudio5-2/

Install GooglePlay in emulator

 

I am using the info from http://stackoverflow.com/questions/11154222/google-play-on-android-4-0-emulator#answer-11213598

1. Go to http://wiki.rootzwiki.com/Google_Apps#Universal_Packages_2 and get the latest .zip compatible with your target device.
    Note the “Not compatible with x.x.x!” remarks

2. Start your emulator:

cd %LocalAppData%\Android\android-sdk\tools

emulator -avd VM_NAME_HERE -partition-size 500 -no-audio -no-boot-anim

Then use the following commands:

cd %LocalAppData%\Android\android-sdk\platform-tools

# Remount in rw mode
adb shell mount -o remount,rw -t yaffs2 /dev/block/mtdblock0 /system

# Allow writing to app directory on system partition
adb shell chmod 777 /system/app

# Install following apk
adb push GoogleLoginService.apk /system/app/.
adb push GoogleServicesFramework.apk /system/app/.
adb push Phonesky.apk /system/app/. # Vending.apk in older versions
adb shell rm /system/app/SdkSetup*

Type-safe ViewModel to ViewModel navigation in MvvmCross

In MvvmCross you can navigate between view-model's as described in the Wiki:
https://github.com/MvvmCross/MvvmCross/wiki/ViewModel--to-ViewModel-navigation

It's good however to use a simple type-safety mechanism.
Suppose we have a ProductViewModel which expects two arguments for initialization:

public class ProductViewModel : MvxViewModel
{
     public void Init(int productId, int clientId)
     {
          ....
     }
}

With a type-safe mechanism, instead of writing:

ShowViewModel<ProductViewModel>(new { productId = pid, clientId = cid });

we can write:

NavigationHelper.ShowProduct(pid, cid);

where NavigationHelper is a simple utility class:

using Cirrious.CrossCore;

using Cirrious.MvvmCross.ViewModels;
using Cirrious.MvvmCross.Views;
using MyApp.Core.ViewModels;
using Cirrious.MvvmCross.Platform;

namespace MyApp.Core.Common
{
    public static class NavigationHelper
    {
        public static void ShowProduct(int productId, int clientId)
        {
            ShowViewModel<ProductViewModel>(new { productId = productId, clientId = clientId });
        }

        static void ShowViewModel<T>(object parameter) where T : IMvxViewModel
        {
            var viewDispatcher = Mvx.Resolve<IMvxViewDispatcher>();
            var request = MvxViewModelRequest.GetDefaultRequest(typeof(T));
            request.ParameterValues = ((object)parameter).ToSimplePropertyDictionary();
            viewDispatcher.ShowViewModel(request);
        }
    }
}

using Cirrious.MvvmCross.Platform; namespace statement is important because it contains the ToSimplePropertyDictionary() extension method implemented by MvvmCross.

Furthermore, instead of using the NavigationHelper class, we can move the ShowViewModel method to a ViewModelBase class:

public class ViewModelBase : MvxViewModel
{
       protected static void ShowViewModel<T>(dynamic parameter) where T : IMvxViewModel        
       {            
           var viewDispatcher = Mvx.Resolve<IMvxViewDispatcher>();            
           var request = MvxViewModelRequest.GetDefaultRequest(typeof(T));            
           request.ParameterValues = ((object)parameter).ToSimplePropertyDictionary();            
           viewDispatcher.ShowViewModel(request);        
       }
}

public class ProductViewModel : ViewModelBase
{
    public static Show(int productId, int clientId)
    {
        ShowViewModel<ProductViewModel>(new { productId = productId, clientId = clientId });
    }

    public void Init(int productId, int clientId)
    {
        ...
    }
}

and we can now write:

ProductViewModel.Show(pid, cid);

Having the Show method near the Init method in the ViewModel class, makes it a bit more easier to maintain the parameters.