CODEWITHSUNDEEP
androidiosversioningmodularity
Naive Developer
Naive Developer

Reputation: 710

How to modularly keep a serve-side application for different versions of an app

I am introducing to the world of apps like Uber and Line. When I am implementing the server-side of this kind of app, I realize I have to support different versions of my app at runtime. To overcome this requirement, I see three different choices:

  1. Keep a (different) running instance of the server-side for each app version supported. For example, if I support 3 versions of an app, I will have 3 instances running in the server.
  2. Use namespaces for functions, in a few words, clone many functions/class. For example, if I support 3 versions of an app, I will potentially have 3 versions of a function (eg. fun_v1, fun_v2, fun_v3).

  3. Keep a (different) configuration file for each app version. This file sets that functions or services an app can use and how to use it.

    These three options don't look so modular and a lot "copy and paste" code. If you have any different opinion, let me know.

Upvotes: 0

Views: 37

Answers (1)

Duy Le
Duy Le

Reputation: 87

normally mobile apps talk to server via a set of API routes/functions.

From my experience, I think I would pick the second option. Usually I develop these API routes into different versions a long the way (eg. v1, v2, v3, ...), so let's say version 1 of the app calls the route POST v1/login which links to login_v1, and version 2 of the app calls POST v2/login which links to login_v2. This technique keeps things flexible as you can map any route to any function that you want (eg. login/v3 to login_v2).

Also, the server will keep track of the latest version of the app. When the app opens, it fetches the latest version number from the server, if it is more recent compared to the current version of the app, we may ask the users to update the app for new features.

Hope this helps.

Upvotes: 1

Related Questions