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
Related
I created an iOS 8.X app with the company I previously worked for, and would like to keep the app for personal reasons. I have all of the code for the app, but it was written in swift 1, and hasn't been updated to the swift 2 syntax. Also, it was written using provisioning profiles for my old company, which I no longer have access to.
I haven't upgraded my personal device to iOS 9 yet so I can keep the app on my device to demonstrate at job interviews.
Is there a way I can locally save the app on my computer and install it on any device without the proper provisioning profiles, developer license, etc.?
You'll need your own developer account, which shouldn't be a problem because they are free now. But basically if you have the source code, you can simply re-build it with your personal provisioning profile. Because you won't be able to set up an explicit application ID, you will simply create a wildcard id on Apple's developer site, then create a developer provisioning profile using that wildcard ID and your personal certificate. Then simply build it to the device directly.
Why are you not updating your device to iOS 9? If properly written, your app will work fin on iOS 9 if it worked on iOS 8. The opposite is not necessarily true, as an app with a minimum OS version of 9 probably makes SDK calls that did not exist in 8. Although some changes may be needed, you should be able to build your app with the latest version of Xcode even though you originally coded it in Swift 1.2. You can find simple instructions on how to do that upgrade. This will also allow you to address any potential iOS 9 issues.
If you don't have the source code, but have the .ipa file, you could also resign it using the instructions here: https://stackoverflow.com/a/25656455/3708242
This is not as ideal, because if there are iOS 9 or iOS 10 issues, you will not be able to fix them. I think keeping the source code available (if you are legally allowed to) will be your best bet.
I am going to build hybrid-mobile-app with Ionic, Angular and Cordova and port it to Android and iOS. One of the main features of the app will be offline storage/capability to store and view app content offline.
Content that I want to save in local DB may be even over 50MB, so local storage is not an option.
So far I found sqlite and indexdb. But I wonder if any of you have previous experience with similar problem to solve and could suggest some other options? Or maybe which option (sqlite or indexdb) will be better solution for my app?
You should also know that localStorage isn't a viable option for permanent device storage if you're going to build for iOS. The OS will wipe out localStorage data when device memory is low. IndexDB may be volatile too because it's stored within the context of the webview.
I develop an Ionic app which has some data stored (not a large amount at the moment) in SQLite. I chose localForage with SQLite driver. It works well for what I need because it stores the data to a database file in the filesystem which is safe from OS deletion. What's nice is that the functions are similar to what you get with localStorage; the biggest difference being that the functions use promises.
This is the stack of components that I used in order to implement what I have now:
Bower components
angular-localForage
localforage
localForage-cordovaSQLiteDriver
You will also need the Cordova-sqlite-storage plugin.
You may also have a look at LokiJS and PouchDB (blog articles from "GoneHybrid", implementing those 2 libs).
I would personally go for LokiJS (http://lokijs.org/) and its JSON file, even if both have adapters for WebSQL, SQLite, IndexedDB.
I was part of a team that built a successful Cordova / Sencha Touch (the UI framework doesn't really matter here) / SQLite app for iOS and Android. We had over 100Mb of data to store in the database, had to encrypt it and transfer it from a server into the app.
SQLite performed well, we also used some custom functions that we wrote to move some of the data crunching we needed into the database engine and out of Javascript.
Another member of the team wrote a short blog article about some of our experiences with this stack.
Overall given my experience, I'd say SQLite is a sound choice, but I don't have experience with IndexDB.
I have some existing Windows Phone Silverlight applications. I am considering porting some of them to universal apps. I can find a lot of information about the development side of things with regards to the port, but nothing that talks about the deployment issues.
For example, my existing WPSL app is a paid app with free trial and some customers have purchased. Do I need to do anything to ensure those paid customers continued to receive the non-trial features if I push a universal app package? The purchase API's are different, are the backend servers/purchase records compatible, or is there no way to keep paid customers at the paid version?
Also, what about app settings from isolationstorage settings and data files saved to local storage by the app? Will these be kept and accessible through the new API's when the new package is downloaded as an update, or will the fact the package is a different framework/version/appid cause the data to be deleted? Do I need to give the package the same id's as the Silverlight version to ensure all this stuff just works?
Thanks in advance.
It should just work without needing to do anything fancy.
It will be the same app, just a different implementation. Your paid users will stay paid and your upgrading users will keep their data.
If you associate and add the new appx to the same app entry on the dashboard then everything should work smoothly. When you associate the runtime app the product ID, etc. will be set to match the existing version in the store (via a mapping since the actual values are different)
IsolatedStorage maps to ApplicationData.LocalFolder and LocalSettings (this was already true on Windows Phone 8 - you could use either API)
See What's next for Windows Phone 8 developers for an overview of your options.
See Migrating your Windows Phone 8 app to a Windows Runtime XAML app for information on feature changes you'll need to be aware of.
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.
There have been a few articles and questions about how to do this but they all seem to have a bias to iOS.
So first of all I am currently using PhoneGaps database functionality:
http://docs.phonegap.com/en/1.0.0/phonegap_storage_storage.md.html
I have a database I need for the app to run from as it contains a lot of information, probably about 1mb worth (can be exposed as .db/.sql). So I want to be able to make my PhoneGap app and build it for as many platforms as possible. However I want it so that as soon as the user has installed the app it automatically installs the database for them.
Some of the solutions seem to recommend creating the database on first boot, but this just seems a bit hack-ish and sidestepping the problem.
I am more than happy to switch over to use webSQL if Android, iOS and other providers support it, however as PhoneGap wraps any available native OS DB functionality it seemed more realistic that you can get an app to pre-populate an Android database and access it via PhoneGap than pre-populate a web database and access it via webSql.
Hopefully this question makes sense and there have been advances since mid last year, which seems to be the last up to date post on this sort of thing.
I just answered another similar question on this topic. First PhoneGap doesn't implement the Storage function that is documented. In fact we take advantage of the sqlite and localStorage functionality that is implemented in all webkit based browsers.
My recommendation is for you to pre-populate a SQLite DB and on application startup copy the DB to the correct location so your app can access it. There is a good blog post on this topic at:
http://gauravstomar.blogspot.com/2011/08/prepopulate-sqlite-in-phonegap.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+GauravSTomarBootstrappingIntelligence+%28Gaurav+S+Tomar+%3A+Bootstrapping+Intelligence%29