Shared Components In Xamarin Forms

Xamarin has several cross-platform libraries available for you to use that we have  unified API for accessing platform specific features from iOS Windows Phone and Android .These are all open source and available through github which you can then use or modify however you like.

There are several components that xamarin supports. The first is Xamarin social which provides some social networking capabilities to your application it has support for example for posting to Facebook and Twitter.

We also have Xamarin.Auth which is used for OAuth. It’s support is to securely connect to web services. And then we have the Xamarin.Mobile component which has location camera and photo access .

As an example here we have some code to take a picture using Xamarin.Mobile this code works on iOS Android and Windows apps .The media picker that you see here provides access to the photo as a file or as a streams . So then you can load it into whatever the platform specific representation of an image might be. Now you could of course write this code using platform-specific api's but then you have to write a three separate times.And in fact you might still choose to use the native API .If you need some special capability that's unique to the platform but more often than not you just want to take a photo.

Another area to look at is the dotnet foundation this is an open source consortium of Microsoft. And Microsoft  partners that has a ton of open source dot net code that you can use.

Another great place to look is a github. Xamarin maintains a list of open source plugins github/xamarin/plugins .These have all been produced by different authors and they're not officially supported by Xamarin. But each provides an abstraction over some specific feature with implementations for each platform . So you can access that feature from shared code. All of these are open source and most of them can be used either in source form or as a binary which you can add using nougat.

 You likely have already used nougat if you've done any Microsoft development but nougat is a package manager for .NET development that supports downloading and installing both binary and source elements in project. There's a large public repository at www.nuget.org which you can use to search for available components by name or by functionality. You can also create your own private repositories using a folder network share or even a web URL.

You can add remove and update components directly from your IDE, it's supported in both visual studio and Xamarin studio through the references note on the project.

 It also supports auto package restore automatically which means you don't need to include the nuget packages directly in your source control . And Microsoft is moving towards this as their primary vehicle of code updates and component distribution including frameworks such as asp.net and Xamarin.Forms.

Another option for Xamarin specific components is the Xamarin component store this is an older distribution channel that was created before nugget .However there are still a lot of great components here.

It's accessible through the components folder in each of your projects. It supports a commercial pricing model. And Xamarin manages this store so that every component is validated and tested.

 You can use either nugget or the component store and often components are published in both. But generally if that's the case you should prefer nugget as it's fully supported by both Microsoft and the Xamarin tools.

Read More

View Sizing In Xamarin Forms

Let's start with the view side of the layout negotiation and look at how a view tells a panel its preferred size and position in all three platforms .

These tend to size themselves just large enough to fit around their content

For example, label and button both typically size themselves just large enough to show their text.

In this case, the label shown here that says hello.

There are many other factors that influence the final size both settings on the view and the layout algorithm. We will see all the detail shortly. Four properties influence the views rendered size. There are all requests and may be overridden by the layout container. The first two are for sizing you can set a width and a height value on the view. Notice that word requests in the property name you use these properties to tell the layout panel its preference but the layout makes the final sizing decision.

The other two properties give positioning information vertical options and horizontal options influence how the view is positioned within its rectangle allocated by the layout container.

You can specify you want to be aligned to one of the four edges of the rectangle. or that you want to occupy the entire rectangle .

 

Notice when we set width request and height request we use literal values like one hundred. In xamarin forms, these values have no unit. They are not points or pixels. They are just values of type double.

Xamarin Forms passes these values on to the underlying operating system.

The operating system provides the context needed to decide what these numbers mean.

   

On Windows, these values are interpreted as effective.

                                  

 On Android there density-independent pixels  

                                 

And on iOS the values are called points

                     

           

Now let's look at how the translation from literal values to concrete units plays out. Your xamarin forms app will likely run on multiple operating systems and on a wide range of devices.

 The width request and height request value set near xamarin source code are interpreted at runtime. According to the rules of the operating system based on the screen size and resolution.

The typical behavior for each OS is to apply a scale factor to your values to determine the number of physical pixels for review

For example if this app will run on the Windows Device shown the one hundred label by three hundred label .would render as 200 by 600 pixels since the devices are the scale factor of two .

