Recently we did a mobile app development project for one of our clients. The requirement was to develop an Android app for a Music Festival based on the design mockups provided by the customer. During the app development we came across some of the non functional requirements and some critical aspects which could affect the estimate if not considered and given an attention to. These are the requirements/aspects which are hardly mentioned in the Requirement Documents but are discussed only during the development which can affect the project estimate, timeline and budget. We would like to share this learning with the community here.
To give a brief idea about the App, it caters the database of artists playing in different music festivals. App has an interesting feature of discovering the artist playing in front of you on the stage through GPS system. You click a single button in the App and it would open the profile of the artist currently playing in front of you. Apart from this, the app has also the features of showing the list of artists playing in current festival, artistâ€™s detailed profile with his schedule of play and social links, favorite artists, festival news, stages and timing details, festival activities, map and festival news and notifications.
Based on our experience and learning, following are few critical aspects to consider while estimating the development efforts.
1. Social Login
Having provision for alternate login mechanism has become common feature now a day. In our case, customer required Facebook as an alternate login method. When it comes to implementing normal username/password login, it is very straight forward and we can estimate it almost accurately. But with Facebook or any other social login, itâ€™s good to consider following things for estimation.
I. Register the app with Facebook
Facebook API requires to the use of Facebook Developer Account in order to make Facebook authentication and retrieving user profile information. You need to register your app through Facebook Developer Account to get some of the configuration details such as Application ID etc. that is used along with Facebook APIs. This process might take little time, so it is good to get these details from the customer as early as possible in the development stage.
Refer Facebook Guidelines to register an app on Facebook.
II. Retrieve user profile information
As per the new policies introduced by Facebook, as of this writing, Facebook has put some restrictions on the type/amount of information you can retrieve from Facebook without any permission. That is, you can fetch user email, first name, last name etc. very basic information easily. But if you want to collect other information, for example, userâ€™s birthday, you need explicit permission from Facebook.
One of our appâ€™s features required to display userâ€™s age in the profile section. But we could only fetch the age-range from Facebook directly, and not the exact age. Hence, we left with the option to use birthday to calculate userâ€™s age. But we learnt that in order to retrieve userâ€™s birthday, you need to explicitly get your app reviewed by Facebook. Their review team checks the purpose of using such information and either approve or reject it based on their policies.
Refer Facebook Help for various user profile information to be retrieved from Facebook.
This Help Page provides guidelines on how to get the app reviewed by Facebook.
Above information advises us to be prepared with proper requirement study before estimating the development efforts.
2. Location tracking using GPS
Many apps use Smartphoneâ€™s GPS feature to build location specific features. In our case, we required to develop a feature which would identify the artist playing in front of you on the click of button in the app. The logic is, app would use GPS to know device location (Longitude, Latitude) and send to the backend system which would find the stage from pre-populated database. It would further find the artist playing at given time on that stage from the database and send the information back to the app.
The critical aspect here is the accuracy of device location. You need to understand the accuracy requirement in advance. Our customer required to accurately detect the device location in the range of 30 feet. That means the app should distinguish two locations parted in the said range in order to make the feature work correctly as per the business scenario. In case of Android, there is couple of options to increase the location accuracy e.g. High Accuracy, Battery Saving and Device Only. You need to implement the feature with enforcing the High Accuracy mode enabled for location tracking to get the accurate location of the device.
It is also worth noting that, testing of location based feature might take more time than estimated. GPS can give bad results for dense areas compared to open areas. So it is advisable that you consider what type of locations you are developing the functionality for, do proper technical feasibility study and estimate the efforts accordingly.
3. Push Notifications
Push notification is another common feature in Mobile Apps. As such, its implementation is pretty easy. Server/Backend system uses the APIs from App Platform (e.g. Google Cloud in case of Android) to send the notification messages based on the device tokens registered at the App Platform. However, functional aspect of the push notification implementation is crucial. Consider following things before estimating the efforts required to implement push notification feature for the apps:
I. Format and layout of the notification message
You need to decide how you want to show the notification message when it is received at the App. This includes deciding either you want to show image in the message, laying out the information to display in the message etc.
Also, as per the simple implementation, new message would replace the old message in the top action bar. You might want to decide if you would like to lineup the messages e.g. something like Whatsapp messages are displayed.
II. Securing messages
If you donâ€™t put restriction explicitly, notification messages are retrieved even when user has not logged-in to the app. If the requirement demands, you need to put the restriction to secure the messages and only show notifications when user is authenticated and already logged into the app.
III. Change of Device
Each device needs to register itself with the App Platform and get the unique Device Token. Device should then inform the server / backend with its unique device token number. Server uses this device token in order to push the notifications to each registered devices.
For single device support, one time device token registration on server suffices the need. However, in most of the cases, App requires to support multiple devices and allow user to make login from any device and continue with his activities. With this requirement, the logged-in user and the device token combination gets changed when user switched to another device for app login, making it potential that app malfunctions with respect to push notifications. Few of such problems can be, app may receive duplicate notifications or security of user specific messages might get voided.
To avoid such adverse possibilities, you need to update userâ€™s device token at server end on every login event. This way, it would be ensured that the combination of user and device token is always correct at the server/backend system.
4. Display graphics content in the app
Graphics is inevitable part of any app, either Web or Mobile. In every other app you would deal with the images, banner etc. graphics content along with the text content. Some graphics content is part of the app design/theme, hence it remains static. However, based on the business requirement, some graphics content is uploaded by users and displayed in the app dynamically by retrieving from the database. In our case, we required to show various sized images/banners in the app which are uploaded and can be changed by the system admin time to time.
For Android App, following are different strategies to scale and layout the image in given view area:
Refer this link for complete list of the options.
Above options would highly influence the quality of the graphics. To give example, if the image size is bigger than available view area, CENTRE_CROP would crop the image from center before displaying it. With this option you need to be ready to compromise the complete view of the graphics. Similarly, FIT_XY would scale the image horizontally and vertically to fill the view area fully by ignoring original imageâ€™s aspect ratio, which can lead to distorted graphics.
Based on the importance of the graphics, you need to select best suited strategy from above options. In our case, most of the images were sponsored content, hence it was important to display the images with good quality by maintaining the aspect ratio of the image dimensions. We selected the option to span the image horizontally by filling the full width (layout_width = â€śfill_parentâ€ť) and adjusting the height according to the aspect ratio of the actual image size (layout_height=â€ťwrap_contentâ€ť). In this case, page length might vary as per the height of actual image but the advantage would be that the image clarity would be maintained. Here, you need to guide the system admin with the benchmark size of the image for each place holder so that there is always control over the space taken by graphics content and overall app design is not affected.
5. Any dependency over backend system
In most of the cases, mobile app has backend / server system as its counterpart. Except some computation performed locally in the device, majority of the content/data is served by backend system, e.g. information from database, content uploaded by other App users etc. In many cases, a web interface is developed for the system admin to configure these contents to be served to the app.
During development phase and QA phase, you might require to use the admin interface to test the app functionality. To give examples, we required testing of push notifications, sponsored image uploads, user status and creating other test data in conjunction with the admin web interface.
That advises us to consider following aspects at the time of estimation; availability of fully functional backend system serving content to app, any bugs in such systems, access rights to admin console, training on operating the admin functions, efforts required to create test data, possibility of test data corruption by other development teams etc.
Have you come across some of the scenarios mentioned in this article? Do you agree and also think the same? Share your experience in the comments section below.