Lessons learned from building Microservices – Part 3: Patterns, Architecture, Implementation And Testing

Introduction

In this blog post I will go over things I’ve learned when working with microservices. I will cover things to do and things that you should not do. There won’t be alot of code here, mostly theory and ideas.

I will discuss most of the topic from a smaller development teams point of view. Some of these things are applicable for larger teams and projects but not all necessarily. It all depends on your own project and needs.

  • Architecture
  • Sharing functionality (Common code base)
  • Continuous Integration / Continuous Delivery (CI/CD)
  • High Availability
  • Messaging and Event driven architecture
  • Security
  • Templates and scripting
  • Logging and Monitoring (+metrics)
  • Configuration pattern
  • Exception handling and Errors
  • Performance and Testing

General advice

Generally I advice to use and consider existing technologies, products and solution with your application and architecture to speed up your development and keep the amount of custom code at a minimum.

This will allow you to save on errors, save on time and money.

Still, make sure that you choose technologies and products that support your and your clients solutions; not things that you think are “cool” right now or would be fun to use. Your choices should fit the needs and requirements on not only your project but the whole of the architecture and the future vision of your project.

Architecture

To keep things simple I would say there are two ways to approach microservices.

Approach one: Starting big but small

The first approach is the one you probably are familiar with. These are big projects by big companies like Amazon, Netflix, Google, Uber etc.

Usually this involves creating hundreds or even thousands of microservice on multiple platforms and technologies. This usually require large teams of people both developing, deploying and up keeping the microservice solution they are working on.

This approach is definitely not for everyone; it requires alot of people, resources and money.

So this is why I recommend approach number two.

Approach two: Starting small but plan big

Most likely you have a team of a few people and limited resources. In this case I recommend starting between microservice architecture and monolith one.

By this I mean that you start the process by designing it and implementing all the infrastructure of a microservice but do not start splitting you application into microservices from the start. Create one microservice, expand it then split it when things start to grow so that it feels like a new microservice is needed.

By this time you have had time to understand and analyze your business domain. Now you have an idea what kind of a communication between microservices you need; perhaps HTTP based or decoupled messaging based.

When you are creating you microservice keep you design pattern for you microservices simple. Do not implement overly complicated patterns to impress anyone, including yourself. It will make the upkeep of you microservices a hell. You want to keep the code as simple and as common inside a microservice and between them.

Share as much as possible between microservices.

Create good Continuous Integration and Continuous Deployment procedures as soon as possible. It will save you time.

Verify you have proper availability and scalability based on your application needs.

Prefer scripting to automate and speed up development and upkeep.

Use templates everywhere you can, especially for creating new microservices.

Have a common way to do exception handling and logging.

Have a good configuration plan when deploying your Microservices.

You also need team member who are not afraid to do many different things with multiple technologies. You need people who can learn anything, adapt and develop with any tool, tech or language.

With these approaches and check list you should be able to manage a microservice architecture with only a handful of people. For up-keeping even one person is enough, but constant development at least two or three would be a good amount.

Sharing functionality (Common code base)

When it comes to code I prefer the “golden” rule in programming to not repeat myself but with microservices you will end up with duplication.

The wise thing to do with microservices is to know when to not duplicate and have a common access to shareable code and functionality; and why do this?:

  • Developer and up doing similar code that is used again and again in multiple microservices.
  • These common pieces of code and functionality end up having the same king of problems and bug which have to be corrected in every place
  • The problems and bugs cause security issues
  • With performance issues
  • With possible hard to understand code even when the logic and functionality is the same but the code ends of being slightly or vastly different.
  • And lastly all of the above combined cause you to spend time and money that you may not have

The next question to ask is:

What should you share? The main rule is that is must be common. The code should not be specific to a certain microservice or a domain.

Again it all depends on your project but here are a few things:

  • Logging, I highly recommend this to a unified logging output format that is easy to index and analyze.
  • Access Logs
  • Security
    • User authorization but not authentication or registration. Registration is better suited as an external microservice as it’s own domain.
    • Encryption
    • JSON Web Token related security code and processing
    • API Key
    • Basic Auth
  • Metrics
  • HTTP Client class for HTTP requests. Create an instance of this class with different parameters to share common functionality for logging, metrics and security.
  • Code to use and access Cloud based resources from AWS, Azure
    • CloudWatch
    • SQL Database
    • AppInsights
    • SQS
    • ServiceBus
    • Redis
    • etc…
  • Email Client
  • Web Related Base classes like for controllers
  • Validations and rules
  • Exception and error handling
  • Metrics logic
  • Configuration and settings logic

