Advantages and Disadvantages of MEAPS

Experience Summary of Using a MEAP Paltform

 
We just delivered our first banking mobile product developed using a MEAP (Mobile Enterprise Application Platform). It has been a mixed experience from the MEAP usage perspective. Throughout the development cycle we were left wondering several times weather choosing a MEAP was the right strategy that we took. Most of the times were those when we were left hanging due to lack of support/expertise for delivering a feature necessary to our enterprise mobile application.  The primary reasons for those hiccups were that the MEAP platforms itself are evolving and they will take some time to stabilize.
 

MEAP definitely make great business sense that is why they have a high growth gradient over the years. Considering the mobility surge over the past few years it may not be all due to the advantages of MEAP. In terms of development costs, time to market, and targeting more number of mobile platforms, MEAP has a definite advantage over native development. But in terms of matching capabilities of the native SDK it has a definite disadvantage.

 
Another turn-off was the regression issues caused due to an update of the MEAP platform plugin. Already tested and working features can break if the platform plugins are not thoroughly verified. With the MEAPs being emerging state, it can only be said as ‘expected’. So additional rounds of testing and verification are required as each Plugin update can cause potential issues. The fast pace in which the mobility arena is moving updated plugins will be expected on a very regular basis. So this becomes a major risk factor towards the end of the development lifecycle.

 
MEAP usage throws some challenges which need to be addressed properly to extract the advantages claimed by the MEAP platforms. The idea is that you shouldn’t be rushing to a MEAP platform because the world is doing so. And yes enterprises should keep in mind that MEAP is not the only answer to the cross platform mobility challenges.  Mobile web backed by HTML5 power is turning out to be an alternative to the MEAPs in addressing the cross platform mobility challenges. HTML5 being backed by the industry biggies, such as Microsoft, Apple, Amazon, and Google has grown significantly over the last two years and developers and the community are still trying to make it stronger.

 

Advantages and Disadvantages of MEAPS

 
Based on the sweet sour experience of developing an enterprise application using a MEAP platform the advantages and disadvantages of MEAPS can be generalized as follows:

Advantages of MEAPS:

• MEAP Platform makes business sense by minimizing the development cost
• MEAP Platform makes business sense by minimizing the time to market
• MEAP Platform makes business sense by enhancing the mobile platform coverage
• MEAP development does not require advanced development skills
• MEAP development is platform agnostic
• MEAP development is device agnostic
• MEAPs provide centralized management for MAM and MDM
• MEAPs provide security guidelines and compliance 

Disadvantages of MEAPS:

• MEAP platform adds another Risk factor
• Too much dependency on MEAP vendor
• MEAPs do not have proper version control mechanism
• Migrating from MEAPs difficult, you are at the mercy of the vendor
• MEAP applications are more fragile as compared to robust native applications
• At times one of the supported mobile platform runs into issues jeopardizing the release 
• Individual platform specific deployments challenges remain
• Individual platform specific testing challenges remain
• Unit testing of the code is a nightmare
• Apart from the native platform expertise, the MEAP platform expertise is also critical to maintain and update
• The MEAP platform support is a big challenge as the MEAP platforms itself are evolving and the churn in MEAPs
• Regression issues in platform plugin updates: Features stopped working only because of plugin updates. So even if you do not change your application code but you may lose a perfectly working feature due a plugin update required to fix another issue

Cleaning Data Bound by Foreign Key Constraints

Integrity constraints are put in place to ensure that the data insertion/updation and deletion are bound within the applied business logic. However there are situations where we might need to remove the data from certain tables but it is not allowed by the database system due to constraints imposed while creating/updating the database tables.

One of the constraints normally imposed between the tables is foreign key constraint where primary key data of one of the tables is used as a key record in the child table. Therefore in such cases the child records needs to the deleted before parent record. This ensures that there are no orphan records. In automated scenarios where data is generated on nightly/hourly basis it becomes the imperative the records be cleaned periodically to keep the volume in control.

If the system under test is external and has not been not designed for cleanup activities then the you might need to alter the tables/constraints to change the behavior as per the requirement. Oracle system provides three modes in which the constraints can be in:

• ON DELETE CASCADE

• ON DELETE SET NULL

• ON DELETE NO ACTION

On using the ‘ON DELETE CASCADE’ option while setting or altering the constraint, only the parent record needs to be explicitly removed. The child records are automatically removed when this option is used.

On using the ‘ON DELETE SET NULL’ option the deletion of the parent records will be allowed but the child records are set to null.

On using the ‘ON DELETE NO ACTION’ option the deletion of parent records is prevented until the child records are present. This is the default mode if either of the above two states are not specified.

An example of creating the tables with ‘ON DELETE CASCADE’ option is as follows:

CREATE TABLE root

( root_id numeric(10) >not null,

  root_name varchar2(50) not null,

  contact_name varchar2(50),

  CONSTRAINT root_pk PRIMARY KEY (root_id)

);

CREATE TABLE branch

( branch_id numeric(10) not null,

  root_id numeric(10) not null,

  CONSTRAINT fk_root

    FOREIGN KEY (root_id)

    REFERENCES root(root_id)

    ON DELETE CASCADE

);

If the table already exists try to alter the constraints using the following:

ALTER TABLE <CHILD_TABLE_NAME> MODIFY CONSTRAINT <foreign_key_name> foreign key(ref_child_columnname) references parent_tablename(ref_parent_columnname) ON DELETE CASCADE;