Friday, October 31, 2014

Some experiences with the new Support packages on NuGet

I spent some time moving over to the new Support packages Xamarin released on NuGet, instead of using the versions from the Component store.

Jonathan Dick made a nice post about what makes the packages on NuGet a bit more smarter than they were previously, which I find very interesting. However, it is not all happy times as there seems to be some caveats by using these packages.

Hence, here are some findings that you might encounter when using them.

I have some Android Library projects, each updated to the new NuGet packages. The Android Library projects seem all to have $(TargetFrameworkVersion) defined in the .csproj file, which comes from the setting in the project properties in the Application tab called Compile using Android version. This sets the $(TargetFrameworkVersion) in the project file. However in my Android Application projects, I previously had that same option set to Use Latest Platform. The problem with this, is that it does not seem to explicitly set that in the csproj file. This gives some problems when fetching the NuGet for the Application project, where NuGet might tell you that it is incompatible and simply not install it (not cool :( ).

Another problem is that, say you have an Android Library project using Google Play services, this is also a NuGet package, which additionally brings in a lot of Support packages (including v4, v7, v13 (whoa!)). Now you do all your stuff with the Play services inside of the library, so you think you can suffice with simply adding the needed Support packages in your Android Application project. Lets say you only need Fragment backwards compatibility and you just pull in Support v4. This will give you a headache and throw a bunch of errors telling you that you have duplicate managed types.
The solution seems to match the packages you added in the Android Library project. So if you are using Google Play services in your Android Library project, you need the exact same packages in your Android Application project.

Apart from these couple of things, it seems that the new packages work pretty well. It also seems that additional Support v7 packages have made it into NuGet and more are to come!

I've switched the MvvmCross "3.5" branch and my own MvxPlugins "threeandahalf" branch to use this new stuff.

Friday, October 3, 2014

Getting User Location to work in iOS8

There were some minor changes to how iOS8 works with core location. Previously when requesting the user's location on the MapView with ShowsUserLocation a nice pop-up would automagically show up asking the user if this was ok. Apple decided to make this a bit more flexible, allowing the developers to enter their own message. So if you compile your pre-iOS 8 app with the new SDK this might break, since you now have to manually call a method to get that pop-up to show.

So the quick fix is to do the following:

1. In your info.plist file add one of the following key/value pairs:

2. I then have a Extensions.cs where I keep my various extensions, for this case I've just made a couple of checks to whether the selectors are available on the platform, so the code won't crash on previous versions of iOS.

3. Remove your previous call to mapView.ShowsUserLocation and do the following instead:

Now you respond to the AuthorizationChanged Event and set the ShosUserLocation flag accordingly.

Edit (3/10/2014 17:00):
Now that I have had the chance to play a bit more with it, I have a couple of observations that might help you. First don't let go of the CLLocationManager instance, i.e. have it as a class field otherwise the dialog will disappear pretty quickly and it won't let you get location updates.

I didn't mention that you will have to do some checks on what iOS version you run at now and only call this code when on iOS 8 and higher, to do this you can do something as follows.