Types of Mobile Application

Mobile Application 'Types' is quite confusing topic. Here is the description of Application 'Types'

1. Browser Access: The applications which we are accessing through native browser. Ex : m.yahoo.com, www.google.com, m.redbus.in

2. Hybrid Apps: We are installing the application in our device and for the functioning of that particular application internet is required. Ex : Social Networking Apps(Facebook, Twitter), Instant Messengers(Skype), E-Commerce(Flipkart), Internet Speed Testing(Speedtest)

3. Hybrid Apps: We are installing the application in our device and if required we are connecting it to internet also. Ex : Few games in which we can play alone and we go online too for playing with different players(multi player). And any medical apps where u want to keep a track record of your health and later want to share with your friends or doctor via internet.

4. Native Apps : The applications which we are installing in our device. Ex : Reminders, Few Games etc.

It can be further understand by the communication medium of the apps:

Native Apps- Which can be installed in the devices and the app does not need any data transfer to the server. With out network these apps work in the device. The data about the app will be stored in the device itself. Example Gaming applications. Here the device memory and configuration is very important as the app completely dependent on this.

Client Server apps- They can be called Semi native apps. Here the app can be installed in the device. But the with out a network it cannot be launched. Because It gets the data from the server. With out the data the app will not proceed further. Example Commercial apps like Banking app. Here you basically can see the form UI but the all the data comes from the server. So the device memory is partially dependent just to install the app as the data comes from the server for every service call.

Mobile Web applications.- They can be called as Mobile browser apps as these are not installed in the device. these can be accessed using the mobile browser by hitting the Url of the web. Here the device memory size is not all important as neither of the from or the app data is stored in the device. It is Completely dependent on the quality of the browser. Every thing comes from the server and rendered in the browser when you hit the url.

Comparison between Native Apps, Hybrid Apps and Mobile Apps:

1.Skills/tools needed for cross-platform apps:

Native: Objective-C, Java, C, C++, C#, VB.net

Hybrid:HTML, CSS, Javascript, Mobile development framework (like PhoneGap)

Mobile web:HTML, CSS, Javascript

2.Distribution:

Native:App Store/Market

Hybrid:App Store/Market

Mobile web:Internet

3.Development Speed:

Native:Slow

Hybrid:Moderate

Mobile web:Fast

4.Number of applications needed to reach major smartphone platforms

Native: 4

Hybrid: 1

Mobile web: 1

5.Ongoing application maintenance

Native: Difficult

Hybrid: Moderate

Mobile web: Low

6.Device access

