I have been watching this tutorial on implementing offline sync in Xamarin using the Azure portal. at 21:15 - 21:32 the tutorial explains that the getTable(myCoolTable) method in
using Microsoft.WindowsAzure.MobileServices.SQLiteStore;
assumes that the location of your database in the Azure portal is at
/tables/myCoolTable although you are able to change this if you want. This is fine if you made your cloud database using their Easy Tables software but I did not. It is not explained how it is possible to change this path, so that I can point my local SQLite database to sync with my Azure cloud database which is stored in ClearDB.
How do I achieve this?
According to your description, I assumed that you could follow this official tutorial for creating an Azure Mobile App backend (for a simple way you could choose node.js backend which works with easy tables and when you adding new table in easy tables, it would automatically create the node.js backend for the related table. Also you could build the c# backend by yourself and deploy it to your mobile app) and download the Xamarin demo project, then follow this tutorial to enable offline sync for your mobile app. Additionally, you could refer to adrian hall's book about Data Access and Offline Sync for a better understanding of offline sync.
Related
We're developing a full-stack platform deployed on GCP via AppEngine and with Firebase (Firestore + RealTimeDb) as noSql Db Module.
We're going live but I've a doubt. Now we're using the Firebase private-key.json to interface our software to Firebase and it is saved to a folder in the project like src/firebase and it is bound to our code through:
admin.credential.cert(require(path))
The API key and the path are saved to the .env file.
We're using the same technique to use the GCP client libraries (for example like Logging system).
I've also see that for GCP client libraries Google advises to use environment variables, but also indicates that they're active only during the session.
Anyway, to respect and to optimize security of our system: we should go live with these configurations or we have to change them? Please, do you have any advice to not expose the credentials and to don't have a vulnerable system?
Thanks guys
Posting John Hanley's, guillaume blaquiere's, al-dann's and Alex L's comments as a Community Wiki for visibility.
App Engine and Firebase are different services. There is a difference between their configuration files.
App Engine does not require a service-account.json file. Use Application Default Credentials (ADC).
Deploying a service-accout.json file inside your application source code is NOT SECURE.
The AppEngine service has the permission to use Firebase product (Firestore, Firebase functions) which should be sufficient. This means that you don't really need an API Key and a Firebase private key in your Node.js back-end.
App Engine runs under a service account. It may be possible to grant relevant IAM roles to that account (i.e. roles/datastore.user), so it can work with the Firestore service. If you would like - you can keep them in different projects.
You can refer to the Node.js quickstart for guidance in this scenario.
I am building a desktop application and added support for the Firebase realtime database. Because I am running a desktop application users will run different versions of my app.
As my app evolves, new features will be added and may require an update to the database schema as well. But I can't do this as I need to keep all client versions compatible.
For example, I have projects saved in the database at project/${uid}/${projectName}. Imagine in the future projects are not anymore tied to a user because I implement "collaboration" and want to change this path. How would I do this to keep all my clients up running?
You could store that path in realtime database and fetching the URL on client as required. I'm not sure what you mean by implement "collaboration" but if you want all the users to be on same version of your application then you would have to store the latest version in DB and verify the version yourself on client.
projects are not anymore tied to a user
In my opinion, if you could store a list of user UIDs who are a part of that project then that would be easier instead of structuring your app as projects/${uid}/projectname. If it is something like /projects/${projectId} then storing that list of authorized users would be much more easier.
There's Remote Config.
Firebase Remote Config is a cloud service that lets you change the behavior and appearance of your app without requiring users to download an app update.
You may have to use the REST API if your are building apps for desktop. Also as #Doug mentioned in comments, it may not synchronize all clients at same time.
I have two apps that use the same Firebase project, so they use the same database when online.
I would like to know if there is some way to make them also share their offline data. In other words, if I make an offline write on app A, I would like to be able to read that document on app B while still offline (metadata pending write = true).
Perhaps if there was a way to change the Firestore local database location to a shared location for both apps, this could be achieved.
Apps (on iOS, Android, and Web) work in a sandboxed environment, and access to each other's sandbox is highly controlled. While it may technically possible to build a solution that shared the local cache, the Firebase SDKs in each app currently uses its own sandbox for its local cache and these can't be shared.
Also see:
How can I share local database of an existing app with a new app and make both work on it simultaneously?
I'm making an in-house application for a company and they want me to use Phonegap for the mobile application. After searching, I decided to go on and use SQLite plugin for the local storage but they have this requirement that when the device goes online all the data on the local storage will synced automatically to the remote MYSql db. I read about deferred functions in jQuery but I'm not quite familiar on how to use them.
Are there any alternatives to achieve this requirement?
I'm currently investigating to achieve a similar goal.
I need to develop an IONIC/Phonegap app that can potentially do CRUD operations with the followings DB engines: MySQL / Postgres / Microsoft SQL Server / Oracle (not simultaneously).
TypeORM seems to be the solution, but I still couldn't connect from Android device to remote MySQL DB.
If you work with TypeORM over NodeJS directly is very easy to have an example up and running and do some CRUD operations with the supported DB engines (just follow the examples and documentation in the previous link).
I'm asking at https://github.com/typeorm/typeorm/issues/548 if anybody has achieved an Android-MySQL connection using TypeORM.
Google just released Firebase 2.0.
It seems they are completely separate platforms.
Firebase: https://www.firebase.com/
Firebase 2.0: https://firebase.google.com/
APIs are also different.
Firebase: https://www.firebase.com/docs/web/api/
Firebase 2.0: https://firebase.google.com/docs/reference/js/#firebase
Could someone explain the differences in the core concepts on both mobile and web?
I've been building an app using old Firebase.
Should I change my codes to use Firebase 2.0?
The new version of Firebase is the same platform - it just adds a whole range of new features, so the big change to the core concepts is an expansion of what you can do.
The Realtime Database offers the same functionality as before, but with a refreshed API and a new console. You can keep using the same approach and data model as before, and the API changes are largely cosmetic (renaming to be consistent with the newer features).
Authentication is pretty similar, but it has been expanded to include new features like account linking and customizable emails. You should be able to upgrade your application to the new SDKs and console pretty easily: take a look at our migration guides for Android, iOS and the web.
You can import your project at any time. Your applications and the existing SDKs will continue to work. You can then update your code when you are ready to use some of the new Firebase features in your application.
The new concepts are really around the new features:
Analytics is a new mobile-first analytics product that gives free and unlimited event reporting, and allows building audiences which can be used in many other services.
Storage allows you to store and serve user-generated content, such as photos or videos.
Remote Config allows you to change the behavior and appearance of your app without publishing an app update.
Cloud Messaging is a cross-platform messaging solution that lets you reliably deliver messages and notifications at no cost. Notifications gives you a tool in the Firebase Console to send re-engagement messages easily.
Crash Reporting lets you collect crash data from your Android and iOS apps, to find and fix problems more quickly.
Dynamic Links are smart URLs that dynamically change behavior to provide the best experience across different platforms. They allow you to use deep links that survive app installs on Android and iOS.
Several existing Google products have been integrated into Firebase as well
Invites replaced AppInvites, giving easy way to sending personalized email and SMS invitations. App Indexing gets your app into Google search.
Firebase now also integrates with AdWords to let you target ad campaigns with Analytics audiences, and AdMob to automatically track in-app ad effectiveness.
Its a lot of new features, but you don't have to try them all at once! Once you upgrade, its straightforward to pick and choose.