Firebase - App developing - calculate the delta without generating a high data traffic - ios

We are developing a social app with Firebase (swift / iOS).
We face the problem that we have two data trees and have to calculate the delta without generating a high data traffic.
Example:
We have a structure cars and a structure user.
The structure cars contain 100 different vehicle models.
The user structure contains all vehicle models that have already been driven by the user.
We now want to implement a high-performance solution in order to determine all the vehicles that have not yet been driven by a user without downloading the whole tree structure.
The number of users and the number of vehicles are growing steadily.
Does anyone have a solution approach or idea in which direction we need to think?
love, alex

I think they key to effectively using firebase is data duplication. So if you want to display a list of cars the user has and hasn't driven, create a separate table containing only the information displayed in that list, like the path to an image, the make & model, using unique IDs as the keys to entries in that table. You wouldn't need to know things like top speed and price until they tap into details, right? (I'm making some assumptions here though.)
Then, simply get the list of unique IDs for the cars the user already has driven, and manipulate your offline model accordingly.
Right now I'm using an external server to manage data duplication, that propagates a write operation to other places in the database when necessary. I'm on my phone right now but I think Ray Wenderlich has an article about this.

Related

How to save an item the user selected

My app starts with five cells (Ca, Alk, Mg, PO3, NO3). When the user taps on the cell they want to dose lets say Ca, it segues to a screen that have all of the Ca products. From there they get to pick which Ca product they need to use, which segues to the calculator screen where they can calculate the dosage they need.
I need to find a way for the user to save the product they chose, so lets say they selected Ca, I want them to save the product in the Ca list, if they chose Alk, I want them to save the product in the Alk list.
I am lost here whether UserDefaults is okay for this or if I need CoreData.
I personally would use CoreData over UserDefaults for this. CoreData is designed to solve persistence in a more general way that will scale with the needs of what you are building. It's possible to do what you describe with either one - but the modeling of your data, with generated files will provide your code with safety, migrations, and performance if you use core data.
See Here for determining which data storage types to use based on the problem you are trying to solve.
For help in how to actually use CoreData - this article gives some code examples for basic CRUD operations.
Basic CoreData Tutorial

Rails: How to query records in different languages

I have a Rails inventory app that is available to global users, allowing them to enter their own inventory information and query those of others.
a British person in London adds 10 units of "bicycle" to the inventory table
a Japanese person adds 2 units of 自転車 (bicycle in Japanese)
a Vietnamese adds 5 units of xe dap (bicycle in Vietnamese)
The British person can query 'bicycle' and it will output all bicycles in the system (17 units) and can show the details of each in their original language, without the users classifying them beforehand. Likewise, the Japanese person can query '自転車', which will show all bicycles.
How can this be done?
The globalize gem requires users to manually translate each record so it's not the correct way. I've heard about machine learning and deep learning but I don't know if it's the right solution for this.
So if stackoverflow is not the right place to ask this? Where should I ask? Quora does not allow long questions.
Machine learning does not seem like a proper solution in this context since you don't have enough experience with it and it's a complex matter to just start with it and learn enough to apply to a real life problem.
Here are a few solutions you could implement today, as long as you understand the requirements and the up/downs for each, you will have to figure those out by yourself.
Since I don't have enough information about your system I'll try and generalize it to something that's likely.
Solutions:
1.Define a limited number of items for your system, like Bike and add
them to a config file or in a items database, each item having it's
unique id and when a user will have to add something they will have
to select from your list. Have a Other item as a catch-all, and
maybe provide a note so the users can add anything to recognize the
item.
2.Similar to the above solution but you give the users a way to add new items into the system, so you have 10 standard items and every user can add items to the site (those being moderated) and other users will have access to them.
3.Have a solid search system in place like Elasticsearch (or anything else), and when the user create items you index that item in the language that is entered, and then use Google translation API (or another translation service) to translate them in all the languages you need and index those for search as well.
I think solution 1 is the best if you are able to implement it followed by solution 2.

CloudKit design advice

Let me preface by saying I know the pros and cons of using CloudKit and that I am trying to work around one of these issues. However since Cloudkit is more or less free, thats what I'm using. I am aware this might be easier with a different framework.
For simplicity sake lets say I'm making a social media image sharing app, I want to track photo likes and my framework is CloudKit. I'm trying to figure out the most efficient way to track likes for publicly shared photos.
A few of the options I've mulled over:
Every like is a new record in the public database with a back reference to the photo. Since CK has no aggregate queries, in order to display the number of likes for a photo I need to query all the records for a given reference and count them. If this number gets very large then I'm iterating over the cursor. This seems quick and accurate to write but potentially pretty slow to display a lot of photos.
Likes are individual records in the private database, I update the aggregate in a single record per photo the public db at the same time. Getting the total like count is now a one record query. Determining if a user has already liked something also becomes easier with a smaller private db of likes. The route sounds like the fastest but its is potentially inaccurate if multiple users are liking the same photo. Also deleting a user and all their private likes leaves my aggregates unchanged, I'd need some process updating the aggregates.
I'd love any advice I can get, thanks !
You second approach is the best, and it's accurate. When you read a data, change it and save it, CloudKit will check if the data is changed in the mean time. So when 2 are updating 1 photo at the same time, then one will get a CloudKit error that the data has changed. Then just try to update again until you succeed.
No matter what solution you choose, if you want to update the likes after a user is removed, you need a process that does this.

Conceptualizing a parse.com data structure for checkout lanes in a store

I have a question concerning Parse.com and Swift. To make a long story short, I'm creating an app that allows installers of racking around cash registers to enter the details of checkout lanes into their phones, save it to Parse.com, and then have it be retrievable by the guys making the racks in the shop.
For the app, I was thinking of a basic flow like this: A) ask how many checkout lanes there are (x), B) populate a table view with x rows, C) each row represents a register that, when tapped, takes them to a detail view where they can enter details like lane and belt measurements, power sources, etc.
My question is how would I save the registers data to Parse, structurally speaking? Would I be creating a column that stores an array of complex register objects in the row for that specific store? Or would I create a store class, and then a registers class, and dump all those registers into the registers class and relate them, one to one, to the appropriate corresponding store?
I'm not having any issues with the actual saving of the data or the general programming, parse seems pretty straightforward, just conceptualizing the structure is giving me issues. Any help or links would be greatly appreciated.
Here's how I think it should work:
Store class: holds information about all of the stores. Things like the number of registers, number of checkout lanes, location, etc. Stores get a randomly assigned identifier when they are set up.
Register class: holds information about all the possible registers. As you say, users can add them and define values. When created, assign parent store identifier. This should be relatively easy--just get the ID of the nearest store or ask the user what store they are in.
Then you can PFQuery all of the registers by knowing the store identifier, and create an array of all the registers.

Searching for users using Parse

What would be the better approach to let a user search for other users who use the app (using Parse.com as the backend) :
Import all the the data in the _User table then filter t in the app when using the UISearchBar
Querying parse for the search term and loading the results to the tableview
There is no "right" answer. It depends entirely on how you define "better."
Option 1 likely produces superficially the best user experience, in the sense that filtering a list on the fly looks a lot more responsive. But you have to schedule downloading the user list for when the user isn't already trying to search.
Option 2 is likely more efficient. Less bandwidth, less storage. But the user had to be online to search and you probably can't do a "real time" filter unless you're on a fast network.
There may be other factors also. I didn't want to expose a list of users, for example, so I went for option 2.

Resources