On an iPhone 6s we would again see two hundred by six hundred physical pixels.

 Since it also has a scale factor of two. The screen of the Nexus has a higher pixel density so the scale factor is three point five resulting in a render size of 350 by 10520 pixels

 Those values like width requests and height request properties might not be respected at runtime. They cannot be used to see the result of your layout algorithm. for example if you set width request to 100 and its value will still be  100 after the layout algorithm runs regardless of whether the view is actually given units by the layout panel .

Instead, several other read-only properties tell you the actual size of a view in platform-independent unit’s .x and y give you the distances from the upper left corner of the layout

 Width the height tell you the size

And bounds as a convenience property that returns a rectangle containing all four values X, Y width and height.

 These properties are updated every time the layout algorithm runs.

Remember that the layout container gives each child view a rectangle. This rectangle is the area where the child will be rendered with these horizontal options and vertical options control the placement of the child within this rectangle.

 It’s actually a bit trickier than that simple statement the layout options struct has two properties.

 One used by all layouts and one which is only used for stack layout. Let’s look at the details next. The layout option struts two properties are both related to layout but they're not related to each other. Layout options is complex despite only having two properties. Alignment controls how the child view is positioned within the rectangle given to it by its layout container. Remember for each view it has two layout options values. One for horizontal and one for vertical. These two values let you align the child due to any of the edges of its rectangle or to Center, fill is different than the other values it means a child should fill its entire rectangle. Again each of us two of these values so you can independently control whether the child fills a rectangle in just one direction or both.

The expands property lets the view request extra space if the parent stack layout has any available. Expands is only used by stack layout the value is completely ignored by the other layout container’s. We will explore  expands more when we talk stack layout.

 The layout alignment Enums has four values start Center end , fill. When you choose one of these options for either the horizontal or vertical directions two things happen . The width requests or height requests setting is used to determine the view size in that direction if the view doesn't have a sizes default size is used for that access. The view has been aligned to the side of the layout rectangle you specify .in this case the fact layout gives each label or layout rectangle spanning the entire width start Center and end position within that rectangle. Fill however ignore any width request or height request setting and instead size of view so it occupies the entire rectangle in that direction.

 A view can have more than one property setting that influences its size for example it can have on width request of 100 and horizontal options of fill.  In these cases the two settings might conflict suppose a layout panel at 300 units wide the panels are not simultaneously make the view units 100 wide and have it filled a layout width. The fill options will take precedence in this case and the width request is ignored.

This can be confusing since fill is also the default .

Let’s look at that next. Horizontal options and vertical options in both default to fill making these two declarations identical. It’s important to keep in mind this when debugging a UI. It’s easy to forget and it can make it very hard to figure out why your view renders the way it did.

You may want a bit of extra space around a view. For example suppose you have some buttons next to each other you may want to add room around them to avoid accidental touches this is exactly what the margin property is for. Now what you include extra space or in any view. Margin is of type thickness so you have several options on how you would like to specify the value. the most flexible option is to give individual values for all four sides the order is top left right and bottom. Another option is to give two values the first is used on the left and right side the second is use for the top and bottom. Finally you can give a single value used for all four sides.

 There’s another option to add some extra space but this one's only available to layout panels. The padding property has space inside a layout panel. It reduces the area available to layout children. Padding is also a thickness type so you have the exact same options for setting it that we saw with margin.

Read More

Introduction to Rest Web Services in Xamarin

This is a quick introduction to some of the concepts that come up when you are doing rest-based networking.

You have a lot of options when you're talking to various servers. If the server wants you to use sockets of course you can do that .

If you want to use soap you can do that. 

If you have a rest-based server out there you can also do that .

Now we're just going to talk about rest and sits by far the most common. Here’s some statistics from a few years ago.

And you can see how dominant rest has become .One of the main drivers for the success of rest is that it's easy to access from JavaScript clients . Also there's a lot of JavaScript clients out there on the web and of course servers want to make it easy for all those clients to access them so they typically provide a rest style API.

Rest means representational state transfer and the term comes from a PhD dissertation by Roy fielding back in two thousand.

And his insight really was that the world wide web is a pretty good model for a distributed sort of network architecture. There's a lot of nice features that HTTP gives us that the traditional remote procedure call more of the sort of soap based style did not. 

So with the loosely coupled rest style we get scalability and we get reliability or just something we'll talk about well ahead. Let's look at some details so obviously we have resources sitting on a server

 And we want to access it from our clients to use a rest full API

We create a URL and that URL identifies which resource on the server we want to access

And then we include one of the HTTP verbs to say what we want to do to that resource

The URL is human readable. Here’s an example so here we're trying to retrieve see the get verb on the front product with an ID of two

And that style right there is one of the most common ones. But rest really isn't prescriptive is more of some architectural guidance.So the details can vary from server to server so for example it's possible that the server you're talking to uses that style with a query string instead of the slash ID that we saw a moment ago.So just check the documentation for the service that you're working with

Look at in just a little more detail at the different operations so the verb get that is used to retrieve a resource

And we'll get back the resource .In this case a product as the body in the response

If we want to create a new resource, we use post

So we serialize the object include it in the body of the post

and then the server will create the resource in its own data store

It will send back to us. Well this is another thing that can vary by server. It’ll contain either the new resource that just got created or maybe just an ID or URL in case we want to retrieve that same resource again later

And use put to update an existing resource

And again you would include the new data as part of your request

and finally use delete to remove a resource

There are other HTTP verbs that we're not going to discuss like option, head and so on. There are some rest services that support these but they're really uncommon. Rest uses the regular HTTP response codes to tell you whether or not the request succeeded or failed . So for example you might get back ok ,not found and so on. So it's probably good idea check those when you get back your response .

Rest also uses the content type flag to tell you the format of the data that you're receiving here we have text xml but you might also get something like application slash Json. Json probably would be more common these days

And then of course in the body is the actual data that you requested. Here is the XML example and one kind of interesting thing about rest is… it’s pretty lightweight there is no extra envelope surrounding the response like there would be in something like soap

 Next we're going to talk about a really nice performance issue. Some of the operations that you do with a server change the data on the server and some don't. Those that don't are called safe so get options in head or considered safe operations so they don't change the server

In the safe operations the results can be cashed obviously you have a cast in the middle and there's different people that would do the caching probably your network provider or your cellular network provider in the case of mobile.

So the first time you call a safe method you have to go all the way to the server of course

 But the response can get cached and then of course sent back to the client

The next time you make that same request you get a response back immediately from the cache without going all the way to the server

 So this is one of the things that gives rest-based service of their scalability and performance.

 Another nice property is that some of the HTTP verbs are idempotent operations and what that means is. If you send off the same request so two requests containing the same data .The two requests or more requests are going to yield the same result on the server. And this is actually a little bit tricky to see .So let's look at a quick example here so these operations are idempotent

and it's probably not surprising that get is one of them

For example if you sent that request to the server, multiple times the state of the server would be the same after each one of those calls. Therefore, that is pretty intuitive.

 I think here's the one that's not so intuitive delete is actually idempotent so what that means is the first time I send this off that's the resulting state of the server after the operation has finished.

If I send that same request again the state of the server won't change. The item in question has already been deleted. This property does not require that the response is the same each time. For example the second time we sent that request it's perfectly fine that we receive a not found because the record doesn't exist the second time.

So the reason you care about this is because idempotent operations can be sent multiple times which means that you can resend a request multiple times without worrying about issues like side effects.

Let's finish off with just a couple of quick guidelines generally these days JSON is recommended mostly because

·          It's smaller and therefore it's more performant.

·          Check your result codes.

·          Resend requests when they are idempotent and safe if you get a timeout.

·          Check the server documentation just to make sure that you understand something like the URL format. Not every service that looks at first like a restful service actually is. There some out there that don't follow many of the rest guidelines so read the documentation.

·          Rest does not include any security specification so it's really up to the server and you as the client are just going to have to use whatever the server requires of you typically these days that'll be OAuth2.

·          And finally prefer secure connections HTTPS to protect your data as it goes across the wire.

Read More