I have an iOS social app that uses Firebase as the main database to store all the posts with time stamp included
What I want to achieve is to remove anything that is > 10 days old from my database.
Currently, I am checking this with this super inefficient way (The only way I know). Every time the user queries the firebase, I have swift code that also queries the ENTIRE database and delete all entries that is > 10 days old. This works but it is really inefficient...
What you're trying to do is currently best done on a server you control with a job that runs periodically to scan and delete the old items. You can use the admin SDK for that.
You should also have a index on the time field that you're using to determine how old it is, in order to optimize the query that generates the results.
Related
I am mainly just looking for clarification or resources. Let me explain my situation.
I have an app that internally relies on an always-up-to-date database of items. I'd like to show off items that were released close to today's date. I originally thought I'd just query my database and fetch the relevant items from there. So I began the long process of updating target values so the widget could see my classes, etc... But that was such a HEADACHE.
I thought surely there must be a more lightweight method the designers had in mind, so I then read about "app groups" and being able to pass information via saved settings/preferences. So basically when the app runs, you store some data as json and then you can fetch that information in your widget.
But then, to my knowledge, the data won't update unless the user runs the app again. I was hoping I could keep this widget up to date even if the user hasn't used the app in a long time.
What exactly is the process I should be using to achieve this? Are "app groups" basically the only way to do this? Will I just have to accept that I will often times have stale data?
I am implementing a Zapier Integration's polling trigger. I have built a trigger and an API which serves the data correctly. However my concern is about: how to make sure that I provide the new data only, when zapier polls.
I know about the deduplication mechanism. I provide ids in all the items and Zapier makes sure that one item is used only once. However in my application the items can go into hundreds very quickly and in months they will be in thousands and beyond. I want an optimised solution where I serve only the items which will eventually be used by Zapier, thus reducing the memory usage in my application.
Some timestamp can be save for every call, which I can store inside my application but that will not be a foolproof solution. Same API can be used by user in multiple zaps, plus there are sample calls etc.
Great question! The simplest way to do this is to add a date parameter to your API that lets you filter for items created after that date.
Then, in your Zapier code, provide that param for all trigger calls. I'd set the time to 24 hours ago. So, when a trigger fires, it'll only get items created in the last 24 hours. That could be a big list, but items will cycle out after a day.
Is it possible to get the DataPoints with history like last update date/creation data and original/updated value?
I need to get a user's weights, and sync them with my app, but, I need to know what records have been updated after I made the first get for a specific period (like last 01.01.2020 - 02.02.2020).
My app uses ionic and cordova with the health plugin, but that is not the point of my question. If needed I can write a new plugin to acces the fit data.
This is the existing plugin code to get the data: https://github.com/dariosalvi78/cordova-plugin-health/blob/master/src/android/HealthPlugin.java
It appears that you cannot get the history of the records.
When working with a database on Firebase, is it possible from within an iOS app to check the date(& time) a document was last updated using some standard API? I mean without implementing my own system to know when it was last time touched.
It would be convenient if there was a field "lastUpdate" time-stamp for instance.
Neither the Firebase Realtime Database nor Cloud Firestore automatically adds a timestamp field to the data for writes.
If you want such a field, you will have to add it yourself, either from the client, or from Cloud Functions.
For a simple example of the latter, which tracks when a node in the database was last modified, see this folder in the functions-samples repo. The main code:
exports.touch = functions.database.ref('/chat/{message}').onWrite(
(change, context) => admin.database().ref('/lastmodified').set(context.timestamp));
I have a application need a list of data, but these data may be very large. If I'm going to show this list of data in client (mobile app), I can't get all of the data from server because the limit space of mobile.
For example, like Facebook app, there are tons of newsfeed in server, and user can only see some of them. If user want to see more, they need to scroll down and fresh. So how to implement something like this in both client and server? (Currently my server is written in ruby on rails, and client is iOS)
And once the client get those data, does it store in memory or in local database? I'm worried about memory limit in mobile phones.
Thanks
On the server-side, you could probably write an API supporting pagination and custom results count, i.e.: myapp.com/api/get?start=0&count=20 to get the first 20 results, and when the user scrolls all the way down your view on the iPhone, fetch the next items, like that: myapp.com/api/get?start=20&count=20.
If you plan your design well, you'll get something very flexible that you'll be able to change later if you realize that 20 results is too much/not enough, etc.
Depending on your app's architecture and the amount of data your app will handle, you might also need to provide API methods based on the last-updated time, to ensure you're not missing data (e.g., if you call your second get?start=20 a few minutes after the first one, the start index might not have the same meaning).
As for storing data locally, it all depends on what you want to achieve. Are you sure you need to save everything the user has downloaded? You could store only the most recently fetched items in a local SQLite database and query them the next time your app starts up, before refreshing the view (I don't know how it is implemented in Facebook's iPhone app but at least it looks like it's done that way).