Native: Full access(Camera, microphone, GPS, gyroscope, accelerometer, file upload, etc

Hybrid: Full access(Camera, microphone, GPS, gyroscope, accelerometer, file upload, etc

Mobile web: Partial access(GPS, gyroscope, accelerometer, file upload

7. Advantages

Native: Lets you create apps with rich user interfaces and/or heavy graphics

Hybrid: Combines the development speed of mobile web apps with the device access and app store distribution of native apps

Mobile web: Offers fast development, simple maintenance, and full application portability. One mobile web app works on any platform.

8. Disadvantages

Native: Development Time, Development Cost, Ongoing Maintenance, No portability (apps cannot be used on other platforms)

Hybrid: handle heavy graphics, Requires familiarity with a mobile framework

Mobile web: handle heavy graphics, Can't access camera or microphone

MOBILE APP TESTING CHECKLIST V

Store specific checks

The app cannot download code to be installed without the users consent.

The app can only get new functionality by way of an upgrade through the app store.

After download, an app should remain working. An app cannot turn off after a few days.

An app can’t be a “trail”, “beta”, “demo” or “test” version.

Apple product names should be spelled correctly in the app. (For instance: IPhonez is wrong).

If the app uses the web, it is not done using third party (i.e. non-Apple) browsers.

You cannot mention other app platforms in your app (for instance: “Also available on android!”)

An app cannot use old interfaces, like for instance the iPod click wheel.

Functionality should be in sync with functionality described in store.

The app can’t use the user’s location without permission.

All url’s in the app code should be fully functional

The location services cannot be used to autonomously control of vehicles or for emergency services.

An app cannot use push notifications without user consent.

Push notification can’t send personal information.

The App may not distribute any private information of users (like Player ID) through the game center.

Ad banners must be hidden when there are no ads available.

The app must respect copyright of apple and other parties.

An app can’t restrict the users of the app for instance by location or carrier.

The in app purchase mechanism cannot be used to purchase goods and services used outside the app.

The in app purchase mechanism cannot be used to collect money for charities. This has to be done through SMS.

The in app purchase mechanism cannot be used to buy a raffle or lottery ticket directly from the app.

Apps that encourage the users to use the device in a way that may damage the device will be rejected

An app cannot require user’s personal information (for instance email address) in order for it to function.

An app cannot use location services of the device without asking permission.

An app cannot send spam or introduce viruses, or use other apple platforms like Game Center and Push Notifications to do so.

Push notifications have to be send using the Apple Push Notification (APN) API. This has to be done using an APN ID.

Multitasking functionality of the app can only be used for its intended purposes, i.e. VoIP, Audio playback, location, task completion, local notifications, etc. This means that generally an app can’t run in the background but has to be closed off if it’s not used any more.

The app must have some functionality. For instance, it can’t be just a title page leading to some text. It can’t be just a song, movie or book as there are different platforms for that.

The app can’t use any “non-public API’s”. This means that you can’t use some functions that the distributing platform uses for its own apps. (This can generally be checked best by some sort of automated tool, like http://www.chimpstudios.com/appscanner/)

The app can’t reprogram controls of the device that are not intended for that use. (For instance: using the volume button as a shutter for the camera).

The app should aim at backing up a minimum of information on iCloud. The information in iCloud should be just the user generated information. Information that can be recreated or downloaded should not be backed up.

The app should not access information on the device outside the app without the user’s permission (for instance, copying the address book or getting information from other apps).

The app should not access or write files outside the “Bundle” and “Documents” directory. (because the app can’t read or write data outside the designated container area).

In general, the app has to be decent. So no explicit material in the sense of sex, violence, drugs, alcohol or tobacco. It cannot address a specific ethnic or religious group in a derogatory way.

The app has to be honest. This means that the description of the app has to be correct, and all functionality has to work as described. If an app gives diagnostic information, it has to be reliable. This also means that the genre and category in the  description must be appropriate. The app icons should be consistent and appropriate.

MOBILE APP TESTING CHECKLIST IV

App specific checks

Has the app been tested on different type of devices and different versions of OS?

Stability check: if the app has a list (for instance of pictures) in it, try scrolling through it at high speed.

Stability check: if the app has a list (for instance of pictures) in it, try scrolling to before the first picture or behind the last picture.

Is downloading of the app prevented in case it’s bigger than the OS allows downloading when connected to cellular networks.

Integration: does the app connect correctly to the different social networks (LinkedIn, twitter, facebook, etc).

The app does not interfere with other apps when in background/multitasking mode (using GPS, playing music, etc.).

Can the user print from the app (if applicable) The search option in the app displays relevant results

Verify most common gestures used to control the app.

What happens if you select different options at the same time (undesired multitouch, for example – select two contacts from the phone book at the same time).

App name should be self explanatory

Does the app limit or clean the amount of cached data.

Reloading of data from remote service has been properly designed to prevent performance issues at server-side.

Does the app go to sleep mode when running in the background (prevent battery drain)

MOBILE APP TESTING CHECKLIST III

App UI checks

Use at most one action on the screen that is highlighted as the most likely for the user. (Example: in iOS a blue button represents the default or most likely action).

To keep controls as unobtrusive as possible for instance by fading them out if they are not used for a while.

Make it possible for users to go back to a previous screen for instance by adding a back or cancel button

The main function of the app should be apparent immediately. It should speak for itself.

If the app is stopped at an unexpected time, user data should be saved locally and available at start-up.

Do not use standard buttons for other functions then that they are normally used for

Users should be warned of the consequences of deleting a document Keyboard adjusts to expected input (for instance numbers/letters when expected).

Are inactive buttons clearly distinguished from active buttons?

Minimize user actions by using a picker or a table view where users can select a certain choice over a data entry field where users have to type a choice

In an app, the user should not be able to store files locally, outside the app sandbox.

In an app, the user should not be exposed to the permissions of a specific file

Tapable elements should be about 7x7 mm in size, using the pixel density of the target device you can calculate the amount of pixels (chapter documentation contains a link to different devices compared).

Do not redefine gestures in your app that have a standard meaning (example:swiping from top to bottom enables the notification center)

Requirement to login is delayed in the app as long as possible

In case of ‘live’ filtering of data while the user enters his search query, verify the performance.

The appearance of buttons that perform standard actions are not altered in the app (for instance: refresh, organize,trash, Reply, back, etc.)

If there is a long list of data to scroll trough, provide a search option above the list.

If performance is slow, indicate a progress status icon (“Loading…”), preferably with specific message.

The app should respond to all changes in device orientation, as per the design

MOBILE APP TESTING CHECKLIST II

Device specific checks

Can the app be installed on the device?

Does the app behave as designed/desired if there is an incoming call?

Does the app behave as designed/desired if there is an incoming SMS?

Does the app behave as designed/desired if the device is tilted?

Does the app behave as designed/desired if the device is shaken?

Does the app behave as designed/desired if a local message is coming from another app (think of: calendar reminders, to-do task etc.).

Does the app behave as designed/desired if a push message is coming from another app (think of: twitter mentions, whats app message, word feud invitation, etc).

Does the app behave as designed/desired if the charger is connected?

Does the app behave as designed/desired if the charger is disconnected?

Does the app behave as designed/desired if the device goes to sleeping mode

Does the app behave as designed/desired if the device resumes from sleeping mode

Does the app behave as designed/desired if the device resumes from lock screen?

Does the app interact with the GPS sensor correctly (switch on/off, retrieve GPS data)?

Is the functionality of all the buttons or keys on the device defined for this app?

Verify that buttons or keys which have no defined function have no unexpected behaviour on the app when activating.

Does the app behave as designed/desired if the “Battery low” message is pushed

Does the app behave as designed/desired if the sound on the device is turned off?

Does the app behave as designed/desired if the device is in airplane mode?

Can the app be de-installed from the device?

Does the application function as expected after re-installation?

Can the app be found in the app store?

Can the app switch to different apps on the device through multitasking as designed/desired?

Are all touch screen positions (buttons) working when a screen protector is used.

In case there’s a true “back” button available on the device does the “back” button take the user to the previous screen?

In case there’s a true “menu” button available on the device, does the menu button show the app’s menu?

In case there’s a true “home” button available on the device, does the home button get the user back to the home screen of the device?

In case there’s a true “search” button available on the device, does this get the user to some form of search within the app?

MOBILE APP TESTING CHECKLIST

Checklist comprises of below mentioned categories:

• Network specific checks
• Device specific checks.
• App UI checks.
• App specific checks. (These are related with functionality that is frequently used in an app.)
• Store specific checks

Network Specific Checks

Does the app behave as per specification if connected to the internet via Wi-Fi?

Does the app behave as per specification if connected to the internet via 2G?

Does the app behave as per specification if connected to the internet via 3G?

How the app behave if out of network reach?

How the app behave if it is in low network reach?

Does the app behave as per specification if navigating through application screens and Airplane mode is activated.

Does the app behave as per specification if while playing media content, Airplane mode is activated.

Does the app behave as per specification if while initiating a call from Device, Airplane mode is activated.

Does the app behave as per specification if while sending a SMS from Device, Airplane mode is activated.

Does the app resume working when it gets back into network reach from outside reach of the network?

Does the update transactions are processed correctly after re-establishing connection. 

Does the app still work correctly when tethering or otherwise connected to another device

What is the behaviour of the app if network switches between  (Wi-Fi, 3G, 2G)

Does the app use standard network ports (Mail: 25, 143, 465, 993 or 995 HTTP: 80 or 443 SFTP: 22) to connect to remote services, ( as some providers block certain ports.)