Database structure for app to show random items once to users - sql

I am trying to design an app (mobile + web) that displays random items stored in a database to the Users.
The issue I have is that I do not know how I should design such a database. The idea is that all users are logged in to use the app and that they get random items on the screens and can then swipe to the next one. The app should keep track of all the items that the user has already seen and never ever show them again. You could think of it as a similar app then Tinder but its not for dating.
I know how I should structure my database to store the items but I do not know what the best practice for such a use case would be. Should i create the complete items database for every new User and then delete the items from it that they have already seen? Or is there another (better) way to do this ? I can't really think of another way for now and my Project is stuck on this crucial part.
Many thanks in advance for any suggestions :)

Related

Trying to make an auto-generated day based mobile app

I'm new to React Native and, in fact, even to development, because I've never been a developer before. I've been learning for a few months and I have some app ideas.
So ... because this is my level and I really don't know how I could do that, please don't hate me, I just want to ask you about this.
I would like to build something similar to a list of activities, but “aware of the time”. For example.. I would like to have a new list of activities with the same tasks every day. If it is 23:59, the progress made that day will be saved in the database, and at 00:00 a new list will be generated for the new day. If the user does not use the application for one, two or three days, the "empty progress" will still be recorded.
So.. again, please don't hate me, I think that would be the backend part. What can I use with React Native to achieve this type of behaviour and how?

How to delete all companies or contacts?

I'm using the free HubSpot CRM for now. I wrote some scraping code and through the API added over 17k companies and 4k contacts.
There were some errors due to an incomplete understanding of some of the API calls and now I'd like to wipe everything out and start over.
I realize I could run the "Get Recently Created Companies" and for each of the 20 it returns run the delete company API call, then loop it until no companies exist, however this seems like something I shouldn't have to write code to accomplish.
I checked the Academy but the examples showed an interface that didn't match what I see, so it's either outdated or meant for a different version of HubSpot than I have. Didn't find much on Google either.
Anyone else know of an easy solution for this?
HubSpot developer here. I just checked with the folks who run the Contacts and Companies APIs – the best option you have right now is to contact support.
I know that's not the answer you're looking for. We're working on improving things, but it's not there yet.
Ran into this issue myself, needing to delete 8k test the marketing team had generated when we were still playing around with features. Had to reach out to customer support a few times to get the answer as it's not at all intuitive.
On this help page they say that you can mass delete contacts by adding them to a list, using Select All, and then Delete. This doesn't work in cases such as mine though as the pagination only allows you to see up to 100 contacts at a time.
The secret step for now is that you have to go down to the bottom right corner and click on "View the old list manager" (black square button with two arrows that's just to the side of the Help button). In this view Select All really does select every contact in the list so that you can perform a batch delete (or other action) on them all at once.
Summary
Create new list with rules to add the Contacts you want to delete
Switch to the old list manager view (button on bottom right)
Select All
Delete
Tell the confirmation box that yes, you really know what you're doing
Hopefully HubSpot will update their help docs soon and re-add the ability to really select all list items in the new view before they completely remove the option to switch back the old view.

SyncFolderItems - syncState size becomes huge! what can I do?

I am writing a mobile mail application and I am using the SyncFolderItems request to sync my folder.
The problem is, that when dealing with folders with a lot of items (e.g. 12000) the syncState becomes huge, and obviously this is not good for a mobile device..
Is there a workaround to this? Should I abandon the Sync operation and use pull subscriptions instead (And perhaps use findItem operation to get the initial id's? )
Thanks!!
What other people say, its a design question.
If you have a lot of e-mail, howmuch do you really need?
I mean, do i need 12000 items on my phone, i dont think so.
Good option is, save all the item id's with subject or something.
When click on the item, get the other properties. And don't save the information, it can be called from the Exchange Server...

Custom iOS address book. Need advices about data structures and performance

I am currently developing a voIP app and I am really stuck with the address book.
Because of the custom design, the native address book does not fit in my app. Besides, I want to add some extra data not present in the native address book. But this is leading into some problems which I've separated into two sections:
1. Data structures:
In a section of my app I need to show to the user all his address book contacts with additional information (if the user has the same app and it's online, for example).
Right now I'm getting all the info from the Address Book api and loading it in an array directly (which is accessed by the tableView:cellForRowAtIndexPath:), but not displaying the custom information I was talking about. I don't know if its worthwhile to store all the address book info in a sqlite data base (where I'd be able to add the extra information easily) or if I should store only that extra information in a file or something.
The biggest problem of storing it in a data base is that the contact's picture is heavy enough to get a wasting-memory data base. I thought to store only a reference (the ABRecordID) and then to gather the related info from the address book instead of the data base, but the Apple documentation of the Address Book api says the ABRecordID is not guaranteed to remain the same, so it could cause my data to appear next to wrong contact data.
Any idea?
2. Performance:
The second big problem with this custom address book is that... the iOS table views are too 'manual' compared to the Android ones, for example. You need to have the data stored somewhere so that when the tableView:cellForRowAtIndexPath: method gets called you return that data. You can also load that data inside this method, but this makes it very slow.
The problem here is that preloading all the data in memory is dangerous, because a person may have 40 contacts or 2000 (and maybe he/she has taken a picture for each of them, which will be much more memory-consuming). If the iOS device runs out of memory the system will kill the app. The data base approach has no memory problems, but making queries for each cell to appear is so slow that it becomes unacceptable.
Again, I need ideas for this. Can't find a tradeoff between performance and memory consumption.
Please, don't ask for code because I'm not allowed to post it. I'd really appreciate your advices. Thank you in advance!
Data structures:
Along with the recordref you should store the name phone number and email address. Nothing else in your data store. If one of the three vales change and the other two remain the same update the changed value. The recordref can change during a restore of a device for many users at once but the name email and phone won't. If the user changes a name or email or phone they won do it across many users at once. Once in a while you end up with a recordref that does not match up with email and phone say, the contact may have changed employers so then show a list of close matches and ask the user to select one.
As far as some one having 1000s of contact I would use paging. Load 100 or 200 at a time in to an array with current row displayed in the table view as middle of your array index. Once the user scrolls 20-30 records update the records in your array from address book. Your going to be spending a lot time resaving data just to go through the collection comparing and trying to keep it up to date. You should be able to store quite a few records long as your not keeping the user images in memory, for that you should let the table view handle it. Get image and assign to cell when you get the notification about the cell about to become visible. Even then I would put a short wait before loading the image, because if the user is scrolling fast the cell will just fly by and you'll get notified that the cell scrolled out and you can release the image data. If the user is scrolling slowly then the short wait/sleep will pass and the image should show up for each cell.
I don't know how much meta your planning on storing in your app wrapping the contacts but if you should create two tables for the contact object, one with 3-4 indexed columns that will allow for faster querying and a second to hold the rest that loaded only when users viewing the contact in a detail view. Can't get too much into a tableviescell, unless your on the iPad.
Hope that helps.

Can I know when the user delete my app?

I'm wondering to know if I can have a event or some way to know when the user deletes my App, so I can delete him from my Database. Is it possible?
First; Just because the user deleted the app on one device doesn't mean they don't have it installed on others - or won't install it on others.
To your question; Apple doesn't give you a way to do this. Perhaps you could use some sort of "expiration" window - e.g.: if they don't start the app within 90 days, expire the records from your database?
The short answer would be NO, since the user can delete your app without even starting it.
What you could do is send a message to your server every time the user starts the app and get an approximation of how active the user is. Very little activity -> delete the user from DB.
Nope, chuck testa. Otherwise people could abuse this feature with alerts and crap like that!