0

Is there any way to make my app "aware" of where it is downloaded from? To clarify, they will not be going through the app store, they will be downloading the actual apk or plist (I think .plist is the extension for iOS?) file directly from my website.

Background

My situation is: You go to my company website, you get involved with one of our contractors, and you download our app from our website. However, depending on which contractor you have a relationship with, the app is branded with different UI elements specific to that contractor. I want there to only be a single app, but when you download it, the app is "aware" of which contractor you downloaded it from, and then uses some logic, (likely calls to a webservice, but the implementation of that is not important here) to display branding specific to that contractor.

I am trying to do this for both android and iOS, so solutions for both or either one would be appreciated. I want there to just be a single app (1 for iOS, 1 for android) because it is not desirable to create a new app everytime we get a new contractor, and because we would only want to have to register 1 app for push notifications.

Asked before

I realize my question is a duplicate:

It is essentially the same as this question: (One iPhone app with different template based on the URL it was downloaded from)

I want to give my iPhone app to different distributors for distribution.

When a user will download the app from one of the distributors and open it the app should connect to our servers and ask for the unique settings of this distributer.

The question is, how each app can "tell" from which distributer it was downloaded from?

I don't want to compile a different application for each client.

I am reasking it because the answers were unsatisfactory and did not at all address the issue, and the question is old (over 3 years old)

The first answer:

Do you want an app or iOS WebApp? if you want iOS app, I do not think you can distribute to other distributors, because Apple is the only distributor of iOS applications, so all the downloads come from there.

if you want a WebApp, you create a download link redirected to your webapp to read the link to the server it pulls everything you need, layout, information, etc ...

They completely missed the point, it has nothing to do with the question. The second part explains how one would get the different UI elements, but does not answer how the app is aware of which UI elements it should be requesting in the first place.

The second answer:

I did some research into this and the only way I found to do it is just to create different targets for each app then share the source code across both the apps, but this still means that you would have to do two submissions still.

This does not answer the question either: AFAIK, multiple build targets help to have a single code base, but you still would be maintaining multiple apps, not a single app.

Community
  • 1
  • 1
chiliNUT
  • 17,144
  • 11
  • 59
  • 92
  • "I want there to only be a single app" -- not on Android, you don't. You may want a single code base, but you need there to be N apps with N application IDs. Otherwise, what happens if the customer tries working with the *second* contractor? – CommonsWare Sep 16 '15 at 17:24
  • @CommonsWare For this situation it is safe to assume you are only ever working with 1 contractor at a time, and if you were to switch to a different contractor, it would be acceptable, and actually desired, for the app to "switch over" to that new contractor. – chiliNUT Sep 16 '15 at 17:27
  • The mechanics of how to do that are also of interest, but not until I get the first part sorted out – chiliNUT Sep 16 '15 at 17:29
  • If your UI decision is based on where the app was downloaded from, since the app will only be downloaded once and cannot be downloaded again while it is installed, the app would remain branded for the first contractor. And what if the client wants to work with more than one contractor at the same time? "not until I get the first part sorted out" -- no, you need to get the one-versus-N decision settled out up front, as at least on Android, the solutions would differ. – CommonsWare Sep 16 '15 at 17:31
  • By "getting the first part sorted out" I just mean, I would not want to be concerned with switching an app's branding to a different contractor, before I figure out how to brand it in the first place. Your issue "the app would remain branded for the first contractor": That is exactly the behavior I am looking for. And "what if the client wants to work with more than one contractor" that is not an option. You will never be working with more than one contractor. – chiliNUT Sep 16 '15 at 17:36
  • @CommonsWare for android, we just found this, I think this would likely do it for me: http://stackoverflow.com/questions/4093150/get-referrer-after-installing-app-from-android-market – chiliNUT Sep 16 '15 at 17:38
  • Since that's only for the Play Store, and you are not distributing through the Play Store ("you download our app from our website", "they will not be going through the app store"), then I am confused. – CommonsWare Sep 16 '15 at 17:39
  • @CommonsWare you are correct, however it would be acceptable to have it in the playstore if it solved the issue – chiliNUT Sep 16 '15 at 17:40
  • do you want to show different ui on the base of some contractor category by skills or something? – Muhammad Babar Sep 17 '15 at 07:42

1 Answers1

1

For Android, for a self-distributed app, you have two main options for creating "branded" editions of that app.

One is to use Gradle product flavors, where you create one flavor per contractor. Each flavor can have what amounts to an "overlay" sourceset, where you can replace stock resources (strings, icons, colors, etc.) with ones for that flavor. When you build the app (Android Studio, CI server, manual command-line builds, etc.) and have it build one or all flavors, you get a per-flavor APK with the per-flavor resources. If, at a later point, you elect to have per-contractor application IDs (so N contractors' apps can be installed at once), making the change will mostly be a matter of adding one line per flavor to your Gradle build file (identifying the application ID for that flavor) and updating your GCM API key for each application ID.

The older approach would be to change files in assets/ of a standard APK to make a branded edition. This approach is aggravating, as you can't take advantage of Android's resource system, and you have to arrange to re-sign the modified APK, but it will work.

In both cases, you have dedicated APK files per contractor, so you arrange for your download link to point to the right one for the contractor for this particular customer.

The com.android.vending.INSTALL_REFERRER solution probably is not a great solution for you. Besides the dependency on the Play Store, your app would have to have branding for every contractor "baked in". Certain elements (application icon, application name) cannot be changed at all and would have to be the same for all contractors. Other elements (launcher icon, launcher name) could be changed, but on some devices will take a reboot to take effect. And if you don't ever get that broadcast, or it is not for a recognizable referring URL (e.g., the user just found your app in the Play Store and installed it), you're in trouble.

CommonsWare
  • 910,778
  • 176
  • 2,215
  • 2,253