I am creating an application that will track user locations and create incident tickets related to this information. Therefore I have the following setup
Basic Setup
iPhone App: Tracking user location (lat, long) and reverse geocode the information
Server: Database for saving incident tickets including the location information
I am struggling now with the “right way” to save location information for tracking users and incidents. The flow should be as follows:
Intended Approach
Tickets being created should be persistently saved with the information given, like lat, long, address so I see a table of incidents that happened
The geo information should be efficiently handled in terms of reverse geocoding, as I thought about caching the address and lat,long info, which could possibly not allowed to google TOS
Application / Server Workflow
Iphone App User hits a button and executes a POST request sending lat/lng to the server
Server system creates a ticket associated to this request and saves this ticket info in a table called incidents
The challenge I am facing now, is how to handle the management of location data correctly, like the address information. As I want to use reverse geocoding to get the street name associated with the latitude and longitude information, I could use the Reverse Geolocation service on the iPhone or GoogleMaps API. The first question I am having is:
Question 1)
Should I reverse geocode on the iPhone and send the address info via POST request to the server as well and save the info in a table?
Question 2)
Should I only sent lat/lng information and do reverse geocoding on the server before I save the data to the database
The next step I am struggling with is, how to efficiently save the data in the database, considering database normalisation.
Currently whats happening on the server is:
Create incident
When the server receives the POST request coming from the app, an incident ticket is being created and saved to the table incidents
The user lat/lng posted to the server from the app will be used to attach this info to the ticket entry to be saved in the database
So the current table format is:
incidents (id, incident_reference, address_id, latitude, longitude)
Now I do not know where to save the corresponding reverse geocoded information (address)
Question 3)
Should this information be saved with the ticket info itself? I see challenges there, as I would create redundant information
So the current table format would be:
incidents (id, incident_reference, latitude, longitude, street_name)
Therefore I could use the reverse geocode info I receive from the iPhone app directly to save it directly to the incidents table. But wouldn’t that be a bad practice though? I think I would create multiple times the same address information, which would not be good in terms of database normalisation? It somehow does not look like a good idea….
To find a solution, I thought about creating a separate address table with the following table setup:
incidents (id, incident_reference, address_id, latitude, longitude)
addresses (address_id, latitude, longitude, street_name)
Question 4)
Using this approach I would imagine, that I could then cache the already received reversed geocode info, to save it in the database and query my table addresses next time for an existing address. The challenge i see here is, that there would be possibly never the exact same latitude/longitude so I would have duplicate address entries with different lat/lng information in the table.
Q1: No, leave that to the server, to reduce the impact on the iPhone (bandwidth usage, battery usage)
Q2: See Q1
Q3: see comment
Q4: what is your question? Are lat/lon the same for different incidents on the same address? I very much doubt it.
Related
I am building a mobile app (in flutter firebase, but the answer does not have to be firebase specific). And I would like to implement a feature that notifies users whenever anyone from their contact list joins the app. This seems like a very EXPENSIVE feature.
At the top of my head, I see a lambda/cloud function that is triggered everytime a user joins and then searches a database of users and their respective contacts for the existence of the new user's phone number. To me, this solution does not scale well for two reasons: if the number of total users is in the millions and the number of users joining simultaneously is a lot.
My better solution is to get the user's contacts upon joining and then searching a database of current users contacts for any of the phone numbers of the newly joined user.
Is there a solution better than the second one? If so, what is it? If the second solution is standard, what kind of backend storage mechanism provides the best search and retrieval time for a database of users and their respective contacts?
In the case of large users ill not do first solution because that may slow the sign up process instead i will creat a cron job that runs at a specific time or periodically it will get the list of the latest users signed up that day or that hour whatever you prefer then that cron will check the new user if related to any user in the databases and send a notification right away, or a better solution create a temporary table in a database in another server insert the notification informations into the other server, creat another cron job in the second server it will run at a specific time to sendthe notification
Currently, I'm trying to build a dating app(server part).
I'm going to store each user's profile data like videos, photos, profile messages to AWS S3.
And I have user info including location(longitude, latitude) in my database server.
If you've ever used this kind of app, you might easily understand how it works.
First, whenever a user opens this app, the user gets to see the profile of other users one at a time based on the current location.
Second, the user gives like or dislike to the current profile and gets to the next profile.
So, in order to implement the first step, I'm going to search other users in a certain distance from the user's current location in the database, but here I'm only going to get unique user ID values from database. This only happens once when a user opens the app.
Now that I have other users' id values like [id1, id2, id3, id4...] I can load each user's profile data from AWS S3 with each unique id value one by one whenever the user needs to see the next profile.
Here my question comes. To build the recommendation logic like that, where should I keep the id values??
Thanks in advance.
Use a in memory cache like Redis/memcache (both provided by AWS). Also your cahce should get updated as and when data in AWS S3 profile updates because only then you will have latest data.
instead of code, have more of a best practice/functionality question regarding CloudKit. Can't seem to find answers, or maybe just don't understand.
Questions:
When I save the record, cloud kit creates a unique record id, i was thinking of getting that id and storing in core data to allow specific query's on that at a later time vs entire database searches. However, once I save a record, how do i get the record id that was created? Is this possible?
What if I allow a user to report another user for some reason and thereby want to block that user from posting to the cloud until a review can be done. Is there a user access database in the cloud? if not, thoughts on how to?
Thanks all.
By default when you create a CKRecord it will generate a guid as it's ID. You can also specify your own id the moment you create the CKRecord. The it does not need to be a guid. As long as it's unique. Your save action will have a callback where you will get the ID.
Every user has it's own unique id which you can easily get. You could create a table with your blocking information. You only have to query for that yourself to implement the blocking mechanism.
Is it possible to create/store user accounts in a data store that exhibits eventual consistency?
It seems impossible to manage account creation without a heap of architectural complexity to avoid situations where two account with the same UID (e.g. email address) can occur?
Do users of eventual consistency stores use a separate consistent DB as an identity store, or are there solutions/patterns that I should be exploring?
Thanks in advance,
Jamie
It is possible to do use management in an eventually consistent data store. We do it. It works under the following assumptions:
Conflicts shouldn't happen and when they do there's a clear path to conflict resolution. If the account ID is a person's email address, then if two separate people try to register under the same email there's a bigger problem here. What we do in this case is block both new accounts as soon as the conflict is discovered and send an email to the address in conflict explaining to the user that there's an issue (possible fraud). You can either ask the user to reset to the account or ask them to contact support.
Repeated access by the same user within the timeframe in which the data is inconsistent go to the same replica. For instance, if a person just registered and the next request is a login, you must validate that login against the data replica where the new registration details exist. So if the eventual consistency is due to multiple data centers in different geographic locations and under normal conditions a request goes to the closest data center geographically, you're OK.
There are some edge cases, such as if a user registered against one data center, then that center crashed, and now the user cannot login even though he still can see the application - served from some other data center. You can calculate the expected frequency of this case based on your number of daily new users and average data center downtime. Then decide whether it's worth worrying about one user in a (million/billion/whatever your number is) having a problem and possibly contacting support. I faced the same decision not long ago and decided that from a cost-benefit perspective the answer is no.
Is this posible to get the users current location with address and contact information(phone number).
I have used CLLocationManager to get the current location of the user and the tried to get the address and other detail using google API, in the response I am getting current location's detail. But there is no contact information.
Like if user is currently visiting walmart or any other famous location then we can get their store's phone numbers or not?
Please tell me that, Can we get the phone numbers using google API or not?
Thanks
If you can, it would be passed to you in the MKPlacemark that is sent to the MKReverseGeocoder delegate you have specified.
There is an "addressDictionary" property, which contains dictionary entries that conform to the "Address Book". If a phone number is available it would be in there.
If not, it either isn't available for your location or Google doesn't return that data to the reverse geocoded API.
Based on Google's JSON/REST based docs (http://code.google.com/apis/maps/documentation/geocoding/) I'd assume this data won't be returned, as it doesn't seem to be returned by the native API either.