Is there a way I can make my Worklight's app public version number be different than the version number we're providing in application-descriptor.xml?
For example, I want my users to see the version 3.0.1 on Android settings (which is defined by the version attribute in the application-descriptor.xml) and one day I will want them to get an update from the Worklight server, but at that point I'd like that to turn into version 3.0.2. The problem is that a 3.0.1 will not update against something on the Worklight server that is 3.0.2.
Is there a way I can get around this?
Worklight does not provide this ability. IMO this is because what you're asking for is not inline with the thinking and intended usage of the Direct Update feature.
Direct Update is meant as a way to quickly provide fixes after having already released an app version to the store, for example in cases such as:
discovery of minor or major UI or logic bugs you've found in the app, or
for closing security holes that have been found
This is all happening to the same app version (lets say 3.0.1). Consider these as 3.0.1.build releases. or something.
It is not meant as a way of releasing new versions of the app. For this purpose use the conventional and appropriate way of releasing new app versions.
If you want to change the app version (which should coincide with a new app release), then you need to increase it in application-descriptor.xml (and other Worklight-related tasks), create a new binary and upload it to store, which users are then able to update and will see the new version number (lets say 3.0.2).
Related
I have a mechanism reading the Appstore version and forcing the user to update the app. For doing this, I use the following URI: https://itunes.apple.com/lookup?bundleId=xxxxxx
It used to work, but with the last release of my app, I have noticed that it wasn't forcing the update anymore, despite the new version was on the store (the Update button was visible on the store page).
I decided to not update it and let the weekend pass, and today my app was already up-to-date when I opened it. I suppose my phone updated it automatically, unfortunately, so I cannot be sure that my app would have forced the user to do it, but I suppose so.
My guess is that the link I'm using in my app and whatever API iOS is using to automatically update, need time to know the latest version that is already available on the store.
Does anyone have any information about this?
I am experiencing a strange issue.
New app version was released to appstore, containing new variable stored in user defaults and some minor updates. technically, we are creating new variable, which is an array of values in user defaults, and appending some items in the array. For append, we are using values which were already in place in the previous version (e.g. user_id, device_id and one more string parameter, all 3 were received from backend on 1st registration).
It was (obviously) tested before release. Testing strategy:
A. We were building adhoc old version (say #1) and new version (say #2), installing v1 on the devices and updating it to v2 (by simply downloading new adhoc v2 and installing it on top of v1).
Then, we published v2 to appstore, and issued one more test:
B. We were building same adhoc old version (say #1) installing v1 on the devices and updating it from the appstore, by
B.1 in-app update functionality - following the link to appstore and
B.2 just downloading most recent version from appstore.
Both were fine and both are still fine. Works perfectly.
Now, users are reporting old appstore-installed v.1, updated from appstore to v.2, is crashing after update (almost immediately when it is started).
Only difference we can observe is that when tested, appstore version was installed over adhoc, and now it is appstore over appstore.
Was anybody ever facing the same issue? What is the difference in update process "adhoc -> appstore" versus "appstore -> appstore"? Could it be related to the fact that appstore update is cleaning up all the info from user defaults and thus we need to repeat the application reg process (get all the data again like in the first clean install)?
I still have no crash reports in hand, so I am asking for some advices which can help me to solve the issue faster.
Thanks everyone in advance!
...looks like the issue is linked to GoogleUtilities: we have v7.2 in our current build, however previous build was of v7.4, and - as I found out recently, there is an issue related. TWIMC see https://github.com/google/GoogleUtilities/pull/37 for details.
It is still TBC now, we'll be checking in the next 1-2 days, and I will post some updates here. If indeed related to library version, then it has nothing to do with the app distribution (whatever if it is adhoc or appstore based).
Will apple reject an app for doing things like putting up a screen that says: "We've added lots of new features.You need to update before using this app..."? I'm unsure if this is a nosy thing to do but it may be something I need if I ever create lots of new features that need widespread frontend adoption.
This is fine. Clash of Clans for example will not let you play if it detects a newer version on the Appstore. Many online-related apps need to be up to date.
Also, you don't need to force all updates. You could simply force critical updates only.
is there an api call to get the latest version of the api?
something like:
https://rally1.rallydev.com/slm/webservice/versions
i have read through the documentation at:
https://rally1.rallydev.com/slm/doc/webservice/
but have not spotted anything like this.
all the urls have the version embedded in them, so it's like a chicken and egg thing.
Current version of API cannot be determined programmatically.
In WS API 1.18 we deprecated "current" pointer to the most recent version of the web service.It changed with every new release of the web service. We deprecated it because it was found to negate the benefits of the web service versioning. Users tended to point at current as a convenience without being prepared for its intrinsic volatility. To encourage users to point their applications at a specific version and to minimize the impact of releasing new versions of web service API we removed the current pointer altogether.
The most reliable way to check the latest version of API is to access our WS API doc you mentioned in your post.
There you can see the latest version under the Available Versions section in the left frame. The latest one is by default listed as selected.
I have a logistical question: I'm trying to figure out the best way to manage APIs getting out of sync with an app. The best way to explain it is with an example:
Let's say MyApp Version 1.0 posts to a "submit_feedbacK" API that requires first_name, last_name, and email.
I then submit MyApp Version 2.0 to the App Store. That version is designed to post first_name, last_name, gender, and email to the API. All of these are required fields on the API.
The problem I have:
- If I update the API before the new App is live, it will break Version 1.0
- If I wait until Version 2.0 is live and remotely cripple 1.0, I have to time it correctly.
I'm going to guess that the 'right answer' is to maintain two different APIs. But if both APIs post to the same live database, that makes things a bit awkward.
Does anyone have suggestions on how to model this?
This question may share some aspects with iOS consuming API design.
The right answer is definately to provide two APIs (at least for a short period of time while users adjust). You do not have to maintain two versions at the same time, as once a newer version is released you can maintain that one, and simply provide the old one for legacy users. The only real changes you may have to make to it are things like security patches or major issues. Major changes (such as you deciding to restructure your entire database) may lead to the old version not working any more, however update to newer API versions should be designed to allow previous versions to still function.
The other question I linked you to gives an answer about how you can have different version of your app access the correct version of the API.
Another note is that it may be easier for you (depending on what framework you're using) to design your APIs as engines or subapps, and simply mount them at different end points. I know that this is easily do-able in Rails by using Engines, and in Node with Express using app.use() with sub-applications.
I would use a webservice/http endpoint for the communcation with your app. If you preferer to maintain the same URL in all versions of the app, then include a version number in all the requests/posts to the server so it knows how to handle them. This will also make the development and tests easier as new versions can test against the new api on the server.
So on any function you can call in the webservice/server add a single variable with version number. a BYTE ought to be enough as I think you could start over and "kill support for v1.0" once you hit 256 versions of the same function (if ever).
Once the server receives a request/post with data, you can just code a simple switch/case structure in the server API so support works for both versions.
If they do similar, but eg. swaps the parametres or something, you can handle all these serverside and the BAL/DAL (n-tier structure) can be maintained on the server part of the solution.
Btw. my answer is not just for iOS or smartdevices, but merly a client/server approach for a "work-in-progress" production setup where everything has to be online, while still being under development and maintanance.
Hope it makes sense, otherwise, comment on it and I shall try to explain it further.
just FYI, I use CodeIgniter. I'm using the REST Controller provided at https://github.com/philsturgeon/codeigniter-restserver. I ultimated ended up settling on having different end-points for every version. Basically I'd check out a new repository for each release and put it into a unique directory. (i.e. http://www.mysite.com/1.0/api/method, http://www.mysite.com/1.1/api/method, etc) Trying to maintain multiple versions of an API under one code-base just sounded too scary. At least when I released a version, I would know it is locked in stone and I don't have to worry about breaking it. (Note: I had to use a special .htaccess tweak to get multiple CodeIgniter instances running from the same domain. I can share it if you like)