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.

BlogImage_E-ioT.2

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.

Uber Jeddah

unnamed

Seems like Uber just landed in Jeddah, after their trial run in Riyadh. Now you can use it in Jeddah as well. Really smart move as I believe Uber perfectly fills a certain market gap they have in Jeddah. It all comes down to – as usual – finding sufficient number of drivers to cope with the market demand.

Image

The saudi market is quite ready for Uber due to saudis aversion towards standard Taxis, generally speaking it is socially frowned upon to be seen in a taxi. Also women aren’t allowed to drive around town hence they have to rely on undependable limousine drivers. Uber with their unmarked highend cars and well trained drivers provide a long sought after alternative. I wouldn’t be surprised if they got completely inundated in requests within the first week of their launch.

it is no surprise that they chose to use a female model in the email ad they sent, after all I recon women are going to be their main target customer.

The main challenge though is finding legal dependable drivers, due to the new Saudi visa regulations finding such drivers would be a hard nut to crack. Let us see how they are going to handle that challenge.

Overall i’m excited and definitely using them on my next visit to jeddah.

 

**here is an update**

Seems like Uber is expanding to egypt, just spotted a couple of vacancy spots on uber careers in Egypt, lets see how its going to fair in the Cairo Traffic Challenge.

Local Products Data Security Concerns

Last week a mini scandal broke out when Pavel Durov the founder of Vkontakte Russia’s dominant social network fled Russia and made really disturbing statements about the Kremlin trying to coerce him into divulging information about Ukrainian citizens and anti-corruption activists. Already the Russian Government is the majority stockholder of Vkontakte and they are in full control of the company.

Today, Durov announced he has fled Russia, citing security concerns after resisting pressure from the Kremlin to share user information from the Vkontakte network. In his public statements he has said that, in particular, the Kremlin had tried to force him to turn over information about Ukrainian citizens and anti-corruption activists in Russia.

PavelDurovvKontakte

This fits perfectly with a concern I’ve had for a while now about the privacy and security of local products and services. In my opinion privacy laws implementation in our region isn’t sufficient to protect our data from preying eyes, especially if backed by the government. It is quite easy to subpoena the entire database of a social network company for instance, or even require direct live access to the service based on the telecom laws. It gets even more interesting when you think of all the different ways the government can use to coerce “convince” the product founder to divulge the information he has about anonymous users he doesn’t know personally.

The concern here is not about technical security of the product as much as it is about the physical security of the founder and his family. Personally I don’t believe it’d take a lot of effort from the correct authority to extract all the info he has on any of the products users. After all such authorities have really convincing methods.

Another concern would be the political affiliation of the founder, since the product is local, his political affiliation may match or be quite different from yours. There is no guarantee that his access to your data wont be use either way. Again referring to our lax privacy laws implementation. Even if implemented without proper periodical auditing there is no way to be 100% sure no one is snooping on your data.

That is why I choose not to use local apps and services as much as possible. Most offer geo-services (cairo360-bey2ollak-wasalny-circle tie-etc…) and the last thing I want is for some entity to have real time access to my where abouts 24×7. Also their is that inherent risk associated with installing any mobile app on your phone, most request access to your contacts anyway (all android have access to all photos stored on device), just think about where your data may end up migrating to without your knowledge.

Naturally these risks are associated with almost any product you end up installing or using but I feel a lot more comfortable knowing that my data MAY end up getting exposed to some XYZ developer in some obscure country who knows nothing about me and has zero interest on our current local affairs. And knowing that it’d be quite hard to coerce someone that far away.

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() +
"/ProjectName";
File dir = new File(file_path);
if(!dir.exists())
dir.mkdirs();
File file = new File(dir, name);
FileOutputStream fOut;
try {
fOut = new FileOutputStream(file);
abmp.compress(Bitmap.CompressFormat.PNG, 85, fOut);
fOut.flush();
fOut.close();
} catch (Exception e) {
e.printStackTrace();
}

2. Share URI from file

Uri uri = Uri.fromFile(file);
Intent intent = new Intent();
intent.setAction(Intent.ACTION_SEND);
intent.setType("image/*");

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.

Reference: http://developer.samsung.com/forum/thread/gesture-not-supported-on-the-s4/201/244204?boardName=SDK&startId=zzzzz~

Wasalny’s Next Big Step

Last year I wrote an entry on how Wasalny is technically superior to Bey2ollak but due to how social apps work Bey2ollak is much more reliable. Which explained why Bey2ollak won the Google’s much coveted Ebda2 award. Seems like there is an interesting twist unfolding right now, in which Wasalny may end up having the upper hand.

Wasalny Vs Bey2ollak

Seems like the Kuwaity government is interested in using Wasalny as their official app, this twist means that Wasalny will have a new fresh start to grab the critical mass needed to maintain market superiority. This adoption grants wasalny access to this huge untapped gulf market, with most of the population being in their 20s-30s and most having access to a smart phone its a treasure trove that no one was able to break into prior to this point.

Kuwaiti leaders showed great support for the venture, installing the app on the electronic devices of every police officer and providing access to every billboards in Kuwait City to allow for real time traffic information.

Bey2ollak’s massive user base is irrelevant when it comes to global expansion, since the data set greatly relies on the location of the users contributing it. Furthermore one of the main reasons Bey2ollak was such a hit in egypt, the usage of funky franco arabi interface and street names actually works against it when we talk about regional expansion, I recon it’d be completely unreadable for none Egyptians. Bey2ollak team have been working on revamping their interface but they retained the quirky but cool franco arab routes designations, since it is one of their main selling points.

Full of terms only Egyptians would understand

Bey2ollak full of terms only Egyptians would understand

Wasalny is a bit more standard

Wasalny is a bit more standard

I believe Wasalny has a really interesting future ahead of it, with the partnership they have with Etisalat -which happens to have branches in most of gulf countries- and the official adoption by the Kuwaiti government its only a matter of time until it breaks into the gulf’s user base. Once the initial critical user base is achieved it’d be quite hard for any competitor to depose them.

**I’ll write a follow up post on the potential revenue streams traffic apps can generate.

sources http://www.wamda.com/1970/01/wasalny-co-founders-on-their-traffic-app-s-next-turn?ref=fb