I wish to distribute my enterprise Worklight application to many different clients.
Basically what I want to do is give my customer the .ipa and .apk files of the Worklight app so that they may upload them onto their own Application Center. The problem is that each application needs to be slightly different in that there are different URLs they must refer to as well as some other properties such as text.
I was wondering if there's a way to have my ipa/apk read from a properties that my client could change on their own without having to rebuild the ipa/apk?
EDIT for clarification:
The application I'm referring to is NOT the Application Center app, it is an application I've built using Worklight that I would like to distribute using the Application Center. I will be selling my application to entire companies rather than single users. Once the company has the application, their employees will need to download it somehow (using the Application Center I'm hoping).
Right now I'm trying to figure out exactly how I will distribute my application to my clients. My application calls services of another application hosted on another server (aka the "URL" I was referring to before, it is NOT the Worklight URL). The problem is this URL will be different per client and as far as I know right now in order to change this URL per client, I must recompile the ipa/apk for each client. This is what I'd like to avoid. If possible I would like to distribute the same ipa/apk to each client and have them change some sort of parameter somewhere to set the correct URL for their environment. It's also important to note this URL does not go through an adapter, and lives directly in the client.
IMO what you are asking for is not possible, be it with a regular native app or a Worklight hybrid app (that is really a web app but enclosed in a native "shell").
Once you produce the .ipa or .apk file, it is closed and cannot (unless cracked) be opened to make changes (that would be a security breach). Using a "properties file" next to the app is obviously not possible either.
You will need to create a custom .ipa/.apk for each customer.
Related
proteus is basically a runtime layout engine for Android developed by Indian e-commerce Flipkart.
Basically, I want to be able to control my home screen & Support Screen of the app from a backend server, so that I don't have to push every for every small change and also I don't want to use web views (we all know the limitations)
I don't think such a tool exists but you should look into Firebase, specifically the remote config module. It allows you to set parameters from your backend which can then be read on your mobile app, at every launch for example. This would allow you to set custom values for any variable you might need on these screens.
You could also look into AppCenter by Microsoft. It is a service which lets you deploy app updates over the air instantly, without going through the App Store and Play Store review processes. The only downside is that you can't push updates containing native code as your app needs to be re-bundled.
With a company App configured on a Windows phone there is the posibiltiy to push the installation of an App. When the user starts the pushed App some configuration data must be introduced. I would like to save the user this step but I still don't know how. Isn't it possible to push files over the company App/Exchange, as it is on a Windows machine? So I could read the configuration out of this file.
your use case does raise many questions (probably just terminology)
The only way to push an APP to a device is through the Windows Phone store or website.
If you want to push configuration to a device for an app then the app must be run at least once to enable that ability and you could then use a background task to periodically check for new configuration and download it.
The other thing you can investigate is push notifications but they are not really meant for pushing data, you can sent simple objects or data to the device as a raw push but the app must be running first.
The most common way to achieve what you describe is to have the app load config at launch, locally first and then update it from a web call (if web is available, as these are mobile devices you can not guarantee connectivity). We do something very similar with AdRotator where we try to download config at start and if that fails use a locally cached version.
As of WP 8.0 there isn't the possibility to push Apps or Files through the company App.
I read about Worklight's Direct Update feature already. However, I still have some questions that would like to clarify:
Q1: Is it true that Apple allows Worklight Apps to be published to APP
Store even there is a direct update feature?
Q2: How will Apple review and monitor the Worklight Apps' content if
there is a huge change after the direct update? Or, Apple does not
worry about the cached web resource in the application, does it?
Q3: Is there any limitation or pre-condition about the direct update
for the web resource? For example, the major entries of html and js
script files must be existed... etc.
Q1: Is it true that Apple allows Worklight Apps to be published to APP Store even there is a direct update feature?
A1: There are existing Worklight customers that have submitted an application to the App Store and passed Apple's app submission process. For best results, make sure you use Worklight v5.0.6.1 or later.
Q2: How will Apple review and monitor the Worklight Apps' content if there is a huge change after the direct update? Or, Apple does not worry about the cached web resource in the application, does it?
A2: Apple only reviews app submissions to the App Store and whether or not they follow their guidelines. They do not review future updates to the application (as long as it was not re-submitted), for example in the form of a Direct Update unless there are some extra-ordinary circumstances (like inappropriate content that was discovered afterwards, for example...)
Q3: Is there any limitation or pre-condition about the direct update for the web resource? For example, the major entries of html and js script files must be existed... etc.
A3: I am not entirely sure I understand the question. There is no limitation in Direct Update - this feature replaces the existing web resources of an application with new ones. The only thing I can think of is that both the Worklight Studio (that the app was created on) and Worklight Server (that the app lives on) must be of the same version number.
An update.
Apple now allows code updates if you use a webview
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts,
code and interpreters are packaged in the Application and not
downloaded. The only exception to the foregoing is scripts and code
downloaded and run by Apple's built- in WebKit framework, provided
that such scripts and code do not change the primary purpose of the
Application by providing features or functionality that are
inconsistent with the intended and advertised purpose of the
Application as submitted to the App Store.
With Direct Update, the mobile application can be automatically update with a new version of the web resources. In order to update the native resource, a new version of application must be uploaded to application store.
Consider the case that I have an update for my Worklight app with both native and web resources code update which has already been in application store.
Questions:
Is the following a correct way to update the app?
Step 1. Package the app in .ipa / .apk (with native + web code) and submit to application store
Step 2. Deploy an updated .wlapp file (with web code) to Worklight Server.
In application store, I can specify the application version when uploading the application. Will the application version be incremented automatically once I deploy the .wlapp to Worklight Server?
If the user does not update his application in application store and open the application, since there is a new web resource update in Worklight Server, it means that there will be a direct update alert box to prompt the user to download the latest application and in this case only web resource will be downloaded. There are some problems when the native code and web code are correlated?
Thanks a lot.
This would essentially be the correct order of steps, yes.
However, since you say you're updating both the native and web resources, I would make sure that the existing app can work with just the web resources update (without updating the native), because once deploying the .wlapp to the Worklight Server, existing users will receive a Direct Update.
If this scenario is not one you want to support, then in application-descriptor.xml you should also up the value of the version=" " attribute in the environment's element. When building the app after doing so, this will create a new .wlapp (for example: myProjectNameMyAppName-1.1.wlapp instead of ...-1.0.wlapp).
This means that the existing 1.0 users will not receive any Direct Updates, unless you deploy an updated ...-1.0.wlapp to the Worklight Server.
In relation to the above, no, the application version is not incremented automatically, it is something you need to control manually.
Also, I don't think the version value is something you control in the application store interface...
IFAIK the application version is changeable in Xcode prior to creating the .ipa for iOS and in AndroidManifest.xml prior to generating the .apk for Android (and in similar fashion for other environments).
EDIT: Actually... I think that changing the version value in application-descriptor.xml will also up the application's version number. Need to look at the end result (in AndroidManifest.xml or the Xcode project, in Xcode).
This would really depend on the behavior of your application and how resilient you've written it to be in the face of updates. I have slightly covered this in #1 above.
Other than talking about it theoretically I would suggest taking the jump actually upload an app to an application store, and test it privately, of course. This would be the most convenient to do using Google Play where publishing an app is near-instant.
We have an Adobe AIR application which could be possibly downloaded from multiple domains. And when it's run, it should connect back to the site it was downloaded from to get data to show to the user.
So far we have a separate application build for each domain with a site URL hardcoded into it. And I wonder is there a way for AIR application to find out at runtime the URL (or at least domain) from which it was downloaded?
What we would like to have is a single downloadable binary served from all different domains, which still can know it's origin URL.
There's no function to retrieve such information, it would just make no sense if you think about it.
The most stable way is to include an external configuration file into the package.
Note that you can use ANT to automate this process for this final deployment.
There's no direct way to do it.
Here are some options which come in mind:
Build different versions for each site (this could be automated)
Let user choose the site at first launch
Try to guess it using using whatever resources you have (timezone, language, etc)
How should this work? The only solution i see (independent from AIR) is that you deliver an extra (properties) file with the application, containing the URL downloaded from. So you dont need to build a separate app for each domain, but only package a different domain-file with it. The app then reads this file and executes some context sensitive stuff.
I am trying to address the exact same issue right now.
It looks like you can modify the install badge to pass parameters to the air app.
From what I gather the values are only passed down on install or launch-from-badge.
Something I plan on researching is that one of the parameters in "AIRBadge.as" is _appURL which is the URL of the page the badge is on. I don't yet know if that value makes it down to the installed AIR app in some way; but it could be a useful property. I'm ultimately hoping that the AIR install process injects that into the application descriptor xml, but I'm not holding my breath.
Check this page out: http://archive.davidtucker.net/2008/01/10/air-tip-5-passing-arguments-to-an-application-on-install/#
When the user downloads, you could store their IP address in your central DB. Then when the app is installed and runs the first time, the app could hit your central DB to match up their IP address with the server they downloaded from.
A cookie with a specific name being stored on a download page, and the AIR app looking for that? Though that might not work for direct downloads. It might also be hard to pull off since knowing the specific browser used to download it would be an issue.