Sharing data among app user using Realm Mobile Platform - android

I have a question about users accessing data created by another user. I will explain below with a case study.
I am using Realm Mobile Platform. The app uses Realm Auth to allow users to register by email, google and facebook account. At this moment I am using as a REALM_URL: ...":9080/~/name".
I will try to explain what I would like to achieve with the following example.
Imaging that I have UserA and UserB. Once the users have registered in the app (using SyncUser), they would be redirected to a project activity. Each user would be able to create their own projects. Before Realm Mobile Platform (Realm Mobile Database), user data was stored in user devices. Now, because I am using "~" in the REALM_URL, when users entered in the project activity, the activity requests and shows all the existing projects for that user.
The app has another activity with a search functionality where users can search for public projects. For example, the UserA makes public Project1. UserB should be able to find Project1 and follow it, or ask the owner to become a contributor. Once the UserB follow or get access as a contributor, Project1 should be shown in the Project activity of UserB.
The question is how to make this possible.
Option A: Use a unique and common Realm for all users.
Deleting the "~" from the REALM_URL and adding different fields like "ownerID" to the project RealmObject and a list of subscribed projects to the user RealmObject. This will allow user to query to all the projects (owned and subscribed) in the project activity and search for public projects in the search activity.
Option B: Use two realms, one private for the user data, and one public for projects.
The private would have a REALM_URL including the "~" and the public will be absolute. Later, when a new user sign up the app would give privilege (mayRead, mayWrite, mayManage) through the Access Control.
Which one would be a better option? Is there any other better option?
Thanks

The answer to your question is, it depends. The Realm Mobile Platform (RMP) will automatically handle all of your data sharing, conflict resolution, and syncing across the users. In this way, RMP acts as a server and single source of truth.
Both OptionA and OptionB will require this single source of truth and some knowledge of user access control.
Let's go through the pros and cons of each option.
OptionA:
Pros
Only one database, conflict resolution is done by Realm
Significantly less work on the mobile side, you just listen to
the server
Cons
Potentially difficult to do user access control
OptionB:
Pros
User's private data is completely separate
Cons
You will be responsible for writing the data conflict resolution between the local database and the server
Your app will most likely be larger due to storing multiple databases.
In my experience, dealing with database conflict-resolution yourself is truly painful. It seems like OptionA is by far your better option.

Related

How should i handle Rest services for 2 apps same database

I have an application server running some rest services for management, filling the database and is all setup, but i also have an android app that only search through that database for 2-3 columns for each table. My question is, should i create two models in the same server? I mean like Model, repository, controller and assemblers for managing app and android app or, should i use only one and handle only the info i want in the android app. I think for security reasons there shouldn't be risks of info leaking.
Edit: Well i ended up creating Object and response/ObjectApp in my server for now to send data. Hopefully someone knows how to properly handle this and tell me if i did it right or if i should change it

Utilizing Realm Object Server for a collaborative application

So for the past few days I have been reading through the Realm documentation and I am very excited to use this data synchronization solution in upcoming projects. After using standard database schemas (SQL, Firebase, etc). I am still not fully understanding the best way to utilize Realms. I see Realms are meant to be very flexible, but there are not many examples or docs of how to set up and efficient structure.
So, I wanted to just provide a simple collaborative app idea, and show my first thoughts on how I would set up the Realms. For simplicity, lets say this is a messaging app that contains chatrooms. Users can create chat rooms and the owner of the room can invite people to their room. Once that user is added to a room, they will have read/write access to the room.
My current structure:
1) A realm for each user. (/Users/uid) . Each one of these realms will have public read access and write access only for the user that owns it.
2) A realm for each chatroom. (ChatRooms/uid) . Each chat room will hold the various models pertaining to that specific room (messages, likes, notifications, etc). Initially only the owner will have read/write access, everyone else will have no access. The owner can then start handing out read/write permissions to the users they invite.
3) A public realm that holds mappings of a user to a chatroom. (ChatMembers). This realm will hold models that have two attributes, a user id and a chatroom id. A user can query this realm by there id to see what chatroom realms they will have access to.
I feel this is a very basic structure, but I am still not positive if this is utilizing Realm to the best of its abilities. Also, if anyone can lead me to some better documentation, please do. Would appreciate anyones feedback!!
Refer to: https://docs.realm.io/platform/getting-started-1/android-quick-start/step-4-chat-room-permission-api
Here they have used the permission API and partial sync,to design a chat app that enables the user to create public and private chat rooms.
I would also recommend you to follow the previous steps also mentioned in the above link, to have a basic understanding of how realm works.

Right architecture for a partly shared realm

I'm currently working on a Tinder-like app, where users get recommandations of other users, that are chosen by some algorithm. Each user will have it's own user specific realm, but this data will also be shared as the other users get this user as a recommandation. From what I have read, the shared realm will automatically get duplicated on the local devices of each user, which I definitely don't want.
So how can I now have a pool of users, but only share the calculated users by my algorithm to each user separately?
I have read some other threads about this topic also had a look into 'Designing a Database: Realm Threading Deep Dive', but at the moment I have no idea how to design my realm environment. Thanks
At the moment, the recommendation is to split the data into separate Realm files and move it between Realm files on the server in your own code.
We realize this is a bit cumbersome, and are currently working on better ways to achieve fine-grained sharing of data between users with object-level permissions. Stay tuned in the coming weeks and months.
Until then, duplicating the data into user-specific Realms is the best way forward.

