Menu

Tag Archives: Xamarin Dev Days

This is the final post in the series about custom map renderers on Android. To recap, we added a map page to our application and then customized the appearance of the map markers and the info window that is shown when the user taps a marker.

Now we are going to make the map a bit more usable by making it possible to update the pins from the view model, and making it easy to consume services in the Android specific project.

In the previous post, we defined a CustomMap control that only had one property:

Finally, I want to show how you can use that data binding technique to pass some services through to your Android project. For example, when a user taps a marker on the map, the info window will show. We can listen for when the user taps on that info window and use our Prism navigation service to pull up a new page. Let’s add the new bindable property to the CustomMap class.

And now we can get use the navigation service from our CustomMapRenderer like this by adding in our InfoWindowClick handler. Remember that we wired it up in the OnMapReady function. Now let’s put some functionality in the handler:

You can find all of this code in my GitHub repo in the MapRenderer solution. If you run the project, you can tap on the “Map” button on the main page. It will bring up the map and display a marker. If you tap the test button, it will update the marker to a new location. Tapping on the marker will show a custom info window, and tapping that window will use the Prism navigation service to navigate back to the main page.

Sounds like I am finally going to pick up a Mac laptop, so I should be able to expand these posts to the iOS platform. Looking forward to that.

In the previous post, we setup our DevDaysSpeakers app to include a page that displays a map. To get the map to display our information, we have a few things we have to do. Let’s start with subclassing the Xamarin Forms Map class with our own class and create our own pin data object.

And now we will use our new CustomMap class in our XAML. Make sure that you have the namespace declared (see view namespace below) and then you declare it as below. Note that I am just using some of the properties that are declared in the base Map class.

So if we were to run the app at this point, we would see the exact same thing as before. To add the custom behavior, we need to add in our custom map renderer in the Android project. So let’s get started.

In our droid project, let’s create a new class called CustomMapRenderer in the root of the project. The very first thing that we see is that we have to decorate the code at the namespace level to tell Xamarin that whenever we see the CustomMap class in our shared XAML, we should implement using this class. It will look like the following:

Included above is the class declaration and you can see that it derives from MapRenderer class and implements a pair of interfaces that are used to display the map in Android.

In the CustomMapRenderer, we want to keep track of a couple of instances, the first being our subclasssed Map (CustomMap) and the actual GoogleMap object is in Android. These objects are picked up in a couple of different places.

First, the CustomMap object is captured when the CustomMapRenderer instance is assigned and you can capture that by overriding OnElementChanged. You also use this method to clean up your wired up event handler for when a user taps on the info window associated with a map marker.

Secondly, in our implementation of the IOnMapReadyCallback interface, our implementation of the OnMapReady function saves the instance of the GoogleMap.

Most of that is pretty straight forward I think. We are implementing our interfaces and saving instances to the Map objects so that we can use them later. We are also wiring up the event handler so that can capture when the user taps the information window that appears after tapping on a map marker.

Next we will handle adding the pins to the map by implementing the UpdatePins method. The interesting thing in this is that our CustomMap instance (_customMap) contains the business data of the app, while the GoogleMap (_map) instance does all the presentation.

From above you can see that we are creating markers, setting the title property and the address property, and also changing the look of the pin itself. In this case we are only changing the color from default to blue. But you can also add in your own bitmaps if you want.

Let’s talk a bit about customizing the info window. In case you aren’t sure about the info window, this is what is pop’d up on the map when you tap on the marker. We have the ability to customize it and this happens in the GetInfoContents method in the code fragment above. By returning null, you will just get the default contents.

If you want to do something custom, you will need to define your own layout in the Resources\layout namespace. If you look at the sample code, there is nothing special there, I simply used some random template I saw somewhere to learn some syntax and made one. I am more familiar with XAML and just tried to match up the containers and controls.

But to me, the more important code is overriding the GetInfoContents method to put useful information in the popup.

Well, hello from Las Vegas! I am down in LV for the Autodesk Developer Network Dev Days and the Autodesk University. It’s a pretty fun time, especially if you are involved in engineering or CAD of any kind. If you are like me, also a dev person, there is lots of cloud stuff to add in there. And now even virtual reality and augmented reality to geek out!

In any event, travel makes for weird schedules and time awake. So here I am working on navigation in Xamarin Forms projects. But first a little recap: in our last post we really dug into dependency injection and showed the power of it. We saw some concrete examples of how it can make our app better architected, and how that makes it more maintainable. Next we will take that architecture to the next level and add in navigation. You probably remember from the start of the app how we had to register pages for navigation: let’s review that.

In a normal Xamarin app, the navigation system is accessed via a singleton object. To navigate to another page , you have to provide the actual page type of the destination page to the navigation service. Right away, you can see that this could be a headache in the future: if you change the page type, you need to change it everywhere in your app that the page is referenced. Yuck. And what if you have needs that are a bit more dynamic? For example, you could have a free version of an app and a paid version. In that case your dependencies just increased by a factor of …? Well, it depends on the app, but every time you have to make that decision in your app is another level of complexity. Instead, wouldn’t it be cool if you could just determine if the app was paid or not and navigate to the appropriate page based on that status?

Prism provides a better model for navigation. Not only does Prism remove the dependency on types, it also moves the navigation brains up to the view model (where the business logic is) and away from the presentation level (where the Xamarin navigation system resides). And this all begins in the RegisterTypes method of the App object. So let’s start with what we have there.

