Tuesday, August 05, 2014

Auto binding of outlets in Xamarin iOS and MvvmCross

 

If you are like me and you don’t like doing the bindings in code, you start thinking about solutions.

So I’m experimenting with the idea of creating the bindings at runtime, based on a simple name convention:

  • An UIButton outlet with the name 'btnXXX' is bound to the view-model 'XXXCommand' property.
  • An UITextField outlet with the name 'txtXXX' is bound to the view-model 'XXX' property.
  • An UILabel outlet with the name 'lblXXX' is bound to the view-model 'XXX' property.

For example, if you have a UIButton outlet called btnLogin, it's bound to view-model LoginCommand property.

I uploaded the code here;

https://github.com/nitescua/AutoBinding/

This can be done for other platforms as well.

Tuesday, July 29, 2014

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

Monday, May 26, 2014

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

Monday, April 07, 2014

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.

Thursday, March 27, 2014

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/

Friday, March 14, 2014

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*