Customizing a Xamarin Forms Application, Part 2

Url: https://visualstudiomagazine.com/articles/2016/11/01/xamarin-forms-application-part-2.aspx
In an earlier column on Xamarin Forms app customizing, I looked at how realistic it is to create a Xamarin Forms (XF) application and how close it can tie to the platform. How close does an XF application look in comparison to an iOS and Android application? Now that my startup has been using the application, we found a few items that were "wanting":

• Saving log-in information. When an app is loaded, no one wants to continually type in a name and password. Users want to just load the application and go with it.
• Network requests. When a network request is ongoing, such as an upload, what kind of information is communicated back to the user? Is it just the activity indicator or is more possible?
• Network availability. Is there some mechanism to check for a 3G/4G/Wi-Fi network? If there is no network, the application should communicate this to the user or at least not crash.

I'll look at these nagging features and how to improve the UX of the application.

Android 7 with Xamarin

Url: https://visualstudiomagazine.com/articles/2016/12/01/multiwindow-mode-via-xamarin.aspx
Xamarin has updated Xamarin.Android to support the latest version of Android -- version 7, aka. Nougat -- that was made available in mid-August. My Nexus 6p and Nexus 7 have both been updated to Android 7 since then, and developers have all of the sweet, gooey goodness necessary to build applications for it.
While Android 7 doesn't appear to be a major update, there are some new items in it that are rather interesting:

• Multi-Window API: Users can open two apps on the screen at once, assuming that the screen on the device is large enough to support more than one app.
• Notification Enhancements: The notifications system was redesigned to include a direct reply feature. Users can reply directly to messages from the notification UI.
• Data Save: The Data Saver is a new system service that helps to reduce cellular data use by applications. It does this by giving users control over how applications use cellular data.

Other features of interest to developers include network security configuration, doze on the go, key attestation, new Quick Settings APIs, multi-locale support, ICU4J APIs, WebView improvements, Java 8 language features, directory access, custom pointer API, platform virtual reality (VR) support, virtual files and background processing optimizations.

App-to-Market: Locking In Technology Options for Your Startup

Url: https://visualstudiomagazine.com/articles/2016/12/02/startups-does-technology-matter.aspx

How crucial is the technology you choose to run it and build apps? It almost doesn't matter, as long as your chosen path provides enough options to deliver to customers the solutions they need. We look at the Microsoft stack as an example.
You've been working in a company that has its own data center with servers sitting in racks. You got training on how to use and deploy solutions on them using a combination of Visual Studio, .NET, servers, Cisco, and a bunch of other enterprise-grade technologies.
You have ideas for some apps and you've been getting ready to venture out on your own. To get a feel for what it might be like, you attend several startup competitions. No one at those competitions are using any technology related to .NET. Some of the attendees you talked with say that knowledge of the Microsoft technology stack isn't useful in a startup. They've even got you second-guessing your choices.
Now you're wondering, "I've got all of this .NET knowledge, but they say that .NET isn't startup friendly; what am I going to do now?"
Note: Since this is Visual Studio Magazine, this article will have a .NET slant to it. Don't worry; I recognize the bias; even then, you can really take a language- and platform-agnostic approach to tool choice for your startup. Just about every stack has something for every facet of building apps.

Speech Recognition in iOS 10 and Xamarin

Url: https://visualstudiomagazine.com/articles/2016/10/01/xamarin-support-ios-10-speech.aspx

On September 7 Apple introduced it's newest phone operating system, iOS 10, a gold master version of the XCode programming language and the iOS SDK Xamarin followed up the next day with binding support for iOS10 APIs, and developers were off to the races. Apple supplied the final releases of iOS10 and developer tools the next week after, and Xamarin had updates in less than 24 hours.

Technology happens that quick these days.

In this and future articles (depending on how you respond to this one), I'll highlight some of the new features in iOS10 and Xamarin's support of these features. Since we aren't going to attempt to cover everything here, I'd like to look especially at what I think will be useful now, and this time we'll cover speech recognition capabilities to get you started. Speech recognition is getting more useful as an input option for apps where users need to be less distracted (when driving, for example).

Thoughts on Investment Money (for Technology Startups)

It is hard to say no to investment money.  It really is.  Who doesn't want to "roll in the dough."  

However, I think it is somewhat important to understand what to do and what makes sense.  Unless you have a great idea with a team that is awesome and have already proven the items I am about to list out, then this isn't really for you.

If all you have is an idea, don't take much/any money.  Venture and angel money chased ideas in the rollup to the dotcom bubble bursting.  They don't want to do that again.  You won't get any from anyone outside the 3Fs, but it is important to not take money to early.  Who wants the awkward family dinner?  Ah yes, nothing brings a family together more than the awkward fight about money, politics, and religion.  If you want to see some love, go to a family event where you've lost $75k of the family's money and say something like "I'll just do better the next time."  Another good one is to be sitting there and your mother say something like "My son lost $75k of our money this year on a stupid idea, how has everyone else been doing this year?"  Yeah, those could be fun times.  Assuming that everyone was on the up-n-up and it is just bad blood, not stealing that occurred, these are times when you really just want to slink out the door and head home.  In case #1, there won't be a next time.  No one from the family will make another investment.  It does not appear that the "son" had a good idea.  He didn't take the money seriously anyway with that flippant attitude.  In the 2nd case, the family did not understand the risks of investing in technology.  Typical technology investing is either win big or 100% loss.  There usually is not place in between.  In neither case will the 3Fs ever invest again.  Neither will the son/daughter ever make the ask again.  This is just an awkward situation for years to come.

There is a next step after having an idea and creating an MVP.  You show it to people, get their feedback, and work on someone to pay for it.  Now that you have a theory on how to make money, you have to actually go get them to pay money.  Basically, you have to go prove your theory.  Get people to like what you build, bring them some value, you scrape off some of the value, and lather, rinse, repeat many times.  

Hopefully, this is a short time frame between idea, to mvp, to feedback, and to income.  If you can do this, you have eliminated some amount of risk.  The elimination of some amount of risk is good.  You won't be able to eliminate all of the risk associated with a startup, but you can eliminate some of the risk of the startup.  Eliminating some of the risk of a startup will definitely help you with raising some amount of angel/venture capital.  And it will definitely make Thanksgiving dinner a bit less noisy.

Xamarin Forms Thoughts - Use the Right Tool For the Job

If you've landed here, hopefully, you've read my initial thoughts on Xamarin.Forms in my article at: https://visualstudiomagazine.com/articles/2016/09/01/how-platform-specific-can-you-go.aspx.  Because it is listed as Part 1, there is obviously a Part 2 that may or may not have been posted by now. 

Note: I respect Jason Smith and his group at Xamarin immensely.  My complaint is not with his group.  His guys are smarter than I am.  They have forgotten more about mobile platforms than I will ever know.  My complaint is that too many developers are using Xamarin.Forms in a way that leads to failure.  They turn around and blame the technology, when they should be blaming the decision maker for using the wrong tech.

I wanted to take some time to expand on my thoughts on Xamarin.Forms.  I've copied out the first part of my article to give a baseline for my thoughts.

My personal beliefs on cross-platform development were formed in November 1993. I worked at The Coca-Cola Company at the time, and a few colleagues and I were discussing how to provide Mac users with the same set of applications that we were building on Windows 3.1 with PowerBuilder.
The discussion centered around the UI. The concern was with providing a Windows-centric interface to Mac users. I remember one of the great lines from the meeting: "If you provide Windows help to a user expecting Mac balloon help, you are going to have users that hate you." After this and some personal experiments, I came to agree with this viewpoint. If developers want to make users as happy as possible, they need to call the native APIs of the platform.
Fast-forward to 2009, when I fell in love with the Xamarin iOS product from the first announcement. Xamarin had created a way for C# developers to use the Microsoft .NET Framework and to call into the native platform APIs. Xamarin Android operated the same way. While I would often discuss the need for a cross-platform UI with Xamarin management, I never forgot the lessons of cross-platform from many years ago. At the same time, I knew that there was a need for a cross-platform toolset to create an application. I had talked to enough people to understand the pain and agony. Quite honestly, I was a fence sitter in this area. I liked the idea of XF, but I was never quite ready to make the jump and, honestly, try XF for anything more than some personal experiments and helping a couple of customers.
The problem with cross-platform tools is that they tend to target the lowest common denominator. This commoditizes the UI. This isn't necessarily a bad thing. Time to market can be improved. There are lots of applications that don't need a fully optimized platform. There are a number of applications where getting something out quickly and solving a business problem can be the most important factor.
There's no "one size fits all" solution no matter what some faction wants to preach. Some applications have very device-specific needs -- some applications don't -- it very much depends on the situation. Users, the ones who pay for development, tend to want applications that look, smell and taste like every other application that they already have. The worst possible situation to get yourself into is the one where you start down the road of using a cross-platform framework, and the users demand so many features that are platform-specific that it would've been easier and cheaper to have just built two or more platform-specific applications. That is a special type of hell. I've been there, and it's a bad conversation to have with a paying customer. The bottom line is that you need to have a real-world discussion with your users and the people that sign the checks. No one will quite understand it, but morally, you really need to have this conversation in the consulting world.

To help solve the cross-platform problem, Xamarin has produced Xamarin.Forms and added this product to the list of tools for developers. XF is a cross-platform API that maps to device-specific APIs. This article will delve into an examination of Xamarin.Forms with an application that I had to write for our startup and how well it meets several requirements:

• How well does it display on a platform? How much platform-specific code is necessary? Does the application "look" like a native platform?
• When a developer has to resort to native API calls, how easy is it? Can it be done? Does it work?
• When something else has to happen, how much third-party support is there?

There's lots of discussion regarding what types of apps work with XF. What types of apps should a developer target with XF? There's a set of apps that work well, and there's a set of apps that I'd be concerned about using with XF. Apps that work well with XF include:

• Internal company applications. Internal apps tend to be heavily data-bound. Solving the business problem is the most important thing.
• Applications that don't need to customize the UI. The more customization of the UI, the less an XF app makes sense.

It's into this world that XF sits, and a ton of developers see Xamarin.Forms as the holy grail, the solution to all of their problems, the cross platform magic, free safe sex, etc.  Let me be clear (as our President likes to say), there are a certain set of applications that work really well with Xamarin Forms, and there are a certain set of applications that do not.  I've listed out the types of apps that work well, let's look at the type of apps that do not.  These are:

• Customer facing applications.  Customer/Consumer facing applications tend to need lots of UI customization.  Customers want applications that look, smell, and taste like all of the other applications on the devices.  Give them a windows app that runs on their mac and they will burn you in effigy forever.  XF can do a lot of things, but its not magic.  It is not going to solve every problem and there will be some things that it limits you from doing.  Nothing is as embarrassing as someone pulling their phone out and saying "This app does this, why doesn't ours?" and then having to explain the problems with cross platform development tools.  You can easily spend a lot of time, much more than was budgeted for, to do all the little UI specific cool things that makes a marketing manager happy.  Somebody's got to pay for this time, it ain't going to be me.
• Performance driven applications.  If an application needs the utmost in performance, a cross platform tool will probably not be the right tool.  You want as few layers in your application as is possible and make sense.

What are the mistakes that I see happening?  They tend to be numerous.  I'll try to summarize them here:

• No, no, no, shoehorning XF into every application that you could ever want to build and magically getting iPhone, Android, Windows, etc. out the other side is not a good idea.  I see this one over and over and over.  XF is not a hammer and everything is not a nail.  It sounds cool.  It is the siren's call of developers.  It has rarely worked great (dare I say ever) in the past.  You have to take each individual application requirement and use the appropriate tool to build it.
• XAML.  This is another tool I'm not convinced is the best idea to use.  Yes, there are a lot of XAML developers in the MSFT space.  That doesn't mean that using XAML is a good idea in a mobile application.  Currently, the XAML tools are in their infancy (alpha or beta level).  There is going to be a growing pain with them.  My guess, and I have no data to back this up, is that there are performance problems under the hood with respect to Android and I bet that these problems happen when using XAML.  Why?  If you build a native layout in Android with it's xml, there is a lot of work that the android layout subsystem has to do for a deeply nested Android layout.  This is time.  I bet that there is some work done to turn a XAML layout into an Android layout that is happening behind the scenes, then the Android layout subsystem has to take over and do it's work.
• Android is slow.  It is a horrible resource hog.  My iOS golf app runs great in the iPhone.  The Android version runs great, but it is an up to date nexus 6p.  There is lots of complaining about performance in the Xamarin Forums with regards to performance in Android.  This so reminds me of 2011 when Xamarin.Android had performance problems.  Eventually, the Xamarin.Android problems got solved.  Eventually, the XF problems in Android will be solved.  Dang, there is a lot of pain right now.
• Lots of Android phones are old.  Let's be clear. iPhones turn over every 2-3 years.  Most of the people I know update every 2 years.  There are lots of android phones out there that are older.  How many people are out there running Android 4.x phones or phones that originally came with Android 4.x?  The answer is a lot.  As of today (10/12/2016), Android 4.x and earlier is over 40% of the Android phone marketplace.  There are a lot of old phones out there.
• I've seen 3 XF apps up close and personal beyond my work.  1 worked fine because it was nothing more than a wrapper around html.  The other two had a lot of performance issues on Android.  It's easy to say that the developer was at fault, but there also has to be something for the developer not being given full information as to the reality of XF on Android.  Just expecting them to become aware of a performance problem on their own is tantamount to lying.  There needs to be some indication that there are performance issues, the situations where these occur, and how to mitigate them.  There is mostly silence on the matter.
• It seems that you have to add lots of third party components to get an XF solution to work.  Will these components be kept up to date?  Will they be supported under future versions of iOS, Android, etc?  Do they really work?
• And then there are all the classic software development mistakes that happen.  My favorite being the management adage: We've hit a bump in the road, let's get someone that uses this stuff all the time for the little tweeks that we need.  No, no, and no.  By the time a problem has been found by users, it is typically too late.  The only good solution at this point is to just start over.  Management fights back with: we've already spent all of this money, we can't just dump what we have and start over.  Me: what you have doesn't work.  FYI, I get pulled into this issue all the time.  My response now is just to blanket direct the company to start over.  No amount of pulling someone else in is going to solve a problem. 

To tie this together, XF works great in small applications.  It works great in internal company applications.  Not so much in consumer facing applications.  Not so much in user facing situations.

Ok, great, so what are you supposed to use?  Use Xamarin.iOS, use Xamarin.Android.  Learn the platform specific features.  These will solve your problems.  You'll be able to take advantage of platform specific stuff that makes an iPhone app an iPhone app or an Android app an Android app.  Your users will like it much better.  Yes, this will probably cost more than building one app to rule them all, but you'll probably have more success as well.  Still want to use XF?  Fine, then embed some XF in your iOS and Android applications.  This will limit your exposure to problems and lower your risk.  While people say that they are worried about cost, they really need to be worried about something more basic, which is success (at least they should be).  I would question the ability to be successful if you are building a major consumer facing application with Xamarin.Forms.  Small applications, I'm not worried about.  Applications built with Xamarin.iOS and Xamarin.Android, I'm not worried about.

PS. I love the XF bug where it displays the label in the wrong color on the Galaxy s4.  That's a nice one to get thrown in your face when you are testing and showing what you have built.

PSS. But Wally, you love Xamarin Forms according to your articles.  No, I love solutions.  XF fits a part of the cross platform problem.  Not all applications fit into the space of "I need something quick that works for iOS & Android and don't care that much about the UI."  My example picture taking app for golf fit into that space.  Just because I would build my picture taking golf app in XF means that it is suitable for every situation.  And btw, my golf app is pretty robust now.  It worked really well in some low quality cell connectivity areas last week.

PSSS.  I was finally able to find a solution to my problem of already having an image in a byte[].  Here it is: https://forums.xamarin.com/discussion/17882/blob-to-image-binding.  I'll probably be talking about this in a future article.  :-)  How I missed this post previously, I don't know, but I am glad to find it.

