The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

As of MEAP 15 there is no explanation for #2.

I'm piecing together the idea that "ViewModel", in this context, is another bit of MvvmCross "magic".
It seems to resolve to the ViewModel that corresponds to this View? True or False?

You have said that the book is locked down, so additional explanation will wait until some other forum/channel becomes available.
If you have that opportunity please explain how that magic will work, if at all, in a method that is shared across multiple Views. Either in a base class, or a method that is called from multiple Views, which VIewModel will be invoked.
Also, can multiple Views "share", that is invoke methods from, a single ViewModel?

As of MEAP 15 there is no explanation for item #4.
In Chapter 10 there are 2 .axml files, each defining
But, there is only 1 Resource.Designer.cs file defining its value
public const int toolbar_layout = 2131296397;

In the 2 xxxView modules
var toolbar = FindViewById<Toolbar>(Resource.Id.toolbar);
how is this resolved to the toobar for each View?

Are there conditions that would require unique names within each View?

Almost every programming problem has multiple solutions.
Is it correct to think of Bait & Switch and IoC as two solutions to the "how do I access device-specific implementations from my common, .Core logic"?
Rather than prepare 3 separate libraries can I put
Mvx.RegisterType<Interface, Implementation>();
in the application-specific Setup.cs files?

It seems to me that creating 3 libraries (what, exactly, is a "library" in this context?) creates more "moving parts" than keeping all the source in 1 solution, and is thus less error prone.


My goal is to:
1. GET a PKCS12 file from my server.
2. Save the public cert and private key to the Android keystore.
3. Digitally sign 'documents' (JSON messages).
4. PUT the signed message to my server.

