I just need to be sure about some things regarding the API
WL.device.getID(option)
Questions :
Will this be unique to every device ?
Wont this id change regardless of MobileFirstAPP version releases or re-intallation of the app or product update meaning Worklight 6.0,6.2,6.3 in future too ?
Yes it will be unique to every device
In Worklight latest versions at least (6.2, 6.3 and above) there is no change in the WL.device.getID() between versions.
Related
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).
We have a hybrid apps and would like to track users clicks and need to identified unauthenticated users..
I am thinking about using the MAC id but it's seems to be deprecated in ios7..
However, I see that MobileFirst has an option to get a device id using
WL.Device.getID()
Please advise if this option would work to get a unique ID or if there is a method to get the MAC id..
Thanks for your help
I don't know what is your MobileFirst version, but for this exact need you can use the Operational Analytics feature provided by IBM MobileFirst with its API, that allows you custom tracking... See here: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.monitor.doc/monitor/c_op_analytics_overview.html?lang=en
Can I use the version number less than the last approved version by apple?
for Example:
Current version on app store :1.8.0
New version I want to use : 1.0
Is it possible?
Can i also change the App name showing on iTunes store?
Lowering application version: Lowering the version number of an iOS application is not possible once your application has been approved. You can only go up: from 1.8.0 to 1.8.0.1 for example.
Changing application name: Changing the application name is possible when you create a new version of the application. You cannot modify the name of the current version. The new application name needs to be available for the chosen language.
Good luck!
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).
I want to change my app from a paid version to a free with ads. However, I don't want the people that originally paid for the app to get the ads.
I was thinking I could include a new update that has extra code that sets up some UserDefaults saying the version doesn't have ads and then do the update to the free version. But that doesn't seem like a very reliable solution.
I think, it depends on minimum OS version, that your program can be run on. For iOS 5.0 and later you can try to use iCloud to store some flag about purchased version. It allows you to set this flag not only for one device, but for the user's account.
Or you can store this info in the keychain to get it later. But in this case your user will not be able to have no ADs on some other device with his(her) account.
Anyway, as far as I know, you need to create an update for your app first to write this flag anywhere. And only in some time make an update with ADs.
I will be glad to see comments if someone has another thoughts about this issue.
It seems there is no reliable method to detect whether someone paid for your app or downloaded it later when the price has been changed to free. For this reason I have decided to create two separate entries in the app store.