The above registers the SpeakersPagae for navigation and associates it with the SpeakersViewModel. There is also an optional parameter in the call to associate the registration with a key. Since we didn’t provide a key, Prism made one for us based on the name of the page. When you call NavigateAsync, you provide the key and the Prism navigation system looks up what is associated with the key and instantiates the appropriate page and view model.
We can improve this by specifying our own key. If we do that, in every place we navigate to the page, simply changing the initial registration will allow us to put in a different page. We won’t have to go to every place and change the call. I like to create a static class with the page keys so that I can reduce my use of magic strings.

Awesome! Just by using the key instead of the page type name, we made our app even more flexible and easier to maintain. None of our in app navigation will change, we always just call:

NavigationService.NavigateAsync(PageKeys.Speakers);

What else is important in this? Well I mentioned this before, but the navigation system is rooted into the presentation layer of the code. But navigation is really about business logic. The Prism navigation service abstracts out the presentation and the service is passed around as an interface. For unit testing of your view model, you can mock the interface and your view model won’t know or care.

You probably already know how the view model gets the navigation service (dependency injection, constructor parameter), but just in case it is late or you don’t remember every single detail of the previous posts, we just put the dependency into the constructor and the dependency injection container injects it for us. You can see this in the code. If you are looking at the code and saying: wait, INavigationService is not registered anywhere in your code, you are right. The App base class does it for us because they assumed that you were going to want that service. Dig into the Prism code if you want to find out more.

The last thing I want to bring up with respect to Prism navigation is how to pass data during navigation. When you use the NavigationService.NavigateAsync method, the second parameter is a NavigationParameters object, and you can pass pretty much anything in in. Let’s dive in.

In this example, I want to know when the SpeakersPage is navigated to the first time. So in the app object, I am going to add that parameter to the initial navigation in the OnInitialize method.

How do we consume this data? And where do we consume it? This data is really business logic data so we want to consume it in the view model. To get the data up to the view model we have to have our view model implement the INavigationAware interface. This interface has two methods: OnNavigatedFrom and OnNavigatedTo. I normally like to implement this in the BaseViewModel class so that all the view models have it already and I can also setup some generic functionality if I want.

But how does that actually work? What happens is that the navigation service is aware of the page creation. And as part of the page creation, we know that the view model will be automatically injected. The navigation service will look at the view model object that was injected and see if it implements the INavigationAware interface. If it does, it will call the OnNavigatedTo method. More awesomeness!

Well, that is it for navigation. You can see full-on code at the usual place in my GitHub repo under Step 04.
Enjoy!

Introduction

In our last post, we set up the view model for the SpeakersPage and made use of the built in view model functionality included in Prism. We setup a base view model for our app to contain common functionality. The SpeakersViewModel class has the implementation code for retrieving the list of speakers embedded in the view model itself. Fine for a demo, but in a real app, we would be better served by moving this functionality out and using it via an interface. By implementing the functionality as an interface, we will be able to reuse the code in other view models. Since the SpeakersPageViewModel only knows it via the interface, we will also be able to mock the service with known values for use in unit tests, without changing the view model. And we can use the Prism framework and the dependency injection that is built in to make this easier. So lets take a look at this.

The Interface

The first thing we want to do is look at the functionality that is currently in our view model class. All it is doing is calling a web api to return a list of speakers. That seems pretty straight forward. Let’s start our interface with that:

From above, you can see that we have just moved all of the implementation code from the view model into a separate service object. So how do we start using this new code in our SpeakersViewModel?
The first thing we need to do is register this service in our App object. Remember that we are registering via an interface: this means we can change out the implementation at any time.
Here is the RegisterTypes function in the App object updated to register the service:

So what do we have above? All of a sudden the ViewModel has a dependency on ISpeakersService. But we weren’t creating the view model in the first place: instead, Prism and the AutoWireViewModel attached property (see the previous blog post) are creating the view model for us and attaching it to the page. When Prism does this, it uses the container that was selected (step 01 blog) to create the view model and all the dependencies that are required for the view model, and it does this via reflection and then looking at what you specified in the App.RegisterTypes method. I hope that you can see that you can change up the implementation details of the interface without ever affecting the view model itself. You can even unit test your view model by mocking the service.

Now the view model just makes a call to retrieve the speakers. It has no idea if the speaker are read from a web api, a database, a file or even from memory! It just knows to make the call and it will get the data.

I really want to emphasize this: the view model knows nothing. It has no dependency on any implementation and you can change that around as you see fit! In fact, I am going to change the code of the SpeakersService implementation. I captured the json payload that was returned from the web api and saved it as a constant in the implementation. Now instead of calling out to the web api, I just return the json payload directly, and now for testing, everything is much quicker. And as mentioned earlier, using these known values, I can use this implementation for unit testing of the view model.

Recap

We have taken the next step in making the dev days app a little more production worthy. We took out the implementation of our speakers service away from the view model, defined it as an interface and injected that into our view model. We used the dependency injection that is built into Prism to inject the implementation of the service into the view model. And then for fun (and quicker testing), we changed the implementation of the interface to serve up the results from a json payload that had been captured previously. Now we can do testing much quicker.

Hello everyone, just a small follow up on the event yesterday. It was a nice introduction to Xamarin, and we were well led by the presentation team of Mark Schramm (@markbschramm), Adrian Stevens (@Adrian_stevens), Jan Hannemann (@bitdisaster) and Sergiy Baydachnyy (@sbaidachni).

Presentations from Adrian, Jan and Sergiy preceded lunch (thanks Microsoft) and afterwards, Adrian led us through a sample app using Xamarin Forms. If you want a quick introduction to Xamarin Forms development, head over to the dev days GitHub repo (https://github.com//xamarin/dev-days-labs) and follow the hands on lab. It is a pretty good introduction.

For my part, I am going to turn that app into a series of blog posts on using the Prism framework. So keep your eyes open for that.