I'm considering using Firebase as the main database for mobile based social network including only mobile clients (android, iOS).
In the scenario of social network where each user is exposed to only limited amount of data within its friend circle Firebase actually works quite well. However I have certain concerns I wan't to clear up before any heavy lifting starts.
I have the messages and chat functionality where users can message to all his friends or selected friend group. Since each user have slightly different friend circle, the message (or notification with the reference) needs to go to each friend.
My concern is if the user has 500 friends this would within the app generate 500 push requests to firebase with 500 different urls.
Alternatively I could store the chat/message in one place however receiving the message would mean to scan 500 different urls (all friends) to get the latest messages in the phone. Either way I end up with the same.
Do I have to be worried about app performance?
My second thought was to build the proxyserver which would take care of pushing notifications to friends so the app would send only one request for the server to push the message to all friends individually. But this would add up extra development work thus the cost to the project.
The answer is to de-normalize your data and put messages in people's inbox at the time they are created. We built an app called Firefeed to showcase this approach: http://firefeed.io/.
The basic concept is to create several copies of a message at creation time and send a copy to each of the recipients "inbox". Of course, this means that a sender cannot edit or delete after it is sent, but this might be an acceptable trade-off in most cases. (Note: It is technically possible to edit/delete a message, but it's a very expensive operation since you'll have to traverse your entire network to find the copies).
There's more about how to de-normalize your data in this blog post: https://www.firebase.com/blog/2013-04-12-denormalizing-is-normal.html
Related
So I have a project that I'm making which is An Android Application, which takes provides information taken from API Server (Laravel 5.x) and also provides live-chat feature
What I'm not sure of doing is how to handle the live-chat feature. Currently here's how the chat system works (keep in mind, there is also a Web App which provides the same feature, that I'm willing to change) :
User type chat and sends it. The client (Android app or Web App) sends it to the API Server. which then saves it to the database.
Then the API Server (which is connected to mysql database server) sends in email / notification which based on the other user's configuration.
When the other User opens the chat, it will call the API Server (which is connected to mysql database server) asking if there's an update every 3 seconds.
if there is, then (Android App or Web App) will show the new chat.
Now first of all I know that this is not efficient, bad on performance, etc.
Now I want to try and use firebase database for realtime chat.
Now, I really want to use the API Server for logging and storing Chat info inside my own database because of some legacy Android App which takes a long time to work on.
which is the better scenario :
The Android App directly sends new chat information to Firebase Database
The Android App sends new chat information to API Server. Then the API Server sends it to Firebase Database
Is there a better way to do this
so which is the better way to do this?
I would highly recommend using the firebase firestore. It sounds like it would solve the best of both worlds. Nosql json storage format is great for a chat app. Also the data is "live" so it will loosen for a change and update the user sides data. Saving you the 3 sec call resources. Last I checked it was still in beta but I used it top make an app that lets you create plus and live pools and it wad pretty smooth. It does take a bit to wrap your head around though.
I am developing an app which can be used for sharing location between 2 or more devices. One can be a publisher and other can be a subscriber. I got the first part done where I have an app which can read current lat-long from the device.
The second part is to publish it a repository (which is accessible on the internet to other devices also) so that other devices which subscribed to feeds of this device, will get such values and then render location on their devices. i.e. Bus Sending it location and people can subscribe to it to check when it will come near their home so that they leave office to reach bus stop just before 5 mins left for the bus to arrive at their stops.
I am looking where can be the best place to put such date where many devices can read and write (kind of online cache) for my application.
Maybe something like Firebase Realtime Database. Google Cloud Storage is not a good backend for something like this since it doesn't provide synchronization, and it would be hard to separate and authorize access to this privacy sensitive data.
Currently I'm working on the MQTT based Chat application where I need to assign
Unique Topics to Users dynamically.
So, I thought of using their IMEI/MobileNumber. But in iOS, we cannot get the IMEI Number so we thought of generating a random IMEI from the backend and assign it to the Users.
Now, My problem is whenever user changes his mobile, the IMEI Number changes and it will be fresh profile again to that user.
If I use based on his Mobile Number, there is a chance when the user doesn't use the sim for 3 months. The connection automatically terminates from the network provider and the same number will be assigned to another new customer(atleast here in india).
Can anyone suggest me a good approach for the Topic Generation?
BTW, I need a Web Chat also and that need to be fetched from database. that is the only reason, I'm focusing on the Topic Generation. So, I will fetch messages based on his topic and show them in the Web Chat.
Do anyone know, how whatsapp maintained their topics?
I thought of using their IMEI/MobileNumber.
Bad design. Have the user create an account (i.e. email) with a password for your service that way no matter what phone or phone number they have, they can still log in and use your app. And make sure you ENCRYPT the user credentials in your database. Start FIRST by building an app with proper security or else you will be hacked 5 minutes after you launch it.
Do anyone know, how whatsapp maintained their topics?
Just because Zuckerberg copies everyone else, doesn't mean you need to copy them. Also, I believe whatsapp created there own version of a MQTT Broker. Hence, it will have an entirely different set of functionality from a regular MQTT Broker.
I'm developing an app which list the shops around my area by category. I have a REST API where the results would be returned in paginated mode (page=2, limit=20 etc) and users will need to login to the app in order to view the listing.
I'm thinking to incorporate offline 2 way sync into my app. The moment when user logs in for the first time he has to be connected to the internet and subsequently once he has logged in he should be able to proceed straight to the main screen eventhough the app is offline.
User also has the ability to post a review offline in which I suppose we should cache the post request in the DB and listen to network state changed event? Once there's a network then query everything in the cache and send to the server.
I understand how this can be achieved at high level but I'm still new to Android and not exposed to the popular libraries out there. Just wondering is there any library that is already doing all the magic for me?
I stumble across Sync Adapter and Content Provider but it seems like they are quite complicated to a beginner. Is there a simpler library that can achieve similar results?
Also from my understanding the way how it works would be.. there will be a service that periodically poll server for changes - and fetch when there's any then store into SQLite. On poll it will also retrieve client changes and send to server. When user views listing the app will retrieve from SQLite instead making request to the server - there is no direct interfacing between the App and server. Can anyone verify if my understanding is correct?
I'm looking for suggestions for ways to share Android app data between phones running the same app. For example, lets say I have an app that stores a database of book reviews. If person A has a book review that person B doesn't have, what are the options for getting that information from person A's phone to person B's phone?
Currently, I'm aware of the following options:
- Upload data from person A's phone to a server, then download data from server to Person B's phone.
- Write code to have the phones sync up using bluetooth
- Write code to send SMS messages
I'm wondering if there are any more options besides these, and if there's actually a best-practice for accomplishing this?
Ideally, I want the users to simply click a button in the app to make the sharing take place, so I don't want to go down the bluetooth route because that requires the user to do a bit of setup (or assumes they already have set things up in the form of bluetooth settings).
Since the data can be of variable length and potentially large, I believe that would rule out text messaging.
As far as the server route goes, from what I understand this seems to be an ok way of doing things, but my problem is that I have no experience with having users potentially sign in to a server and then uploading data. I don't know of the cost concerns (if any), or of potential security concerns (allowing just anyone to upload data, I'm not sure if I would have to take steps to ensure someone couldn't bypass the app and upload malicious data).
So, can you guys give me suggestions and point me in the right direction? Thanks.
I'm wondering if there are any more options besides these
You could try generating a QR code and scanning it on the other phone. Beyond that, I think you have it mostly covered.
and if there's actually a best-practice for accomplishing this?
That is impossible to answer in the abstract.
Keep the database server side and interface with it via a web service
I too am looking for a solution to this very problem. I'll throw it out there that a fourth, or rather extension of your first option, is to use the Cloud to Device Messaging Framework, though it still requires (as best I can tell) having your own server, though I suppose you wouldn't need to store the database server-side longer than it takes to send the message, provided you keep it under 1024b (or whatever the actual size is).
I don't believe there is a convenient way to monitor/send email in the background. If I could have my app monitor email messages looking for a key subject, then parsing the body, I could probably accomplish what I'm looking for using email as the transport.
The problem with maintaining a server, is that you probably would need to build in a subscription fee to your app to cover the costs of maintaining a server, as one time sales may not be able to cover the ongoing expense.