Sharing one global reference Realm between two users - ios

apologies in advance if this is trivial, but I only have about a month’s worth of experience in Realm and Swift (but I’m not new to programming in general), and I’ve devoted for literally dozens of hours trying to find a solution.
What I am trying to make: An app that retrieves price data from a single, global realm, /Companies, in a Realm Cloud instance, then graphs it. I need exactly two users to have access to the global realm. One “user" who periodically (every few months) updates the data (but does nothing else), and one user who can read and graph anything that the other user puts in /Companies.
Note: The app works as intended if it's using only a local database, but I’m fairly sure this means that it can’t be updated.
Apparently, this is an extremely complex goal, because I cannot find a single example of something like this. I have tried so many “Permissions" and multi-user examples from the realm.io.docs and every site multiple pages into Google, but everything is on how to create private realms or restrict additional users from seeing an existing realm, or they do not explain how to just create a user and let them access a realm in the Cloud. There are a few hundred objects in /Companies, so doing it by hand using Realm Studio is not practical. Could someone please explain how to hard code just a single global realm with two users?
This is really stupid that I’m having so much trouble with this, but I’m completely stumped. I don’t need the app to be adaptive, I don’t need any fancy UI, security, restrictions, none of that. I just need to be able to update some data from a separate entity--Realm Studio, a macOS app, an ios app that never leaves the computer-- whatever, so that the client iOS app can see and use the new data.
If someone is able to provide a solution, I’ll probably cry out of gratitude, I’m so exhausted and frustrated.

As far as I can tell, you simply want one user to update and one user to retrieve and use the updated data. I suggest the following two cloud solutions:
Firebase
One solution could be to use a backend, say Firebase, that will be used by the one updating the Realm - Jared Davidson has a decent tutorial that will get you started.
Realm Platform Cloud
Furthermore for a simplified and powerful solution, you could use Realm's own cloud service, Realm Platform Cloud, having a 30-day free trial followed by 30$/month.

Related

Firebase vs Parse (What are actual examples of apps when Firebase is preferable?)

