After my user logs in the app pulls down a list of their meetings and adds them as UILocalNotification.
Each time the user launches the app and logs in this happens.
Which of the following is better "practice" when it comes to doing this over and over:
Pull all the location notifications with scheduledLocalNotifications then as I cycle through the downloaded meetings check to see if a local notification already exist for that meeting. If so, don't add it.
Use cancelAllLocalNotifications to clear all the local notifications and add them over.
It seems that #1 would be the right way but I'm concerned that if I have a meeting at the same time as another (it happens), it will view it as already added and won't add the new one.
Personally I would pull down the locations and check through them. It just feels tidier to me rather than destroying everything and creating it all again. Then again, #2 might be (negligibly) faster as you don't need to loop and check.
If you're concerned about #1 not matching where two meetings have the same time, you could add your own unique identifier to the UILocalNotification object via the userInfo property, and query this to see if the meeting is the same event, rather than basing it on the time of the notification.
If you have an unique token, say a UUID, for each meeting, the double-booking situation can be avoided. Put this token in the userInfo dictionary for the notification and then you can see precisely which meeting the notification is for. Comparison to determine the if this meeting has a notification queued already would best be done by this unique token, making sure the time of the meeting did not change.
Related
I have set up two referral credit rules.
All acting users get 7 default credits every time they trigger the event mq_app_open
Referred acting users get 10 default credits every time they trigger the event mq_app_open
mq_app_open is a custom event that I am recording on app open.
I can see that rule 1 is getting applied but can never get rule 2 to be applied.
What actually does "Referred acting users" actually mean?
I think the issue probably relates to the fact that when I open the app from a (universal) deeplink I see two events
open
mq_app_open
For each of Session Referring Branch Link ID, Session Referring Click ID and Session Referring Link URL are all null.
Oddly, when I let the app go into the background and then the foreground again I see the following events
open
referred session
For these two events Session Referring Branch Link ID, Session Referring Click ID have values but Session Referring Link URL is null.
I am not sure why any of these values are null when it would seem they should all reference back to the link url that was clicked on.
Alex from Branch.io here:
Referred acting users is a rather confusing way to say 'users who take action and open the app after clicking on a Branch link'. We should probably adjust our terminology to make this a bit clearer. For most purposes, you can think of this as Referred users.
I am actually not certain why rule 1 is working but rule 2 is not. Possibly there is some conflict with having two rules applying to the same user from the same event — you could try refactoring the rules so that Referring users get 7 points and Referred users get 17.
Those session parameters should be coming back with values, assuming a link was clicked. We probably need to do a bit more debugging to see what's going on — would you mind submitting a ticket to the Branch integrations team so that we can dig into the code and the backend config of your specific app?
I want to declare a winner of a game when ever its time expires.
is there any functionality in parse to perform an action on a specific time.
Qaiser,
As far as I am aware, there is no way to use a timer in the CloudCode on Parse. They have a 3 second timeout on cloud operations. I am assuming from your question statement that the time expires on a client device and then you want to use Parse to send a message to all other participants of the game that the time has expired and a winner has been named.
Personally, I would use a single timer in the "Leader" of the game to update "gameOver" and "winner" keys within a "game" object that holds all relevant data for your game. However, this structure is subject to the moving pieces within your specific game (without more information, I cannot suggest an alternative). In each client, I would use a timer to request an update of the "game" object every couple of seconds to keep non-leader users up to date. Once those fields have been set, then their clients know that the game has ended and a winner has been named.
I am unaware of any functionality in Parse to implement a model-observer scheme where Parse would automatically send an update to every observing client. If this is key to your game, then perhaps looking at Firebase would be helpful because that is integral to the way that Firebase structures its database scheme. However, the system is slightly more rudimentary and hierarchal than Parse, so it might not suit the rest of your application quite as well.
Hope this helps!
I am using HP Project and Portfolio Management(PPM) tool and I am adding a custom field in my request type which has date as value. Now my requirement is to send the email notifications to the users once the date mentioned in the custom field crosses the system date.
I had tried to set the notification for field level from Notification tab but not getting the custom fields in the list. All the fields, which is available, are pre-configured fields.
So, can anyone suggest me how to implement this requirement? And also where the changes need to be done If any required to implement this?
Please answer in detail and also reply soon.
Thanks in advance!!
PPM notifications can be configured on pre-defined events, like a certain transition, or timeout etc...
One possible solution for this scenario is to have timeouts on your decision step. Time out goes to an execution step, which checks for the date condition. If the condition is met it fires the notification. Else it just returns to the original decision step.
The downside of this work around is that there will be transaction details added once daily. Also the last update date of the request keeps updating daily, which is not ideal if you want to track what was the last time an end user update the request.
It is a workaround cause of the restrictions around notification events.
And if you have a large workflow, I would not recommend this work around.
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 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.