Getting Started

Mego Pro is a module of MegoGrid. Here, I’ll explain what Mego Pro is and how it can help Android App Developers.

Modern mobile technology is becoming too vast for most people’s comfort. In keeping with the KISS principle, (Keep It Short and Simple), developers are doing their best to improve technology. Because their time is precious, they build frameworks to be more efficient. While developing applications, they have certain features in their applications for which they want some limited access. To get the maximum functionality, they often design a separate module along with the main application.

Now, I’m sure everyone has further questions, so lets start with the basics. Let’s cover the What, Why and How, of Mego Pro.

Mego Pro Demo is an app which demonstrates how we have used our Mego Pro module. It helps developers concentrate on their main application development and frees them from the obligation of making other modules to provide some limited access to their topmost features. By limited access we mean that you, the developer, can provide trial days, limited access to features, limited item access from groups of like items, etc.

This tutorial is divided into several parts, each focusing on a different aspect of the Mego Pro module. Feel free to read through in any order, but we recommend that you download the source code and refer to it while reading. Some parts of the code have been omitted or changed in this tutorial for the sake of clarity, so you may find it useful to keep the full version close at hand.


As mobile application developers, we all know that there are certain features to which we want to give only limited access. For example, gaming applications have certain levels to play. If it’s a good game, it will stop you after the completion of certain levels and ask you to upgrade to a pro subscription in order to play further. Have you ever wondered how others apply restrictions like these to their applications?

I know you’re confident you can make modules like these on your own. But consider how much time it will take. You’ll need to keep track of your app users, their application usage details, how many trial days they’ve used, how many times they’ve used certain features, etc. It’s frustrating and time consuming to worry about these things in addition to processing your own app’s data.

It’s for this reason that we’ve introduced our Mego Pro module—to help developers save time. We worry about developing this sort of functionality so they can concentrate on their app development.

This module has six types of feature validations which have been integrated to the demo application. This Demo app will show you how each validation works. All the validation types are described below:

Before we explain the details of the above mentioned validation types, we need to adjust a few configuration settings on the application’s main activity onCreate() method. This demo app uses SplashActivity as its main activity. The two code snippets below demonstrate how we configure our Demo app. The first code snippet is used to authenticate user applications. It’s important that you call it first.

MegoAuthorizer megoAuthorizer = new MegoAuthorizer(SplashActivity.this);

After inputting the above code snippet, call our MePro Module main class MePurchaseManager as shown in the below code snippet.

MePurchaseManager purchaseManager = new MePurchaseManager(SplashActivity.this);

Once you’ve configured these, you’re ready to call our Mego Pro module API in your app. Use it in any section of code that you want executed once this validation is successful-- otherwise users will get specific prompts from the validation types asking them to unlock any custom purchase modules you have integrated with your app. We’ll explain later how to integrate your custom purchase modules with this module. Meanwhile, just use the detailed description of the validation types mentioned above.

Trial Days

In your application, you can develop a feature which will give users trial access for a few days. This is the validation which performs such functionality in your application. Just call the MePurchaseManager’s getIdStatus() method at the point in your code that allows access to that feature. This method includes three parameters, which are:

Please note that you must initiate the MePurchaseManager class in each activity or class where you want such validations in your application. Below is the code snippet which demonstrates how we integrated this validation in the demo application:

