Updating Client App (iOS) after new SUP deployment

[Former Member]

Hello,

I am willing to understand how to do a graceful update at the client side, after a new deployment has been made at the SUP side.

Assume that you have an app (iOS for my case) working well integrated with the SUP backend. Then:

1) Make a change in the MBO model; it could be as simple as adding a new field into an existing MBO.

2) Deploy your changes. Create the new generated code in the process.

3) Apply the newly generated code to the app. Update the client app.

4) The calls to the SUP Backend fails with SUPSynchronizationException.

I understand why the calls to the backend are failing; the client database schemas are no longer in sync with the newly deployed backend database. There could also be versioning differences that SUP checks.

Basically, what is necessary is: During the update of the client app, the client database schemas also get updated. This is a known concept in the Core Data world in iOS (https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/...). Does such a concept exist in the SUP world as well?

Thanks,

Guven.

[Former Member · Accepted solution]

Thanks for the clarification.

From your answers, I can conclude that there is no way to update an app if the MBO definitions have been changed. The user has to delete app and install the app again. The alternative is what you have proposed; having two versions simultaneously.

This comes as a surprise to me because I don't know how the MDM will make sure that the user deletes the app from his/her device. Also, what if the user has some data waiting to be synchronized? That will result in data loss. I am hoping that there is another alternative solution to this.

Thanks for your input Dave.

[former_member184221 · Accepted solution]

I typically have systems with 1,000 or more users. So you can't assume that when you produce a new version of the software that everyone will upgrade together. Nor do you normally want to have downtime while everyone upgrades. So this is the strategy I use:

1. All 1,000 are using App 5.0 and MBO 1.0

2. Develop and test App 6.0 and MBO 2.0

3. Put live MBO 2.0 with zero users.

3. Setup a pilot test group of 20 users and using Afaria to deploy App 6.0 and MOB 2.0. Meanwhile the other 980 users are still using App 5.0 and MBO 1.0. Test for 5 days.

4. Put App6.0 and MBO 2.0 live region by region 200 users per day using Afaria.

Does that help. I don't see any deficiencies in SUP when you use Afaria as the MDM.

Have fun coding, David

[Former Member · Accepted solution]

This actually looks like a good strategy.

I have put a little more thought into this and now I see why I was pushing for an update rather than a new version install. We are currently in a pilot phase where backend MBO changes are pretty frequent. Therefore, we can't push a new version that frequently and expect the pilot users to install these new versions. So, an update would have been a lot more seamless for us.

When we go live, the need for MBO changes will be a lot less. Therefore, we can go with the strategy you have proposed and create new versions of the app and make it available in waves.

Thanks a lot for your help,

Guven.

[former_member184221 · Accepted solution]

If you use Afaria, the end users don't even have to be aware that a new app has been pushed.

Also things can get tricky if you are interfacing into BAPI's. Because if a BAPI say has one new field and one old field removed, you can't connect both the new and old MBO to it. Basically you end up with old and new ZBAPI's ! The same is true with other systems, e.g. New and old web services or Tables. The trick to it all is to plan it out.

[former_member184221]

I usually do this by updating the MBO version number. e.g.

Old App is using MBO version 1

New MBO is created which is called version 2 and it uses the new database schemas.

Application modified to use MBO version 2.

As App is deployed it uses MBO v2.

The point is that both MBO version 1 and version 2 are live and the app being deployed automatically uses the correct MBO.

[Former Member]

Hello David,

Thanks for the reply, a couple of questions:

- Is there an API to specify with MBO version to use from the client side?

- What do you mean by 'As App is deployed it uses MBO v2'. Are you talking about a new app or are you updating the current app on the client (without deleting it)?

Thanks,

Guven.

[former_member184221]

Always talking about a new App, you can't dynamically change the MBO code attached to an App as its compiled into the App.

This is what I mean by MBO Version:

You have two choces here, you can either change the "Target Version" from 1.0 to 2.0 (or any other number). Or you could change the Package Name for the second version of your MBO.

The MBO code then compiled into your iOS client then has to call the correct name for the package.