I would like to use Firebase for analytics on iOS and Android app. My users are most of the time in remote area with poor or no network. I would like to optimize battery life so I don't want firebase to create web requests all the time. Is there a way to dispatch data only on command ?
I would like to have the same behaviour than google analytics with the analytics.setLocalDispatchPeriod(0); and send data only when the user is connected to wifi for example.
The SDK already tries to minimize the upload interval times to one per hour to avoid draining battery. If there is any problem with the network, it won't retry immediately but in hours later or back-off if needed. It also has several methods to optimize data latency so it won't be good to freely control the scheduling system.
Related
I am developing an Android app which basically does this: On the landing(home) page it shows a couple of words. These words need to be updated on daily basis. Secondly, there is an 'experiences' tab in which a list of user experiences (around 500) shows up with their profile pic, description,etc.
This basic app is expected to get around 1 million users daily who will open the app daily at least once to see those couple of words. Many may occasionally open up the experiences section.
Thirdly, the app needs to have a push notification feature.
I am planning to purchase a managed wordpress hosting, set up a website, and add a post each day with those couple of words, use the JSON-API to extract those words and display them on app's home page. Similarly for the experiences, I will add each as a wordpress post and extract them from the Wordpress database. The reason I am choosing wordpress is that it has ready made interfaces for data entry which will save my time and effort.
But I am stuck on this: will the wordpress DB be able to handle such large amount of queries ? With such a large userbase and spiky traffic, I suspect I might cross the max. concurrent connections limit.
What's the best strategy in my case ? Should I use WP, or use firebase or any other service ? I need to make sure the scheme is cost effective also.
My app is basically very similar to this one:
https://play.google.com/store/apps/details?id=com.ekaum.ekaum
For push notifications, I am planning to use third party services.
Kindly suggest the best strategy I should go with for designing the back end of this app.
Thanks to everyone out there in advance who are willing to help me in this.
I have never used Wordpress, so I don't know if or how it could handle that load.
You can still use WP for data entry, and write a scheduled function that would use WP's JSON API to copy that data into Firebase.
RTDB-vs-Firestore scalability states that RTDB can handle 200 thousand concurrent connections and Firestore 1 million concurrent connections.
However, if I get it right, your app doesn't need connections to be active (i.e. receive real-time updates). You can get your data once, then close the connection.
For RTDB, Enabling Offline Capabilities on Android states that
On Android, Firebase automatically manages connection state to reduce bandwidth and battery usage. When a client has no active listeners, no pending write or onDisconnect operations, and is not explicitly disconnected by the goOffline method, Firebase closes the connection after 60 seconds of inactivity.
So the connection should close by itself after 1 minute, if you remove your listeners, or you can force close it earlier using goOffline.
For Firestore, I don't know if it happens automatically, but you can do it manually.
In Firebase Pricing you can see that 100K Firestore document reads is $0.06. 1M reads (for the two words) should cost $0.6 plus some network traffic. In RTDB, the cost has to do with data bulk, so it requires some calculations, but it shouldn't be much. I am not familiar with the pricing small details, so you should do some more research.
In the app you mentioned, the experiences don't seem to change very often. You might want to try to build your own caching manually, and add the required versioning info in the daily data.
Edit:
It would possibly be more efficient and less costly if you used Firebase Hosting, instead of RTDB/Firestore directly. See Serve dynamic content and host microservices with Cloud Functions and Manage cache behavior.
In short, you create a HTTP function that reads your database and returns the data you need. You configure hosting to call that function, and configure the cache such that subsequent requests are served the cached result via hosting (without extra function invocations).
Sorry if that has been answered - I couldn't find a complete answer - as there seems to be conflicting resources.
What I'm trying to achieve is the architecture where my backend 'communicates' in real time with millions of clients through Firebase DB (RTD or FS). Kind of like what's drawn here:
The architecture in a nutshell: millions of clients write 'events' to the Firebase DB, my java server listens to these 'events', processes them and writes 'responses' to the Firebase DB that are synced back to the clients.
The question: Is App Engine the best solution? Is it even suitable for the job?
On the one hand, in App Engine's documentation there's an example of it used that way:
https://cloud.google.com/solutions/mobile/mobile-firebase-app-engine-flexible
On the other hand, there are (seemingly) known issues with that approach:
1) App Engine instances awake on http requests, not on firebase events. https://stackoverflow.com/a/38357458/1806956
Jobs have a timeout, so even if we do a cron wakeup every minute, it doesn't ensure (or does it?) that the listener will keep living forever.
2) App Engine does not support the Firebase Admin SDK due to background threads? https://stackoverflow.com/a/45046605/1806956
3) App Engine limits the number of background threads. In a real app, we're talking about potential thousands of concurrent users, all throwing events...
Are the above issues not updated? Thank you...
I've been putting together a mechanism to sync activity data collected by the MS Band with our backend via the cloud API and getting all the boilerplate setup for the OAuth flows... The intent being to periodically run this data through our backend processes to categorise periods of meaningful walk based activity.
I've been experimenting with the data available and as far as I can tell we cannot get access to the raw step data (or at a fine grained level )? We have successfully been able to request summary info by hour/day, however this is not fit for our purpose.
What I'd like is to access step data in the form [startTimeStamp,endTimeStamp,stepsTaken,...] where each record represents a continuous period of movement by the wearer.
We would also be able to work with data summarised by minute as this would give enough context to our use case.
Is this possible via the cloud API? or are there any plans to implement the Period "Minute" on the summary API endpoint?
https://api.microsofthealth.net/v1/me/Summaries/Minute?startTime=2015-12-09T14%3A00%3A00.369Z
If this isn't possible perhaps there is another way to make this data available? (via HealthKit on iOS or Fit on Android?)
As a complete alternate perhaps it might be possible to get the accumulated step data detail from the band via bluetooth in a similar fashion to the native MS Health App?
We already use the SDK to stream realtime Heart Rate data during user cardio sessions, but there appears to be no way to extract the historical step info from the band directly.
Thanks!
the Band itself monitors and logs the steps over time. When sync'ing, that log is transferred to the Cloud via the Microsoft Health app. The app then pulls the "steps for the day" from the Health service.
These logs are not exposed to apps via the SDK. The only way to calculate steps per custom short period yourself is to have your app sample the counter in the background on a frequent enough basis in order to do the calculation.
I've read quite a few posts (including the firebase.com website) on Firebase connections. The website says that one connection is equivalent to approximately 1400 visiting users per month. And this makes sense to me given a scenario where the client makes a quick connection to the Firebase server, pulls down some data, and then closes the connection. However, if I'm using angular bindings (via angularfire), wouldn't each client visit (in the event the user stays on the site for a period of time) be a connection? In this example having 100 users (each of which is making use of firebase angular bindings) connecting to the site at the same time would be 100 connections. If I opted not to use angular bindings, that number could be (in a theoretical sense) 0 if all the clients already made their requests for data and were just idling.
Do I understand this properly?
AngularFire is built on top of Firebase's regular JavaScript/Web SDK. The connection count is fundamentally the same between them: if a 100 users are using your application at the same time and you are synchronizing data for each of them, you will have 100 concurrent connections at that time.
The statement that one concurrent connection is the equivalent of about 1400 visits per month is based on the extensive experience that the Firebase people have with how long the average connection lasts. As Andrew Lee stated in this answer: most developers vastly over-estimate the number of concurrent connections they will have.
As said: AngularFire fundamentally behaves the same as Firebase's JavaScript API (because it is built on top of that). Both libraries keep an open connection for a user, so that they can synchronize any changes that occur between the connected users. You can manually drop such a connection by calling goOffLine and then re-instate it with goOnline. Whether that is a good approach is largely dependent on the type of application you're building.
Two examples:
There recently was someone who was building a word game. He used Firebase to store the final score for each game. In his case explicitly managing the connections makes sense, because the connection is only needed for a relatively short time when compared to the time the application is active.
The "hello world" for Firebase programming is a chat application. In such an application it doesn't make a lot of sense to manage the connections yourself. So briefly connect every 15 seconds and then disconnect again. If you do this, you're essentially reverting to polling for updates. Doing so will lose you one of the bigger benefits of using Firebase: it automatically synchronizes data to connected clients.
So only you can decide whether explicit connection management is best for you application. I'd recommend starting without it (it's simpler) and first testing your application on a smaller scale to see how actual usage holds up to your expectation.
I have a requirement to deliver push notifications to an app that runs on iOS and Android, with approximately 2 million installations in total. I've built a PoC using Azure Notification Hubs. This works fine tested against a handful of phones / tablets I could borrow. I've also tried the same with Amazon's SNS and that worked well too.
I have no reason to believe that hubs wouldn't scale as I need it to but I wondered if there was any provision for load testing. I can't borrow 2m phones but maybe I could configure a hub to call a service I host, thereby simulating a push to either the GCM or APNS gateways? This would help build confidence in my end-to-end performance / volume testing.
I believe this is not supported. If there is a load testing capability, it's internal to Azure and not offered for public use.
However, Microsoft does provide an SLA for the Basic and Standard tiers of Notification Hubs. They claim they use the Notification Hubs service to deliver things like the Breaking News alerts for the Bing News apps. The SLA guarantees 99.9% successful message delivery within five minutes (over a month).
The Service Bus SLA (which covers Notification Hubs) is here: http://www.microsoft.com/en-us/download/details.aspx?id=4767
I could not find SLAs for GCM or APNS.
Notification Hubs do provide a fairly rich reporting API, that you can query with OData filters to determine how many notifications are sent over given periods of time.
But I expect that the variable load conditions that affect the service as a whole will mean that no specific promise is made about the specific timeliness of any delivery (within the five-minute guaranteed delivery time). In other words, all of your 2 million notifications might be delivered within fifteen seconds, or it might take 4 minutes to send the first message, with all of them delivered at 4.9 minutes, depending on who else is using the service and how heavily they are using it.