Clever Geek Handbook

Launcher / client applications for Windows Azure Mobile Services

Note that you have a WAMS service (.net backend in my case) and client mobile apps out there in the wild, and you want to release v2, which contains splitting the schema changes (splitting one table into two tables, for example).

I understand server side staging, but this question is about versioning clients. How to handle the period during which your updated mobile app is gradually rolled out to the user community and you have a mix of old and new customers in the wild?

Approaches I thought of:

  • Deploy the v2 mobile app with a new URL pointing to the new service. PRO: Simple client code CON: Consumption of two WAMS instances and complexity of synchronization across two db instances (one user may have different client versions on different devices, and their cloud data in different WAMS instances must sync until they are updated everywhere ).

  • Add version awareness to a mobile app with two or more datasets of the data model - one for the current version and one for v.next. Before upgrading the server, you deploy a version-aware client. PRO: easier and cheaper server side management. CON: Larger and more complex client code, and users who do not upgrade are blocked after server upgrade. It also sets a server rollout date on the client app approval timeline across multiple app stores.

  • Use a single database instance and a single server, but support the hybridization of old and new server versions through clever use of DTOs that expose the old wire protocol on top of the new schema along with new objects. Presumably I could add a version element in the routing path on the server. PRO: simple client, no server side gateway synchronization CON: more complex server code; keeping running offline sync is difficult if tables are split or merged (possible solution: parallel tables are kept in sync with code / script)

Option 3 is my current favorite, but is there a better / preferred way to overcome the changes in WAMS deployment with back.net server and offline sync network client app?

+3


source to share


1 answer


You might also consider using Azure API Management ( http://azure.microsoft.com/en-us/services/api-management/ ) for version handling. This would probably be most useful for option 1.



This is not really an easy solution, and if # 3 is the best for your scenario, I would recommend that you go with that.

0


source






More articles:


All Articles