When you upload a new version to app engine, let's call it '10', you can send requests to this version directly using this url: http://10.myapp.appspot.com
I find it very useful and I made an habit to release my android app pointing to the corresponding server version. So when I upload version 10 to the play store it points to http://10.myapp.appspot.com, the same goes to version 9: http://9.myapp.appspot.com.
Is this correct usage or this feature? What is the best practices regarding Versioning in App Engine?
I'm doing it because I want to maintain backward compatibility, so that if I'm making a change in the server the old clients won't notice it because they are connected to an older version.
I understand it's problematic because all the versions share the same DB as well as problems that could occur when I configure warmup for the default version that doesn't apply to the other versions. So am I making a mistake by using it this way?
Application versions are useful for things like testing new versions before deploying them "live." I would not use it to ensure backward compatibility with you existing clients. Furthermore you can have only limited number of versions per application.
You can have up to ten versions of each application; once you've reached that limit, you'll need to delete existing versions before you can deploy new ones.
Another thing to consider is that some App Engine services (e.g. Datastore) are independent on a particular version but others (e.g. Cron jobs) are tight to a concrete version (usually default version unless specified otherwise).
However, you can have different versions of your application's public interface (REST/SOAP services or whatever you use) so that new features or changes are available only to the respective clients.
Here is an example of dummy REST API using versions.
https://myapp.com/api/v1/questions/10/answers?max=10
https://myapp.com/api/v2/questions/10/latest-10-answers
Related
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:
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.
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).
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.
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.
The fictitious situation is the following: I have a mobile application that has been published to the store for about a year now (both for iOS and Android). I’m preparing a new version of the application. Some of the api’s in the back end are obsolete or deprecated.
The problem is that users of the application that would not update the app to the new version will experience problems with the operation of the app because the back end api’s have been replaced or removed.
The question is how to deal with this situation before becoming a problem?
Are there any guidelines from apple or google for obsolete functionality between different versions of the application?
#Dimitris, Here you need to provide force update to the old apps. This can be done using app configuration file. Basically, you will have an app configuration file which contains JSON with following keys:
{
"server":{
"app-server1-base-url":"http://",
"status":{
"is-running":true,
"message":"We are busy upgrading XYZ server with technology and features. We will be back soon. We apologize for the inconvenience and appreciate your patience. Thank you for using XYZ!"
},
"force-update":{
"status":false,
"message":"Please download the latest version of XYZ from App Store to continue using the app. Thank You!"
}
}
}
Here 'app-server1-base-url' key will be base URL for the app. you can put all the service URL in this file.
Case 1:
Your app will check this at the time of launch whether force update available or not to the app.
Case 2:
API versioning can be done if you want to handle it using backend.
Note: Please keep configuration file on services like AWS S3 etc.
As Puneet Sharma said in this post: https://stackoverflow.com/a/18756151/8354952.
Almost all changes to the iOS versions are additive and hence an
application build using lower version still runs on the higher iOS
version. But we also need to notice that APIs are introduced or
deprecated and behaviors of existing APIs may occasionally change.
Basically the old version application may run on the latest system version. But some special api or class may be deprecated, this will cause some weird behavior or crash. So Apple or Google will also recommend user to update old version applications.
For the api from our own server, we can do the application compatibility by ourselves. Upload the current version identifier, the server can transfer different types of data through detecting the identifier.
I am handing off an Android app to a non-technical client for long-term maintenance. Could anyone offer insight into how often the app might break due to OS updates such that they would have to bring in an external developer?
I'm guessing this would depend on the type of app, so let me offer a bit more info below:
Our app displays live bus information using the google maps SDK
We have few external dependencies - just joda-time, hockeyapp, and AppIntro
Thank you!
If you would solely depend on platform / SDK functionality, your app will not break unless Android / Google actually starts and removes deprecated functionality in newer SDK versions - which it has actually not done in the past a single time (well, except once, when they moved the old Apache HTTP library into an external dependency, but this really happened only one time so far). So, your app will continue to work, but will slightly degrade wrt integration and UI design over the upcoming SDK versions. See for example how "alien" Gingerbread or older apps look on modern Lollipop or Marshmallow devices - but also see how they continue to work.
If you depend on Google Maps, you depend on Google Play Services, and that is an entirely different area. Since Play Services are updated separately and constantly by Google, their API evolves differently and more often introduces breaking changes. These breaking changes are, however, long communicated before, like e.g. the abandonment of the old Maps v1 API that was IIRC around for more than two years after it was announced as deprecated.
HockeyApp is another candidate where you depend on external server functionality. If Microsoft decides to do whatever with this service (change APIs, abandon it altogether), you of course need to touch your implementation. But again, this should be communicated a long way before it will actually happen.
This was an interview question for an Associate Mobile Developer position that I was not able to answer properly. Can somebody please shed some light on the matter?
The whole question was presented this way:
After the launch of iOS7 a lot of applications needed to be upgraded in order to make them work with iOS7. What kind of changes occur when a new OS for Android/iOS is launched for which we need to upgrade our applications? Why can't an application running on iOS5/6 properly function on iOS7? No need for being specific about iOS7. I want a generic answer that explains the compatibility issue for past and future upgrades on any platform.
My answer was more towards the UI/UX compatibility but the interviewer was not very happy with the answer. What could I have said more?
In the majority of the cases, most operating systems updates are designed to be backward compatible. This means that an application written and optimized to run on a specific version of an OS should run without any problems on the next version.
Backward compatibility is usually preserved for a few 'generations'. An app running on version 1.0 of an OS is very likely to run on version 2.0, probably on version 3.0 but maybe not on version 4.0 or later.
New APIs are designed to implement new technologies and old APIs are marked as obsolete. Obsolete APIs are still part of the newer OS version, but their use is discouraged for new development.
"Why can't an application running on iOS5/6 properly function on iOS7?" This statement is too general, and I would say that only a small percentage of application suffer from this.
There are some technological changes that might affect more than others. For example, a hardware upgrade on a device is much more drastic than an algorithm change.
And there's obviously the commercial reason, and for some brands like Apple, this might be the biggest reason to compromise backward compatibility. In Apple's case, the backward compatibility is also restricted with the App Store policies. To upload an App to the store, you need to comply with certain guidelines that implicitly force you to upgrade or rewrite some of your code, and sometimes it forces you to buy the latest development tools, which only run in the latest OS which only runs on the newest machines.
If I target my Android app for version x, will it have any problems if the user uses an Android version above x?
What will I have to watch out for?
Yes, it's should work.
Updates to the framework API are designed so that the new API remains
compatible with earlier versions of the API. That is, most changes in
the API are additive and introduce new or replacement functionality.
As parts of the API are upgraded, the older replaced parts are
deprecated but are not removed, so that existing applications can
still use them. In a very small number of cases, parts of the API may
be modified or removed, although typically such changes are only
needed to ensure API robustness and application or system security.
All other API parts from earlier revisions are carried forward without
modification.
Take a look at this
Yes! It should work on upper versions of the sdk without error. But you should carefully read the release notes