5 Important Mobile UX Areas People Usually Forget

5 Important Mobile UX Areas People Usually Forget

At Salty Dog we help clients to define their app. Many clients know how they want their app to solve a particular problem but haven’t figured out how the app will look from the perspective of their customers.  There are some key UX areas they often forget that can have a huge affect on the user experience.

Here are some of the most easily overlooked UX areas:

Login and Registration

Login and registration are usually the first part of an app your user will see. Some commonly forgotten sub-use cases are: forgotten password, registering email, forgotten password but haven’t verified their email, or re-sending email verification.

Forgetting passwords can happen more frequently on mobile devices. It can get really annoying for a user to try a bunch of passwords, then have to go back to the main website to request a new one.  This is amplified if the registration requires email verification, and they are denied a new password because they haven’t completed this process.

The solution to these issues is to remember some of the more subtler use-cases. Here are the  use-cases for a complete login and registration experience.

  • As a user, I would like to register/create a new password-protected account, in case I don’t have one yet.
  • As a user, I would like to authenticate with the app, so that my information is protected.
  • As a user, when I start the app I would like to know if I haven’t validated my email address if I haven’t, so I know to look in my inbox or spam folder.
  • As a user, I would like to be able to resend the email verification in case the old one is expired or lost.
  • As a user, I would like to be able to set a new password via my validated email address in case I’ve forgotten my old one.
  • As a user, I would like to be able to log out of the device, in case I want to restrict access or log in as a different user.
  • As a server administrator or app owner, I want a way to log a user out, in case there is a good reason I want them to re-authenticate.
  • Application Updates

    Sometimes it is necessary to make changes to the way the app works and require users to update. For example, there might be a change to the way the server works that breaks any previous versions of the apps that haven’t updated, or there is a really important security fix.

    The solution for this is to provide a way to make sure the user updates the application, and then gracefully degrade functionality if they do not update. A simple flow outline might work like this:

    1.On app start, connect to the server supplying the version of the application.
    a. If the version does not need to be updated, then respond with an OK.
    b. If the app DOES need to be updated, then respond with a “needs update”.
    2.If the app received an “needs update” response from the server, then:
    a. Inform the user they need to update.
    b. Let the know that functionality of the app will be impaired if they do not.
    c. Give them an easy way to facilitate the update such as a button that takes them to the App Store or Market app to update.

    Important Notices

    It is really important to be able to send notifications/notices to the user. The purpose can be anything from letting them know about planned server maintenance, other companion applications, updates/upgrades to the functionality,  or bug fixes.

    What makes this so critical is because of how difficult it can be to communicate with the user. You need to communicate with them so you can set their expectations about app functions and changes. In the absence of information, the user may jump to negative conclusions that can result in bad reviews, or worse, uninstalling your app.

    The fix is relatively easy and accessible: add a way to send notifications to the user. There are many third party services that can do this. Some even allow targeted notifications to segments of your users.

    Alternatively, you can implement your own solution. The messages can be displayed using webview controls, allowing you to point the user to blog posts or release notes. The app just needs to be smart enough to know if the user has seen the notification before so they don’t get spammed with notifications.

    Network Problems

    Issues related to the network or connectivity are ignored a lot of times, and are only discovered in testing or when a user has issues with it. These fall in three basic categories:

    1.Server issues. The server might have an issue. The cloud provider may decide to reboot your server. Even though the network is functioning correctly, the server may not respond.

    2.Network issues. Sometimes there are outages either at the ISP/provider level or somewhere in the backbone.

    3.Device connectivity. It could simply be an issue with network connectivity from the device. The user is out of cell range, or service quality is low.

    4.Planned outages. The server might need to be upgraded, or the system restarted.

    There are two basic ways of dealing with this. First, design the app with lack of connectivity in mind. For example, if the app cannot reach the server then handle it gracefully. When the network is not reachable, you can give an indication in the app so the user has an idea of what is happening. I’ve seen some apps show an indicator in the title-bar.

    Second, leverage the Important Notices suggestion above. If you’re using a 3rd party notification service, then you can inform users that you’re aware of the outage and when they can expect it to be available again.

    Interacting With Someone Who Doesn’t Have the App (Yet)

    When designing social apps such as chat, it is easy to forget about the case when one person has the app and they wish to interact with someone else who doesn’t. This is important because it can provide a viral way of gaining more users.

    We’ve blogged about this in detail here and here.  The basic problem is how to interact with someone who doesn’t have the app yet. Once you solve the interaction problem, how you can turn that into a seamless onboarding process for a new user.

    The answer is to use something called deep-linking in conjunction with SMS messages and a bit of magic from the iOS web-view control and Android App Store broadcast message. This allows you to send an invite link to someone over SMS, which sends them to a landing page that includes links to the appropriate web-store to install the app. After they’ve installed the app cookies can be used on iOS or broadcast messages from the Google Play Store App, to let the newly installed app know there was an invite from someone else.

    This allows an invite to go to someone without the app, them to install the app, and then pick the invite up from where they left off as if they had the app installed in the first place.

    Summary

    When making your mobile project it is important to remember what happens after the initial release and use. As the overall quality of apps has improved, sensitivity to clunky apps has increased. Failing to include these user stories is very likely to result in a user deleting your app.  These user stories should become a part of your larger release strategy to help you plan for ongoing updates, user engagement, and to ensure that you have the infrastructure in place to support users when they have a problem with the app.

    Xamarin Binding: Survey Monkey SDKs

    Xamarin Binding: Survey Monkey SDKs

    Recently I helped someone who was having problems binding Android and iOS native SDKs to Xamarin. Xamarin binding is a complicated subject and though Xamarin has documentation, there are some sticking points that are not quite obvious.

    The two Survey Monkey SDKs can be found here and here:

    The github project with my binding solution

    Survey Monkey Android Binding Library

    Binding native Android to Xamarin is done though through creating a special Android Binding project. In Visual Studio 2015 this project type can be found under installed templates under Android:

    Once the project is created, it will contain a couple special folders: Jars and Transforms. Jars contains any jar (or aar) files that need binding. Additionally you need to add any jars it references. If they are already bound like Android Support v4, you can just add the Nuget package.

    Transforms contains a set of xml files that use what appears to be xpath to select nodes and then perform tweaks.

    The transformation process works like so:

    1. Reflect over the jar and aar classes.

    2. Produce an internal xml file detailing the classes, properties and methods. After building the project once you should be able to see an example of this at <project dir>/obj/Debug/api.xml.

    3. The files in the transforms directories apply transforms to this api.xml file, which is then used to generate the C# wrapper code.

    In the case of Survey Monkey after adding a nuget reference to Android Support v4, there were three errors:
    Inspecting the code GetRespondentTaskLoader shows this method signature that’s causing the error.
    GetRespondentTaskLoader derives from AsyncTaskLoader. AsyncTaskLoader’s LoadInBackground returns a Java Object. In C# an overridden method can’t change the return type. The fix is to update the transform code to change the return type. This is done in Metadata.xml in the Transforms directory with this line.

    This tells the Android binding project to change the return type of the loadInBackground method on the GetRespondentTaskLoader class to a Java.Lang.Object.

    The other error we encountered was exactly the same, but for another class. The fix for it is the same:

    The last error is not fixed with the transform. The generated class is a partial class. We can fix this error by supplying another part of the partial class that contains the LoadInBackground method to fulfill the implementation:
    With those changes, the build complete with 12 warnings and 0 errors:

     

    12 Warning(s)

    0 Error(s)

    Time Elapsed 00:00:04.4374710

    ———————- Done ———————-

    Build: 0 errors, 12 warnings

     

    The Android Binding Project is ready. See the github for the example of how to use it. It is exactly the same as the native Android Survey Monkey SDK.

    It is worth noting that it may not be necessary to access the 3 task classes RetrieveSPageTask, GetRespondentTaskLoader, and GetRespondentTokenTaskLoader directly. We could possibly just remove the class definitions using the Metadata.xml transforms file. I opted to leave them in case there is a use for them.

    The latest version of Xamarin, as of this writing, will not run correctly out of the box on some x86 emulators. This is easily fixed by adding x86 or x86_64 to the ABIs for the Advanced tab under Android Build:

    Survey Monkey iOS Binding Library

    An iOS binding library is created through a completely different means. Rather than reflecting over the binaries, a command line tool named Objective Sharpie is used to scan header files and create decorated C# classes, similar to P/Invoke.

    The default framework option with sharpie didn’t work. I think that is because Survey Monkey’s iOS SDK framework doesn’t follow the right naming convention. Fortunately it is possible to reference the header files and generate the stubs:

    Which responds with:

     

    Parsing 2 header files…

    Binding…

    [write] ApiDefinitions.cs

    [write] StructsAndEnums.cs

    Binding Analysis:

    Automated binding is complete, but there are a few APIs which have been flagged with [Verify] attributes. While the entire binding should be audited for best API design practices, look more closely at APIs with the following Verify attribute hints:

    MethodToProperty (1 instance): An Objective-C method was bound as a C# property due to convention such as taking no parameters and returning a value (non-void return). Often methods like these should be  bound as properties to surface a nicer API, but sometimes false-positives can occur and the binding should actually be a method.

    StronglyTypedNSArray (2 instances): A native NSArray* was bound as NSObject[]. It might be possible to more strongly type the array in the binding based on expectations set through API documentation (e.g. comments in the header file) or by examining the array contents through testing. For example, an NSArray* containing only NSNumber* instances can be bound as NSNumber[]  instead of NSObject[].

    Once you have verified a Verify attribute, you should remove it from the binding source code. The presence of Verify attributes intentionally cause build failures.

    For more information about the Verify attribute hints above, consult the Objective Sharpie documentation by running ‘sharpie docs’ or visiting the following URL:

    http://xmn.io/sharpie-docs

    Submitting usage data to Xamarin…

    Submitted – thank you for helping to improve Objective Sharpie!

    Done.

     

    It gives a couple warnings, which in this case can be ignored. The latter of the two StronglyTypedNSArray just means that we may have to cast an NSObject to a particular type before we can use it.

    An important thing to notice is the Verify attribute. Sharpie will put this in the generated code, but will not compile. This will force you to look at the line and make sure the generated code is correct. In this case everything was ok, so I removed the [Verify] from the code.

    The files generated by sharpie aren’t the same name as the default files generated when I created the binding project. If you look at the properties for the two .cs files created in the project you’ll see this. (From Xamarin Studio)

    If you decide to just add the files, make sure the build command is set to ObjcBindingApiDefinition.

    I simply pasted the contents into the existing files.
    Fixing an objective sharpie error with enums. The code for StructsAndEnums did not compile:

    If you know this will only run on 64 bit devices, then the quick fix is to change the type to a ulong:
    The last thing I had to do was add some code to make sure it loaded the binary file. This is done in the SurveyMonkey.framework.linkwith.cs file:

    Then the binding project is ready to go. Just add the binding library project to the Xamarin iOS project and you can start using.

    Next Steps

    There are a few things I will add in the future:

    1. Create a nuget project. Everyone loves nuget. It would make it easier to use without having to muck around with projects.

    2. Create a cross-platform Xamarin Forms plugin so that Survey Monkey can be used from a Forms App.

    3. Unify the return data type between iOS and Android. Right now Android returns a json string to the calling activity. iOS returns an object hierarchy. Before a Xamarin Forms plugin can work in a useful way, the way the data is consumed needs to be the same.

    Let me know if you have any questions, comments or inquiries at curtis@saltydogtechnology.com
    User Experience:  Inviting users to your Android or iOS app Part 2

    User Experience: Inviting users to your Android or iOS app Part 2

    Previously in (User Experience:  Inviting users to your Android or iOS app Part 1) we explored a way of inviting and onboarding new users to an application. It worked but had some UX issues related to it.

    The solution relied on putting deep links in SMS messages and then sending them to the recipient. Here are the 4 use cases again.

    A ) Bulk invites, or outside of the app, inviting someone who may or may not have the app:

    1.The user’s information, name, phone number and possibly custom message, is captured and inserted into the database along with a unique identifier.

    2.The website then generates an SMS with an url that contains the unique identifier as a parameter.

    3.The SMS is sent. That’s it!

    B ) Someone uses the app to invite someone else who may or may not have the app:

    1. The user selects a name from their contact list.

    2. Optionally, they write a message for the receiving user.

    3. The app then makes an authenticated rest call to the server, where the information is inserted into the database.

    4. The rest call returns the unique id that was generated.

    5. The app formats an url using the unique id, and then sends in in an SMS message to the recipient. That’s it!

    C ) Someone receives an invite who does not have the app installed:

    1. The user receives an SMS with a web url in it. The url has a unique id appended as a query parameter.

    2. The SMS has a short message, asking them to click on the url for more information.

    3. The user clicks on the url.

    5. Since they don’t have the app installed the url starts the default browser and the visit the web page.

    6. The web server, looks up the unique id from 1), and retrieves the details of the invite such as the recipient’s name, or even a custom message. It also includes a link to Apple App Store or Google Play Market for downloading the appropriate app for their operating system.

    D ) Someone receives an invite who does have the app installed:

    1. The user receives an SMS with a web url in it. The url has a unique id appended as a query parameter.

    2. The SMS has a short message, asking them to click on the url for more information.

    3. The user clicks on the url.

    4. Since they have the app installed, and deep linking is enabled, the app is opened.

    5. The app fetches the parameter from the url the performs a REST call to the server and looks up the details for the invite.

    6. The app displays a screen with the details.

     

    A and B dovetail into C and D. The problem is that if they have the app installed the will still be receiving SMS messages and the user has to click on it. That is at least two clicks just to get into the app.  1) Select the notification to open the SMS app. 2) Select the URL to open up our app. Depending on the operating system and version, there might be another step in there to verify that you want to open up the app. That might end up being really annoying! Fortunately, there is a better cleaner way to handle this. Basically, we want the app to automatically open when it receives an event notification.

    We can easily do this using the push notification facilities in iOS and Android. The trick is knowing if we should send an SMS or send a push notification. We have part of the equation solved already. We know the phone number of the person when they originally were sent the invite. We can use that to create a user account that just hasn’t been tied to the information for push notifications. When the recipient installs the app we can associate the phone number with that app installation. This way in the future when we send an event to that phone number, we can check if it is associated with an installation. If it is, we send the push notification instead of an SMS. So we’re almost there. The only question is how do we associate the phone number to the installation. We can ask the phone number, or we can request permission to read it. However, there is a slicker way to handle it.

    The Magic

    iOS 9 comes with some new abilities. The new Safari View Controller can share the same cookie space as the main Safari app. This means you can verify if the install action originated from a click in safari. Google Play has an INSTALL_REFERRER Broadcast. Basically, you just need to append a custom referrer to the query parameter to the end of the Goole Play Store URL when you send the user there. Google Play will fire off a broadcast intent to your app that includes the referrer. Here is an updated use cases for the first time the app is installed

    Someone receives an invite who does not have the app installed:

    1. The user receives an SMS with a web url in it. The url has a unique id appended as a query parameter.

    2. The SMS has a short message, asking them to click on the url for more information.

    3. The user clicks on the url.

    4. Since they don’t have the app installed the url starts the default browser and the visit the web page.

    5. The web server, looks up the unique id from 1), and retrieves the details of the invite such as the recipient’s name, or even a custom message. It also includes a link to Apple App Store or Google Play Market for downloading the appropriate app for their operating system.

    6. The web page sets a cookie (for the iOS case) and the link to the Google Play Market appends a referrer that includes the unique id created in 1.

    7. The user installs the app.

    8. (iOS) When the app is run the first time, it loads the Safari View Controller, then looks for that cookie. If it is there then the user installed via visiting the web page and we can look up the invite and associate the phone number with the user record via a REST call.

    9. (Android) When the app is run the first time, it waits for the broadcast from the Google Market App. If it is received, then the user installed via visiting the web page and we can look up the invite and associate the phone number with the user record via a REST call.

     

    Now you have a very slick invite and onboarding process!

    User Experience:  Inviting users to your Android or iOS app Part 1

    User Experience: Inviting users to your Android or iOS app Part 1

    Often the use cases and implementation around inter-app invites is overlooked. Handling it easily and well can be a bit subtle.

    You have to deal with the situation if an intended recipient has the app installed. If they do not, you will want to do one thing. If they do have the app installed, then the invite notification should be handled in app. It becomes a bit of a chicken and egg problem — how does someone receive an invite if they don’t have the app installed?

    Fortunately, there is a clever thing you can do for invites that handles both cases. It leverages a feature that both iOS and Android have: The ability to map an url to an app, so when the user taps that URL in email or sms (or a web-page) it starts the app if it is installed. This is called Deep Linking.

    In Android this is done using deep linking and an intent filter in the manifest:

    When Android detects that url, it will open up this activity. More details here: https://developer.android.com/training/app-indexing/deep-linking.html

    In iOS 9+, this is done with universal links. Basically you include an apple-app-site-association file that describes what urls your app should open. For example:

    Note: don’t append “.json” to the file.

    See more details here.

    Let’s talk about the use cases in a bit more detail and then walk through how these are solved using the feature I described above.

     

    There are 4 use cases you need to consider:

    1. Someone receives an invite who does not have the app installed

    2. Someone receives an invite who does have the app installed.

    3. Bulk invites, or outside of the app, inviting someone who may or may not have the app.

    4. Someone uses the app to invite someone else who may or may not have the app.

     

    The first are almost the same. It is just a matter where the SMS is sent from.

    Bulk invites, or outside of the app, inviting someone who may or may not have the app:

    1. The user’s information, name, phone number and possibly custom message, is captured and inserted into the database along with a unique identifier.

    2. The website then generates an SMS with an url that contains the unique identifier as a parameter.

    3. The SMS is sent. That’s it!

    Someone uses the app to invite someone else who may or may not have the app:

    1. The user selects a name from their contact list.

    2. Optionally, they write a message for the receiving user.

    3. The app then makes an authenticated rest call to the server, where the information is inserted into the database.

    4. The rest call returns the unique id that was generated.

    5. The app formats an url using the unique id, and then sends in in an SMS message to the recipient. That’s it!

     

    A couple notes about this. In step 3, want the user to be authenticated so that someone couldn’t call the REST api directly and use it to spam. In step 5, the app sends the SMS. The server could send it, and in the future you may want it to, but if the app sends it then the user pays the SMS costs.

    Someone receives an invite who does not have the app installed:

    1. The user receives an SMS with a web url in it. The url has a unique id appended as a query parameter.

    2. The SMS has a short message, asking them to click on the url for more information.

    3. The user clicks on the url.

    4. Since they don’t have the app installed the url starts the default browser and the visit the web page.

    5. The web server, looks up the unique id, and retrieves the details of the invite such as the recipient’s name, or even a custom message. It also includes a link to Apple App Store or Google Play Market for downloading the appropriate app for their operating system.

    Someone receives an invite who does have the app installed:

    1. The user receives an SMS with a web url in it. The url has a unique id appended as a query parameter.

    2. The SMS has a short message, asking them to click on the url for more information.

    3. The user clicks on the url.

    4. Since they have the app installed, and deep linking is enabled, the app is opened.

    5. The app fetches the parameter from the url the performs a REST call to the server and looks up the details for the invite.

    6. The app displays a screen with the details.

     

    So there we have a basic way of sending invites users whether or not they have the app installed. However, if they have the app installed the will still be receiving SMS messages and the user has to click on it. That is at least two clicks just to get into the app.

    1. Select the notification to open the SMS app.

    2. Select the URL to open up our app. Depending on the operating system and version, there might be another step in there to verify that you want to open up the app.

     

    It works though it is a bit clunky. Every time an invite is sent, the user will have to click on the link in the SMS. In a future blog post, we’ll see how to optimize this and make it better.

    Using Azure Functions and Document DB for Simple User Authentication

    Using Azure Functions and Document DB for Simple User Authentication

    Often my clients need simple, inexpensive, yet scalable solution for user management. This is especially true of clients that are startups, or are developing MVPs. Cost and scalability are important.

    Facebook’s Parse.com server was my go-to tool until Facebook kicked it to the curb. It has since been open sourced, but still remains somewhat of a black box. (Unless you want to learn a new framework.) Now that Microsoft has added Azure Functions to its lineup, there is something simplier to set up.

    With Azure, it is easy to implement a simple authentication system that uses best practices for passwords and hashing, and the creation of JWTs.   Azure Functions are Microsoft’s answer to AWS Lambda. Like AWS lambda, Azure Functions are serverless pieces of functionality triggered by a customizable variety of things. You are charged by the amount of memory in GB/sec for the time consumed by each individual action.

    “HTTP triggers” are a REST endpoint that executes a specific Azure Function. There are other kinds of triggers such as queue events and timers. This post will focus on HTTP triggers.

    Azure Functions are built on top of Azure Web API, but each function is in a separate directory. Azure function supports multiple languages, such as C#, python, PHP, JavaScript and others. I opted to use C #, as that is my language of choice.

    An Azure Function

    There are a couple configuration files in each directory which let Azure Functions know several things related to each function. In the case of HTTP triggers, this includes the REST route and security on the function.

    Files in an Azure Function directory.

    function.json

    Though Azure Functions supports debugging, they don’t yet support unit testing. To make it easier to test this project, I put the bulk of the functionality into a shared assembly. The Azure function calls into the shared assembly which parses parameters, delegates to sub-components and formats the output. This allows me to quickly develop and debug the basic functionality. Additionally, it should be compatible with Azure Web Api projects, though I haven’t tested it yet.

    Simple Authentication

    This simple authentication has 3 HTTP methods: Register, Login and GetCurrentUser. The first two methods are straightforward. GetCurrentUser is there to show how to validate the java script web token (JWT).

    For data storage I decided to use Microsoft’s NOSQL solution DocumentDB. DocumentDB’ s pricing model is based on reserved units of processing and max storage size. (Check https://azure.microsoft.com/en-us/pricing/details/documentdb/ for more pricing details.)

    This project uses a simple abstraction for database access to facilitate mocking for unit tests, and to allow a way to use another database. The functions are very thin wrappers around calls into the shared assembly which coerce values, validate input, catch errors and return results accordingly.

    There are three layers. Layer one coerces parameters from HttpRequestMessage objects and formats the HttpResponseMessage. It calls into an object that does the bulk of the work but has no awareness of http request or response messages. Finally, there is a database abstraction layer, which is concerned with finding User objects based on ID, email address or email validation code, and saving the user objects.

    Creating a User

    I followed best practices by using hashed passwords and user specific salt values. Additionally, I decided to use JSON Web tokens that can be passed into API calls for when the user is authenticated.

    User registration simply becomes a matter of making sure the normalized email address is unused/unique, initializing the salt value, and then hashing the password storing it. I used code from here (reference) to store the hashed password. The hashed password and the salt are stripped from the user data when returned from a function. At this point I do not issue a token, because in the future I will require email validation.

    Authenticating a User

    User authentication takes an email address and a password. The user record that corresponds to the email address is retrieved, and the attempted password is hashed using the salt from the record. If the hash value and the hashed password in the user record match, then I return an HTTP 200, a sanitized user record, and the JWT. The JWT is non-standard right now and simply contains a creation date and expiration date, and the ID of the authenticated user.

    If the two hashed values do not match, and HTTP code of 401 (unauthorized). It is considered best practice to give no indication if it is the email or the pastor that is incorrect so that they would be hacker cannot test for valid emails.

    Verifying the User Authentication

    If there are other Azure Functions that require the authenticated users, the JWT needs to be passed in. To check it, it needs to be unwrapped, the signature tested, and the expiration time checked against the current time. If the signature is incorrect, or the expiration time is passed then an HTTP 401 would be returned.

    Of note: JWT is what is as known a bearer token. This means that no matter where this token comes from it is considered good. Some people add the hashed IP address that was used to authenticate to the token, and that is compared at the time the particular call is made. If the hashed IP address don’t match, then it is assumed that the token is invalid:

    A couple notes about the code.

    First, I use the JWT library from here https://github.com/jwt-dotnet/jwt However, the nuget package is compiled for .Net 4.6, but Azure Functions only work with .Net 4.5 as of this writing. For ease, I just copied the source in verbatim.

    Second, I created some extension methods around the User object to create objects, set passwords and test password matches. Likewise, there is a helper class for JWTs called Tokens.

    Testing

    To make it somewhat easier to test I wrote the Azure Functions to work as either a GET or POST. That way I can simply use a browser and type in the correct values in that URL and press enter and observe the results.

    Here is the response indented.

    Next Steps

    There are several things I will add over time:

    • Controlling what gets returned from the GetCurrentUser call.
    • Common UX patterns such as the onboarding process (see User Experience:  Inviting users to your Android or iOS app Part 1 and Part 2)
    • OAuth 2.0 and/or OpenId connect. Since this supports JWTs, it shouldn’t be too hard to add the extra steps that allow for OpenId connect.
    • Let’s encrypt support. There is a Microsoft Web API plugin that can do this. and since Azure Functions use Web APIs, it isn’t too hard to get it hooked up.

    References

    1. https://crackstation.net/hashing-security.htm
    2. https://github.com/defuse/password-hashing
    3. https://github.com/jwt-dotnet/jwt
    4. https://github.com/curtisshipley/BlueDog
    Three Tools to Make Your MVP Faster, More Flexible, and at a Lower Cost

    Three Tools to Make Your MVP Faster, More Flexible, and at a Lower Cost

    This most efficient business solution to manage risk is a Minimum Viable Product (MVP). At Salty Dog Technology we create MVP’s to test the basic functionality needed to verify solutions.

    Having a MVP that includes a back-end amplifies risk beyond a stand-alone architecture. These risks fall into three common categories: cost, time and flexibility.

    Cost matters.  An MVP’s costs can spiral if the back-end implementation is expensive operate or takes a lot of hours to build. Though not in plain sight, the server’s cost should not be underestimated.

    Time matters.  If you go the route of building everything from scratch, it can take longer, be more error prone and require more testing. There is a lot of “plumbing” that needs to be implemented in that case.  You can miss product release goals if this is not taken into account when making development schedules.

    Flexibility matters.  Building a back-end from scratch requires finding or creating a bunch of scaffolding functionality. If you use a 3rd party framework, then you bring its baggage along, which may be more trouble than it’s worth. All frameworks are built with assumptions that may, or may not be ideal for your app’s back-end. A back-end implementation that cannot easily change will incur higher costs and take more time.

    There are some 3rd party back-end services you can try such as Facebook’s defunct and now open-sourced Parse Server, or Google’s Firebase. They have a vested interest in locking you into their service and libraries, and often they have tiered pricing which may not reflect your usage. This means that you may end up having to pay a lot more and have less ability to change.

     

    A Middle Solution

     

    At Salty Dog, we use a strategy that combines three Microsoft programs: Azure Functions, Azure DocumentDB and Xamarin.

    Azure Functions:  Azure  Functions are a way of providing server functionality without actually having to create a server. You are charged for the resources when they are used, as opposed to a virtual machine which incurs ongoing costs independent of actual usage.

    Azure functions are not tied to single computational resources. The more that your Azure functions are accessed, the more computational resources will be automatically applied. This allows the Azure functions smoothly scale according to application needs.

    Azure functions provide a rich programming environment where the functionality can be implemented in a number of languages including C #, PHP, JavaScript, Python and others.  They can utilize third-party libraries to provide extra functionality, as well as access external resources such as databases and messaging infrastructures.

    DocumentDB:   DocumentDB is a server-less, schema-less JSON document database. Document DB stores the data in hierarchical JSON documents. They are indexable by primary and secondary keys. Like Azure Functions, it scales smoothly as your needs grow.

    This means that time doesn’t have to be spent creating the schema, updating the schema, making sure that all data passed conforms to the structure. All of those things take time. Purists would argue that those up-front definitions provide a higher level of quality, and they’re right. However, that purity and build-in checking comes at a cost that isn’t necessary with an MVP.

    Azure provides is an SQL interface to DocumentDB that understands some aspects of JavaScript syntax. This gives you a known query language that can leverage Javascript data aspects.

    Xamarin:  Xamarin provides a set of tools to build Android, iOS, and Mac OS apps using C#. Rather than writing in Java, Objective-C or Swift, you write in C#. It is compatible with a lot of existing .Net libraries that can be used directly in the applications.

    There are multiple ways to use similar functionality across the platforms in a generic way. Typically this is done using an IoC or Inversion of Control, system.  This means that someone can create a GPS widget that is used the same way, down to the API level, on both Android or iOS.  Below the surface, it accesses the specific native functionality on the device. This means the code you write doesn’t have to know if it is running on Android or iOS.

    Xamarin has created a cross platform user interface library called Xamarin Forms. Xamarin Forms provides a usable lowest common denominator UI with the ability to customize and enhance it. For less fancy or performance sensitive applications, such as games, it can speed up development.

     

    The Right Building Blocks

     

    Together, the three tools provide a solution to the main risks we identified.

    Cost is saved.  Infrastructure, routing, and boilerplate are built in. A lot of the “plumbing” is in place.  Azure Functions feels like you’re working with a bigger web framework, without sacrificing flexibility.

    Pricing is relative to the actual time a particular function is performing work. If one month the Azure Function is only used for an hour demo, we will only be charged for that hour. Conversely, if the month after that, we put our app in the hands of 50 potential clients and they use it heavily, the infrastructure will smoothly scale to meet their demand without any intervention on our part.

    Using Xamarin for mobile development, especially Xamarin Forms, enables code reuse, since the same piece of code may be able to run on either Android or iOS. Development will not be done twice as it would have been if building native apps.

    Time is saved. Apps can be developed locally, unit tested, and put on the server using common source control methods, like Git and branching.  It isn’t necessary to continually upload to the servers and test. This makes it easy to add features, find bugs and fix them. When the code is ready changes are pushed to the right branch, and then Azure Functions will execute a pull from the control panel. This allows multiple live versions that correspond to production phases such as “beta” and “development,” or whatever makes sense for our product. With Xamarin, the app can be separated into distinct parts  for testing in isolation outside of a mobile device.  This can save time in the develop, test, and fix cycle.

    Flexibility is saved.  Since the interface between the application and the web server is the well-known REST standard, your app isn’t locked in because of special libraries.

     

    Summary

     

    Creating MVP’s for mobile need not be time consuming or require huge infrastructure investments.  Using Azure Functions, Azure DocumentDB, and Xamarin allows code to be quickly developed, unit tested, and reused. Used in conjunction, they allow you to focus on the MVP and its refinement without worrying as much about cost, development time, and flexibility.