Xamarin Forms Thoughts - Use the Right Tool For the Job

If you've landed here, hopefully, you've read my initial thoughts on Xamarin.Forms in my article at: https://visualstudiomagazine.com/articles/2016/09/01/how-platform-specific-can-you-go.aspx.  Because it is listed as Part 1, there is obviously a Part 2 that may or may not have been posted by now. 

Note: I respect Jason Smith and his group at Xamarin immensely.  My complaint is not with his group.  His guys are smarter than I am.  They have forgotten more about mobile platforms than I will ever know.  My complaint is that too many developers are using Xamarin.Forms in a way that leads to failure.  They turn around and blame the technology, when they should be blaming the decision maker for using the wrong tech.

I wanted to take some time to expand on my thoughts on Xamarin.Forms.  I've copied out the first part of my article to give a baseline for my thoughts.

My personal beliefs on cross-platform development were formed in November 1993. I worked at The Coca-Cola Company at the time, and a few colleagues and I were discussing how to provide Mac users with the same set of applications that we were building on Windows 3.1 with PowerBuilder.
The discussion centered around the UI. The concern was with providing a Windows-centric interface to Mac users. I remember one of the great lines from the meeting: "If you provide Windows help to a user expecting Mac balloon help, you are going to have users that hate you." After this and some personal experiments, I came to agree with this viewpoint. If developers want to make users as happy as possible, they need to call the native APIs of the platform.
Fast-forward to 2009, when I fell in love with the Xamarin iOS product from the first announcement. Xamarin had created a way for C# developers to use the Microsoft .NET Framework and to call into the native platform APIs. Xamarin Android operated the same way. While I would often discuss the need for a cross-platform UI with Xamarin management, I never forgot the lessons of cross-platform from many years ago. At the same time, I knew that there was a need for a cross-platform toolset to create an application. I had talked to enough people to understand the pain and agony. Quite honestly, I was a fence sitter in this area. I liked the idea of XF, but I was never quite ready to make the jump and, honestly, try XF for anything more than some personal experiments and helping a couple of customers.
The problem with cross-platform tools is that they tend to target the lowest common denominator. This commoditizes the UI. This isn't necessarily a bad thing. Time to market can be improved. There are lots of applications that don't need a fully optimized platform. There are a number of applications where getting something out quickly and solving a business problem can be the most important factor.
There's no "one size fits all" solution no matter what some faction wants to preach. Some applications have very device-specific needs -- some applications don't -- it very much depends on the situation. Users, the ones who pay for development, tend to want applications that look, smell and taste like every other application that they already have. The worst possible situation to get yourself into is the one where you start down the road of using a cross-platform framework, and the users demand so many features that are platform-specific that it would've been easier and cheaper to have just built two or more platform-specific applications. That is a special type of hell. I've been there, and it's a bad conversation to have with a paying customer. The bottom line is that you need to have a real-world discussion with your users and the people that sign the checks. No one will quite understand it, but morally, you really need to have this conversation in the consulting world.

To help solve the cross-platform problem, Xamarin has produced Xamarin.Forms and added this product to the list of tools for developers. XF is a cross-platform API that maps to device-specific APIs. This article will delve into an examination of Xamarin.Forms with an application that I had to write for our startup and how well it meets several requirements:

• How well does it display on a platform? How much platform-specific code is necessary? Does the application "look" like a native platform?
• When a developer has to resort to native API calls, how easy is it? Can it be done? Does it work?
• When something else has to happen, how much third-party support is there?

There's lots of discussion regarding what types of apps work with XF. What types of apps should a developer target with XF? There's a set of apps that work well, and there's a set of apps that I'd be concerned about using with XF. Apps that work well with XF include:

• Internal company applications. Internal apps tend to be heavily data-bound. Solving the business problem is the most important thing.
• Applications that don't need to customize the UI. The more customization of the UI, the less an XF app makes sense.

It's into this world that XF sits, and a ton of developers see Xamarin.Forms as the holy grail, the solution to all of their problems, the cross platform magic, free safe sex, etc.  Let me be clear (as our President likes to say), there are a certain set of applications that work really well with Xamarin Forms, and there are a certain set of applications that do not.  I've listed out the types of apps that work well, let's look at the type of apps that do not.  These are:

• Customer facing applications.  Customer/Consumer facing applications tend to need lots of UI customization.  Customers want applications that look, smell, and taste like all of the other applications on the devices.  Give them a windows app that runs on their mac and they will burn you in effigy forever.  XF can do a lot of things, but its not magic.  It is not going to solve every problem and there will be some things that it limits you from doing.  Nothing is as embarrassing as someone pulling their phone out and saying "This app does this, why doesn't ours?" and then having to explain the problems with cross platform development tools.  You can easily spend a lot of time, much more than was budgeted for, to do all the little UI specific cool things that makes a marketing manager happy.  Somebody's got to pay for this time, it ain't going to be me.
• Performance driven applications.  If an application needs the utmost in performance, a cross platform tool will probably not be the right tool.  You want as few layers in your application as is possible and make sense.

What are the mistakes that I see happening?  They tend to be numerous.  I'll try to summarize them here:

• No, no, no, shoehorning XF into every application that you could ever want to build and magically getting iPhone, Android, Windows, etc. out the other side is not a good idea.  I see this one over and over and over.  XF is not a hammer and everything is not a nail.  It sounds cool.  It is the siren's call of developers.  It has rarely worked great (dare I say ever) in the past.  You have to take each individual application requirement and use the appropriate tool to build it.
• XAML.  This is another tool I'm not convinced is the best idea to use.  Yes, there are a lot of XAML developers in the MSFT space.  That doesn't mean that using XAML is a good idea in a mobile application.  Currently, the XAML tools are in their infancy (alpha or beta level).  There is going to be a growing pain with them.  My guess, and I have no data to back this up, is that there are performance problems under the hood with respect to Android and I bet that these problems happen when using XAML.  Why?  If you build a native layout in Android with it's xml, there is a lot of work that the android layout subsystem has to do for a deeply nested Android layout.  This is time.  I bet that there is some work done to turn a XAML layout into an Android layout that is happening behind the scenes, then the Android layout subsystem has to take over and do it's work.
• Android is slow.  It is a horrible resource hog.  My iOS golf app runs great in the iPhone.  The Android version runs great, but it is an up to date nexus 6p.  There is lots of complaining about performance in the Xamarin Forums with regards to performance in Android.  This so reminds me of 2011 when Xamarin.Android had performance problems.  Eventually, the Xamarin.Android problems got solved.  Eventually, the XF problems in Android will be solved.  Dang, there is a lot of pain right now.
• Lots of Android phones are old.  Let's be clear. iPhones turn over every 2-3 years.  Most of the people I know update every 2 years.  There are lots of android phones out there that are older.  How many people are out there running Android 4.x phones or phones that originally came with Android 4.x?  The answer is a lot.  As of today (10/12/2016), Android 4.x and earlier is over 40% of the Android phone marketplace.  There are a lot of old phones out there.
• It seems that you have to add lots of third party components to get an XF solution to work.  Will these components be kept up to date?  Will they be supported under future versions of iOS, Android, etc?  Do they really work?
• I've seen 3 XF apps up close and personal beyond my work.  1 worked fine because it was nothing more than a wrapper around html.  The other two had a lot of performance issues on Android.  It's easy to say that the developer was at fault, but there also has to be something for the developer not being given full information as to the reality of XF on Android.  Just expecting them to become aware of a performance problem on their own is tantamount to lying.  There needs to be some indication that there are performance issues, the situations where these occur, and how to mitigate them.  There is mostly silence on the matter.
• And then there are all the classic software development mistakes that happen.  My favorite being the management adage: We've hit a bump in the road, let's get someone that uses this stuff all the time for the little tweeks that we need.  No, no, and no.  By the time a problem has been found by users, it is typically too late.  The only good solution at this point is to just start over.  Management fights back with: we've already spent all of this money, we can't just dump what we have and start over.  Me: what you have doesn't work.  FYI, I get pulled into this issue all the time.  My response now is just to blanket direct the company to start over.  No amount of pulling someone else in is going to solve a problem. 

To tie this together, XF works great in small applications.  It works great in internal company applications.  Not so much in consumer facing applications.  Not so much in user facing situations.

Ok, great, so what are you supposed to use?  Use Xamarin.iOS, use Xamarin.Android.  Learn the platform specific features.  These will solve your problems.  You'll be able to take advantage of platform specific stuff that makes an iPhone app an iPhone app or an Android app an Android app.  Your users will like it much better.  Yes, this will probably cost more than building one app to rule them all, but you'll probably have more success as well.  Still want to use XF?  Fine, then embed some XF in your iOS and Android applications.  This will limit your exposure to problems and lower your risk.  While people say that they are worried about cost, they really need to be worried about something more basic, which is success (at least they should be).  I would question the ability to be successful if you are building a major consumer facing application with Xamarin.Forms.  Small applications, I'm not worried about.  Applications built with Xamarin.iOS and Xamarin.Android, I'm not worried about.

PS. I love the XF bug where it displays the label in the wrong color on the Galaxy s4.  That's a nice one to get thrown in your face when you are testing and showing what you have built.

PSS. But Wally, you love Xamarin Forms according to your articles.  No, I love solutions.  XF fits a part of the cross platform problem.  Not all applications fit into the space of "I need something quick that works for iOS & Android and don't care that much about the UI."  My example picture taking app for golf fit into that space.  Just because I would build my picture taking golf app in XF means that it is suitable for every situation.  And btw, my golf app is pretty robust now.  It worked really well in some low quality cell connectivity areas last week.

PSSS.  I was finally able to find a solution to my problem of already having an image in a byte[].  Here it is: https://forums.xamarin.com/discussion/17882/blob-to-image-binding.  I'll probably be talking about this in a future article.  :-)  How I missed this post previously, I don't know, but I am glad to find it.

Smoky Mountain Boys and Girls Club Charity Golf Event

On October 5th, we ran the Smoky Mountain Boys and Girls Club Charity Golf Event.  This was using our golf scoring application.  The application is built on Microsoft Azure and uses Xamarin for some of the club management pieces, such as picture taking (Note the picture shown in the scoreboard below).  The event had 65 teams spread across two courses (River Course and Highlands Course at the Sevierville Golf Club).  Originally, there were 67 teams, however 2 did not show.  The system will allow teams to be entered, grouped together, flighted, etc.  There are two key items for the event:

• Additional sources of revenue.  The scoreboard & scorecard provides for sponsorship placement.  Notice in the picture the three sponsors in the header.
• The amount of time saved in team scoring, totaling, breaking ties, flighting, and etc. that occur after the event.  On an event this size, these typically take 1-1.5 hours and are prone to human error.

