Deploying A Mobile APP in an Enterprise Environment

The use of mobile application on consumer grade devices is increasing in popularity as more and more companies are using customised apps on mobile devices for field purposes instead of using a purpose built device. Example of such an implementation can range from Biometrics Scanning, Merchandise Delivery or even Taxi Dispatching.


Certain risks are associated with this approach since unlike web applications each user is responsible for managing and updating his version, just like the pre web-apps days back when people used desktop applications, These risks include:

  1. Using an obsolete version of the app that is no longer compatible with the backend.
  2. Using a version of the app that include a critical security issue.
  3. Incorrect business process due to the use of an older version of the app.
  4. Using a none official version of the app using the same backend, thus bypassing any front end validations.

There are certain guidelines that can be followed to control the inherent risk, I’m going to list some of them here as a guideline

I. Upgrade Enforcement 

For critical upgrades that renders the previous versions obsolete, for instance changing the business process or introducing a critical security enhancement. The best practice is to break the backends backward compatibility.

Breaking the backend backward compatibility can be done by adding an app version check with every request, including the app version in every request is easy and has a negligible cost on both data and processing yet is very useful when needed. The server response should include an error code that would trigger a “You Must Upgrade Now” message.

II. Upgrade Notification

For less critical updates push notifications can be used to suggest an upgrade to the customer, a more aggressive approach  (for android) would be to handle the push to fire the play store on the application’s URI. The frequency of these notifications can reflect how important this update is.

III. Application Verification

To restrict against none official apps the api should include a verification token, there are many ways to implement this, one of the easiest way would be encrypting one of the fields (timestamp for instance) and sending both the encrypted as well as the none encrypted versions. The backend would then verify the version of the app by comparing the decrypted field against the plain text one, if they do not match the response should indicate that.

There are many ways to implement this, the encrypted field approach happens to be the easiest way to do it.

IV. Root Check/Emulator Check

Rooted phones can offer a malicious user the means to manipulate the backend calls, while keeping the verification field. A root check can be conducted on the device every time an activity is started. Emulators are easy to uncover as well.

V. Malicious Usage checks

Just in case all of your checks fail, backend should conduct even a rudimentary malicious behaviour check, blocking devices that exhibit none expected behaviour.

VI. Connectivity Issues

Even with the advances in cellular service coverage 3G/4G service remains spotty especially in rural areas. There are few ways to mitigate this depending on the nature of the requirements. If no online/sync operations are required you can implement a simple request cashing service, in which server side requests are cashed to be retried when connectivity is available.

VII. Usage Patterns Analytics (for android)

Creating usage heat maps is important when it comes to determining how the people are actually using the applications and whether certain features should be augmented or removed due to lack of usage. Luckily google analytics can be integrated to track usage or activity launches, it can even be used to track individual controls actions.


I hope this post was helpful I’m planning to write another post soon on how to conduct unit, QA and scale tests on enterprise apps.


USSD API on Android

I’m currently trying to build a small widget that shows you several statistics about your cell phone usage, this would require using USSD codes and catching their responses. I scoured the internet for a solution however wasn’t able to reach one.

The only available solution which is mainly a hack relied on catching the logcat entry and displaying it, unfortunately this was fixed in subsequent versions of android and now USSD response doesn’t appear in the logcat.

There is even a Facebook page created just to request this feature from google…anyway if anybody manages to find a way to handle USSD responses please do share.



It is now possible to read the USSDs using the accessibility services, the downside is how indirect this method is and how the app should be manually enabled as an accessibility app in the device setting.

Sharing an Image from Bitmap in Android

I had a project that required downloading an image from the internet then calling the sharing intent to share that bitmap, I went through countless entries until I reached the conclusion that it is impossible to share an image directly from a bitmap object, the bitmap must be saved first and then you can share it and if you dont want to keep a copy on disk you have to explicitly delete it.

Here are how I ended up doing it.

1. Save BitMap

String file_path = Environment.getExternalStorageDirectory().getAbsolutePath() +
File dir = new File(file_path);
File file = new File(dir, name);
FileOutputStream fOut;
try {
fOut = new FileOutputStream(file);
abmp.compress(Bitmap.CompressFormat.PNG, 85, fOut);
} catch (Exception e) {

2. Share URI from file

Uri uri = Uri.fromFile(file);
Intent intent = new Intent();

intent.putExtra(android.content.Intent.EXTRA_SUBJECT, "");
intent.putExtra(android.content.Intent.EXTRA_TEXT, "");

intent.putExtra(Intent.EXTRA_STREAM, uri);
startActivity(Intent.createChooser(intent, "Share Cover Image"));


If you can come up with a hack to share directly from BitMap please do share, but I dont believe it is possible.


Samsung S4 Gestures SDK not supporting S4 phones!

Lately I just got myself a Samsung Galaxy S4 LTE, a decision based mainly on the array of sensors it supports that aren’t present in any other device in the market. Gesture control promised to be that one cool feature that I can build intuitive ergonomic apps around. I installed the Samsung SDK following the instructions on Samsung developers site only to get an exception stating that my device isn’t supported, which didn’t a lot of sense since I had the flag ship, the top of the line device and more importantly it had air gestures in many of the native apps. Turns out that the gesture control library requires at least Android 4.3 (Jelly Bean API level 18), while the S4 LTE is running android 4.2.2 with only the american carriers updating to 4.3 for the time being.

Gesture/Motion Control which are present in Samsung S4 devices are only accessible to developers if the device is running Android 4.3, while they have 4.2 factory installed.

Even if I install a custom ROM and bring my device up to 4.3 any app i’d build wouldn’t be useful for most of the users until 4.3 becomes the new standard.

It doesn’t really make much sense from Samsung’s part to release a device that supports certain functionality while the SDK can’t access them using the factory installed Android version, and its not like the features aren’t there, they are there and being used by the system. The only problem is they aren’t accessible through the SDK.

This may explain why these features are under used by developers. The only apps that use these features are either Samsung apps or released by one of their premium partners.

Yes i know there is a work around and you can always access the underlying API, reverse engineer one of the current Samsung apps and figure out how they access the sensors, but too much of a hassle for a simple silly app to be honest.


Debug Android Apps over WiFi

For some weird reason both my Samsung data sync started developing weird behavior at the same time, the solution was simply to use wifi instead. My device is routed so I just downloaded ADB Konnect and ran the connect command from my development machine:

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb connect

For none rooted devices there is an alternative but it requires having a working usb cable in order to activate it.

  • Connect tablet via USB and make sure debugging is working.
  • adb tcpip 5555
  • adb connect
    (replace with desired address)
  • Disconnect USB and proceed with wireless debugging.
  • adb usb to switch back when done.


Agendat the Android Game


I’m almost done building my first Android game Agendat (agendas), A game based on the events Egypt has been going through since the revolution. Agendat is divided into chapters representing the phases of the Egyptian revolution. With major revolution themes/memes scattered through game play. Agendat which means Agendas alludes to the term used by the late chief spy Omar Suliman when he referred to the protesters describing them as people with ulterior agendas.

A Fun, silly game about Egypt and the revolution.

Generally the game is a tongue in cheek representation of the revolution and shouldn’t be taken seriously, the main target here is for the game to be fun rather than an accurate depiction of the revolution, and as usually its intended to be absolutely free.

Chapter 1: Infilat Amny (Police Disappearance)

Chapter 2: Ta7arosh Gama3y (Sexual Harassment)

We currently have around 6 chapters ready, but only 2 of them are intended to be playable when we publish the game.

All the graphics in this game was provided by my partner S Graphic Design, who are about the fastest person you can get to design game components for you.

S Graphic Design