Does anybody have any good solutions for doing messaging on a Realm Object Server?
I imagine one solution is to have a public realm in which every user has a PublicProfile object. Then users can "message" other users by editing other users' public profile. This seems unrealistic, however, because users would be constantly syncing all of the changes to this public realm despite most of the information being irrelevant to them.
One big public Realm that is shared between all users would, in principle, be one way to achieve the result. This has various drawbacks. One of them is, as you mention, that all users would download everything. Another drawback is that there is no privacy or security. Anyone could pretend to be anyone else, and anyone can read anyone else's messages.
A better solution would be to have one Realm per set of users that need to communicate. The Realm would act like a channel between two (or more) users. You would need one big public Realm where all the channels were broadcast. Also you would need to set permissions on the channels.
So, when a user wants to send a message to someone else, they first check if the channel exists. If not, the user creates and distributes permissions for the channel Realm. The user also broadcasts the existence of the channel in the common Realm. All users listen for changes to the common Realm and start sessions with their own channels.
Related
Is this a common/reasonable Use case?
An app allows a user to save favorites locally so that the user doesn't need to signup.
Then the user afterwards desires to share their favorites.
Therefore favorites data needs to be synced from local to remote. The usual local storage for flutter is sqflite, and firebase/store is the remote. However, this seems cumbersome, as sql to nosql conversion is necessary.
I thought that this would be a general issue for UX etc, but I can't find any discussion of this issue? Maybe forcing the user to create an account is the most general solution?
It's a common understanding that if you don't have user account then you can't have any user data associated with your name. You don't have to force the user to have an account or lock them out.
When they favourite something just show a dialog telling them "If you don't have an account your favourites are stored on the device only. If you want your favourites to be available everywhere please create an account" then show options for "Create account" or "No, Thanks"
Create account: Goes to account creation page
No, Thanks: Adds the device to the favourites list and lets the user continue to do what your app does.
There's no problem to solve here from what I'm seeing. If you don't have an account you don't get account functionality. If you track users without them entering anything it's also a little bit illegal and creepy so no need to push the limits on how you can track the same user.
Another way to think of it is to make signup so easy they don't mind and also guarantee that it's worth it. Won't be used for spam or information selling. Take what's app as an example, even though you need to mobile number to send the messages, it's just used as a unique identifier and has nothing to do with the device's number.
Ask for their phone number or email or just any email, you'll most likely get fake info.
And what does your analytics say? Are you getting requests from users saying they lost all their information on a different device? How many people are using your favourite functionality?
I may have come to the party a little late here but here's my 2 cents worth.
The Sql to NoSql conversion is not cumbersome. In fact, there is a reasonable use case for this. I have the same requirement for an app that I am about to build.
Anyway, to store data in RDMDB or NoSQLDB you will need a data model to ensure consistency in your app. If the user has been using the app offline, and they later choose to go online, you can allow them to create the Remote Account, then check if they have local favorites. If they do, you will HAVE to ask them if they'd like to import them into the remote storage. If they choose to do so, you will then have to read their favorites from the local storage and store them in a List<Model> then map() that back to the online storage.
NoSqlDB can accept the json type data, so your model should include the conversion fromMap() and toJson() for this purpose (and others).
When I have come around to doing this, I will share my code (if I remember to come back here).
I am creating an Unity game where I want to have global top 50 score list with usernames. I use Firebase realtime database. There is no need for user to authenticate. I am not that familiar with database security and pretty beginner with this concept. I am using Rest Api from Unity Asset store because it was pretty easy to send and get data from databse.
How can I be sure that every score sent to database is from my app?
Add a dedicated user with password to your database
Somewhere in you app, add those credentials e.g. in a ScriptableObject / in some component
Always use those credentials to authenticate
Note that your app can still be decompiled and thereby cheated.
You can at least make it more difficult by encrypting the data etc.
The only way really around is to have an account and sessioning server to assure a user is locked in with a valid session.
If you don't use Firebase Authentication, you can't restrict who can access your database. Anyone will be able to issues a query, and they can even do it using the Realtime Database REST API. All they have to know is the name of your project.
Even if you do use Firebase Authentication, anyone may still effectively authenticate and access the database outside of your app using other public APIs.
My experience is that you can't stop dedicated "users" from cheating global at high scores. I made a small handfull of trivial games for windows phone with global top 50. Even if your game is unpopular, and you obfuscate your code, and you are on an unpopular platform, and you encrypt your network traffic: somebody is going to jailbreak their phone, decompile your app, and inject their own high score into your game before high scores are sent to the global list. The only way I ever came up with to combat this was to keep track of play sessions -on the server- to make sure their scores were theoretically possible based on how long they were playing.
Disclaimer: I don't know anything about Firebase
From what I can tell, you will need to set up access for Default and Public sections of your configuration to tell the database who can and cannot access your database. Here's their documentation on Get Started with Database Rules.
In general database access, no one should know the details of your connection to a database, so all calls should only ever come from your app.
I'm trying to determine if I can use Realm DB for an app I am building and I am stuck on access control.
In the Realm DB documentation it looks like the only way to do access control is through Realms themselves, by either granting or revoking access to an entire realm. The documentation also says to try and keep the number of concurrently open and syncing realms to about 12. I am trying to build an app with a social feed where users can "follow" each other, and you could potentially follow hundreds of different users. You see very little data, just their activity, so there is not much actual data going back and forth, but you should only have access to view that data if the other user lets you follow them. I am thinking of it being like each user having a "private" realm and a "shareable" realm that they can grant other people access to. Is there any way to do this with Realm DB that doesn't involve syncing hundreds of different realms?
At the moment, there is no other way than syncing hundreds of Realms.
There will be another way in the future where you can use partial
synchronization.
https://realm.io/docs/java/latest/#partial-synchronization
I really need some expert help here!. Does anybody knows of a way of getting the list of the users currently connected to a BlazeDS server? Is there any built-in mechanism of knowing this? or do I have to implement some kind of server side logic every time a user access my Flex application and store all logged in users details somewhere and retrieve them later?
The nearest thing I can think of, using BlazeDS, is to obtain a list of clients currently subscribed to a destination, but this won't solve the problem IMO.
First of all, you need to define a destination and make sure that all clients will actually subscribe to it (see BlazeDS documentation for this). Then, on the server, you can then get a reference to the message service
MessageService messageService;
messageService = (MessageService) messageBroker.getService("message-service");
and ask for all subscribers with the getSubscribersIds method on the MessageService instance, specifying the name of your destination. This will only returns a number of identifiers, internally generated by BlazeDS (they are also available on the client side of the connection).
To resolve the same problem, I used this approach in combination to a custom server-side logic to store logged-in users (explicitly invoked login/logout methods). Regularly looking at the subscribers can help to clean this store, because in my experience there's no way to be sure that a "logout" method will always successfully called, expecially from Flex client running in the browser, while BlazeDS will automatically take care of cleanup of the subscribers.
I don't like very much this approach, probably someone came up with a better solution..
I have a web application, where users will see notifications for their new messages, I want to push the notifications to the users who are already logged in.
I have seen that I can do it using Server Push of PokeIn, I have tried and understood the simple application using it, but I am not getting the ClientID thing.
The ClientId it saves in "OnClientConnected" is a simple integer, so how does it recognizes clients and calls functions on them ?
Also, it is written that it uses a hybrid long polling approach, can somebody please explain me what is this?
I will not be able to implement without having sufficient knowledge of it.
Does saving the ClientID in the database for logged in user and then pushing data using this will do ?
UPDATE:
Even from requests within the same
browser window or tab, the ClientId
received every time on every request
is different, so I had to include the
Handler in my master page and on every
request, I had to map the ClientId
received to the Logged In user, so
that I can send messages to him.
Can't I just map the (ClientId to
LoggedIn UserId) only once on LogIn
and then use that same ClientId to
send him messages ?
ClientID represents the identification key of the specific client view of your application and subject to change on each time.
It helps you to manage and target specific views by keys. On the other hand, you can still use ASP.NET session ids with PokeIn client ids.
The only difference is, if any user opens your application on the different tabs of same browser, each tab will have a unique client id. Actually, this is a great
functionality you may need. On the other hand, PokeIn also notifies you when a client is disconnected (almost instantly)..
You may reach session id by the client id;
CometWorker.GetSessionId(string ClientId)
or client ids for a session id by;
CometWorker.GetClientIdsBySessionId(string sessionId)
Additionally, if you don't want to use client id system (which is very useful), you may choose the "Joint" option. It helps you the send and receive messages from
the client with the name you have defined. (There is a sample for the "Joint" feature in here)
Because PokeIn provides various connection options, you don't have to think about the approach behind it when you work with PokeIn. It simply provides benefits
from the various solutions. More information can be accessible from : "FAQ" and "Advanced Tutorial" (http://www.pokein.com/Help/AdvancedTutorial.aspx)
At last, you don't have to save PokeIn client id to the database. PokeIn manages your server side objects per each client efficiently.
I suggest you to check the samples and tutorials.
As an answer for your update, you are free to use Joint feature of PokeIn when you need shared server side instances for the clients or consistent naming for the clients.