I have found classes like (
I have seen how to bind a .jar file, creating Managed Callable Wrappers.
I have found android.jar inside the Android SDK folder.

I am missing the conceptual 'glue' to put those pieces together.
Do I need to extract the .class files I need from android.jar, build my own much smaller jar, and bind it?
Should I expect to already be on the phone? If so, how do I build bindings to it?
If I 'roll my own' (which just seems wrong to me), how do I deal with different API levels on different phones?

Thank you,

Almost like my question about "raw" Xamarin:
Where can I get an example of how to use Android classes (e.g. Signature) when I can not find a Xamarin wrapper?
I understand the concept of JNI, although I have never used it.
Where can I find documentation/guides for this topic, suited for a newbie?
Can the Java code be invoked from both the .Core and .Droid projects?


This may be my dumbest question yet, but here goes:
If I need to step outside the walled garden of MvvmCross, and use Xamarin routines directly (e.g. Signature Pad), what must I be aware of?
Is there a "standard" set of functions/code/techniques that must be used to 'access' 'Xamarin' from 'within' MvvmCross?

Thank you,
This note may find its way to a Revision or a Vol 2 or the cutting room floor.

Underneath Fig 8.25 you mention plugin's and how they are registered (reflection).
1. What is the role of the bootstrap file?
2. What, if any, is the relationship between plugin's and bait & switch?
3. How should plugin's like the FusedLocationApi be used?

So much about the Android and iOS environments (like, all of it) is unknown to me, I don't know how to make tradeoff's.
We seem to share the same FUD: Will navigating, while navigating, break Navigation?
And if so, in what ways? Could I simply run a test and look for a consistent, hard failure?
Or, like non-threadsafe code, expect my first failure a year from now?

Given the way these OS's do memory management, could I:
Create a singleton, lets call it Cache, do all my database fetches into it, rather than local (aka automatic) variables?
Using Mvx.Resolve, each ViewModel could quickly access the data it needs, and I could do the 'heavy lifting' before deciding where to navigate?

Even slicker, maybe, keep the data in the ....Service object itself?


The ViewModel implements UI logic, including Navigation.
All of the examples I can find, either in the book or elsewhere, are user-driven navigation, like button taps.
What about data-driven navigation?
If, while loading data in the Initialize method, a specific condition requires a different screen, how does the ViewModel navigate to a different ViewModel?
Are there restrictions on which methods in the ViewModel can initiate a Navigate request?
What about the back stack of screens? Should I (how do I) remove the screen that was almost, but not quite, shown?
What about the data that was loaded? Is that data available to be passed, via Navigate?

Regarding break: I highly recommend Fiji.
Regarding Vol 2: It took Donald Knuth 3 volumes, and that was before the world started changing at Internet speed.
Just my opinion, but I could see you adding in 'generic' ways, as well as specific.

For example, the "sad path" could be greatly expanded.
Modal windows.
Logging and reporting back to the developer's web site.
What I think of as "conditional" navigation:
Take the email example: If there is only 1 email, maybe we want to skip the list screen and go directly to the detail screen.
If there are 0 emails, maybe display a message about that condition.

Dig into additional details like the Presenter: what they do, how we can harness them.

Returning values from ViewModels to the "calling" ViewModel.

During the construction of the book this forum has functioned as both:
- a feedback mechanism for the specific contents of the book
- a technical forum regarding Xamarin programming

I assume the 2nd use was valuable to you because it gave you feedback about topics the readers felt were interesting/important or needed clarification in the book.
Now that we are weeks away from final publication of the first edition, what are your plans for this forum?
Take a well-deserved vacation and never look at it again? smilie
Continue to monitor/respond so that you can develop the Table of Contents for Volume 2?

Its interesting: The more details you learn, the less sense the initial simplifications make.
Take binding as an example.
You say, in several places, that the MvvmCross binding layer uses reflection to find "the" property.
For example:
local:MvxBind="Text Name" />

If I have multiple classes, each of which has a Name property, how does the MvvmCross binder know which class I'm referring to?
Must all public property names be unique across the whole project?
Can the reference from the layout (axml file) include the class?
local:MvxBind="Text Parent.Name" />


The more I learn, the less I know.
After a few hours 'Googling' I've added a new term to my vocabulary: back stack.
Will Manning let you add a 'teaser' chapter? A preview of Volume 2? I'll buy the MEAP right now. smilie

IMO, the Countr example, with two master/detail screens, is a great introduction: simple enough to explain, complicated enough to be meaningful in the real world.
Because navigation is SO important to GUI's, a few chapters on the human engineering and the programming behind it will be a great next step in your exposition.
Topics like:
- resource consumption
- the back stack
- complex apps with 5-6-7 (or more) screens
- user-driven navigation among the screens
- menus
- everything I don't even know to ask about


The Cheshire Cat (Alice in Wonderland) made it clear: "Words mean exactly what I want them to mean. Nothing more, nothing less.".
As a relative newbie to C#, with a background in C++ and Java, I understand Properties to be a stylized version of private, instance variables with getters/setters. Rather than have the IDE create all that as source code, Microsoft has the compiler do the same work, while the actual source code is very sparse.

My point: I thought you (and Microsoft) indicated that backing fields are specifically associated with Properties. They can be auto-generated by the compiler, or explicitly by the programmer, but the term "backing field" only applies to Properties. True or False?

Thus my confusion when bullet #2 states "The counters service is passed in as a constructor parameter and stored in the
backing field".
Would that sentence be more correct if it stated " the instance variable", or words to that effect?

On the bottom of page 263 you say "...and this database access will be on a background thread.".
Nothing in the code made this conclusion obvious to me, so I backtracked to the top of page 215, where you reveal that SQLiteAsyncConnection provides the 'magic'.
I have not seen you make use of the "link" capability within a pdf. This might be a good place for a link.

I know you have proofreaders.
This might fall somewhere between a bug and my lack of understanding of C# and a typo.
1. Is the compiler auto-creating a private backing field named "name"?
2. It appears that the value of the name is being stored in a member variable in the counter object (
3. The 'if' statement appears to be checking the incoming value against the auto-created private backing field, not the value in the counter object?
4. In addition to the 'magic' of auto-creating a backing field, does the compiler also automatically update that field in the setter method, regardless of any other code we write? That is, both and name are kept in sync?

public string Name
get { return counter.Name; }
if (Name == value) return;
counter.Name = value;
Calibrating your audience is always tough, but I'd like to suggest that people exploring Xamarin are likely to be newbies to mobile in general. That is clearly true for me.

The extent to which my Samsung Galaxy S4 without an SD card acts like a USB-connected filesystem is amazing. The only thing I can't do is assign it a drive letter. Otherwise, Windows Explorer is perfectly happy with it.
Therefore, when PCLStorage said I was getting file at /data/data/com.mycompany.projectname/files/database.db3 I fully expected to see the file in Windows Explorer.
But no such luck.

1. Where are the db3 files stored?
2. As I "junk up" my phone with experimental and otherwise brain-dead databases, how do I clean them up?

Reading Listing 7.8 and the surrounding text I formed the opinion that each table needed its own file.
Clearly not true.
A sentence or two, to that effect, might save someone else from the same misconception.


At almost 600 pages I'm sure Manning is close to saying "enough is enough, already".
Notwithstanding the realities of the technical publishing business, I'd like to suggest either a new section, a "Volume 2", or just a second edition, that includes more details around the sad path.

Listing 5.6 makes the point that exceptions must be caught.
FWIW, I fully agree.
As a server-side programmer I always had a logging mechanism, Operations folks to monitor the log, and HTTP 500 to tell the client side programmers that something just went sideways.

Bringing together Listing 5.6 and SQLite-net-pcl, what are your recommendations for where to 'catch' the exception: repository, service, viewmodel or model?
1. How to expose the failure to the UI?
2. How to inform the developer of the failure details?

Thank you again,
Two points:
Have you or Manning considered releasing updates more frequently? More like CI for a programming team, with a "stable" and "daily" branches?
It would prevent people like me from reporting things that have already been fixed.
It will also get "team review" of the changes, not that we ever introduce bugs with our fixes. smilie

You say "In computing terms, a thread is a thread of execution—".
It is generally not a good idea to use a word in its own definition.
Elsewhere you say things like 'a thread is a sequence of executed instructions'.

You recommend registering all the Services as singletons with the IoC container.
You recommend implementing longer running tasks as multiple background threads.

I'm concerned about the instance variables in the classes.
Is there any Xamarin/Android "magic" that makes the single object thread-safe?
Is that my responsibility?

I started out as an operating system programmer on an early timesharing system.
I have always been a bit skeptical of attempts by application programmers to run things "in parallel".
Once the service is "safe", isn't that a euphemism for single threaded, but with all the complexity of apparent parallelism?

I know that Manning has a team that will eliminate 'typos'.
In technical books, "typos" come in flavors, some of which only a developer will notice.

You say "Copy this from the various size
folders to the relevant folders in the app, and add the code in listing 10.4. to the layout
inside the frame layout."

I think "frame" should be "relative".

After 50 years as a software engineer I decided to write my first GUI program, so I'm still coming up to speed on the Xamarin ecosystem.
I can see why you chose not to include menus: it seems they would take a book by themselves to cover properly.

Since you do cover Navigation, you may find this question within the scope of this forum:
NavigationDrawer's seem to require Fragments. True or False?
Fragments seem to be small pieces of UI (sub-screens, if you will) that are swapped into a "parent" view.

1. Can I have a code-behind file for a fragment?
2. Can I have a ViewModel for the "parent" view?
3. And the real question: Can I use Mvvm 5.x style Navigation to show other Views entirely from within a Fragment?

Without knowing the innards of the Android OS I have no idea if I would be leaking resources like crazy, leaving stranded views on a stack or other bad things.

My app has a natural flow to it. Navigation will expose the 'next' view/viewmodel pair as appropriate.
The purpose of a Menu is allow the user to 'jump', out of sequence, to any View they choose, like a hyperlink.

Thank you,
Where does MvvmCross publish the dependencies for each release?
For example, the SquareRt project uses MvvmCross 5.2.1 and Xamarin...
Yet I see warnings that suggest the Nuget package versions might not be compatible.

Because I'm starting a new Android/iOS project, I assume a developer should always start with the newest MvvmCross, currently 5.6.3.
Most bug fixes, etc.
How do I know what version of Xamarin packages to use?
Again, newest seems best, but only if they are compatible.

OK, I'll made a donation to the OpenCollective.

I know Microsoft bought Xamarin in 2016.
How does MvvmCross fit into that lashup?
How do you fit into Microsoft, Xamarin and MvvmCross?

Continuing on this thread:
You say "This means we must have a small part of our value conversion in platform-specific code, using value

1. Which project contains this platform-specific code? .Core or .Droid?

On page 70 the diagram shows what appear to be two classes: BoolToViewStatesValueConverter and BoolToHiddenValuesValueConverter.

2. Although not shown, is it correct that the .axml file for each platform will reference the correct method for the platform?

At the very end of section 3.4.4 you ‘tease’ the reader by mentioning MvxVisibilityValueConverter.

3. How should that class be used? How does it know if it being invoked from Android or iOS specific .axml files? That is, how does it know what kind of values to return?

For this reader, at least, the topic of Value Converters needs a few more words.
If you have the time, please add a complete example of how to control the visibility of a button.

I took advantage of Manning's year end sale.
I mean that in the worst sense of the word.
This book is absolutely worth the full asking price.
How do I send you the extra twenty bucks?

I'm working my way thru value converters.
I can see:
local:MvxBind="Text Number, Converter=DoubleToString"
local:MvxBind="Text Result, Converter=DoubleToString" />
-rwxr-xr-x@ 1 mfeldman 1063665260 2084 Oct 25 22:44 ./Chapter 11/SquareRt/SquareRt.Droid/Resources/layout/squarert_view.axml

And I can see:
public class DoubleToStringValueConverter : IMvxValueConverter
-rwxr-xr-x@ 1 mfeldman 1063665260 617 Oct 25 22:44 ./Chapter 11/SquareRt/SquareRt.Core/ValueConverters/DoubleToStringValueConverter.cs

What I can not see is how the string "DoubleToString" ends up referencing the class DoubleToStringValueConverter"?
Is that just part of the MvvmCross "magic"? For Android, but not iOS, it slaps "ValueConverter" at the end?

Thank you,
These may stoop to the level of "typos". I'll let you decide.

You say "Let’s see how the SquareRt app code can be divided up between layers. We can take
the user flow we’ve defined and map it across the layers. This is shown in figure 6.25"
Should this be Figure 6.11, immediately below the text?

You say "This
very quickly leads to three classes that are the main structure of our app, as shown in
figure 6.26."
Should this be figure 6.12, immediately below the text?

On page 299 you say "These toolbars are available in the Android SDK on
Lollipop and later, and in the support library for earlier OS versions. Seeing as we want
to support as many versions as possible we’re going to use the support library version of
the toolbar."

I know the book could be infinitely long if you included everyone's suggestion.
Like all suggestions, this is your call.

Is it useful to add 2 or 3 sentences to show how programmers can select which toolbar (SDK or support library) to use?

If this was Java the answer might talk about which jar's to put in the classpath and/or which packages/classes to reference.

On page 294 you say "There are two types of these UI elements - views (not to be confused with
MVVM views) and view groups. Views are widgets - UI controls that users can interact
with, such as buttons and text boxes."

Does it make sense to use term layout instead of "view group" and widget instead of "view".
I'm extremely new to Xamarin/Android but I think I seen those terms used elsewhere.

Thank you for a GREAT book,
Two nit picks with Table 9.1:
1. Please add a section describing purpose of the values-v21 folder.
2. The menu section indicates that toolbars should be in /menu folder.
As shipped, the project puts the toolbar.xaml file in the /layout folder.
Please reconcile

On page 292 you recommend using all lower case and underscores for the names of XML files.
Yet, 4 lines above, the FirstView.axml file that ships with the example code is camel case.

Much more important that my personal preference (I like CamelCase) is how the binding code operates.
If axml files follow the lowercase & underscore standard, how does that impact ViewModel .cs files?

In your opinion, should a bug be filed with MvvmCross?

Good job. Thank you.
"State" is perhaps the most pernicious topic in software engineering.
On page 53 you explain how the ViewModel class should be stateless, while it should obtain its state from the Model.

What about the state of the UI? For example, visibility of widgets?
I understand it is the ViewModel's responsibility to change the state of a widget. True or False?
Where should that state be remembered? In the properties of the widgets themselves?

Thank you,