I have noticed on a number of platforms: iOS, Android and BlackBerry that when updating an app the entire app is downloaded again (others mobile platforms may work this way too but I have only been exposed to these platforms).
Why does the entire app need to be downloaded again for an update instead of incremental updates?
This seems very inefficient especially if you are dealing with large apps.
Your basic question is not true for iOS, as of 6.0:
Starting with iOS 6, the app store will automatically produce an
update package for all new versions of apps submitted to the store.
This package is optimized for updating an app from one version to
another, and contains files that have changed between the prior
version of an app and the new version of the app, excluding files that
have not changed.
When used optimally, an update package is significantly smaller to
download than the full package of the app and the update will install
more quickly. Also, in many cases, this mechanism allows updates to
large apps to be downloadable over cellular networks where app
downloads are subject to a size limit.
In addition to new content, the update package contains instructions
on how to transform the prior version of the app into the new version
of the app. New files will be added, modified files will be replaced
with their updated counterpart, and deleted files will be removed as
part of this transformation. As far as the developer and user are
concerned, this process is entirely transparent and the resulting
updated app will be indistinguishable from a full download of the
corresponding updated version of their app.
So, yes, it is possible to do delta application updates, as well as delta OS updates, on mobile platforms. This capability simply has to be added by the OS vendor.
Some of the code and other content might be updated and/or changed. This requires a update. Since Android does not allow you to change/delete/add files to the installation folder, you have to download and reinstall the whole app.
Related
I always assumed that when I uninstall a Codename One app (Android and iOS) all its data in the Storage and in the home path of the File System Storage is also cleaned... it seems so in my phones, but this is not the case on the Android phone of one of my friends (I'm referring to the same app developed by me).
Is there an explanation? Is it possible to be sure that all app data is cleaned during the app uninstalling? This is particularly useful during the software development.
Could this behavior be the one described in the answers to the question An Android app remembers its data after uninstall and reinstall?
Thank you
I'm guessing here but it could be related to Android backup support which restores the data. Otherwise if you used FileSystemService and stored data in he SD card area that won't be removed on uninstall.
For the former we have a build hint: android.allowBackup=false
I have a website on AppEngine that is 99% static. It is running on Python 2.7 runtime. Now the time has come to evolve this webapp, and since I have almost none Python code in it, I'd prefer to write it in Go instead.
Can I change runtime from Python 2.7 to Go, while keeping the project intact? Specifically, I want to keep the same app-ID, the same custom domain attached to it, the same SSL certificate, and so on.
What do I have to do in order to do that? I surely have to change runtime in the app.yaml. Is there anything else?
Bonus question: will such change happen without a downtime?
I'd be grateful for any links to documentation on exactly that (swapping runtime on a live app). I can't find any.
Specify a runtime as well as a new value for version. When deployed you'll have an older version that is Python and a newer version that is Go. There won't be any downtime (same as when deploying a newer version of Python).
Rather than trusting links/docs (that may be out of date or not 100% exactly what you're trying to do), why not create a new GAE-Std project for testing purposes and try it yourself. Having a GAE-Std test project is good for testing new function (especially by other testers who won't have access to the dev environ on your laptop).
The GAE services offer complete code isolation. So it should be possible to simply deploy a new version of the service, which can be written in a different language or even use a different GAE (standard/flex) environment. Personally I didn't go through a language change, but I did go through a split of a single-service app into a multi-service one, I see no reason for which the same principles wouldn't apply.
Maybe develop the new version as a separate app first, to be able to test it properly without risking an accidental impact on the old version and only after that bring the code as a new version in the old app. That'd be using the GAE project isolation. You can, in fact, test the entire version migration as a separate app if you so desire without even touching the existing app. I am using this technique - a separate app ID - to implement a staging environment for my app, completely isolated from my production app, see How to copy / clone entire Google App Engine Project
Make sure to not switch traffic to the new version at deployment time. This keeps the app working with the old version. Test first that the new version works as expected using Targeted routing. Then maybe use Splitting traffic across multiple versions to perform A/B testing with just a small percentage of the traffic going to the new version. Finally, when happy with the results, switch all traffic to the new version.
You need to pay special attention to the app-level configs (dispatch, cron, queue, datastore indexes), shared by all services/versions. They need to be functionally equivalent in the 2 versions. The service isolation doesn't apply to them, only project isolation can ensure no impact to the old version.
There should be no need to make any change to the app ID, custom domain mapping or SSL config. The above mentioned tests should confirm that.
A few potentially interesting posts related to re-working services/modules:
Converting App Engine frontend versions to modules
Google App Engine upgrading part by part
Migrating to app engine modules, test versions first?
Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
I have recently moved from a web context into a mobile context (building a React Native app). One of the most powerful processes in the web world was Continuous Delivery. I would like to recreate a continuous delivery pipeline, into production, for the React Native mobile context. My understanding is that this is possible so long as only the javascript bundle gets updates rather than the underlying native components.
I have been finding blogs such as:
https://hiddentao.com/archives/2017/02/17/continuous-integration-for-react-native-with-testfairy-testflight-deploy/ and it appears that fastlane is the most common solution for Continuous Integration in the mobile ecosystem, but posts about Continuous Delivery are a little thin on the ground.
Is this because it is impossible? Is the promised land of "just update the js bundle" a lie? And if it is not impossible, how would I configure fastlane to push directly to production? Or would I use some other tool? Is it generally considered an anti pattern in the space? If so why?
It IS possible to update the javascript portion of a React Native app.
Fastlane is a great tool for building and deploying mobile apps but it is not itself a continuous delivery tool. However, used in conjunction with some other CI tool (Jenkins etc) it can make it easy to configure app store or beta releases triggered at some set interval or based on a certain trigger.
Fastlane is primarily designed to solve the issues associated with building and deploying native applications and as such it is very useful for building/deploying the native RN app to the app store but is likely not the best tool for managing your JS pushes. There are a few tools that are popular for pushing the JS code:
https://deploy.apphub.io/
and
http://microsoft.github.io/code-push/
are two popular mechanisms specifically built for this purpose and provide command line tools for deploying updated javascript. These could be configured in Jenkins (or another CI server) without necessarily needing to use fastlane.
As #john_ryan specified you could use CodePush for application updates. Nevertheless, it is worth taking into account some features of this solution:
You can't use hot updates if you need to add some native modules.
It strictly not recommended to use hot updates if you updated React Native version. In most cases, the consequences will be sad.
New users will get outdated built-in version at first app launching. Actual version will be presented on second run only.
Given all of the above CodePush is best for:
To decrease app update time for critical bugs. Of course you must release native update as soon as possible in this case also.
Non major updates. For major updates in most cases you need to update screenshots, app description, release notes and draw the user's attention about update. Hot update for major changes does not fit because of "second run update" cycle.
Testing stability of new update on a small part of users.
A/B testing.
You should use fastlane in any case. It really cool for custom builds, updating stores meta info, screenshots etc. For beta builds delivery I recommend Crashlytics Beta.
We have an net 4.0 winforms application that we publish with clickonce to the client pc's. The installation is about 80 MB. The application is offline available and the update occurs in the startup of the app using
ApplicationDeployment.CurrentDeployment.Update
Each time we do an update of the application everything works fine and each client gets udpated. However the application cache keeps growing in size... We noticed that more then two versions are kept in the LocalAppData folder. The size of the clickonce installation folder is more then 1GB.
ClearOnlineAppCache works only for online applications and we don't find any information to clean the LocalAppData for offline application.
Is there any way to manage previous versions of our application in the LocalAppData folder from our client pc's?
Update:
We removed our custom update code and used the update mechanism of the Clickonce framework. Now old versions are removed properly and only two versions are kept in LocalAppData. I have still no idea why all versions are kept when we update through the custom update code.
I've seen this issue before, but I clarified with the ClickOnce lead at Microsoft before answering.
It keeps two versions of the deployment plus there are extra folders for each assembly. When processing an update, ClickOnce figures out which files have changed by comparing against the assembly it has already cached, and it only downloads the ones that have changed. The deployment folders have hard links to the assemblies in the separate folders. So you might see additional files, but it's not actually the file, it's a link to the files in the assembly-only folders. Explorer will show it as a file, but it's not. So unless you're running out of disk space and are just concerned about the folder size, be aware that the information reported by Windows Explorer may not be accurate.
There is an answer to this problem here
I wrote a function to clean old ClickOnce versions in the client side.
In my machine I've freed 6Gb of space. I don't want to even know the total space used by old versions org wide...
I have created a Silverlight 4 application, that is running out of browser. As you will know, there is a function that is checking if a new version of the app is available and installing it.
But what if I want to only check for the update and not installing it?
Personally, I do not like applications that silently update themselves, downloading something from the internet. So I'd like to have the following mechanism.
- when the app starts, it checks if updates are available
- if so, I show a messagebox to the user, telling her that there is an update and that she can download and installing it via the update-button
- the user can now decide to update
Unfortunately, there seems to be no option to just checking for updates without actually downloading and installing it. Any ideas, how to achieve this?
Thanks in advance,
Frank
You can roll your own update detection, by having a small file on your server next to the XAP for your app, that contains the latest version. For example:
http://localhost/myawesomeapp.xap
http://localhost/myawesomeapp.xap.ver
When you want to check for updates without downloading them, you can always hit the .ver file, check the version listed in it and if newer then the current running app, show the Update button to the user.
Note that this approach also would allow you to create more advanced scenarios, like prompting the user to upgrade to a different version of the app (Pro for example) or that they need to upgrade their Silverlight to get the latest.
And if you have multiple apps, you can list all of them in that file and do cross-promotion between your apps.