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!
Related
Hi i'm actually working on a report system for my social network, i want to achieve something like : if a user is reported 5 times it will update a field on the user table to deactivate the user.
So if 5 row of reports is created i want to update the "activated" field
The thing is i'm working with GraphQL and Vue for the first time, my backend is in Symfony with ApiPlatform.
Should i try to query all the reports with the userId who is reported to count if there is 5 row when a user is reported and then mutate the user object to deactivate it or can i achieve this more easily on the backend side ?
So anything of importance should be done on the backend. The frontend is easily hacked and while it's good to stop normal (good) users from seeing something they're not supposed to, it's not a blocker to anyone who has even rudimentary web coding ability.
Seeing as you're talking about someone being reported, I'd recommend doing it on the backend and then make sure the frontend reflects that gracefully.
Hum it seems that the answer is that i need a reportListener and i need to listen the postPersist event, then inside this function i can check how many report there is for a user using the ReportRepository->findBy function, then i can count the row of the array return by the function and if the count is > 5 then i edit my user, persist and flush.
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 :)
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...
I'm trying to decouple some of the bits of our big-ball-of-mud architecture, and identified several boundaries that are obvious candidates for using CQRS to provide a more resilient and scalable solution.
Typical example: when a customer places an order, at the moment we block their thread whilst the order is submitted for payment, approved by the sales system, etc, etc.
This can all be handled asynchronously - allowing us to accept and queue orders whilst the payment processing system is unavailable, etc. - but I'm not sure how I should manage the UI data for the customer.
In other words - they place an order. Their order goes in a queue. If they log back into their account five seconds later and click "review orders" - what happens?
If I draw it from the central repo (or from a cache that's updated based on that repo), then the user won't see their order and will probably try and place it again - or phone us and panic.
If I draw it from a local database, then I have the overhead of maintaining another database of orders - which will need to be synchronised in a load-balanced environment, and seems to undermine a lot of the advantages of CQRS.
I want to do this in lots of places - and not all of them are actions as significant as confirming an order; in some cases it's as simple as a customer changing a phone number or something - so they're not all cases where I can just say "thanks a lot, we'll send you a confirmation e-mail" - because sending confirmation e-mails for every modification to a record strikes me as a little excessive.
Any patterns or solutions I should look at to help with this?
Something worth considering is a 'user' inbox: a place in your app the user can consult 'in-progress' commands at. You could also 'push' notifications back to the user's UI when he has already moved onto another screen, but still resides in your app. This might also be an option when the user logs back on.
Another option could be faking the synchronous experience, i.e. wait around and do polling while in the background everything happens asynchronously. Granted, this might involve including timeouts as well, but I'd argue that those are embraced in today's synchronous processing as well.
On top of all this, you may want to both inform and solicit feedback from your end users about how they experience your app and its behavior.
Regardless what anybody tells you, if you want to handle this elegantly, it will take some effort on your part.
The best thing to do is lie!
The user should have no idea that their transaction is in fact a little like Schrödinger's cat, either dead or alive. From their perspective the transaction was a success, because you just indicate to them that it was successful and queue the job away for offline processing.
Because the vast majority of transactions are successful you can then handle those that are not with an appropriate compensationary mechanism.
Insignificant cases, like modification of some record:
Send the user to a confirmation page telling him something around the lines of "Thanks, your input is being processed. What do you want to do next?" and a couple of links.
If you absolutely have to send the user back to the edited record or a list thereof, in non-distributed systems we're probably talking about milliseconds until the read store has been updated. As long as it takes longer to redirect the user to the new page, from the user's POV everything's fine.
If in some cases the user actually doesn't see his update "immediately", he might call user support. They tell him to hit F5. What? It's there now? Great! Guess what he does next time before reaching for the phone.
Significant cases like offline order processing:
There might be an implicit concept of a Received Order or Pending Order in your domain. If you make this concept explicit, you can present the user with accurate information.
"Thank you very much! Your order has been received an we'll keep you updated once it has been shipped. [Click here] to see a list of your pending orders..."
I think the simplest thing, doing nothing, can often be good enough. If user changes phone number, and the system processes this command in 1-2s, it is a good chance user has not had the opportunity to see old data in-between this operation.
If that is not satisfactory, and your user must absolutely know that his request was fulfilled, your UI can subscribe to domain events. Once the command is executed successfully, your UI gets notification and can inform the user. There are various ways you could do this in UI. You could simply block until the success notification arrives. Or you can say "we received your request", and once you get confirmation, show the notification window "your request was fulfilled" somewhere in the corner.
I'm looking for ideas on how to implement some type of fast login scenario for an application that will allow employees to quickly login.
I work with an organization that has employees rotate every 30 minutes to a different location. If there are 3 employees, then the first employee won't come back to the checkout station for an hour. The checkout station is a higher traffic area where different things are borrowed by customers. Right now they have a generic login, but the organization wants to track which employee checked out/in a borrowed item. The problem is when they rotate there are customers there many times and having them logoff and login either via a workstation login or an application login is too slow for customer service.
Any suggestions?
I think a fingerprint reader would work well for logging in users. Then, they wouldn't have to type anything to log in.
There are plenty of biometric SDKs online that should be able to help you with this. And, I think some commercial readers will do something similar already, so you wouldn't even need to write any code.
Here's an article on Microsoft's Upgraded Fingerprint Reader
Also, you can have them scan once to log in, and once they are logged in, they can scan again to get logged completely out of the system (instead of just locking the screen or forgetting to log out and walk away.)
Use an application-level login, but make it only based on typing in their employee ID. This will simply identify who they are, exchanging security for speed while not giving up identity. Using employee ID's for this is a good way of guaranteeing uniqueness. I've seen systems like this work in retail, and it's really fast. Employees get used to typing this number into the console.
I'm not sure if it's in your budget but this sounds like a good use for those little button 1-wire devices. Basically it's an electronic "key" that is about the size of a button and can be read very quickly.
So Employee A goes to the station, puts his button on the pad(takes like 2 seconds) and he's logged in. When he needs to leave he pushes one button to log out, then employee B can come and log in, etc etc.
a picture of the button: