Yep, I thought the same after I asked the question:

Each model now looks like this, so they all have a primary key with autoincrement:

public class MyModel : BaseModel {

    public int Id {get; set; }

    //...other properties

}

public abstract class BaseModel {

    [PrimaryKey, AutoIncrement]
    public int PrimaryKey { get; set; }

}

Same for us.
Xamarin.Forms: 3.6.0.264807
Xam.Plugin.Iconize.FontAwesome, both versions 3.5.0.115 and 3.5.0.117 are not working as expected.

Version 3.5.0.114 is fine. At least with FontAwesomeSolidModule.
<iconize:IconLabel FontSize="20" Text="fas-circle" TextColor="DarkOrange"/>

I have an active googol places autocomplete working with Xamarin Forms or Cross Platform. I have a working solution that auto populates the address when the user types in the address. My problem is when the user selects it from the list the address does not go to the search_bar.text… The search bar just remains with the text that was typed.? how can I get the text when selected to populate in the search bar.
FYI I am new to Xamarin forms and C# so pls be specific as possible thx.

void Search_Bar_PlacesRetrieved(object sender, AutoCompleteResult result)
{
    results_list.ItemsSource = result.AutoCompletePlaces;
    spinner.IsRunning = false;
    spinner.IsVisible = false;

    if (result.AutoCompletePlaces != null && result.AutoCompletePlaces.Count > 0)
        results_list.IsVisible = true;
}

void Search_Bar_TextChanged(object sender, TextChangedEventArgs e)
{
    if (!string.IsNullOrEmpty(e.NewTextValue))
    {
        results_list.IsVisible = false;
        spinner.IsVisible = true;
        spinner.IsRunning = true;
    }
    else
    {
        results_list.IsVisible = true;
        spinner.IsRunning = false;
        spinner.IsVisible = false;
    }
}

async void Results_List_ItemSelected(object sender, SelectedItemChangedEventArgs e)
{
    if (e.SelectedItem == null)
        return;

    var prediction = (AutoCompletePrediction)e.SelectedItem;
    results_list.SelectedItem = null;

    var place = await Places.GetPlace(prediction.Place_ID, GooglePlacesApiKey);

    if (place != null)
        await DisplayAlert(
            place.Name, string.Format("Lat: {0}\nLon: {1}", place.Latitude, place.Longitude), "OK");

} 

When the user clicks the back button to return to your TakePhotoPage, the file is null. You could detect this behavior through this variable's value:

if (file == null)
{
    // This means come to this page with back or cancel button
    // Navigate to the page as you want    
}

Hi. You couldn't find any resources? Where did you look?

Try this, it's an introduction to Azure Easy Tables which demonstrates Web APIs
https://devblogs.microsoft.com/xamarin/getting-started-azure-mobile-apps-easy-tables/

For storing images, you can use Blob Storage
https://devblogs.microsoft.com/xamarin/xamarin-plus-azure-blob-cloud-storage/

I found this is not only an issue with text wrapping, but also wrapping content within flex layout. If you have a view with multiple content containers (some being flex wrap), the overall height has issues calculating. I hope this bug gets fixed in the newer Xamarin updates

For me, it was my stupidity that caused this problem. I created an initial page via xaml and wished to implement that template across additional pages. In my laziness, i succumbed to a copy - paste error. The line that did it for me was the x:Class...

@jezh I noticed that a sample code using ListView did not exhibit the same problematic behavior, so I tracked down the difference.

It's related to how NotifyCollectionChanged messages are interpreted, where on UWP the ListView is more picky than on Android.

My Remove messages were sent using
OnCollectionChanged(new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Remove, item));
This seemingly triggered a reset of the Listview - for every remove the list scrolled to the top.

When I changed to use the constructor with item position
OnCollectionChanged(new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Remove, item, oldIndex));
then the expected behavior did indeed happen - the item was removed and items below moved up to fill the void.

In summary, this is a lesson for when not using an ObservableCollection base for your collection class - if you do your own CollectionChanged notification then make sure it behaves exactly like ObservableCollection. Following documentation and guidelines is not enough.

I'm not sure whether to call this a bug or poor documentation. My expectation on behavior was based on documentation, behavior on Android, and runtime output (no errors, warnings or log messages). On UWP expectations were not met, whereas on Android they were.