My use-case for Firebase is slightly different than most. We do not use FB exclusively for our back-end. We have a large MariaDB server dealing with relations and all data.
Our goal with FB is to allow clients on iOS devices to have their specific data available. We need to load the data once and then listen for changes to this particular data. Here is a rough overview of how it works:
The main ViewController is loaded
Firebase is initialized and we listen for FIRDataEventTypeChildAdded. (Persistence is enabled)
Firebase loads all matching records. We then loop through and store them locally in the internal SQLite DB.
In the normal userflow, we push other ViewControllers on the screen. The problem is, once the main ViewController is loaded, FIRDataEventTypeChildAdded fires again for each record.
Questions:
When FIRDataEventTypeChildAdded fires again, is it loading the data from its internal cache (Persistence?) or is it re-downloading everything from the Firebase server? I've used Network Link Conditioner to completely cut the internet connection, and when I do, it does not fire the FIRDataEventTypeChildAdded at all, but as soon as the net comes back, it fires FIRDataEventTypeChildAdded for every single record.
How can I achieve the above where we load all records on login and then only listen for changes to those records? I am already using orderBy and startingAt so if the answer involves one of the above, I cannot add another "hasDownloaded=yes" filter.
Thanks in advance.
A Firebase reference listener connects to the server once, and stays connected until that query is turned off. As long as the reference being listened to is in memory, there is only one connection made to the database. Once this connection happens, all data will come through as child added data again.
The issue here is not so much with Firebase but that your app is continuously readding listeners to a reference, making the data be redownloaded from the network every time.
So to your first question, yes it is redownloading from the network. To your second, you just need to make sure the Firebase query never leaves memory. This can be done by making your query globally scopes, or simply by not turning off the query when the view controller exits scope (then you need to make sure not to readd multiple queries on subsequent loads).
Related
I have an Firebase-backed app with the following database structure:
posts
/uid
/postId
Originally, i'd load data from the posts/uid node using ObserveEventOfType with .childAdded. This would load stale data frequently (~5 times a day) for all users of my app simutaneously. When attempting to update the data by making a new post, Firebase would still return stale data.
As a result, I decided to try keepSynced. Now, if my reference looked like this:
reference = Database().database.reference.child("posts").child(uid)
keepSynced would load all of the data at that node, which could amount to very large downloads if there are many children in that node. So, I decided to change the reference/query to:
reference = Database().database.reference.child("posts").child(uid).queryLimited(toLast: 25)
When turning keepSynced on for this node, it syncs for the last 25 children in the node successfully. However, I still am facing the issue of receiving stale data rather frequently. So here are my questions:
When adding the keepSynced mode on the limited query, does it only sync from the initial node you added it to, or does it always just sync the 25 latest children under that node?
Where is the best place to add the keepSynced(true) line in code? Before we load the reference, in viewWillAppear, or inside of the actual download callback?
Similarly, where is the best place to use keepSynced(false)?
Do the keepSynced listeners delete when the app fades into the background?
Why does keepSynced sometimes not address for child updates?
I currently use keepSynced(true) inside of the function I use to load posts which is called on viewDidLoad.
Thanks in advance.
As its name implies keepSynced(true) keeps whatever query or reference you call it on synchronized in the local cache. It quite literally just attaches an empty observer to that query/reference. So in your Database().database.reference.child("posts").child(uid).queryLimited(toLast: 25) it will sync the last 25 child nodes, and keep synchronizing those (removing previous ones as new ones are added).
Firebase Realtime Database caching mechanism works most reliably if you repeatedly listen for the exact same data. Specifically, a .value listener attached to Database().database.reference.child("posts").child(uid) may not see data that was cached through Database().database.reference.child("posts").child(uid).queryLimited(toLast: 25). This is because the Firebase client guarantees to never fire events for partial updates, and in this example it can't guarantee that it has all data from the first reference.
For your questions:
See above...
It's most common to add them in viewWillAppear.
I'm not sure why you'd want to call keepSynced false, so can't recommend anything there.
Not sure if this is what you mean, but keepSynced(true) is not persisted between runs of the app. So you have to call keepSynced(true) each time your app/view starts.
See above...
In general you seem to try and work around the way the API works, by calling the API in different ways. I typically don't see great results from that. If you want your app to behave differently than the API does, consider creating a custom wrapper, and caching the data there.
So, I'm still an unexperienced developer and I need some help with an app I'm currently developing.
The app consists of different tab-views. The first two of them rely on data that is stored on a database. The first database I created myself with Firebase, because it is a news-section, which I need to update regularly myself. The second tab-view needs to request simple data from two different databases, which both return data in the JSON format. The App then should save the data of both databases as custom objects in two different arrays, which both will be used to compare the data sets and display some of the data in a table view.
The thing I'm struggeling with is where to trigger those network requests without compromising the user's experience. What is the best practice to do so? At the moment, the first network request is in the viewWillLoad() method of the associated viewcontroller. But I'm not quite happy with that because there is a small delay between opening the app and displaying those news. Additionally is it better to download the data and then save it locally on the device and compare it to the data online or to download it everytime? It's not a lot of data and just text - no pictures, videos whatsoever - and little pieces of the data change regularly and most of the data changes only twice a year)
Thanks for helping me out here, because I somehow did not find a lot of information on how to structure those requests and I hope that some more experienced programmers might be able to help me here.
You can kick off network tasks in your AppDelegate in:
func applicationDidBecomeActive(_ application: UIApplication) {
}
Just make sure you throttle it so you don't do it too often.
Generally, you want to cache/store your network results and display the cached values. This is especially important if the user is in an area with limited or no network availability when they launch your app.
If you're using CoreData then updating the data will update your table view automatically. If not, then you can call reload() on your table view in the completion block of your network update, or post a notification that your view controller is listening for, and update then.
Either way be sure to update using a URLSession data task on a background queue.
In the iOS Firebase SDK, if I perform a .ChildAdded query, for example, and then later perform the same query again, will the query perform on the local cache or will it hit the Firebase servers again?
In general: the Firebase client tries to minimize the number of times it downloads data. But it also tries to minimize the amount of memory/disk space it uses.
The exact behavior depends on many things, such as whether the another listener has remained active on that location and whether you're using disk persistence. If you have two listeners for the same (or overlapping) data, updates will only be downloaded once. But if you remove the last listener for a location, the data for that location is removed from the (memory and/or disk) cache.
Without seeing a complete piece of code, it's hard to tell what will happen in your case.
Alternatively: you can check for yourself by enabling Firebase's logging [Firebase setLoggingEnabled:YES];
I understand that Core Data is essentially a self-contained local database, but I'm not sure if I should be using it in my app or not. Basically, it would be more for caching purposes if anything, since I retrieve all of my content from a web server database. Regardless, I was wondering if Core Data would be useful is any of these situations:
Scenario #1: I retrieve a list of "items" from the web server and feed them into a table view. This is essentially the first page the user sees. The table can be refreshed to retrieve more results, but existing items likely won't change. Over time this list of items could grow tremendously. Items can be deleted.
Scenario #2: A user has a friends list. This list of friends will stay the same unless he or she adds more friends. I imagine there will be a scenario where a friend deletes their account, in which case the friends list will be altered as well.
Scenario #3: Messages can be attached to items. They can't be edited or deleted, so the only change in state for a list of messages would be if a new message was added. Essentially the same as items, except they can't be deleted.
Actually, for your scenario I would say that you don't need any persistence in your app, but rather fetch your data from the server every time the app starts and just keep it in memory. There are a lot of apps which are doing it this way and this is totally fine behaviour.
However, there are some drawbacks of not using persistence:
worse offline experience for your user since they depend on a network connection, so effectively without a connection they can't do anything within your app
risk of slow loading
On the plus side we have:
using Core Data in your app is a huge implementation overhead (especially if you haven't used it before)
after having integrated Core Data, you still have a lot of issues to tackle, first and foremost: data synching between your app and the backend
If you decide to go for persistence, also take a look at alternatives to Core Data like Realm.
Finally, my advice still is to not use Core Data in your situation. However, keep in mind that you can build a version of your app that doesn't use persistence. And then, once you see that your app is well-received and gets more attention, you can still go and add persistence later on.
Since I've started developing my Blackberry app, the biggest problems I've encountered all had to do with SQLite Databases.
Right now I'm putting my app through a stress test, and when problems pop up I address them by printing out statuses to the console and taking care of things line by line. Right now (after mashing buttons on my app) I received a "Database is locked" error and I'm not sure what to do.
It seems that once the database is locked it's locked for good until it is unlocked........ my question is how can I unlock it?? First of all, how can I check to see if it's locked??
I'm sure our users won't be mashing buttons like I did, but you never know. I want to account for every possible scenario.
Thanks
EDIT: This is what happens in my application..... When I launch it starts a thread, this thread performs a cleanup on one of my tables based on how old certain pieces of data are (uses DELETE). The thread then continues to get a USER object from my DB (read only), it then uses this USER object as a parameter to call a web service. The data retrieved from the web service is INSERTED into my database. (It's a little more complex than that as a few read/write operations are performed at this time. After that, the thread fires a callback method to update my UI.
This all works fine. I can exit the app WHILE the thread is running and relaunch and a flag will prevent it from starting a new instance of the same thread (unless the other one is done of course).
Now my problem: My app's home screen is a list of buttons, when the user clicks one of these buttons another, more detailed list is loaded (this requires a READ ONLY call to the database). When I launch the app (firing the web service calling thread) and then click a button on the main screen right away, the table gets locked. (Not always, sometimes it takes 4 or 5 tries, sometimes more, sometimes less). But if I keep doing this it WILL eventually lock making it impossible to make any calls to my DB, hence no more UI (which depends on the DB).
The DB call that populates the UI on the second screen is READ ONLY, can't I have as many of these as I need?? What causes the DB to lock?? What's the difference between a DB lock and File System error (12)??
I seemed to have fixed the problem. I was under the impression that if a read/write connection was open then a read-only connection could be created safely.
This doesn't seem to be the case. If I have a read/write connection open then no other connections can open until that one is finished.
I basically created one read/write connection, set a flag to identify it as open, and during my read connection use the same Database object if the flag is open, or create a read only if it's closed.
So far so good.
Sqlite does not support concurrent modification. In practice on BlackBerry, this means you can only open the database from one part of the code at a time. To maintain this one-at-a-time access, you need to close the database when you are done with it, as #AnkitRox points out.
However you also need to guard against concurrent access. Even if your code properly closes the database, it is possible for two different threads to access the database. In that case, you will need one to wait. In Java-ME this is typically accomplished through the 'synchronized' keyword, and using the same lock object for all database access.
Check properly that, you are opening and closing database before and after execution of query respectively.
Because if Database is going to open without closing it properly, then it gives errors.