I developed an application using Realm database with user authentication via iCloud token.
Now I want to publish my application to the App Store and need to deploy Realm to the production.
My question is: What is the best and easiest way to deploy my Realm DB? I tried Realm Cloud and Azure with preinstalled image, but neither of those supported configuration of the Realm to communicate with iCloud. And all resources I found linked to non-existing Realm docs.
Related
I'm currently [attempting] to use Realm in one of my applications; however, I'm unable to view the default.realm file in Realm Browser or Realm Studio, which I'm finding very inconvenient. Whenever I attempt to open the file I'm asked for an encryption key. I am not encrypting my realm files as far as I know.
All cocoapods are up to date as are Realm Browser and Realm Studio. I've created the file from new multiple times.
Any help would be greatly appreciated.
Further Information:
Podfile:
pod 'StitchSDK'
pod 'RealmSwift', '=10.0.0-beta.3' (this is directly from the MongoDB Realm tutorial)
Xcode version: 11.6,
Realm Studio: 3.11.0
I am attempting to open the auto-generated default.realm file stored at realm.configuration.fileURL (/Users/.../Library/Developer/CoreSimulator/Devices/9C9C5338-B831-45FC-BDDE-2311C4B6DE0D/data/Containers/Data/Application/F8149B26-D04F-4B1E-A923-BE0F5D229595/Documents/default.realm) and have deleted and regenerated this and its associated files to create it 'from new.'
When opening the file in Realm Studio (I've deleted Realm Browser since reading the comments) I receive the message: "Opening Realm files of format version 11 is not supported by this version of Realm". I am following a iOS SDK Tutorial for Realm in the MongoDB Docs to implement Realm in my app and it works: I'm just unable to view the file.
I do not have Filevault enabled and am developing for iOS. I'm not sure where to check for the sandboxing so it should be whatever the default is.
Thank you again!!
Whoa... pod 'StitchSDK' is not the correct podfile for working with MongoDB Realm. Stitch is a soon-to-be discontinued/depreciated product and is not needed as it's functionality is rolled into MongoDB Realm.
(Note this answer assumes you're sync'ing your data)
The confusion here is that Realm is in the 'middle' of a transition. The 'classic' product called Realm is currently 5.x and is what's referenced on the Realm.io website and is covered in the Getting Started Guide for 5.x
This version stores it's data locally first and synchronized with the Realm Object Server, and you can view that data using Realm Studio 10/11.x
The new product (unreleased and still in Beta at this time) is called MongoDB Realm and while they are similar, MongoDB Realm stores it's data locally first and in MongoDB Atlas (server)
Realm Studio "does not work" with MongoDB Realm. Your error is probably due to being sandboxed but that's another issue. Just don't use it at this time as it may corrupt your data. MongoDB Realm objects are a bit different than Realm objects so you may have weird issues.
To work with MongoDB Realm, you need to log into the MongoDB Realm website console, and either select Realm
to configure, work with your app specs, or to check the error log
or, select Atlas->Collections
to see your actual data.
We have an older application based on the AppEngine SDK (now deprecated) and the superseded Cloud Datastore.
In the process of migrating to Google Cloud SDK we also decided to move from JPA/Datanucleus to Objectify.
Given that the Cloud Datastore will be automatically upgraded to Cloud Firestore in Datastore mode sometime in the future, we decided to test our application as described at the bottom of this page:
https://cloud.google.com/datastore/docs/upgrade-to-firestore#testing_an_existing_application
1) Create a new project. In this project, create a Cloud Firestore in Datastore mode database.
2) Using the managed export service, export some of your application's data to Cloud Storage.
3) Using the managed import service, import your application's data to your new project.
4) Copy app logic you want to test to the new project or simulate app behaviour against the new project.
That's what we did and after some issues we could make a portion of our application run fine with the new datastore in a separate test project.
Now to the actual issue...
We wanted to test if the updated application could also run with the superseded Cloud Datastore, so we won't have to worry when the automatic upgrade occurs (as our app will be already ready).
So we deployed it as a new version of the existing AppEngine project (v2-dot-.....): unfortunately running the new version throws a permission error as soon as the app tries to read the datastore:
com.google.cloud.datastore.DatastoreException: Missing or insufficient permissions
So the questions are:
- could this be related to the Cloud Datastore not being upgraded to Cloud Firestore in Datastore mode for our project yet?
- is there anything we can do (add specific permissions maybe) to make it work anyway?
Our concern is that we need to have the new version of the app deployed before July 2020 (that's when the older AppEngine SDK will stop working), and we are worried that the automatic upgrade of the datastore will occur later.
Thank you for your help.
Turned out our project doesn't have the PROJECT_ID#appspot.gserviceaccount.com member in IAM.
It has a pletora of other members (for example: PROJECT_NUMBER-compute#developer.gserviceaccount.com, PROJECT_NUMBER#cloudservices.gserviceaccount.com, service-PROJECT_NUMBER#compute-system.iam.gserviceaccount.com, etc) which I guess are legacy members used in previous versions of Google App Engine.
Adding PROJECT_ID#appspot.gserviceaccount.com with the role Editor fixed the issue: now the new version can be deployed to the old projects and it works fine even if the datastore has not yet been converted to Cloud Firestore in Datastore Mode.
I just ran into this issue and spent way too much time troubleshooting it. Nine times out of ten if you're running into this issue it's because the default App Engine service account doesn't have permission to edit Cloud Datastore. The default App Engine service account is used by default if you're doing a simple gcloud app deploy and nothing else fancy. I solved the problem by giving the default App Engine service account the roles/datastore.owner role with the following:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:PROJECT_ID#appspot.gserviceaccount.com" \
--role="roles/datastore.owner"
I'm new to working with back-end, but have been running into issues trying to get my iOS app to connect to my PostgreSQL DB.
I have developed an app with Swift which is a game that I want to run locally on iOS devices. I have a PostgreSQL DB set up in Google Cloud Platform but I cannot figure out how to get the Swift app to connect to my PostgreSQL DB.
I've read some about using Vapor or Perfect to run the application using Googles App Engine but I'm not sure that is what I want to do since I want the app to run locally but there are a few aspects of my app that I need a global database for.
Would anyone be able to point me in the right direction of how I need to connect my Swift application with Google Cloud's PostgreSQL?
Your question is pretty much very similar to this one.
In short, the correct answer is you shouldn't connect your client side application directly to the database. Instead, you should build a service that can connect to the database, and act as a service between your application. This helps prevent any unauthorized queries to your database and provides better performance. If you wanted to do this on GCP, you could look into something like Google Cloud Functions or Google Cloud App Engine to act as a service.
An alternative would be to use a "Database-as-a-Service" like Cloud Firestore. This is a scalable, pay-as-you-go service with great mobile support.
Yeah sure you need a server, ruby on rails to connect to your Postgres database.
The server will facilitate data back and forth from the Google cloud Postgressql
I am trying to add AWS Cognito to my iOS application using AWS Amplify. The docs suggest to use amplify add auth on the CLI, but this does not seem to work with an existing User Pool (i.e. you have to create a new one). Is it possible to integrate AWS Cognito into my iOS (Swift) project using an existing User Pool?
Amplify CLI doesn't support existing resources at the moment but you can manually edit your awsconfiguration.json to include the User Pool that is already present as outlined here.
Update: Since 2020 Amplify allows you to use existing User Pools (yeah!). Just run:
amplify import auth
Source: https://aws.amazon.com/de/about-aws/whats-new/2020/10/use-existing-cognito-user-pools-identity-pools-for-amplify-project/
I'm hooking up Filepicker.io to my meteor app for file uploads. That service has an API key which (of course) they recommend keeping secret. I've found a couple other sample apps on github where the filepicker secret is in plain site in the client code. That just seems a little shaky. And even if it's not in a public repo, since it's specified in client code, I can grab the key from the app using the Javascript console (if I wanted it).
I wonder there is a way to stash secrets along with an application (like heroku config) that would make it easy to keep that key secret.
My current plan is to put the key in the database and lock up that model so it's only available from server code. Is there a simpler way?
Thanks for any pointers.
The devel branch (soon to be in 0.5.3) has a new Meteor.settings feature: if you pass a JSON file as an argument to meteor run or meteor deploy, the object will be available on the server as Meteor.settings. (With meteor deploy, this is persistent so that you don't have to remember to pass it each time.)
(If you're using your own hosting environment, you can pass the contents of the JSON file in via the METEOR_SETTINGS environment variable.)
Using the database works too --- that's how Meteor Accounts stores configuration for OAuth accounts. My personal opinion is that Meteor.settings is best for app configuration, whereas the database is best for package configuration, since that allows packages to show an interactive configuration widget on first run like accounts-ui does.