How should you distribute your shared functionality and code? Well it all depends on your project but here are a few ways:

  • One library to rule them all :D. Create one library which all projects need to use. Notice: This might become a problem later on when your common library code amount grows. You will end up with functionality that you may not need in a particular Microservice.
  • Create multiple libraries that are used on need basis. Thus using only bits of functionality which you need.
  • Create Web API’s or similar services that you request them to perform a certain action. This might work for things like logging or caching but not for all functionality. Also notice that you will lose speed of code to latency if you outsource your common functionality to a common service that is run independently from your actual code that needs that common functionality.
  • A combination of all of the above.

Dependency injection

Use your preferred dependency injection library to manage your classes and dependencies.

When using your DI I recommend thinking of combining classes into “packages” of functionality by feature, domain, logic, data source etc. By doing this you can target specific parts of your code without “contaminating” the project with unneeded code even if you have a large library like a common library.

For example you could pack a set of classes that provide you the functionality to communicate with a CRM, get, modify and add data.

This would include your model classes. A CRM client class, some logic that operate on the model to clean them up etc.

Once you identify them, make your code that that you can add them into your project with the least amount of code.

Also consider creating a logic to automatically tell a developer which configurations are missing once a set of functionalities are added. The easiest way to achieve this is to add this at compile and/or runtime with checks.

See my previous article on this matter for a more detailed description:

https://lionadi.wordpress.com/2019/10/01/spring-boot-bean-management-and-speeding-development/

Continuous Integration/Continuous Delivery (CI/CD)

There are may ways of doing CI and CD but the main point is that ADD it and automate as much as possible. This is especially important with microservices and small team sizes.

It will speed things up and keep things working.

Here are a few things to take into consideration:

  1. Create unit tests that are run during your pipelines
  2. Create API or Service level tests that verify that things work with mock or real life data. You can do this by mocking external dependencies or using them for real if available.
  3. Add performance tests and stability tests to your pipelines if possible to verify that things run smoothly.
  4. Think of using the same tool for creating your API or service tests when developing and when running the same tests in a pipeline. You can just reuse the same tests and be sure that what you test manually is the same that should work in production. For example: https://www.postman.com/ and https://github.com/postmanlabs/newman
  5. Script as much as possible and parametrize your scripts for reuse. Identify which scripts can be used and shared to avoid doing things twice.
  6. Use semantic versioning https://semver.org/
  7. Have a deployment plan on how you are going to use branches to deploy to different environments (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow), for example:
    1. You can use release branches to deploy to different environments based on pipeline steps
    2. Or have specific branches for specific environment. Once things are merged into them certain things start to happen
  8. Use automated build, test and deployment for dev environment once things are merged to your development branch.
  9. Use manual steps for other environments deployment, this is to avoid testers to receiving bad builds in QA or production crashing on bugs not caught up.
  10. If you do decide to automate everything all the way to production, make sure you have good safe guards that things don’t blow up.
  11. And lastly; nothing is eternal. Experiment and re-iterate often and especially if you notice problems.

Common tools to CI/CD

https://www.sonatype.com/product-nexus-repository

https://www.ansible.com/

https://www.rudder.io/

https://www.saltstack.com/

https://puppet.com/try-puppet/puppet-enterprise/

https://cfengine.com/

https://about.gitlab.com/

https://www.jenkins.io/

https://codenvy.com/

https://www.postman.com/

https://www.sonarqube.org/

High Availability

The main point in high availability is that your solution will continue to work as well as possible or as normal even if some parts of it fail.

Here are the three main points:

  • Redundancy—ensuring that any elements critical to system operations will have an additional, redundant components that can take over in case of failure.
  • Monitoring—collecting data from a running system and detecting when a component fails or stops responding.
  • Failover—a mechanism that can switch automatically from the currently active component to a redundant component, if monitoring shows a failure of the active component.

Technical components enabling high availability

  • Data backup and recovery—a system that automatically backs up data to a secondary location, and recovers back to the source.
  • Load balancing—a load balancer manages traffic, routing it between more than one system that can serve that traffic.
  • Clustering—a cluster contains several nodes that serve a similar purpose, and users typically access and view the entire cluster as one unit. Each node in the cluster can potentially failover to another node if failure occurs. By setting up replication within the cluster, you can create redundancy between cluster nodes.