I am trying to understand WHEN Firebase is preferable (in terms of the types of apps you would choose Firebase for instead of Parse Server... not just the keyword characteristics)
I have read atleast two dozen articles on this subject as I am trying to gain a confident / solid understanding of the benefits of when you should choose firebase (perhaps over something like Parse).
The benefits I see at the top of many lists are "real-time updates" and "scalability" but I don't really understand the context of these terms or there ACTUAL benefit here.
How is Firebase more scalable than Parse?
And why are "real-time updates" so attractive to some people? To me all I notice is that in the Firebase DB Console I can see the information on the screen immediately without hitting refresh when something is written to the DB. That's cool but how is that a main benefit? Doesn't seem all that special to me, but maybe I'm missing something here? This article (https://www.anexinet.com/blog/firebase-real-time-database-benefits-overview/) mentions its beneficial for Chatting services (maybe whatsapp?). What other use-case/apps would be beneficial for real-time updates?
The articles(such as https://medium.com/one-tap-software/firebase-pros-and-cons-ce37c766190a) might say something like
"JSON removes a lot of the constraints from the RDBMS in favor of
scalability and standardized data containment."
To me, learning NoSQL has been a challenge, as I come from a Relational Database background where data redundancy is a no-no. I feel like I have had to do a lot of annoying overhead to get the same querying functionality I could get from a RDBMS like MySQL using Primary and Foreign Keys and two or three tables.

What are the advantages of Core Data over Firebase realtime database when offline mode is activated?

My question might seem a bit naive, but as a beginner iOS developer, I'm starting to think that Core Data is replaceable by firebase realtime database (or firestore in the future). I used both of them in two seperate projects and after activating the offline feature in firebase, I got the same results (that is, the data was saved to the device without the need for an internet connection). I think I read something in the firebase documentation about it not being able to filter and sort at the same time which would probably mean that Core Data can be more convenient for complex queries. It would be great to have some senior developers' views on this subject.
Thanks in advance.
The question is a bit off-topic for SO (IMO) and is (kind of) asking for opinions but it may be worth a high-level answer. I use both platforms daily.
Core Data and Firebase are two unrelated platforms used to (manage and) store data; it's hard to directly compare them without understanding your use case.
CD is a framework used to model objects in your app. It's the 'front end' of data storage, where the 'back end' could be SQL, flat files, plists etc. It's more of a single user concept which stores data locally on the device (it has cloud functionality but that's a different topic).
Firebase on the other hand is a live, event driven, cloud based, multi user capable NoSQL storage. While it offers off-line persistence, that's really for situations where you need to be interacting with data when the device is temporarily disconnected from the internet.
It is not correct that:
firebase documentation about it not being able to filter and sort at
the same time
But, your Firebase structure is dependent on what you want to get out of it - if it's structured correctly, it can be filtered and sorted at the same time in a variety of very powerful (and faaast) ways.
Core Data is really an incredible technology and building relationships between objects is very straight forward and has SQL-like queries for retrieving data.
If you are looking for a database that leverages local storage - go with Core Data or another database that's really strong locally such as Realm, MySql and a number of others.
If you want to have Cloud based, multi-user, event driven storage, Firebase is a very strong contender (Realm is another option as well)
I would suggest building a very simple To-Do type app and use Firebase for storage in one and then build another using Core data. Should only be a couple of hours of work but it will really give you some great basic experience with both - you can make a more informed decision from there.

Swift caching data using Apollo Client and GraphCool Backend

First of all: I am a beginner to swift, so please excuse, if my question seems to be obvious to many people, but i could not find a satisfying answer for me, after doing some research on the subject "caching".
I have a very simple GraphCool Backend setup (using GraphQL query language) and Apollo:
https://github.com/apollographql/apollo-ios
on the client's side in my swift project.
As my database is going to grow over time, i am already thinking about how to preserve data volume for my users when making GraphQL-queries, i.e. i do not want to fetch all the data, every time the user restarts the app, but instead cache some data in local storage. Since i am already using apollo, i would like to know if apollo allows caching on local storage, or do i have to use a third party library to do that?
I am aware that there are 'cachePolicy' options in Apollo, but as i understand them, they are only for memory caching.
(I did not present any of my app's code for this question, because i don't think it gives any additional benefits as my question is basically about caching in Swift.)

Is it good practice to store items retrieved from a web service as Core Data objects?

I've heard of iOS developers retrieving items from a RESTful web service and storing them as Core Data objects right away. I can see why that may be useful if you want to save or cache these items so the user can see them later (e.g. Facebook feed), but are there any other reasons to do so? I have items in my web service that are invalid within an hour, so caching is out of the question. If it's a good practice to do so, why?
For me, there are 2 reasons to stock datas in local:
Better UX: first, show old contents, then do an update in background for example, then update your application UI when new contents are availables.
Work offline whenever online mode is impossible.
Even if your items are invalid within an hour, if you do not cache items in local, your application has to call to webservice to retrieve these items, and it takes time.
Caching almost never hurts and CoreData is a very nice way to cache data which comes in as a pile of similar records.
I am one of those devs you mentioned who store almost anything using CoreData. Because I do, a lot of useful code and selfmade frameworks has summed up over time which make working with CoreData and RESTful apis a breeze. And if connecting an api to CoreData is just a matter of a few lines of code, there really isn't any reason not to.
While I cannot share my libraries, I'd strongly recommend taking a look at RestKit, which does pretty much the same - mapping a RESTful api to CoreData. And if you're not used to CoreData yet, fear not. It is a very powerful tool and getting used to it is definitely worth the while!

When creating an end to end iOS app, should the front end or back end be created first? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been a developer for 10 years (non iOS), and working for a large company have never created applications end to end. Just worked on very large applications, on pieces.
I'm starting to get into iOS for fun, and have an app in my head that I want to create. I've wireframed the entire thing using the iOS app 'interface'. Since then, I've begun to start coding. I have about 15 scenes in storyboard (the total app will probably be 100+), and right now I'm just using hardcoded 'fake' data.
However, I've recently begun to think that maybe I should be creating the database and some initial data there instead of using all this hardcoded fake data.
Does anyone have any suggestions and reasons why one way is better than another?
Should I create the back end before the front end? If I do, then each new scene I add I can work the real data in from the beginning instead of having to replace fake hard coded data.
Also, I know little about creating back ends. The application I'm creating is nothing like twitter, but for data access and for this example, let's say it is. It's main view of the application is something like twitter. The user can hit refresh and get many new data points ('tweets' in twitter) from the server. So the application could be very data intensive. Am I best off using something like Parse and paying for their services, or creating something in LAMP, or something else. I've worked with SQL and database a lot in my last 10 years and am very comfortable with that aspect of the back end.
Thoughts? Suggestions?
Thanks!
I'd say you have 3 options here :
Front-end first, back-end afterwards
Good thing is while developing your front-end, you may understand what's really relevant and what isn't. You probably won't do anything unnecessary on the back-end part. A bad thing though is that bad stuff may happen when you try to connect you back-end to your front-end, and involve some code refactoring on the front-end side, if you don't make sure they at least can work together.
Back-end first, front-end afterwards
You may here not really see where you're going while developing the back-end. You'll see (you may even know it already) that what you'll create for the client-side may not really be as it looked in your head.. You'll probably have to rework a lot on the back-end.
Front-and-back-end together
This is how I usually work. Start the front-end just as you did with hard-coded data, and start asap to work on the back-end. Move your boilerplate data on it, just so you can make sure they communicate well. Then, try to work on both simultaneously. That way, if you change your mind about something on one side, you won't have to redo much code on the other side.
Regarding the back-end solution, pretty much all I can say is that I used Parse.com services, and it's really good. In my case, I was not ready to create an entire back-end by myself. If you can, maybe you don't need them. But, (and it's a big one), Parse's SDK can take care of the whole communication between your back-end and your front-end. You don't have to manage network availability, caching stuff, and every thing you have to think about when you develop for a mobile OS. This is very nice.
Their free plan lets you run 1M queries every month, which is quite a lot. But if you want to go further and reduce the number of requests to Parse, you can combine your own back-end and theirs. It may not work for your specific case, but you can have the user access your server to check if new data is available, and only then query Parse. For example, for a news app, have the news on parse.com, store the most recent news date on your server, save the last update date on the client device, and before accessing parse, compare the dates with your server. If needed, query parse, if not, go to the cache (handled by parse's SDK). That way you can limit the number of queries and stay in the free plan.
You should probably try to estimate the number of queries you'll have per month and the monetary impact before choosing.
Just my own opinion :]
I would suggest you to add new features to your app with the smallest possible complexity. Like e. g. "The user can see a list of all registered users." - This example might not fit perfectly well for your case, but I hope you get the point: build one small thing at a time.
But for these small things: make the full trip front and back. Since it shouldn't take you too long to complete such a feature, it doesn't really matter if you complete the frontend or the backend first. So for this part: basically what #rdurand already said ;)
Regarding the backend I see two options:
Either you create some REST-Services yourself. The choice of technilogy should depend on what you know already. I am a big fan of JAX-RS, but if you don't already have some java experience you might have hard time with this.
Use some kind of SAAS-API. I've heard some good things about http://www.apiomat.com/, but never used it myself...
Good luck ;)

Resources