I'm using ABAddressBookRegisterExternalChangeCallback to receive notifications when my address book database changes. My app allows users to edit a person's contact info. However, it takes forever for the callback to be invoked. For instance, in one case it 30 seconds. I need it to happen immediately! How do I go about doing this? Has anyone else experienced this issue using ABAddressBookRegisterExternalChangeCallback?
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 just saw the message after I submitted an update for my app
If your submission needs to be tested, it will take us up to 5 business days to make sure it meets your certification requirements. If not, within a few hours, you can either publish it yourself or it will go live automatically if you chose to automatically publish it. We’ll send you an email once it’s been processed or if we have additional questions.
How can I say that I don't want to be tested. It's a bug fix update that I just sent and I want to publish my app as soon as possible.
Don't worry with this message, because it's a default information that is shown after an app is updated. If you only change the price, for example, your app doesn't need be recertified, however if you change other characteristics how the markets, code, ... so it'll be tested again.
I have implemented a tableView with a searchBar added to it. I want to call a service when user start typing the search keyword in the search bar. I know that I can call the service in the change event listener that will call the service.
I know that for every change in the search bar it is not good to call a service. So what is the efficient approach of using search bar when the search result is coming from a service call or what we can do to make the search efficient.
For example: the search functionality on Apple's App store
I did something like this for one of my test projects. I would check in my change event that at least 3 characters were entered before I would attempt a look-up. I have no idea why I went with 3, but it seemed like a decent number of characters for filtering my data. I would also set a flag that a network request was in progress. So if they entered 3 characters, you could kick off the search if no look-up was already in progress. If there was a network request in progress, you could setup a wait interval to keep checking if the request came back and kick off an additional request when it is. I would send back short lists of items, which for me was 25 so that my table appeared fast.
Though I didn't do this, you could track the interval of time between characters typed to make sure the user is finished typing. For the best interval you will need to experiment with what is reasonable for an average user. Get some feedback from typically non-power users on this.
I can see a potential issue where you are in the middle of a look-up, but the user is still typing. You might need to track those character updates and perhaps kick off an additional search for the updated character string. You might even check the character search string you sent at the time with the current characters in the input box and choose to abandon the list of look-up items you already received and just do another search.
You might want to show the list of items you did receive just so the user knows the app is working, but immediately send another request for look-up items automatically. A user might eventually start hammering keys and think the app is unresponsive if you don't show something in the table once in a while.
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!
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.