Things that help in high availability

  • Make your application stateless
  • Use messaging/events to ensure that business critical functionality is performed at some point in time. This is especially true to any write, update or delete operations.
  • Avoid heavy coupling between services, if possible and if you have to do use a lightweight messaging system. The most troublesome aspect of communicating between microservices is going to be over HTTP.
  • Have good health checks that are fast to respond when requested. This can be divided into two categories:
    • Liveness: Checks if the microservice is alive, that is, if it’s able to accept requests and respond.
    • Readiness: Checks if the microservice’s dependencies (Database, queue services, etc.) are themselves ready, so the microservice can do what it’s supposed to do.
  • Use “circuit breaker” to quickly kill unresponsive services and quickly run them back up
  • Make sure that you have enough physical resources(CPU, Memory, disk space etc) to run your solution and your architecture
  • Make sure you have enough request threads supported in your web server and web application
  • Make sure you verify how sizable HTTP requests your web server and application is allowed to receive, the header is usually that will fail your application.
  • Test your solution broadly in stress and load balancing tests to identity problems. Attach a profiler during these tests to see how your application perform, what bottlenecks there are in your code, what hogs resources etc.
  • Keep your microservices image sizes to the minimum for optimal run in production and optimal deployment. Don’t add things that you don’t use, it will slow your application down and deployment will suffer; all of this will lead to more needed physical resources and more money needed.

Messaging and Event driven architecture

I will be covering this topic in an upcoming post but until then here are a few pointers.

Because of the nature of Microservices; that they can be quickly scaled up and down based on needs I would very highly recommend that you use messaging for business critical operations and logic.

The most important ones I would say are: Writing, Updating and Deleting data.

Also all long running operations I would recommend using messaging.

Notice: One of the most important thing I consider is that you log and monitor the success of messages being send, processed and finished, with trailing to the original request to connect logs and metrics together to get a whole picture when troubleshooting.

I have coveted this in my previous logging post: https://lionadi.wordpress.com/2019/12/03/lessons-learned-from-building-microservices-part-1-logging/

Security

Generally security is an important aspect of any application and has many different topics and details to cover.

Related on security I covered this extensively in my last post in this series on Microservices, go check it out: https://lionadi.wordpress.com/2020/03/23/lessons-learned-from-building-microservices-part-2-security/

Templates and scripting

To speed up development, keep things the same and thus avoiding duplicate errors + unnecessary fixes, use templates where possible. This is especially true for Microservices.

What are possible templates that you could have:

  • Templates for deploying Cloud resources like ARM for Azure or Cloudformation for AWS.
  • Beckend Application templates
  • Front application templates
  • CI/CD templates
  • Kubernetes templates
  • and so on…

Anything that you know you will end up having multiple copies is good to standardize and create templates.

Also I recommend that for applications (front or backend), it is a very good practice to have the applications up and running as soon as you duplicate them from your repository. They should be able to be up and running as soon as you start them.

Script as much as possible and make the scripts reusable.

Parametrize all of the variables you can in your scrips and templates

Here are a few things you would need for a backend application template:

  • Security such as authentication and authorization.
  • Logging and metrics
  • Configuration and settings logic
  • Access Logs
  • Exception handling and errors
  • Validations

Logging and Monitoring (+metrics)

Again as with security this is a large topic, I’ve also written about this in my previous post in the series and recommend go checking it out:

https://lionadi.wordpress.com/2019/12/03/lessons-learned-from-building-microservices-part-1-logging/

Configurations pattern

For microservice configurations I recommend a following pattern where your deployment environments (DEV, QA, PROD etc) configuration files configurations/settings values are left empty. You still have the configuration/setting in your configuration/settings files but you leave them empty.

Next you need to make sure that your code knows how to report empty configuration values when your application is started. You can achieve this by creating a common way to retrieve configurations/settings value and being able to analyze which of the needed and loaded configurations are present.

This way when your docker image is started and the application inside the image starts running and retrieving configurations, you should be able to see what is missing in your environment.

This is mostly because you don’t want to have your environment specific configurations set in your git repository, especially the secrets. You will end up setting these values in your actual QA, PROD etc environments through a mechanism. If you forget to add a setting/configuration in your mechanism your docker image may crash and you will end up searching for the problem a long time, even with proper logging it may not be immediately clear.

I’ve written an previous post on this matter which opens things up on the code level:

https://lionadi.wordpress.com/2019/10/01/spring-boot-bean-management-and-speeding-development/

Exception handling and Errors

Three main points with exceptions and errors:

  • Global exception handling
  • Make sure you do not “leak” exceptions to your clients
  • Use a standardized error response
  • Log things properly
  • And take into consideration security issues with errors

Again for for details on logging and security check my previous posts:

https://lionadi.wordpress.com/2019/12/03/lessons-learned-from-building-microservices-part-1-logging/

https://lionadi.wordpress.com/2020/03/23/lessons-learned-from-building-microservices-part-2-security/

For error responses, you have two choices:

  1. Make up your own
  2. Or use an existing system

I would say avoid making your own if possible but it all depends on your application and architecture.

Consider first existing ones for a reference:

https://www.hl7.org/fhir/operationoutcome.html

https://developers.google.com/search-ads/v2/standard-error-responses

https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling/

Still here is also an official standard which you can use and may be supported by your preferred framework or library: https://www.rfc-editor.org/rfc/rfc7807.html

