Your message is highly valuable for us. One of our experts will follow up with you within 1-2 business days to discuss your request or to inquire for additional information if needed.
Demand for business mobile apps is booming today. Staying mobile is very important for modern businesses. Enterprise mobile applications digitalize workflow and help company’s employees and clients to have anytime-anywhere access to corporate resources. From small day-to-day planners to intercorporate social networks and data analysis tools for the company governance, these apps save billions allowing businesses to stay mobile. However, development of such applications requires a specific approach.
We start a set of articles dedicated to the industrial development of applications for the corporate customers with the article on defining initial business app requirements.
What customers ask for
Planning is important. A business mobile app is frequently supplied as an addition to the web application. The reasons to develop a mobile app may vary, e.g., when the adaptive interface of a web application is insufficient for mobile devices, or when the planned functionality should be considerably different. In such case, the mobile application has to be fully integrated into the corporate information environment. This can dramatically influence the application architecture. All this should be considered as early as during the planning stage.
Continuous support and updates require accuracy and good order. If the web application continues to evolve, the mobile application has to be updated on a regular basis. Here’s where a huge challenge is for any company.
Human factor always plays a great role in your project success. In the course of software development, specialists may come and go, switch to other projects, fall ill, etc. The app architecture and documentation have to be in perfect order so that the new specialists can quickly adapt, even if they work or worked for another company. When the source code of your product appears to be a random result of a Programmer’s Deep Thought, your team will have hard times maintaining it.
Along with the functional requirements, declared by a customer directly, your application should meet the whole range of criteria. These criteria are commonly described in the architecture documentation and the so-called Service-Level Agreement (SLA).
Most of these non-functional requirements address the following criteria:
- Platform compatibility
Let’s review each of them one by one.
The most common practice is to have clear requirements for the total page load time, as well as for any asynchronous request. Naturally, an application shouldn’t annoy the user due to slow response times, let alone random freezes or crashes.
A small case from Infopulse’s practice. During the load testing, we found that one of the queries was taking 45 seconds – precisely 45 times longer than acceptable. Luckily, this bug didn’t require much work and was quickly fixed before hitting the production.
Newer platform versions bring new functionality, at the same time setting new challenges for the developers. Backward compatibility with old legacy platforms can sometimes raise even more challenges and issues.
The development, testing and further support of a product for different platform versions have a huge impact on selected tools, as well as costs, resources and time required to implement all that.
E.g., during a compatibility test of an iOS 10 app for our global customer, we discovered that the text on “Sign in” button was displayed in Chinese or Japanese characters. We needed to change only one line of code to fix this bug, but we had to recompile the app, perform the full-cycle testing all over again, publish and reinstall for all users. All that had to be done before the new version was deployed to the end-users all over the world.
When developing business applications, a special attention should be paid to security due to the confidential nature of the data. Clients won’t be happy if valuable business data falls into the hands of hackers or competitors. Therefore, all technologies and outsourced components are always assessed from the security standpoint, while the final product is scanned for vulnerabilities before the release.
For instance, sensitive data, such as login or password, is either encoded or not stored at all. User authentication should be protected via security protocol, while levels of access to data may vary based on users’ rights and roles.
In its essence, a common mobile app is a set of pages with transitions between them. An app page may contain a form with control elements and data visualization, a list, or a combination of both. If the amount of data increases, the application may slow down and cause memory leaks, loose data, and crash. In order to avoid such issues, developers use various techniques, such as dynamic data loading, caching, repeated usage of visual components that are used to display various screens. If overlooked, this all may cause severe damage to the company.
Scalability is very important for your app. If you initially design your app with room for scalability in mind, it would require minimum investments in the course of development. If you start thinking about scalability during the development stage, its implementation may be rather time- and resource-consuming. The worst case is when you start planning scalability by the end of the development cycle, i.e., during acceptance or load testing. In this scenario, prepare for the unforeseen consequences and serious problems.
E.g., even if we expect not more than 100 data set entries, it still makes sense to provide room for additional on-demand page loading (e.g., 20 values at a time).
We all have our own vision of creativity and it’s absolutely true for the software development as well. Software developers are very creative people. Their creativity, however, should not be chaotic. When starting a project, you need to agree on a development syntax by forming a Project Syntax Style Guide. This is where you need to set development environment, establish clear project rules, while statistic code analyzers become developer’s best friends. Otherwise, the application code can quickly become an unusable mess.
Let’s say, our application should have an option for phone calls. While each platform (iOS, Android, Windows) has a specific interface for this purpose, developers would benefit a lot from using a universal shared code to invoke a calling service. To solve this task, some coding patterns can be reused, such as repository, inversion of control (IoC), etc., which at the same time allows to smoothly implement unit testing.
Usability is a very important aspect of any application and should never be neglected.
Here’s a simple example. Landscape view for Android devices requires separate layouts, extra programming, with all the ensuing consequences. The portrait view, however, is a widely accepted standard for any business application. We need to consider, whether our application should support the landscape view or our users need only the portrait view.
Another example. What’s the best way to process exceptional conditions? As a rule, a user will see a simple error report, while the details are stored in a log. At the same time, a log should be stored on the server and, except for a detailed error itself, it should also contain information about a user and a mobile device.
Working ad-hoc and creatively can sometimes be a nice approach, however, creativity requires preparation. You need to carefully study your future audience and your client’s requirements.
While there are numerous types of testing, all of them are required to detect defects at a certain stage of application development. We list some of them below:
- Acceptance testing, when defects are detected by the customer
- Manual testing, which is performed by the developer
- Load testing, which serves to determine the capacity to process large volumes of data or a large number of queries
- Automated UI testing
- Unit testing
For the server side, unit testing is considered obligatory and should cover about 60-80% of the code. For the mobile part, however, unit testing and TDD (test driven development) have not yet become a common practice.
We hope that the above-mentioned ideas will be of use for you or your company.
In our next article, we’ll speak about selecting the right platform for enterprise mobile applications development. Stay tuned!