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.
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.
I know Apple has this API I can hit:
http://itunes.apple.com/lookup?bundleId={id}
However, for the PlayStore, I'm looking for something similar, rather than parsing the app page
https://play.google.com/store/apps/details?id={id}
and then looking for the <div> that contains itemprop="softwareVersion"
There are a few questions about this here on SO and elsewhere on the web, but they are outdated, and make reference to unofficial APIs.
There is no Official API for grabbing the App version from the Play store.
I'd be curious exactly what you would use such an API for, if you wanted to add it in a comment. There may be a better way of achieving what you want.
Edit:
For forcing an update to your app there are other recommendations. We normally recommend that you don't have "always update to the latest version in the Play store" to developers. For example, the user might want to use your app, but be in a place where they don't have much battery or wifi. Forcing them to update in such a situation is rude, it's much better to give them a week or two until a more convenient time.
If you want to do "never have a version that is more than a couple of weeks old", can I recommend Firebase Remote Config. This would let you on the server update a configuration options for your app saying "the user should have at least this version" and change the behaviour of your app accordingly. It is much more flexible at robust than polling the Play store.
Another approach can be the Support In-app updates besides Firebase Remote config.
Google has released the Support In-app updates feature in which the apps can nudge the users to update their apps without even going to the play store. If an update is available, the users will see a dialog or a full blocking screen where the UI is generated and controlled by google play.
In-app updates works only with devices running Android 5.0 (API level 21) or higher, and requires you to use Play Core library 1.5.0 or higher. After meeting these requirements, your app can support the following UX for in-app updates!
references are here and this helpful blog. Check this out, hope it will help.
I have an android app that is a counterpart to our software product that we sell to customers.
When we sell our product to a company, I need an easy way to give those users access to the app, including updates, product description etc.
The reason that a service like Google Play will not work is, that different customers require different versions of the app depending on their version of the main software.
Some customers are unable/unwilling to stay up to date, and we need to be able to give out different versions of the app depending on their version of the software.
Is there a way to set the max version of the app that a group of users are allowed to download?
This is a really good and difficult question. As someone who has worked on app targeting for many years on Google Play I've been racking my brains for the best way to do this.
The trouble is the completely different business models. Android works on the principle "buy the app once, get upgrades forever, usually automatically". Your counterpart computer software clearly works on a slightly different principle.
I can't think of anything that works well. Sorry about that. Some possbilities which are all broken in some way:
Have a different package name for each version of your app. eg com.myapp.v1, com.myapp.v2 etc. You could have the counterpart software provide the package name in a link to be helpful.This is bad because it punishes users who do upgrade, they have to manually install the new version each time. It also means reviews and ratings wouldn't all be associated with the app. It's a pretty terrible idea.
Make the android app versions always be backwards compatible with all versions of the counterpart software. We kind of do the opposite with the Google Play servers. Because we can't guarantee users upgrade Google Play on their phones, the server has to be compatible with almost every version of Google Play (and Android Market) ever shipped. It's a lot of work, but keeps users happy. You could make sure your app always works with old counterpart versions. You could always have a "sorry, you are getting a degraded experience because you haven't upgraded.
Sorry I can't help more.
I was just wondering the same when try to update from PlayStore.
Generally, say for Windows, when it is updated, downloads the files and patches them. From size perspective, these are significantly small compared to its setup which is around 3.5 GB.
So why its not applicable for ANDROID apps? E.g. any update to WhatsApp is almost equivalent to its original setup file (~18 MB).
Although Play Store calls them updates, you actually download the whole Android app again. In a way, it's still an update because you do actually upgrade to a newer apk version but not quite the way you would've liked. It's taxing on your bandwidth but it's easy.
However, your app's settings (shared preferences) and data (SQLite databases or custom files) survive this update/install process which won't be the case if you manually uninstall & install the app's new version again.
In cases where the app's database schema has evolved between the two versions, Android notifies the app on startup that it wasn't a fresh install by calling a life cycle method onUpgrade() where the app has a chance to upgrade its data left over by the previous version.
When you compare this with Windows, both the OS and the update server are from Microsoft and they must have worked together to figure out what needs to be pushed (.dll, .ini, .sys etc.), update bundle's format/compression and security implications (some sort of encryption to prevent malware injection by any one intercepting the traffic).
No such standard update mechanism has been made available by Google for the Play Store see update and I believe so is the case with every other app store. Obviously, the developers can't roll out one on their own since the updates are handled by Google both at the device and server side.
But, the developers are certainly not unhappy about it. It's much more convenient to test the new apk, see it working and uploading the same rather than fiddling with what changes to push and breaking the app if you miss something. The bandwidth is cheap anyway.
I've just recently discovered that at Google I/O 2012 Google announced that they were working on a Smart Updates technology using some delta encoding algorithm. The idea was to compute the DIFF between two APKs (sort of like we do for text between two source code files), create a patch on the server-side and only send that over the wire.
This feature went live on Play Store later that year as reported by AndroidPolice and TechCrunch.
Developers, Google said at I/O, won’t have to do anything to enable
this feature and according to the folks over at Android Police, this
feature quietly went live late last night or early this morning.
You can see it in action in this video. Notice how the apps start installing once the progress bar hits just 40-50%. This is absolutely brilliant because not only this saves Google terabytes of bandwidth, its pure server-side approach means developers don't have to fiddle with anything. Perhaps, that's the reason it finds no mention on the android developers site and so takes time to get discovered.
With that said, my personal experience seems to coincide with yours. I see most of my app updates download almost the whole of the app. Maybe it's because I don't download very frequently. It's not unusual for me to skip several minor revisions and perhaps the app changes far too much to derive any size benefits out of the patch generated.
There is nothing like an "update" for an Android app. It is always a full app. It is called update, because it is a new version of the app currently installed in a device.
But when it is an "update" the whole app is not fully downloaded. For many years the Google Play downloads just parts of the app and patches the currently installed app with the difference. So in the case of 20MiB the Google Play can download just few megabytes to reconsctruct the new version in a phone. Google calls is Smart App Updates or something like that.
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.