Handle Android application for multiple clients (multiple servers)

Question

I'm here to discuss about different ways to handle an Android application that can point its APIs to a server A (ie. httq://a.myproduct.com/api/...) for the client A, or an other server B (ie. httq.://b.myproduct.com/api/...) for another client B.

What i do actually is to generate different APK of the same app for each client. This solution is okay for one or two client, but will become quite heavy to deal with later..

I'm trying to find a better way to have one unique APK which can work with different server url. Another constraint is that on a same device, i can have an app that talk to server A and an other app that talk to server B.

Here are the solution I came up with :

• Keep going with multiple APK...
• Have a "central" server that each app calls the first time to know with which server it has to talk and that store that in shared preferences.

• Have a file store somewhere that make the link between an app and a server for example:

  com.mycompany.productA:httq://a.mycloud.com
  com.mycompany.productB:httq://b.mycloud.com
  

But how to handle this file ? What is creating it ?

• Use Android account system ? Create an account for each cloud ? I don't really know..

Does anyone, already experienced this ?

Answer 1

Considering you are able to map connecting devices IMEI to clients, I will briefly give you pros and cons of the three methods you mentioned.

Multiple APK's

• Fully isolating client from other knowledge - safe
• Not scalable and maintainable (issuing updates if needed).

Central Server

• Scalable, easy to update information (in case you change a.mycloud.com to a2.mycloud.com)
• Not as robust. What if server goes down? Possible attacks, or bugs to worry about.

All URLs embedded into APK

• Stable and does not have large overhead in time/resources spent of your team.
• Insecure, you should assume people having access to APK will have access to the file mapping IMEI's to companies.
• If client's IMEI data or company url's is sensitive data, then a big no-no.

Are you a large company? If yes, then you are probably having production servers already and could go with second method.

Answer 2

I guess you can build a generic app and use some sort of auth system on the client app. For example, if the user identifies himself as "Client A", your web-service can "tell" your app to use the first endpoint. If it's "Client B", then it will be second endpoint. Bottom line is: make your users sign-in and then use credentials to distinguish the users.