Monthly Archives

January 2018

Exploring DIL Environment Limitations and Solutions with Xamarin

By Development, Mobile, XamarinNo Comments

In my last installment I described what a DIL Environment is and how it can negatively impact a mobile application that relies on web services. When developing a mobile app there are a number of scenarios you may face regarding the amount of control and DIL support you have with the backend web services you are consuming:

  • Custom Purpose-Built Backend: A custom backend that your team designs, controls, and configures to support DIL scenarios specific to your application.
  • Platform As A Service (PAAS): A backend utilizing a platform like Azure, ApiOmat, or Amazon Web Services that may offer some built-in DIL support which can be implemented and configured.
  • Virtual Blackbox Backend: A back-end that you have absolutely no control over and provides no DIL support.

In this article I will be examining the third scenario, a virtual blackbox backend. In order to maintain functionality for the mobile application in a DIL environment in blackbox backend scenario all DIL support must be implemented client-side within the mobile application itself. This is a common situation when it comes to enterprise and and third party application development.

 

Offline Caching Support- Preserving core application functionality when disconnected

How can a mobile application like this remain functional when it is cut-off from its web service data stream?  The only way is to cache incoming data locally on the mobile device for offline use. The complexity and amount of data consumed by the application would be factors the developer should consider when determining the type of data store and its implementation. One the most common methods would be to leverage an SQLite database within the mobile application to store the incoming data. Xamarin offers excellent support for SQLite database implementation, but there is no framework for resolving an optimal caching strategy.

When creating a local store there is also the need for custom logic to be implemented to manage the data. The storage space on the mobile device is limited. It is unlikely all of the data supplied by the webservice can be cached on the mobile device indefinitely due to the device’s local storage space limitations. Some applications may work best with a FIFO (first-in, first-out) logic applied to the data caching process. This logic could be triggered either when the local data store reaches a predetermined total size on the mobile device’s local hard drive, or the remaining space on the device’s local drive drops below a critical level. At that point old data would be purged to create space for new incoming data. In some cases it might make sense to give users the option to override that logic on specific data objects that may be critical to the user’s purpose.

There must also be custom logic implemented to save and track changes the user makes to the data as they work offline. When the device finally reconnects to the network there needs to be logic to manage the update process. Depending on the amount of data kept in the local store there is a good chance that pushing the entire contents of the local store back to the web service for update would be impractical. Custom logic within the mobile application itself must be implemented to track changes so that only new data is pushed to the web service for update. This strategy would save time and bandwidth, both of which may be critical to the user.

There is no out of the box existing Xamarin framework to support this caching. Each developer must roll their own version and think through all of the use cases.

 

Security Issues- What is the nature of the data being stored?

Depending on the purpose of the application, especially medical data, it is a possibility that the data being cached on the local store is sensitive or private in nature. The presence of malware on the mobile device where your application is in use is a possibility that should be considered. It may be necessary to encrypt the data being cached by your application in order to prevent malware from mining data out of your application’s local data store. Xamarin does support data encryption, but developers typically have to download 3rd party tools to build effectively.

Another issue to consider is if your application requires secure user login. Typically user authentication is handled by backend web services, so how can a user login to the application when disconnected? A custom offline login process must be created and implemented within the application. Validated login information must also be stored locally on the user’s mobile device for offline authentication process’ utilization. Storing login information locally would require an encrypted local store in order to keep users’ credentials secure.

Additionally, when working in a blackbox backend scenario there is typically no way to obtain validated login information by request from the web service. Seemingly the best (and possibly only way) for the mobile application to capture validated login information is to store usernames and passwords when a successfully validated login to the webservice occurs. This solution is limited and would only store the login information of users that successfully log in on a specific device. Authorized users who have not previously logged in on that specific device would not be able to login on that device while it is disconnected.

 

Battery Life- Is this a critical issue for your user?

When a device becomes disconnected from the network it begins scanning for a new connection. This scanning can consume a lot of power and drain the device’s battery very quickly. Accelerated battery consumption is potentially a big problem for end-users if they are in a situation where there is no access to electricity. Within your mobile application it may be wise to implement logic that alerts the user when the device becomes disconnected from the network and then offers options to the user for the device’s network scanning behavior. It may be possible to override the device’s default network scanning behavior in order to give the user the ability to change the time interval between scan attempts or stop the device from scanning for a new connection altogether. All of these options would help to extend the battery life of the device. The user should also be given the option to re-enable the network scan when the user is back within range of the network. While the OS of mobile phones do implement battery saving techniques, Xamarin developers don’t have existing tools built into the framework.

 

Conclusion