River Course Scoreboard: https://golfeventscores.azurewebsites.net/PublicScores/SingleScoreMultiplePlayersSummary?TournamentId=30951

Highlands Course Scoreboard: https://golfeventscores.azurewebsites.net/PublicScores/SingleScoreMultiplePlayersSummary?TournamentId=30952

Does your charity have a golf event that it wants to take to the next level?

Check our video on the subject: https://youtu.be/gjfgzHZJXN0

Pellissippi State - "Swing Big For Students"

On Thursday, we ran the scoring for the Pellissippi State "Swing Big For Students" event.  There was a morning event and an afternoon event.  The scoreboard for both events are below.  The scoring have the following effects:

• Additional recognition to sponsors.  Charities are able to capture additional sponsorship monies on the scoreboard.
• Faster scoring.  The totals are completed when the last team inputs their score.  There is no chasing down a group to get their scorecard.
• Fun.  You get to see where your score is relative to everyone else you are playing against.

Morning event: https://golfeventscores.azurewebsites.net/PublicScores/SingleScoreMultiplePlayersSummary?TournamentId=30924

Afternoon event: https://golfeventscores.azurewebsites.net/PublicScores/SingleScoreMultiplePlayersSummary?TournamentId=30925

Contact us for more information!

Realities of Cross-Platform Development: How Platform-Specific Can You Go?

My personal beliefs on cross-platform development were formed in November 1993. I worked at The Coca-Cola Company at the time, and a few colleagues and I were discussing how to provide Mac users with the same set of applications that we were building on Windows 3.1 with PowerBuilder.

The discussion centered around the UI. The concern was with providing a Windows-centric interface to Mac users. I remember one of the great lines from the meeting: "If you provide Windows help to a user expecting Mac balloon help, you are going to have users that hate you." After this and some personal experiments, I came to agree with this viewpoint. If developers want to make users as happy as possible, they need to call the native APIs of the platform.

Fast-forward to 2009, when I fell in love with the Xamarin iOS product from the first announcement. Xamarin had created a way for C# developers to use the Microsoft .NET Framework and to call into the native platform APIs. Xamarin Android operated the same way. While I would often discuss the need for a cross-platform UI with Xamarin management, I never forgot the lessons of cross-platform from many years ago. At the same time, I knew that there was a need for a cross-platform toolset to create an application. I had talked to enough people to understand the pain and agony. Quite honestly, I was a fence sitter in this area. I liked the idea of XF, but I was never quite ready to make the jump and, honestly, try XF for anything more than some personal experiments and helping a couple of customers.

The problem with cross-platform tools is that they tend to target the lowest common denominator. This commoditizes the UI. This isn't necessarily a bad thing. Time to market can be improved. There are lots of applications that don't need a fully optimized platform. There are a number of applications where getting something out quickly and solving a business problem can be the most important factor.

There's no "one size fits all" solution no matter what some faction wants to preach. Some applications have very device-specific needs -- some applications don't -- it very much depends on the situation. Users, the ones who pay for development, tend to want applications that look, smell and taste like every other application that they already have. The worst possible situation to get yourself into is the one where you start down the road of using a cross-platform framework, and the users demand so many features that are platform-specific that it would've been easier and cheaper to have just built two or more platform-specific applications. That is a special type of hell. I've been there, and it's a bad conversation to have with a paying customer. The bottom line is that you need to have a real-world discussion with your users and the people that sign the checks. No one will quite understand it, but morally, you really need to have this conversation in the consulting world.

Url: https://visualstudiomagazine.com/articles/2016/09/01/how-platform-specific-can-you-go.aspx

Sunday July 11

As good a day as Saturday was, Sunday was the opposite.  I crashed and burned.  When I got home that evening, it was time for the post mortem.  Here's what I found:

• Colman Hoffman found a problem in how I setup his net games.  In digging into that a bit, I also found a bug that would not have even surfaced if I had the set his net games up correctly.  That is why I come nearly every Sunday and am trying to track down all possible issues.  
• The big game appears to be correct.  Both Kevin (Coco) and I came up with 14 plays and the app calculated 14 plays.
• I spot checked a number of games on Monday and I think that they are correct.
• There was a lot of discussion regarding the scoreboard and it not showing data correctly.  This is where the train got off the tracks.  I think this was some confusion.  Let me attempt to clear up some confusion on the scoreboard.
• Numbers on the scoreboard "magically" changed.  The scoreboard is designed to show both the games in their totality, individual games, and the status of an individual player's games.  These all look very similar.  I think this caused some of the confusion regarding results changing.  For example, I can look at Terry Marsh's results, slide over the David Tweel, and get a different result.  I give this example because when I looked at Terry's results, I see the numbers that I thought remember thinking were David Tweel's results.  This confused me.  This is what I think happened.
• Speed.  The scoreboard was slow to update.  It probably was taking 30 - 60 seconds to return results.  If this is not fast enough, people result get frustrated, hit refresh, and are still being delayed.  The speed of calculating a a game with 10 side games is fairly quick.  3 swing games is the equivalent of 10 side games.  There were 14 side games.  I had to calculate a big game and 44 side games.  This is a lot of calculations to handle.  Several of us were refreshing, so we could have had 5 or 6 of us trying to update the scoreboard.  I have a few things that I am going to work on to improve performance.  I won't bore you with the details at this time.  
• Another item in the performance game is the server that I am currently running on.  I am paying for this out of my own pocket.  I started with a starter level server, so I am going to up that a bit to improve performance.

