We're using Application.Current.Properties to store settings data for our app.
When we release a new version of the app to the store (Apple App Store and Google Play), are these settings retained or cleared?
I've just run a test by distributing two versions to HockeyApp - both for iOS and Android - and the values stored in Application.Current.Properties (note, not Settings from any settings plugin) are retained on installation of the updated version.
This is good news for us and our customer!
See this thread in the Xamarin Forums
No, all values in the name-value dictionary are serialized to disk every time when the application goes to sleep. They are read back when the application is loaded again.
The data of your app is - generally speaking - not cleared when you install an update (it is deleted when the app is uninstalled), cf. here, here and here. Hence App.Current.Properties should be maintained when updating an app. But you can easily try it. Publish a beta on HockeyApp, TesFlight or whatever, update the app and see what happens.
Related
I want to control background sync of google-firebase's firestore db with persistance mode (PersistenceEnabled to true).
I'm afraid the old version client, works offline and don't know the app's version-up (with some destructive updates), may upload local-data to server when change to online.
In this case, I want to check current app versions and allow/not allow before sync.
Is there any solution?
Data in the cache is only updated when you attach a listener/observer to it. There is no automatic synchronization happening for the data in the offline cache.
This means that you can add a version check to your application startup code, before you attach any observers. Simply store a database-version field in a global document, and check against that upon application startup. If the version is greater than what the app was made to handle, show an upgrade prompt.
What's the best way to change the Firebase data model while you have multiple versions of your iOS app in production?
Since there's no 'application server' layer in the middle any changes in the database model could break older versions of the app.
Performance Related Example of the problem:
In version 1.0 I was naively keeping everything related to a post under '/posts/'. Now in version 2.0 I want to take Firebase's recommendation and add a '/user-post' endpoint to quickly list all posts for a given user.
People using version 1.0 of the iOS app are not writing any data to '/user-posts' since that endpoint didn't used to exist. People using version 2.0 therefore don't see any posts created by people using the old version of the app.
In theory I could create a server somewhere that listens for changes on '/post/' and adds them to '/user-posts' as well. That seems hard to maintain over time though if you have a lot of different versions of your app.
New Feature Example of the problem:
Lets say in version 1.0 of your mobile app you write new blog posts to '/posts/'. Now in version 2.0 of your app you introduce a Teams feature and all posts need to be in '/team/team-id/posts'.
People who haven't upgraded to version 2.0 will still be writing to '/posts'. Those posts won't be visible to people using version 2.0 who are reading from '/team/team-id/posts'.
I realize you could keep both endpoints simultaneously (and index /posts based on team ID) but over time this seems hard to maintain.
Traditional solutions:
If I were using something like Django or Express I'd do a database migration and then update the server-side endpoints for creating blogposts.
That would make changes in the database from the clients. I could in theory add an application-server tier to my architecture with Firebase, but that doesn't seem like it's recommended: https://firebase.googleblog.com/2013/03/where-does-firebase-fit-in-your-app.html
I would suggest you use Firebase Remote Config to show an alert via UIAlertController or different screen if an update is available. You could force the user to update to the current version and you don't have problems later because no posts with the old code can be created.
To answer your question:
I would develop a different app, add it to the same Firebase project and then let this app convert all old data to the new data model. So you would do this one time after releasing the new version and the old user data is converted to the new data model and everything works smoothly. You could also have a property like databaseVersion for every object.
To prevent future problems you could have a general property named app-version in your Firebase Realtime Database. Before every post the app checks if there is a newer version. If not the user can add the post but if there is a newer version you could show an message/alert via UIAlertController
I'm working with Azure's offline-sync API.
(It's REALLY GREAT so far, but since it's still new-ish it doesn't have comprehensive documentation, only tutorials. We need to craft dependable integration tests, and we're finding that tricky because we need to rely on published behavior in official docs for that... or dig into the source, but that is liable to change at any time.)
The samples do this:
var store = new MobileServiceSQLiteStore("localstore.db");
The comments mention "initializes local store".
I assume the local sync database is a "throw-away" asset, as it can be recreated at will.
Is the expected behavior that it will create the local SQLite file if it does not exist, or it will recreate the file each time the mobile app starts and that call is made?
The tutorials are augmented by the HOWTO documentation (available under Mobile > Develop - in the same area as the tutorials) and the GitHub Wiki and the github.io pages for the SDK.
The local store is created if it doesn't exist, and new fields are added to tables if they are needed. It's sometimes good to delete the database - for example, if you reduce the field count in your mobile app (the process only adds fields). If you do this, the database will be re-created when the app is next restarted.
I try to build a database on Icenium with SQLite and the db does not persist - why? I think the structure of the database is not built on a physical level. Someone you ever had this problem?
I was able to use SQLite with Icenium on my project successfully. As I see, there is also an example that you can look up:
https://github.com/Icenium/sample-sqlite.git
You might also want to take a look at this post: Creating a Database from a SQL Dump, for using prepopulated SQLite database.
From my experience with Telerik AppBuilder (formerly called Icenium), each time you Run the project in a simulator, the simulator starts from scratch and it keeps no record of what happened in previous runs.
The solution I would use to 'persist' the database on a session basis and test your code is as below.
You must keep the simulator open (so don't close it) to keep database intact
and just press Reload button in simulator window to see how an existing database
would run on a real device every time the app is re-started on a real device,
because within a single Run of the simulator it remembers everything.
Even if you want to make changes to your code or html, leave the simulator open and make your code changes (and Save), and then click on Refresh button in simulator window to bring in your recent code changes without losing the database and its data. If you follow this approach you can easily test how a database would behave on real device where a database is naturally persisted.
So think, in terms of 'simulator session' when developing hybrid apps using Telerik AppBuilder.
I'm tryign to use 51Degrees in a .NET project that I deploy to Azure. August 2011, they released v1.2.1.3 marked as "Azure Compatible":
Foundation can now be deployed on to the Windows Azure Cloud service.
See the release note for full details on requirements and how to
setup. Azure related changes include: Instead of a log file, log
entries are written to a log table Instead of a devices file, previous
device requests are written to a device table A new conditional
compilation symbol - 'AZURE'. AZURE enabled builds will not work in
traditional ASP.NET.
Since then there have been a dozen releases and they are up to v2.1.4.9. However, their documentaiton is super light on how to use it with Azure. In fact, there was a bug originally because v1.2.1.3 stated
To make use of the changes you must create a storage account called
‘fiftyonedegrees’. The foundation will then create two tables, one for
previous devices, and another for logs.
This isn't possible because Azure storage accounts need to be unique across all instances so everyone can't create ones named fifityonedegrees.
Their response was:
After rereading the blog it seems I've made an oversight in this
regard, and will update shortly.
The storage account that the Foundation looks for can be changed in
the Foundation source code. Go to Foundation/Properties/Constants.cs
and change the string 'AZURE_STORAGE_NAME' to the name of your storage
account.
However, I'm still at a loss at how to utilize it within my project. Here's my issues:
I'm not clear whether v1.2.1.3 is the only Azure compatible release, or every release after is Azure compatible. Their documentation doesn't say.
When I install 51Degrees via NuGet, my project doesn't get an App_Data folder created which contradicts their documentation. The web.config file even has entries in it that reference the App_Data folder such as <log logFile="~/App_Data/Log.txt" logLevel="Info"/>.
Based on the response to the Azure storage account bug I quoted earlier, they are sayign IN need to edit the file Foundation/Properties/Constants.cs. However, since I'm installing via NuGet and it's a DLL, NuGet is presumably the wrong approach? Do I need to download the source and compile it myself and wire it up to my project manually?
I'm generally new to .NET, NuGet, VS, etc so appreciate the help.
All versions are Azure compatible from 1.2.1.3 onwards. I'm assuming this is the blog post you were talking about. After you've created your azure storage account, you'll have to edit the Constants.cs file in the source code and add in your account name. It's my understanding that this means you'll have to get access to the source code and edit it directly. One you have done this you'll need to recompile for the software to work correctly. I'm not sure if there is a way to perform the same task using NuGet, but I'll look into it. Hope this helps.