Right now i'm using Firebase Realtime Database, is there a way to see if i'm reading data from the Realtime Database or from cache ?(i want the same way like .isFromCache() from https://firebase.google.com/docs/reference/android/com/google/firebase/firestore/SnapshotMetadata).
i read from other stackoverflow question Does Firebase cache the data?, that when i use once(), it clears the cache. is there any way to track where i'm reading the data ?
There is no way in the Realtime Database API calls or results to see whether a resulting snapshot came from the cache or from the server.
The isFromCache method from the Firestore API is not available on Realtime Database. It also doesn't necessarily do what you expect it to do, but that seems besides the point here.
I am building an app like google's keep (notes taking app) using flutter. I can add notes but when I close the app, it resets to initial state. How can I save these notes so when I come back to app, I can read my previously added notes.
When you're saving in a list for example, and render, you're doing that on UI state which is temporary. If you want to store data to last even after the UI got refreshed, you have to use a database that will hold the data until you delete it.
If you just want to store some tiny data, for example light/dark mode preferences or login/logout sessions, you can use shared_preferences. For larger data, I used sqflite to store data in SQL database in system as a file which will be cleared after the app is memory-cleared or deleted. If you want to store the data in cloud, you can use firebase for that.
You have two options:
1) Save locally on device using database. Below are the db solutions.
Moor
Floor
2) Save on the server, you can use Firebase Cloud Firestore.
First of all I'm new in ios/swift...
I need to have offline mode of my app.
I'm using Alamofire for all networking getting json, convert to objects and save into the DB (Core-Data). Wanted to know do I need to have additional cache in between (like: Haneke, or DataCache) in case no internet connection or getting from CoreData?
Is DB request fast/convenient enough?
CoreData is very fast (if correctly used). I don't believe it would be necessary to have an additional cache layer.
It would be just a duplication of data that you already have stored in your DB.
By the way all depends from your project use cases. I would not rely on temporary cached data if my app must work without internet connection.
To give you an idea of core data performances so that you can choose what works best for you: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/Performance.html
Can people give me examples of why they would use coreData in an application?
I ask this because most apps are just clients to a central server where an API of some sort gives you the information you need.
In my case I'm writing a timesheet application for a web app which has an API and I'm debating if there is any value in replicating the data structure on my server in core data(Sqlite)
e.g
Project has many timesheets
employee has many timesheets
It seems to me that I can just connect to the API on every call for lists of projects or existing timesheets for example.
I realize for some kind of offline mode you could store locally in core data but this creates way more problems because you now have a big problem with syncing that data back to the web server when you get connection again.. e.g. the project selected for a timesheet no longer exists.
Can any experienced developer shed some light on there experiences on when core data is best practice approach?
EDIT
I realise of course there is value in storing local persistance but the key value of user defaults seems to cover most applications I can think of.
You shouldn't think of CoreData simply as an SQLite database. It's not JUST an SQLite database. Sure, SQLite is an option, but there are other options as well, such as in-memory and, as of iOS5, a whole slew of custom data stores. The biggest benefit with CoreData is persistence, obviously. But even if you are using an in-memory data store, you get the benefits of a very well structured object graph, and all of the heavy lifting with regards to pulling information out of or putting information into the data store is handled by CoreData for you, without you necessarily needing to concern yourself with what is backing that data store. Sure, today you don't care too much about persistence, so you could use an in-memory data store. What happens if tomorrow, or in a month, or a year, you decide to add a feature that would really benefit from persistence? With CoreData, you simply change or add a persistent data store, and all of your methods to get information out or in remain unchanged. The overhead for that sort of addition is minimal in comparison to if you were trying to access SQLite or some other data store directly. IMHO, that's the biggest benefit: abstraction. And, in essence, abstraction is one of the most powerful things behind OOP. Granted, building the Data Model just for in-memory storage could be overkill for your app, depending on how involved the app is. But, just as a side note, you may want to consider what is faster: Requesting information from your web service every time you want to perform some action, or requesting the information once, storing it in memory, and acting on that stored value for the remainder of the session. An in-memory data store wouldn't persistent beyond that particular session.
Additionally, with CoreData you get a lot of other great features like saving, fetching, and undo-redo.
There are basically two kinds of apps. Those that provide you with local functionality (games, professional applications, navigation systems...) and those that grant access to a remote service.
Your app seems to be in the second category. If you access remote services, your users will want to access new or real-time data (you don't want to read 2 week old Facebook posts) but in some cases, local caching makes sense (e.g. reading your mails when you're on the train with unstable network).
I assume that the value of accessing cached entries when not connected to a network is pretty low for your customers (internal or external) compared to the importance of accessing real-time-data. So local storage might be not necessary at all.
If you don't have hundreds of entries in your timetable, "normal" serialization (NSCoding-protocol) might be enough. If you only access some "dashboard-data", you will be able to get along with simple request/response-caching (NSURLCache can do a lot of things...).
Core Data does make more sense if you have complex data structures which should be synchronized with a server. This adds a lot of synchronization logic to your project as well as complexity from Core Data integration (concurrency, thread-safety, in-app-conflicts...).
If you want to create a "client"-app with a server driven user experience, local storage is not necessary at all so my suggestion is: Keep it as simple as possible unless there is a real need for offline storage.
It's ideal for if you want to store data locally on the phone.
Seriously though, if you can't see a need for it for your timesheet app, then don't worry about it and don't use it.
Solving the sync problems that you would have with an "offline" mode would be detailed in your design of your app. For example - don't allow projects to be deleted. Why would you? Wouldn't you want to go back in time and look at previous data for particular projects? Instead just have a marker on the project to show it as inactive and a date/time that it was made inactive. If the data that is being synced from the device is for that project and is before the date/time that it was marked as inactive, then it's fine to sync. Otherwise display a message and the user will have to sort it.
It depends purely on your application's design whether you need to store some data locally or not, if it is a real problem or a thin GUI client around your web service. Apart from "offline" mode the other reason to cache server data on client side might be to take traffic load from your server. Just think what does it mean for your server to send every time the whole timesheet data to the client, or just the changes. Yes, it means more implementation on both side, but in some cases it has serious advantages.
EDIT: example added
You have 1000 records per user in your timesheet application and one record is cca 1 kbyte. In this case every time a user starts your application, it has to fetch ~1Mbyte data from your server. If you cache the data locally, the server can tell you that let's say two records were updated since your last update, so you'll have to download only 2 kbyte. Now you should scale up this for several tens of thousands of user and you will immediately notice the difference of the server bandwidth and CPU usage.
I want to develop a CRM iphone app. I think there are 2 methods to deal with the data store, one is using the Sqlite(but it can not share datas with others ?), the other method is using the webservice(let the app CURD data by one web application), I want to know which is better?
I think the question is not about having one or the other, you could have both: Webservices to expose a central server somewhere where common data is stored and your local SQLite database where a copy of this data is stored. This allows you for fast search etc. instead of contacting some remote server that may or may not be on-line.
If you want to share your data then you have to store your data in webdatabase otherwise store in sqlite
you can store your data in sqlite for fast access and when you want to share that time you can send it to webservice and retrive when you need to see more data