How To Read The Scoreboard

There is a lot of information on the scoreboard.  A lot of information on the scoreboard leads to a lot of confusion.  Let me attempt to break down what is on the scoreboard.  

• The top of the scoreboard has a list of each individual's hole by hole scores.  Right below that, it shows a summation of the plays.  The plays are broken down into each hole.  The plays for each hole show what I call game plays, birdie plays, the total number of plays for a hole, and the running sum of plays up through a given hole.
• The big game scoreboard has a link for each player in the game.  Clicking on the link takes the player to the scoreboard that only shows that one person's results.  This will only show the games and the results that this one person is in.  It will show this one person's results and how that one person did against each other player.  The results are only accurate for that one player.  I think this is where the confusion started with David Tweel's (Twist) results.  IIRC, we were looking at Terry Marsh and looked over to David's results.  I had been talking to Terry right before the problems started.  I now have text all over the scoreboard when were are only looking at a single person's results.  
• Below the number of plays, it shows the money for each player out of the "big game."
• The next section shows the side games.  These are the 1 on 1s and the 2 on 2s.  Each side game has a link so that a player can look just at that game.  Each side game has a listing of the money for hole plays, the birdie plays, and then the total plays (all are in money).
• The next section is the swing games.  These can be a mini swing or a 3x3 swing.  The money for each player is shown as winning or losing.  There is a link whereby you can dig into the swing game and see the results.
• The final section is the spreadsheet where it breaks all of the information down.  At the bottom is the final total of whether or not you were a net winner or loser for the day.

What Am I Going to Concentrate On?

I have some other commitments that will keep me from being there on Sunday July 18.  Before we get together again, I am going to be working on:

• Revalidating the numbers.  I'm going to go back over the numbers again.
• The scoreboard is a bit confusing.  I am going to work on making it a bit simpler.  There are some things that people use, and some things that they don't.  
• Working on performance.  I'm going to work on my code as well as the size of the server our app runs on.
• Side games.  Jay Maier had some good input on the side games and how to make it easy to create them while on the course.  I also learned a new thing about the side games on Sunday regarding the net side games.

The Nature of Software Development

Software takes a lot to get it working right.  I have to learn how you guys do things, and I have to turn that into software.  The best way for me to learn how you guys work is to have you guys try it out and to give me a feedback.  I got a lot of feedback on Sunday, and it was all good.  :-)

Feedback

If you have thoughts, please let me know.  I will take any of them.

Golfing for the Peyback Foundation and Children's Hospital - Results

The Results of the Morning and Afternoon Rounds:

The Morning Results

The Afternoon Results

We had a long and winding day on Monday.  We went and scored the Morning and Afternoon portions of the Children's Hospital - Peyback Foundation Charity Golf Tournament.  Each portion was flighted.  Pictures were taken of each team while on the course.  The pictures were immediately uploaded to the scoring system for display on the scoreboard.  The flighting of each portion was performed by the application.  As each portion finished, the teams were placed into each flight.  Each team's scores were shown in the flight as well as the team pictures.

The scoring system is hosted in Azure.  The picture upload is done via an iPhone application written in C#/Xamarin.

I learned a few new things that I will work on and resolve the next time around.

Customize the iOS Keyboard with Xamarin

You can customize the iOS Keyboard with Xamarin.

Nearly all applications require that users interact with your app via a keyboard. It could be a search bar, a text field, or something else -- users typically use the keyboard in some way for input. iOS comes with different types of keyboards that can solve just about any need, but there are times when some additional feature would be great. In Google's Gmail app for iOS, for instance, maybe you'd like to make things a bit easier by adding e-mail addresses for .net, .org, and other domain suffixes. This article will look at how to modify the existing iOS Keyboard to better fit the needs of the application.

App To Market: Your Startup Needs An MVP

https://visualstudiomagazine.com/articles/2016/03/22/app-to-market-startup-needs-an-mvp.aspx

An MVP is not some Microsoft award, but the acronym for a term, "minimum viable product," that loosely defines what you're trying to provide as far as features -- at a bare minimum -- to get your app to market. Let's look at the considerations for making sure your app achieves MVP status.

Drill Into Problems with Xamarin Insights

Url: https://visualstudiomagazine.com/articles/2016/03/01/xamarin-insights.aspx

You've completed the initial version of your mobile app. You've deployed it. And now, you've started to get reports of exceptions in your app. It doesn't happen all of the time, and it doesn't happen to all users, only some of them. What's worse is that the errors aren't often repeatable. For some reason, the issues some users are having can't be repeated in your office. You drive around and try to repeat the errors but you can't, so you wonder if it's is a location issue. Perhaps it's a cell signal issue. Perhaps the issue is the version of the OS the user is running. You're stuck and you don't know what's causing the errors. You need more information in order to solve the problem, so where do you turn? Xamarin has released a product just for this situation. It's called Xamarin Insights.

Neo-Socialism

The formal definition of neosocialism from the 1930s has some rather unsavory pieces.  However, we're in 2016.  If people can redefine things, I figure I can to.

Neo meaning new.

Socialist meaning socialist.

I've noticed this new trend of socialists.  They were brought up in a capitalist economy and want it to change.  these people seem to think that things and times are horrible.  If you listened to them and Bernie Sanders, you'd think we were living under the thumb of bankster gangsters.  Puhlease.  These people need a reality check.  In a capitalistic economy, if you come up with a better idea, you have the opportunity to grow, start a business, and change your situation dramatically.  Anyway, these people that grew in capitalism and now think that socialism would be so cool, I refer to them as neosocialists.