The RFC 7807 specifies the following for error responses and details from https://www.rfc-editor.org/rfc/rfc7807.html:

  • Error responses MUST use standard HTTP status codes in the 400 or 500 range to detail the general category of error.
  • Error responses will be of the Content-Type application/problem, appending a serialization format of either json or xml: application/problem+json, application/problem+xml.
  • Error responses will have each of the following keys(Internet Engineering Task Force (IETF)):
    • detail (string) – A human-readable description of the specific error.
    • type (string) – a URL to a document describing the error condition (optional, and “about:blank” is assumed if none is provided; should resolve to a human-readable document).
    • title (string) – A short, human-readable title for the general error type; the title should not change for given types.
    • status (number) – Conveying the HTTP status code; this is so that all information is in one place, but also to correct for changes in the status code due to the usage of proxy servers. The status member, if present, is only advisory as generators MUST use the same status code in the actual HTTP response to assure that generic HTTP software that does not understand this format still behaves correctly.
    • instance (string) – This optional key may be present, with a unique URI for the specific error; this will often point to an error log for that specific response.

RFC 7807 example error response:

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en

{
  "type": "https://example.com/invalid-account",
  "title": "Your account is invalid.",
  "detail": "Your account is invalid, your account is not confirmed.",
  "instance": "/account/34122323/data/abc",
  "balance": 30,
  "accounts": ["/account/34122323", "/account/8786875"]
}
   HTTP/1.1 400 Bad Request
   Content-Type: application/problem+json
   Content-Language: en

   {
   "type": "https://example.net/validation-error",
   "title": "Your request parameters didn't validate.",
   "invalid-params": [ {
                         "name": "age",
                         "reason": "must be a positive integer"
                       },
                       {
                         "name": "color",
                         "reason": "must be 'green', 'red' or 'blue'"}
                     ]
   }

Performance and Testing

Testing