Share lots of data between android applications using internal storage?

Background: we are porting an enterprise system to have android clients. The architecture for windows and html is based around a core library that does the hard business logic but no user interaction at all, and we use programs or single page web apps to provide the user interface and simply call the core API library to actually do stuff.
The "core" is implemented as a shared library on windows and built into each app. If we mirror this and use a java library, we need to share files using external storage, which is a not permitted as data needs to be reasonably secure. (Nb data is binary data, not Sql database, in case that is relevant)
So we thought about using a bound service, and using intents, content provider etc, but it seems (from googling) we must then distribute the background service separately the user interface app, but this seems terrible experience for new users. However, a bound service seems ideal from all other angles.
We also cannot guarantee which apps a user might download, we will have at least 10 individual apps all doing logically different things, but referencing similar data.
In brief:
lots of individual apps all wanting access to same data
no control over which apps are downloaded
using external data is not permitted as data should be semi secure
using sqllite might not work as data is long binary chunks ( eg 3Mb plus ). (Ref: How to share data across a group of applications in Android )
some data files are big and do not want every app to download a private copy
some data changes dynamically, say every 15min
core business logic is big and complex, cannot be distributed in source form, lib/jar ok though.
the windows solutions all use network IO to an application server, but we want to avoid as much network traffic as possible by storing data locally.
How can we bundle a bound service in each and every user interface app we distribute? Or is there a different way to approach this whole design?
I think that there is a few number of options that you can explore:
1) I never have done this before though this seems possible as Android is package based.
First you need to use the same main package across all your apps though each app must be in a separated sub package, e.g. : main -> au.com.myapp.main and the app actually have it's first screen on app1 -> au.com.myapp.main.app1 .
Create on your main app a method(s) that will look for those extra packages (within your project), as it find something you create a trigger that will display a item on the menu. Each app should have the same main packages and main activity, as it will be responsible for enable the user have access to the others and all of them can share the same preferences, files folders and Database.
When installing the same packages should be overrides though those different ones should keep intact. You should have all the 'main' classes for each app, not the real main one declared on your manifest (that will be quite big depending on the amount of activities in all your apps) with those packages.
2) You can using Spongy Castle, create a shared zone (folder) where you create the DB and write your settings or files, encrypting everything with a key (strong one or using RSA) that might be made by the user or provided once for your company at the very first run. You must decide how to handle this.
3) You also can use the share id in all your apps and each app before run perform look up for all packages (it's possible to do) to know and if and what packages exist to check if there is a DB with data in that package.
4) Not really nice though create a background service that keep updated all tables in all apps (sharing id or using content provider), you can user AlarmManager to trigger it in intervals rather keep it on at all times and you have all apps.
My last project had a similar requirement though as the user had to login to do anything, I opted for the option 3 and each data pertinent exclusively to each app went the app DB.
I hope this helps.

What would I need to do in order to connect to a central database with Android?

I'm about to build a GPS Spot Finder application with Android and I am trying to decide what requirements are feasible and what aren't. The app would enable users to essentially add different spots on a Google Map. One of the problems would be fetching the data, adding new spots, etc, etc. This, of course would mean the database would have to be online and it would have to be central. My question is, what kind technologies would I need to make this happen? I am mostly familiar with XAMPP, PHPMyAdmin and the like. Can I just use that and connect Android to the database? I assume I would not need to create a website...just the database?
What different approaches can I take with this? Be great if people can point me in the right direction.
Sorry if I don't make any sense and if this type of question is inappropriate for Stackoverflow :S
Create a website to access the database locally, and have Android send requests to the website.
If users are adding spots to a map that only they see, then it makes sense to keep the data local to Android using a built-in database (SQLite). That looks like
ANDROID -> DATABASE
You can read up about SQLite options here.
If users need to see all the spots added by all other users, or even a subset of spots added by users, then you need a web service to handle queries to the database: Connect to a remote database...online database
ANDROID -> HTTP -> APPLICATION SERVER -> DATABASE
Not only is trying to interface directly to a database less stable, but it may pose risks in terms of security and accessibility.
Never never use a database driver across an Internet connection, for any database, for any platform, for any client, anywhere. That goes double for mobile. Database drivers are designed for LAN operations and are not designed for flaky/intermittent connections or high latency.
Additionally, Android does not come with built in clients to access databases such as MySQL. So while it may seem like more work to run a web service somewhere, you will actually be way better off than trying to do things directly with a database. Here is a tutorial showing how to interface these two.
There is a hidden benefit to using html routes. You will need a programming mindset to think through what type of data is being sent in the POST and what is being retrieved in the GET. This alone will improve your application architecture and results.
Why not try using something that is already built into android like SQLite? Save the coordinates of these "spots" into a database through there. This way, everything is local, and should be speedy. Unless, one of your features is to share spots with other users? You can still send these "spots" through different methods other than having a central database.
And yes, you just need an open database, not a website, exactly. You could technically host a database from your home computer, but I do not suggest it.
If you are looking at storing the data in your users mobile nothing better than built in SQLLite.
If you are looking at centralized database to store information, Parse.com is a easy and better way to store your user application data in centralized repository.
Parse.com is not exactly a SQL based database, However you can create table , insert / update and retrieve rows from android.
Best part is it is free upto 1GB. They claim 400,000 apps are built on Parse.com. I have used few of my application typically for user management worked great for me.

Categories

Resources