I'm working on a feature on iOS for which we want to query a Firebase realtime database, which only updates about once a week. I saw there is a limit of 200k simultaneous connections (for the Blaze plan). My question is: what counts as an active connection?
For example, if we create an observation using the .observe() method, does that mean 1 connection as long as we are observing?
And what about a 'one shot' fetch, using .getData(). Does this close the connection after completion?
We're not actually interested in keeping an observation alive for a long time, as data only changes about once a week.
From the frequently asked questions:
A simultaneous connection is equivalent to one mobile device, browser tab, or server app connected to the database. Firebase imposes hard limits on the number of simultaneous connections to your app's database. These limits are in place to protect both Firebase and our users from abuse.
The SDK connects to the server the first time that you try to access data from (or write data to) the database. The connection stays open for as long as the client has an active listener (so observe in your case) or until about 5 minutes after the last read or write operation.
You can also explicitly control the connection by calling goOffline and goOnline in your code.
Related
I'm creating a simple web app that can connect to a bluetooth device that I want to be able to use offline, so I use a service worker to store the app in the web cache. I know the cache only clears if there is no more space but what about the service worker?
I found that is lifespan is 24 hours. My question is how long can I use the web app without connecting to the internet? Is the cache the only problem or does the service worker "die" after x amount of time and I need to connect to the internet again?
No, it does not die. You can use it forever.
You're confusing two things. The 24 hour lifespan is actually an automatic update checking interval. In other words, when using a site frequently the browser will automatically check for updated Service Workers (specifically updated /serviceworker.js or wherever you store it). Your code can of course manually, programmatically check for SW updates more often. Usually apps check for new SWs every time they're launched. But the device may be offline for eg a month and that doesn't prevent the use of the app.
Apple added in iOS 7 new possibility to execute activities in the background, fetch mode, which can be used e.g. for Twitter, when frequently small amounts of data need to be downloaded (official description: The app regularly downloads and processes small amounts of content from the network.),Apple Document Reference
However, I need to use a TCP connection.
Does anyone know whenever TCP connection may be used in such scenario between the calls?
The scenario is:
I open the TCP socket in the beginning and then the application can use it in these fetch calls. Of course handlers are needed when the TCP connection drops, but there is a difference between rare necessity to reconnect and constant (i.e. in each fetch iteration) need to reconnect.
I have seen many tutorials and opinions on that - I have developed a simple script that will send batches of notifications to Apple servers, and I crontask it every 5 seconds. (it's php so far, should be improved soon).
This way, the code is simple, and if 1 batch is larger, it will not delay the next batch. It also allows to run on multiple servers to dispatch faster and solves any concurrency issues
However, I am not clear about Apple tolerance to the fact that I open/close a socket with them every 5 seconds... In sandbox mode, it works perfectly.
Thanks for the advice
How about this approach:
- batch all in some data-structure (I don't know about PHP, but in Objective-C this would be a NSArray containing instances of some custom NotificationClass or NSDictionaries).
- if you have either A) batched up more then X notifications you send them through, or B) waited a certain time (e.g. 5 seconds).
Depending on what you use the push notifications for you can adjust these variables. A chat app for example want them to be sent immediately, while some daily messaging app would probably be OK with sending them all at once each hour or so.
Also, Apple's words on opening connections:
You may establish multiple connections to the same gateway or to
multiple gateway instances. If you need to send a large number of push
notifications, spread them out over connections to several different
gateways. This improves performance compared to using a single
connection: it lets you send the push notifications faster, and it
lets APNs deliver them faster.
Keep your connections with APNs open across multiple notifications;
don’t repeatedly open and close connections. APNs treats rapid
connection and disconnection as a denial-of-service attack. You should
leave a connection open unless you know it will be idle for an
extended period of time—for example, if you only send notifications to
your users once a day it is ok to use a new connection each day.
See here for official docs (Best practies for Managing Connections).
The idea is that you simply leave the connection open between the batches.
In fact, Apple recommends you create multiple connections, so you can divide the 1000 over maybe five or ten or so connections. You could have some connection manager in your code that controls the lifetime of the connections: if no messages have been send trough for x amount of time, shut it down. If some piece of client-code requests a connection, this manager either creates a new one, or returns one that is not currently being used to send data through. The client of this manager should be prepared to not receive a connection, and the connection manager should in turn notify clients about the availability of connections.
Lots of possibilities in terms of architecture, but the main point it is better to leave a connection open and idle for some time, then to open and close them many times.
i'm writing an app that manage a sqlite database, and i have write a web server, i want the user register in my web server with username and password, i already know how make a request from ios app to server and receive the response, but i want enable also the synchronization of the sqlite database to other device, i now that with core data i can use iCloud synchronization, but for now i prefer use sqlite, and find a way to synchronize it, for example i want create this:
make a change in the sqlite in the iPhone app;
the app send this change to the server for that user;
then the server have to send this update to other device connected at that user;
and now i can't go over, how the server can send this change to the other device? the device has to be always listen to the server? or there is a way to send this update directly to some device and handle it? like an apple push notification?
EDIT: if it's possible use an apple push notification to do this, i doesn't want alert with text sound and badge the user, but send a "silent notification" it's possible?
As a high-level there are a few different ways to approach this, all of which have pros and cons. Two name two examples you can do a polling method, active push or a hybrid approach.
Polling: at some pre-determined interval the app tries to "phone home" and send the delta db changes up to the server. Here you know that your server will be expecting X number of responses in any given interval so you can appropriately gauge your load.
Active Push: The user decides when they want those changes to be transmitted to the server by hitting a "Sync" button. This allows the user to only push data back up to the server when they know there's a change but an over zealous user may make a change, upload, make a change, upload, etc instead of queueing up a bunch of changes and sending them all at once. This may create frequently unneeded server calls.
Hybrid: You setup a polling schedule within the app AND give the user the ability to Sync at-will in the event there is a critical change that needs to be made ASAP.
Regarding the listener side of the equation you face a similar challenge conceptually. If the original user makes 20 changes and presses Sync 20 times do you bombard the second user's device 20 times as well or do you queue those changes up and send them down every 5 minutes (as an example)? Unless you have both devices paired to each other or are connected to the same network AND visible to each other via your app you're going to need to leverage that back-end server. Push notifications can be very useful in this manner but there is extra development and setup overhead to take into account to properly implement them.
To boil this all down I would recommend laying out what YOU want your syncing model to look like before you start marching down a path.
I have an app that tracks wildlife where the user enters data based on their observations (eg. user enters they see 3 moose). The data is then uploaded to a server. However, because this app will be used out in the field where there is often no internet connection, I want to save data if there is no connection, and upload the data as soon as the network is available
I know about Reachability, but it looks like I can only check if the internet connection is available at that moment, and doesn't check in the background for internet connectivity
So to summarize:
If there is an internet connection when users submits data, then that's fine.
If there is no internet connection, when user submits data, I want to save this data. As soon as there is an internet connection, I want the data to be uploaded, without needing the user to open up the app again. I can't rely on the user to open the app again causing the data to be submitted, because they will likely only use this app out of the range of cell towers, and will likely NEVER run the app in a location with a network connection, so it would have to automatically submit this data for them.
Looking around, I can't find an answer so I'm beginning to wonder...is this even possible?
No, Apple don't allow applications to run indefinitely in the background for this purpose, and they don't allow applications to be triggered remotely or anything of that nature. At best you could have your application run in the background to get notifications about major location changes, but you'd have to have it as a proper feature rather than a hack to get around this limitation, otherwise your application won't get approved by Apple.
I know it's possible to utilize the network in the background but only for a limited time after the user closes the app. You could create a timer which checks for a network connection (using Reachability or by pinging Google) and set the timer to fire every minute after the app closes. It's not a very efficient solution but it may work. You should look into how long you can maintain a connection after the app close though, I think it is 5-10 minutes.