In this installment I have taken a look at the challenges presented in attempting to compensate for the limitations of a DIL environment when there is no support for this scenario from the web-services your mobile application consumes. There are many aspects to the problem that must be considered, and the implementations of these solutions will largely depend upon the priorities and purpose of your application. When dealing with a virtual blackbox backend there is a lot of work put upon the application development team to find and create custom solutions and implement them within the mobile application itself.

Xamarin would be a great tool for this scenario when the application being developed is required to be deployed on both Android and iOS platforms. The majority of the custom logic required to implement the DIL solutions I described would be shared in both platform iterations. Sharing that amount of code would reduce development time and allow for faster and less costly deployment across multiple platforms. A DIL environment creates many challenges, but we here at Bytelion relish the opportunity to solve problems and create custom solutions for our clients.

Stay tuned for our next installment as we explore newly created tools and techniques to support DIL using Xamarin!

Why Do I Need A QA Engineer?

By Agile, Development, Innovators, Startup, TestingNo Comments

Introduction

Why is a Quality Assurance engineer necessary for development of software? Couldn’t I simply get my developers to QA/review their own work? Could I get get developers to review each other’s work? These are all questions that I have come across at some point or other from multiple people.

Before I answer, let’s briefly summarize what QA is:

What is QA?

QA is the analysis of functionality and overall appearance of your site / app. This can include (but is not limited to): Cross-browser testing, screen resolution compatibility testing, grammar, spelling, functionality.. the list goes on. QA is ideally approached from multiple angles.

When testing a simple ‘contact us’ form, the QA engineer would ensure that the email field ensures that a valid email address is entered, the name fields do not accept numbers, the name fields do not accept special characters, ensuring fields have limits so malicious users cannot overwhelm your system by entering large amounts of characters, etc.

QA Responsibilities

A QA engineer’s responsibility is to review each feature before it is released, suggest edits to issues and approve code before it reaches the product owner. Therefore, not only is the entire site under the QA engineer’s watchful eye, each part of the site is analysed during its creation.

Why is QA Necessary For Development?

As you can see above, the responsibilities for QA are laborious. A dedicated amount of time by someone who knows your system is needed. Not only is QA needed for each release, regular testing across your site is critical to catch issues that may affect it from external sources.
Example: Still running flash player on your site? Browsers are discontinuing support since it is considered deprecated technology. Your QA Engineer will (/would) know this.

 

Can Developers QA Their Own Work?

The QA engineer should be a consistent team member, part of daily scrums and involved in feature development. Developers however,are assigned a particular module of the whole system and aren’t truly aware of the system as a whole. Not only is development typically modular, a developer has a completely different mindset and thought process. He/she may not consider all the scenarios a tester would consider.
They can definitely code review their peers but QA is a different game entirely.

 

Want to find out more about software development practices? Check out our Blog!
Bytelion is a full service software development firm. Check out the rest of Bytelion.com or contact us to find out more.

What does it mean to be in a Disconnected, Intermittent, Limited bandwidth (DIL) Environment?

By Development, Mobile, Xamarin

What is a DIL Environment?

Disconnected, Intermittent, Limited bandwidth (DIL) environments can occur more often than you think. In a tunnel, elevator, or driving down a scenic country road are all places where you are likely to experience this condition. Your mobile device is either out of range or simply blocked from connecting to the nearest cellular tower or wifi network. You have now entered a DIL environment. So what does that mean for your mobile device? A loss of network and internet connectivity makes your web browser useless, but does it have to render your mobile applications useless as well? This is an important question to consider when designing and building your mobile app.

Why is it Important for Mobile Developers to Consider?

Most mobile applications are designed to utilize various web based services – and for good reason. The native resources of a mobile device are limited in both processing power and data storage capacity. It is only natural to want to connect to a web service to access superior resources remotely in order to enhance the capabilities of an application beyond what the mobile device can provide on its own. We often take for granted that there will be a fast and robust connection to the internet available to the user at any given time, but what about when it is not?

Thinking About Strategies

There are strategies that can be implemented in order to mitigate the effects of this loss in resources when entering a DIL environment. The U.S. Department of Defense has attempted to tackle this problem with a variety of techniques. Sophisticated software and hardware solutions have been devised to enable mission critical applications and resources to remain available for military personnel to utilize on their mobile devices in hostile territory where secure and reliable connections to their tactical cloud resources are non-existent. One solution calls for the implementation of forward-deployed, discoverable, virtual-machine-based tactical cloudlets that can be hosted on vehicles or other platforms which provide a limited substitute for normal network connectivity.

Military hardware solutions are impractical to implement in support of consumer applications in a normal civilian environment. But are there ways to mitigate the limitations of a DIL environment without utilizing costly and impractical hardware solutions? As a Xamarin mobile developer at Bytelion, I will explore this issue further in my next post. Stay tuned, and thanks for reading!