To make sure that your solution and architecture works and performs I recommend doing extensive testing. Familiarize yourself with the testing pyramid which hold the following test procedures:

  • Units tests:
    • Small units of code tests which tests preferably one specific thing in your code
    • The tests makes sure things work as intended
    • The number of unit tests will outnumber all or tests
    • Your unit tests should run very fast
    • Mock things used in your tested functionality: replace a real thing with a fake version
    • Stub things; set up test data that is then returned and tests are verified against
    • You end up leaving out external dependencies for better isolation and faster tests.
    • Test structure:
      • Set up the test data
      • Call your method under test
      • Assert that the expected results are returned
  • Integration tests:
    • Here you test your code with external dependencies
    • Replace your real life dependencies with test doubles that perform and return same kind of data
    • You can run them locally by spinning them up using technologies like docker images
    • Your can run them as part of your pipeline by creating and starting a specific cluster that hold test double instances
    • Example database integration test:
      • start a database
      • connect your application to the database
      • trigger a function within your code that writes data to the database
      • check that the expected data has been written to the database by reading the data from the database
    • Example REST API test:
      • start your application
      • start an instance of the separate service (or a test double with the same interface)
      • trigger a function within your code that reads from the separate service’s API
      • check that your application can parse the response correctly
  • Contract tests
    • Tests that verify how two separate entities communicate and function with each other based on a commonly predefined contract (provider/publisher and consumer/subscriber. Common communications between entities:
      • REST and JSON via HTTPS
      • RPC using something like gRPC
      • building an event-driven architecture using queues
    • Your tests should cover both the publisher and the consumer logic and data
  • UI Tests:
    • UI tests test that the user interface of your application works correctly.
    • User input should trigger the right actions, data should be presented to the user
    • The UI state should change as expected.
    • UI Tests does not need to be performed end-to-end; the backend could be stubbed
  • End-to-End testing:
    • These tests are covering the whole spectrum of your application, UI, to backend, to database/external services etc.
    • These tests verify that your applications work as intended; you can use tools such as Selenium with the WebDriver Protocol.
    • Problems with end-to-end tests
      • End-to-end tests require alot of maintenance; even the slightest change somewhere will affect the end result in the UI.
      • Failure is common and may be unclear why
      • Browser issues
      • Timing issues
      • Animation issues
      • Popup dialogs
      • Performance and long wait times for a test to be verified; long run times
    • Consider keeping end-to-end to the bare minimum due to the problems described above; test the main and most critical functionalities
  • Acceptance testing:
    • Making sure that your application works correctly from a user’s perspective, not just from a technical perspective.
    • These tests should describe what the users sees, experiences and gets as an end result.
    • Usually done through the user interface
  • Exploratory testing:
    • Manual testing by human beings that try to find out creative ways to destroy the application or unexpected ways an end user might use the application which might cause problems.
    • After these finding you can automate these things down the testing pyramid line in units tests, or integration or UI.

All of the automated tests can be integrated to you integration and deployment pipeline and you should consider to do so to as many of the automated tests as possible.

Performance

For performance tests the only good way to get an idea of your solutions and architectures performance is to break it and see how it works under long sustained duration.

Two test types are good for this:

  • Stress testing: Trying to break things by scaling the load up constantly untill your application stop totally working. Then you analyze your finding based on logs, metrics, test tool results etc.
  • Load testing: A sustained test where you keep on making the same requests as you would expect in real life to get an idea how things work in the long run; these tests can go on from a few hours to a few days.

The main idea is that you see problems in your code like:

  • Memory leaks
  • CPU spikes
  • Resource hogging pieces of code
  • Slow pieces of code
  • Network problems
  • External dependencies problem
  • etc

One of my favorite tool for this is JMeter https://jmeter.apache.org/.

And to get the most out of these tests I recommend attaching a code profiler to your solutions and see what happens during these tests.

There is a HUGE difference how your code behaves when you manually test your code under a profiles and how it behaves when thousands or millions or requests are performed. Some problems only become evident when they are called thousands of times, especially memory allocations and releases.

And lastly; cover at least the most important and critical sections of your solutions and keep adding new ones when possible or problems areas are discovered.

These tests can also be added as part of the pipelines.

Topology tests

Do your performances tests while simulating possible error in your architecture or down times.

  • Simulate slow start times for servers.
  • Simulate slow response times from servers.
  • Simulate servers going down; specific or randomly

Test how your system works under missing resources and problems.

Test how expensive your system is

When you are creating tests consider testing the financial impact of your overall system and architecture. By doing different levels of load tests and stress tests you should be able to get a view on what kind of costs you will end up with.

This is especially important with cloud resources where what you pay is related to what to consume.

How to fix internet connectivity errors in Android Studio emulator

This was a strange problem for me. I am not a Java or Android developer but had to create a small Android app to test something. I noticed that no internet connection was available to the emulated device.

After to Googling and wondering I realized that the solution was to:

Disable my ethernet card from my laptop, then restart my emulator. This I had to do because for some reason the emulator or Android studio doesn’t recognize a WiFi card as the primary connection if you have both the ethernet card and the WiFi card enabled. Might be a configuration in Android Studio for make this work but I had to do it from Windows Control Panel: Control Panel\Network and Internet\Network Connections

Xamarin Development – Notes, tips and info – Part 1: How to develop your first iOS and Android Apps

Hi,

This is series of posts and my notes and info which are based on a Udemy course. I’ve taken what I consider “good to know” and wrote them down. This may come handy to someone else.

These are my notes on Xamarin Development.

Presently this post is mostly based on this Udemy Course:

https://www.udemy.com/xamarin-beginners

Contents

What is Xamarin. 2

Xamarin Platform.. 2

Xamarin Test Cloud. 2

Xamarin Insight. 2

Debugging Android applications. 3

Xamarin Platform.. 4

C# as the language for your mobile app development. 4

Share your C# code on any platform.. 4

Device provisioning/installation of your app. 4

First iOS Application. 4

Basic iOS controls: 5

Properties window.. 5

Naming UI Controls. 5

Events. 6

UI Elements. 6

Different Keyboard types. 6

Changing background colors. 7

Tips and Tricks. 7

First Android Application. 7

Basic Androi controls. 7

Naming UI Controls. 7

Accessing UI elements in the code. 8

UI Elements. 9

Different Keyboard types. 9

Navigation between pages in iOS and Android. 9

Navigation between pages in Android. 9

Adding a new layout and activity. 10

Using Intents to navigate. 10

Passing values between activities (pages/layouts). 10

Navigation between pages in iOS. 11

Adding a new navigation controller. 11

Passing values between views/segues (pages/layouts). 15

What is Xamarin

Xamarin Platform

Building applications on mobile devices

Xamarin apps share code across all platforms

Target i0S, Android, Windows and Mac with a single, shared C# codebase. Use the same language, APIs and data structures on every platform.

C# is the best language for mobile app development

Anything you can do on Objective-C, Swift or Java, you can do in C#

Native UI, native API access, native performance

Xamarin apps are built with standard, native user interface controls. Apps not only look the way the end user expects, they behave that way too. This can’t be achieved with other solutions. They look and behave as they would on that native environment (Android. iOS, Windows Phone)

Xamarin Test Cloud

Test your applications on different devices

Test your app on over 1,000 devices

Run your app on a huge collection of real devices from around the world. Select devices based on form factor, manufacturer, operating system, or even popularity in your target market.

Automate using Ruby or C#

With a framework called Calabash you can automate and test any iOS or Android app, native or hybrid, from the UI level down for perfect integration and continuous improvements.

Analyze app performance

See full-frame screenshots and video playback for every step of every test, then receive performance data and compare reports against previous runs to find regressions and bottlenecks.

Xamarin Insight

Monitoring your applications

Precise, detailed error reporting

Xamarin Insights helps developers prioritize issues by showing exactly which users each crash is impacting, and what sequence of actions preceded the crash.

Understand how users are interacting with your app

Developers can see who’s online, which devices they’re using, what issues they’ve experienced, where they’re from, and which activities they’ve used in sessions.

Integrate your data

Connect your app to a variety of external services and be notified when a new issue is opened, an issue is occurring repeated times in a small amount of time, or an issue’s status changes.

· Github

· Visual Studio Online

· …

Debugging Android applications

· You can use normal Android Virtual Devices with the SDK

· for a FASTER experience use the Xamarin Android Player: https://www.xamarin.com/android-player

o You also avoid using Hyper-V on Windows

Image: 1 Xamarin Android Player

o To Use the Android Player just go to your Visual Studio toolbar and select a device in this case the device installed in Image: 1 Xamarin Android Player

Image: 2 Example how to use the Android Player

Xamarin Platform

C# as the language for your mobile app development

· Anything you can do in Objective-C, Swift, Java, you can do in C#

· Things which are better than competition(at the present)

o Stronger Types

§ Generics and Compound types are used safely

· No need for casting of comments

· Good tools that understand what you are doing

o Language-level async, made easy in C#

o First-class functions, lambdas are easy to use

Share your C# code on any platform

· Possible to share on average about 75 % of your code across platforms

o Most of it at app logic, common functionality

o Could also be at UI level

§ Xamarin.Forms could be used in theory to achieve 100 % shareable code

Device provisioning/installation of your app

· iOS – Two options:

o Enroll to the Apple Developer Program:

§ https://developer.xamarin.com/guides/ios/getting_started/installation/device_provisioning/

o Or with Xcode 7 use free provisioning:

§ https://developer.xamarin.com/guides/ios/getting_started/installation/device_provisioning/free-provisioning/

First iOS Application

· Start with a single view app

· Main.Storyboard we define the UI

· ViewController.cs the main logic goes here

· iOS UI design on implementation requires more work to make it work and look good across different iOS devices

· By default the main.storyboard is linked to the ViewController.cs.

Basic iOS controls:

· Label

· TextField (for inputing data)

· Button

Properties window

· Widget tab

o You can alter button properties such as:

§ Color and how it looks

§ Title

§ Font

§ ID

§ etc

· Layout tab

o How the control is laid out on the UI

· Events tab

o How the user interacts with the control through touch

Naming UI Controls

· This can be achieved through the properties window.

o Select the desired UI control from the main.storyboard

o Go to the Name text field under the Identity category

o Notice: This is a physical name, meaning that you use this in the code to access the control

Events

· When users click/touch on buttons an event is launched.

· You can attach to a click event through the UI or through code by normal C# event handling in the ViewDidLoad() function in the ViewController.cs file

public override void ViewDidLoad()

{

base.ViewDidLoad();

// Perform any additional setup after loading the view, typically from a nib.

this.convertButton.TouchUpInside += ConvertButton_TouchUpInside;

}

UI Elements

Different Keyboard types

· You can select different types of keyboard by selecting a text field and under Keyboard Type select the desired keyboard output

Changing background colors

To change the background color of a control simply change the BackgroundColor property. Example>

this.colorView.BackgroundColor = UIColor.FromRGB(redValue, greenValue, blueValue);

Tips and Tricks

Using this.View.EndEditing(true); will end/hide the editing keyboard.

First Android Application

· For Visual Studio development you need Hyper-V to emulate an android device

Basic Androi controls

· Under Text fields category you will find normal input controls

· Under form widgets you will find basic button and plain text controls

Naming UI Controls

· This is found in the properties window under the Main category and in there ID

Accessing UI elements in the code

· In an Android application you have to find the controls manually and assign them to a variable of the same type.

· You use the FindViewById<>() function call. You pass the class type to the template(generic) parameter, then pass the control ID by accessing your project namespace then Resources class, then Id class and finally the control ID which you define in your layout.

Example:

using Android.Runtime;

using Android.Views;

using Android.Widget;

using Android.OS;

namespace BMICalculationAndroid

{

[Activity(Label
=
“BMICalculationAndroid”,
MainLauncher =
true,
Icon =
“@drawable/icon”)]

public class MainActivity : Activity

{

Button calculateBMI;

TextView resultTextView;

EditText heightEditText, weightEditText;

protected override void OnCreate(Bundle bundle)

{

base.OnCreate(bundle);

// Set our view from the “main” layout resource

SetContentView(Resource.Layout.Main);

this.calculateBMI = FindViewById<Button>(BMICalculationAndroid.Resource.Id.calculateBMI);

this.resultTextView = FindViewById<TextView>(BMICalculationAndroid.Resource.Id.resultTextView);

this.heightEditText = FindViewById<EditText>(BMICalculationAndroid.Resource.Id.heightEditText);

this.weightEditText = FindViewById<EditText>(BMICalculationAndroid.Resource.Id.weightEditText);

}

}

}

UI Elements

Different Keyboard types

· To change to keyboard type when typing on a mobile device you do it similarly as on the iOS side

o In the properties window go to Main – Input Format => inputType and change the keyboard type

Navigation between pages in iOS and Android

Navigation between pages in Android

Adding a new layout and activity

· This allows you to create another UI view/page that is to be displayed in your application

To do this in Visual Studio go to the Resources/Layout folder and add a new item. From the Add New Item window select the Android Layout option.

Then create new activity code class which will operate on the newly created layout.

You can create this for example in your project root by adding again a new item there.

Then to create the link and set the content between the layout and the activity call the SetContentView() function.

protected override void OnCreate(Bundle savedInstanceState)

{

base.OnCreate(savedInstanceState);

// Create your application here

SetContentView(Resource.Layout.BMIDetails);

}

Using Intents to navigate

· You navigate to another layout(page) by using the Intent class

· You can use the constructor that takes the present content and the desired activity class associated with the layout

· Then you start the activity and move to the other layout(page) by calling the StartActivity() function

var intent = new Intent(this, typeof(BMIDetailsActivity));

StartActivity(intent);

Passing values between activities (pages/layouts)

· In the activity from where you want a value to be passed to another activity you use the Intent class member function named PutExtra() to store the value. It is a key value pair which can be retrieved in another activity later:

var intent = new Intent(this, typeof(BMIDetailsActivity));

intent.PutExtra(“bmi_value”,this.bmi);

StartActivity(intent);

· And to restore the value you access it through the activity Intent class member by accessing from it the Extras member. From there use the GetFloat() function.

var bmi = Intent.Extras.GetFloat(“bmi_value”);

Navigation between pages in iOS

Adding a new navigation controller

· Drag and drop a new navigation controller

· If you already have a root view controller, then remove the one which was created by the previous operation (Press the mouse second button on the view controller and press delete)

· Next move is to indicate to the application what is the starting view (Apple story board naming is: sourceless seque). You are using a sourceless seque indicator: https://developer.xamarin.com/guides/ios/user_interface/introduction_to_storyboards/

o Drag and drop it on the navigation controller

Image: 3 it should look something like this

· Next create a relationship between the navigation controller and the main view by pressing CTRL + left mouse button on the navigation controller and dragging the mouse over the main view. Then you select the Root option from the new popup. This will mark the main view as the root view.

· Next drag a new view on the storyboard and give it a name. Once you do this the developer tool will warn you that there is no code behind class associated with the view(In Xamarin Studio the UI will offers you to create one). In Visual Studio the easiest way to do it is to press the dark grey area on the view without a controller and writing a new class name in the Class property in the properties window. This will create a new view controller associated to the view selected.

· To navigate from your Main(root) view just select a control that can be pressed like a button, press CTRL + left mouse button on it, then drag to the desired view and let go of the mouse button. In the new popup select Show. This is it. A connection and transition has been made between the views.

Passing values between views/segues (pages/layouts)

· To pass a value between views/segues you can override the function PrepareForSegue() which is launched when the segue is about to be used, that is when the user presses a button or some other UI element which invokes the action of moving from one view/page/layout to another one. What was done earlier.

· In the function you then access the parameter segue and ask for the DestinationViewController class member which you have to cast to the target view controller class. After that it is simply of matter of accessing the defined properties in the view controller class. Same as accessing any public member of a class.

public override void PrepareForSegue(UIStoryboardSegue segue, NSObject sender)

{

base.PrepareForSegue(segue, sender);

var detailViewController = segue.DestinationViewController asBMIDetailsViewController2;

if(detailViewController != null)

{

detailViewController.bmi = this.bmi;

}

}

How to profile and analyze your application performance with Visual Studio 2015

I ran into a couple of good MSDN resources while looking into how to analyze your applications performance and see possible bottlenecks. Here is what I found:

https://blogs.msdn.microsoft.com/visualstudio/2016/02/15/analyze-cpu-memory-while-debugging/

https://blogs.msdn.microsoft.com/visualstudioalm/2015/07/20/performance-and-diagnostic-tools-in-visual-studio-2015/

https://blogs.msdn.microsoft.com/visualstudioalm/2015/10/29/profile-your-cpu-in-the-debugger-in-visual-studio-2015/

https://blogs.msdn.microsoft.com/visualstudioalm/2015/04/29/diagnosing-event-handler-leaks-with-the-memory-usage-tool-in-visual-studio-2015/

https://blogs.msdn.microsoft.com/vcblog/2015/10/21/memory-profiling-in-visual-c-2015/

 

SharePoint CORS fix

This is possible fix for the a possible calls made from one application to your SharePoint side that is located in another domain.

In your SharePoint application add the following custom headers to enable requests from a different domain. Just change the header: Access-Control-Allow-Origin to point to the application who is making a call to your SharePoint application.

<system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name=”Access-Control-Allow-Credentials” value=”true” />
        <add name=”Access-Control-Allow-Origin” value=”http://source-application.com​&#8221; />
        <add name=”Access-Control-Request-Method” value=”GET,POST,HEAD,OPTIONS” />
      </customHeaders>
    </httpProtocol>​
</system.webServer>​

Also if you are making an AJAX call add the following parameter to the call:
xhrFields: { withCredentials: true }

 

Sample code:

jQuery.ajax({
 url: requestUri,
 type: 'GET',
 dataType: 'json',
 headers: requestHeaders,
 xhrFields: { withCredentials: true },
 success: function (data)
 { 

 },
 error: function ajaxError(response) {
 console.log(response.status + ' ' + response.statusText);
 }
 });

Other possible parameters for the AJAX call:

crossDomain: true
And for CORS support:
$.support.cors = true;

A bit more detail can be found here in this post:
https://blog.kenaro.com/2014/03/18/cross-site-scripting-with-sharepoint-2013-rest-calls/

Mobile Device Testing and Debugging with VirtualBox, Android Studio, Visual Studio and IIS

This post is from the perspective of a person who has a Microsoft technologies based web solution that needs to connect with a mobile device. This might work for other types of technologies and virtual machines with some or alot of tuning. Basic principles should be more or less the same.

I will give firstly an introduction on the solution used in my scenario:

I have a Android mobile device with an app in it that needs to connect to a webapi service to retrieve data and post data to it. The thing which this post is concerned about, is debugging the app with Android studio using the app from the Android device against a webapi which is also under debug mode in Visual Studio. This way I can see what is happening both on the client and on the server side.

Basically how this works is that you will have to connect with your mobile device to a local network where your physical machine exists. Because you are using a mobile device the logical way is over WiFi and no having your device plugged in to your physical machine by USB does not work. You can not directly connect to a localhost that way. Well atleast I could not make it to work. Notice that you can connect to a localhost from Android Studio while debugging your Android app but this is only possible is your a emulating the app locally. Even then though you might have problems and have to configure your solution in such a way that your app will pick it up.

This post assumes that you have a ready build for your server side solution at a location in your development machine. Here are the steps:

1. Create IIS site

– Add a new application to IIS which points to your solution build location.
mobile1

mobile2

– Next make sure that the application pool account has enough privileges to the location. I do this by creating a new account to AD or I create a local machine account on my development machine.

This is to configure the Application Pool account:
mobile8

These steps are for the file system level:
mobile3

mobile4

– If you are using a database in your application make sure that the application pool account has the proper privileges. This depends of course on how you have built your solution.
– Assign a port to your web application

mobile6

mobile5

2. Config ports and firewall settings
– Next you need to allow inbound and outbound connections to you web application through the port which was earlier configured for the web application. This needs to be done for both the virtual machine and your actual physical machine.

For virtualBox:
mobile9

For WMWare:
mobile10
mobile11

3. Attach to process

The next steps is to attach your developer tools to your server solution and your mobile application to whatever developer tools your are using, something like Android Studio or XCode.

Config VirtualBox

http://www.howtogeek.com/122641/how-to-forward-ports-to-a-virtual-machine-and-use-it-as-a-server/

 

VirtualBox, Android Devices and error “This device cannot start. (Code 10)”

Ok, if you get this error you are probably trying to install your Android device to windows and it fails. When checking the device manager you might see the following error code. There are numerous posts and instructions which might help you but none did to my LG G3. What eventually helped was an insight based on several different posts.

On my virtual machine the problem was related to the USB port type used in relation to the USB port actually used in your real world machine and USB cable used.

Basically as default the VirtualBox used USB 1.1 which for some reason does not work, probably something to do with my cable being USB 2.0. To fix my problem I installed the VirtualBox extension for USB: VM VirtualBox Extension Pack.

Then I changed the USB type to be used for the Virtual Machine to 2.0, booted my windows and it worked. So if you are getting the error above no matter where you are check that you have the proper USB cable which is compatible with your Android device and the port on your machine. For a virtual machine image check that you have the right USB configuration in relation to your real world devices.

If the case above does not work, then try this KB article from Microsoft:

https://support.microsoft.com/en-us/kb/943104