private void checkBoxStatus(String boxID, final String method_name){
        try {
        //here we have called the validation method getIdStatus(), which will execute the
        //callTask() method if validation is successful otherwise it will show the prompt to the user
            purchaseManager.getIDStatus(MainActivity.this, boxID, 0, new IFeatureClickable() {
                public void onFeatureClicked() {
        } catch (NoDataException e) {
        } catch (InvalidBoxIDException e) {
    //method to be called after successfull validation
    private void callTask(String mName){
        try {
            Method method = getClass().getDeclaredMethod(mName);
            method.invoke(thisnew Object[]{});
        } catch (Exception e)


Suppose you have a feature in your application and you want to limit the number of free clicks users get within it. If users exceed the set number of clicks, they’ll be notified that they’ve exceeded the limit allowed. In this example, this is the validation you’d use in your app code. Call the same method explained in the Trial Days validation type and write your business code inside the body of the onFeatureClicked() method.


This validation type is a combination of the two sorts we described above. As far as implementation is concerned, just call the same method as you have for the first two validation types and write the executable code inside the body of the onFeatureClicked() method. Although there’s no difference between this validation type and two we’ve already mentioned, there is one unique functionality: if users exceed the number of clicks/counts allowed by you, they’ll receive upgrade prompts regardless of how many Trial Days they have left.

These validations help you stop the usage of your feature as soon as possible, especially if you don’t want to wait until the trial days expire. For the code sample, reference the same code which I’ve provided for the Trial Days validation.

Max Concurrent-Recurring

If there’s a feature in your application containing groups of items which belong to the same category, (Think gallery images, videos or any custom collection of similar items), and you want users to select only limited numbers of items at a time before performing an action, then use this validation in your application code.

In this validation, users will be left with the items accessed after each action is performed. Subtract the total number of items they’re allowed access to if they come next time to access the same ones. For example, if users begin with access to five items and they perform two actions, then when they next open the app they’ll only have access to three items.

For this validation, call three more API’s before calling the getIdStatus() as follows:

You can call the destroyBoxCounter(String cubeID) method inside the onDestroy() method of the activity so that it will remove the previously initialized cubeID.

After configuring all the API’s, call the getIdStatus() method as usual. Call the same way you did for the other types of validation at the point that will be executed when users click the UI to perform their actions on the selected items. Below is the code snippet that shows how we’ve integrated these validations into this Demo application:

if(mAdapter.isSelected (position)) {
        //we have called the addBoxCounter() on selection of the item
            mShareImages.add (uri);
        }else {
        //we have called the removeBoxCounter() on deselection of the item
            mShareImages.remove (uri);

After selecting the items users will have access to, initiate this action. Once users click, the following code fragment will execute:

try {
            //when user click to perform his action this method will be called
                    purchaseManager.getIdStatus(BoxConstants.feature1, 0, new IFeatureClickable() {
                        public void onFeatureClicked() {
                //code to be executed after successful validation
                            Intent intent = new Intent();
                            intent.putExtra(Intent.EXTRA_SUBJECT, “Here are some files.”);
                            intent.setType(“image/jpeg”); /* This example is sharing jpeg images. */
                            intent.putParcelableArrayListExtra (Intent.EXTRA_STREAM,mShareImages);
                } catch (NoDataException e) {
                } catch (InvalidBoxIDException e) {

To uninitialize the previously initialized cubeID, use the below code fragment inside the onDestroy() method of the activity:

    protected void onDestroy() {

Max Concurrent-Nonrecurring

This validation type is the same as the previous Max Concurrent-Recurring type, but with subtle differences. Here the number of items users have access to will remain the same each time they access the items and perform the action. The rest of the implementation will remain the same as well. For the implementation details, refer to the earlier configuration steps and code sample.

Max Individual

If your application contains a feature which has groups of items in sequential order, (like a listview,) and you want users to be able to access some of them in sequence, this is the validation type to use. Call the getIdStatus() method and pass the item position as the second argument of the method.

This method is not limited to listview only; you can also use this validation for any custom collection of items to which you want to give limited access in a specific sequence. Below is the code snippet we used in this demo application. It shows how this validation works.

Please note that in this demo application we’ve used a custom collection of items-- not a listview. Instead of passing the item position, we’ve passed the static position as the second argument of the getIdStatus() method.

     * called this method on click of an item which will call the validateBox() method 
     * and pass the static item position into it as its second argument. This argument
     * will validate whether user can access this item or not.

    public void onClickEffectButton(final View view) {
        System.out.println(“PhotoActivity.onClickEffectButton clicked with view: ”+view.getTag());
          validateBox(view, 1);
        }else if(view.getTag().equals(“brightness”)){
            validateBox(view, 2);
        }else if(view.getTag().equals(“cdepth”)){
            validateBox(view, 3);
        }else if(view.getTag().equals(“cbalance”)){
            validateBox(view, 4);
        }else if(view.getTag().equals(“contrast”)){
            validateBox(view, 5);
        }else if(view.getTag().equals(“emboss”)){
            validateBox(view, 6);
        }else if(view.getTag().equals(“flip”)){
            validateBox(view, 7);
        }else if(view.getTag().equals(“gamma”)){
            validateBox(view, 8);
        }else if(view.getTag().equals(“gaussian”)){
            validateBox(view, 9);
        }else if(view.getTag().equals(“grayscale”)){
            validateBox(view, 10);
        }else if(view.getTag().equals(“hue”)){
            validateBox(view, 11);
        }else if(view.getTag().equals(“invert”)){
            validateBox(view, 12);
        }else if(view.getTag().equals(“noise”)){
            validateBox(view, 13);
        }else if(view.getTag().equals(“saturation”)){
            validateBox(view, 14);
        }else if(view.getTag().equals(“sepia”)){
            validateBox(view, 15);
        }else if(view.getTag().equals(“sharpen”)){
            validateBox(view, 16);
        }else if(view.getTag().equals(“sketch”)){
            validateBox(view, 17);
        }else if(view.getTag().equals(“tint”)){
            validateBox(view, 18);
        }else if(view.getTag().equals(“vignette”)){
            validateBox(view, 19);


    //method to be called at at each cutom collections of items
    //here second parameter represents the position of item in the given collection
    private void validateBox(final View view, int item){
        try {
            purchaseManager.getIdStatus(BoxConstants.feature2, item, new IFeatureClickable() {
                public void onFeatureClicked() {
                    if (!loading_dialog.isShowing()) {
                        if (effects.size() == 0) {
        } catch (NoDataException e) {
        } catch (InvalidBoxIDException e) {


Purchase allows users to unlock trial features and access the Pro version. To integrate your purchase module with our MePro module, provide us with a deepLinkUrl which you can configure on the CMS Panel by selecting your own shop options. A deepLinkUrl is simply an intent that will redirect users to your own purchase module activity. It allows you to specify your own credit system and purchase mechanisms.

You can also use other modules, i.e. MeCoin or MeShop or even both together. These handle the purchase mechanism for you. Most modules have built-in credit systems that can be integrated with your MePro module. (To know more about these modules please refer their corresponding documents).

© 2015-2016 Megogrid Inc. / Term of service / Licenses / Privacy Policy 913 N Market Street Suite 200 Wilmington DE 19801 USA