Slim down your Pictures in the iPhone & Android

Url: https://visualstudiomagazine.com/articles/2016/02/01/slimming-pics.aspx

Nothing can be as helpful as a picture. Text is great, but there is a reason why pictures are worth a thousand words. Unfortunately, as the cameras of devices have gotten better, the amount of space that pictures take up has gotten larger. With a late-2015/early-2016 phone, a picture can easily be 2MB. Start trying to upload those via e-mail or to a service (Instagram, Facebook, Twitter), and there are always problems with connectivity or otherwise. Let's examine some simple routines to minimize the size of an image.

Xamarin 4 Overview - Article

Url: https://visualstudiomagazine.com/articles/2016/01/11/xamarin-4-improvements-upgrading.aspx
November 17, 2015 was a great day for mobile development. That is the day that Xamarin shipped the latest major update to its mobile development suite of tools, and with this one there's lots to like:

• Xamarin.Forms. With Xamarin.Forms 2.0, there are updates for iOS9, Material Design, pre-compiled screens, preview support for Universal Windows Platform apps, and gestures support like pinch.
• Visual Studio iOS Support. Xamarin has reengineered for iOS support for Visual Studio in a way that should improve iOS app reliability.
• Mono Upgrade. Microsoft has open sourced portions of the .NET codebase, and what that, Xamarin has incorporated the open source code into the Mono framework. The move should improve the compatibility and performance of the framework.
• The iOS designer. The iOS designer can now load and save XIB files in addition to storyboard files.
• The Android designer. The Android designer now supports Android Material Design.
• Xamarin Test Cloud. To support the Xamarin Test Cloud and its 2,000+ devices that are accessible to developers, Xamarin has introduced a preview tool named the Xamarin Test Recorder, Xamarin.UITest 1.0, and Xamarin Insights, has been released with free crash reporting for all Xamarin customers (and, finally, additional plans for users).

PS. I was told that Listing 5 should have the following change:

protected override void OnCreate(Bundle bundle)
{

            FormsAppCompatActivity.ToolbarResource = Resource.Layout.toolbar;
            FormsAppCompatActivity.TabLayoutResource = Resource.Layout.tabs;
            base.OnCreate(bundle); 

            global::Xamarin.Forms.Forms.Init(this, bundle); 
            LoadApplication(new App()); 
}

A few thoughts on my new column on Startups and Entrepreneurship

I never did put out an intro to my my new VSM Column on Startups and Entrepreneurship, so I guess I'll consider this post an "Introduction and Hello" or something similar.  Here are a few thoughts in no particular order:

• These are my experiences.  My experiences are based on my actual experiences.  I've been directly involved over a long period of time with 3 startups.  Two of these startups were successful and one went into the ground at 500 miles an hour.  These are my long term startup experiences.  I've been involved with several other startups on a short term consulting experience.  None of these short term startup experiences have been successful due to reasons outside of my control, but you knew I would say that.
• I'm a developer that get's business.  I've had it drilled into my head forever.  I hated it when I was young, but now I get it.  It is one of the few experiences that I can remember as being positive about my youth.
• I don't live in Silicon Valley nor have I ever been associated with the startup life style of SV.  Given that most developers that read Visual Studio Magazine are .NET developers and there are few places using .NET in SV, at least that is what I am told, I'm going to focus on the realities that I see outside of SV.  If you are in SV and your read my stuff, great.  If you are in SV and you hate what I say, great.  I would actually like to hear about that.  If you like my stuff, great.
• These are my experiences regarding what has worked for me and what has not.  If your experiences and my experiences are different, great.  I don't have a problem going back and saying that something else worked for someone else.
• If you are a software architecture wonk and think that software architecture is the most important thing, then you are a moron and I'll probably say something along those lines in my column.  The most important thing in a software based startup is to create business value.  If your architecture delays your product, it sucks.  Get something out, get feedback from the users, act on that feedback.  Now, your stuff needs to be secure.  That is also important, but architecture, not so much.  Architecture is something that high end consulting shops use to sell more of their high end hours to CIOs of Fortune level companies.  This column is about getting going.  If you want to invest in cool architecture, invest in it when your startup has moved into the Fortune level of companies.  
• People and dedication are the most important things that you should look for.  It doesn't matter if someone is from Harvard or XYZ polytechnic.  What matters is people and the dedication that they have to solve a problem.  You don't know if someone is dedicated until they are in the foxhole of software hell with you and you are taking grenades on a Friday night.  Are they getting up at 5 am on a Saturday to go to test out software changes from users and to get feedback?  Are they even willing to act on that feedback?

If You Build It, Will They Come?

Url: https://visualstudiomagazine.com/articles/2016/01/06/app-to-market-4-listen-to-users.aspx

Users are the most important part of your application, startup, and, ultimately, business.  You must provide them something of value.  That something must resolve some pain point that they have.  It must do something to somehow make their lives easier.
This time, I'll look back at three of the startups I have been involved with and how each one worked with the users:

• The first was a real estate multiple listing service that was successful.
• The second was a pay-for-placement search engine that was successful.
• The third was a FourSquare-type of service for searching local services that was formed and worked several years, then saw success dry up when listening to customers was refused and FourSquare started up.