I am trying to simulate a buy side client who could send order to an exchange, receive execution reports and further cancel / replace orders. QuickfixJ Banzai swing based UI seems like an ok fit given it’s free and our startup doesn’t want to spend a lot of money for this.
Currently the Benzai UI only has specific text boxes to send orders with fields for symbol, qty etc. I was wondering if someone has come across an extension to this swing UI example which takes messages in a freeform text area so that we are not limited by the number of economic fields exposed in the UI and could send any other fix messages in the text area.
Another tool that comes to my mind is http://fixpusher.sourceforge.net/
AFAICT it is not maintained anymore and probably is capable of more than what you want.
But if you have a little of Java coding experience, how hard can it be to add a text box to Banzai and call MessageUtils.parse() on its contents?
Related
Periodically, I like to send friendly text messages to large groups of people in my contacts. Sending the same message to lots of people is tedious, but I've never been fully satisfied with solutions offered by existing apps. So, I started developing my own.
I started with a Shortcut that works pretty well and has a few defining characteristics:
Messages can have "tags", such as for swapping in a contact's name, for a more personal touch.
Contacts receive their own personal text message. They are not part of a group message. No publicized phone numbers or delete-me-from-the-group bombs.
I can leave the process alone while it works; I don't have to confirm each message to send.
The whole process is serialized and persisted. If the process halts due to a faulty contact (like a disconnected phone number), I can resume the process right where I left off. No contact gets sent a duplicate message.
Shortcuts are a poor man's programming, though, and I was aching for a proper development experience. So I started learning Swift and writing an app to give me a more robust, UI friendly version of the Shortcut.
Alas, I fear I may have been eager. I haven't been able to find any documentation or examples of sending an iMessage or SMS text message to a contact without the need of some UI. MSMessageAppViewController is not what I want, because that sort of defeats the purpose of my automation goal here.
It seems very odd to me that Shortcuts would allow me to send text messages to a bunch of contacts without needing to confirm each message, and yet I can't do the same in a Swift program. Maybe I'm missing something?
This isn’t really an answer to your issue (I believe you can only use MSMessageViewController to send messages), but I did discover you can disable iMessage and Group Messaging and make it so when you send a message to a large group of people it sends them as individual, direct SMS messages.
I used this to send a text out to a group of 90 people without inciting a mass group thread. It was annoying to setup (and if you don’t set it up properly you’ll end up making a giant group thread which is scary) and you have to remember to undo the changes after, but it worked like a charm!
See this q/a: https://discussions.apple.com/thread/5211685?answerId=22908620022#22908620022
I have a project where I have 4 tab bars, and when i switched tabs, my api to get the API request to update my view is in the method viewDidAppear().
However this will make a very bad UX experience for user as whenever they switch tab, a loading icon and some times it load for 0.5 seconds but that instant appearance and disappearance of the loading icon is really bad for UX perspective. How can i implement a view where whenever the database value change, my view is automatically updating itself?
I have thought of using Timer() to implement where it calls the api every second but this is not practical as it will be constantly calling the API every second.
Does anyone have any suggestion? Thank you
There's a lot to unpack here, but I'll try to provide a generalized answer and point to several possible solutions to the UX problem.
There's several aspects that can play a role here:
Do you control the backend the data comes from, i.e. is it possible to follow paiv's comment and implement push notification? Or perhaps use some other means than pure HTTP(S) requests, like a websocket?
How frequently does data change? Is it realistic that it does so in between switching from one tab to another?
On that note, what do you do when data changes while your user is on one tab? Does that get refreshed in any way? Is it a problem if they don't get informed about this immediately? Is there a refresh button?
Do you persist the data beyond a view's on-screen time at all? Is it scrapped when a user re-visits a tab, i.e. does a tab always start "empty" until the API response is handled or do users see the values from the last time they visited that tab?
What best to do depends a lot on the exact answers to these questions. If you cannot enable the backend to do anything besides serving HTTP requests AND have to keep all data up-to-date constantly then obviously you have to do something like the polling you described. The update-interval depends on how important this is for your users. Even if it is 1 second, be aware that this means they could visit a tab before the next update has been fetched.
If you can adapt the backend and up-to-date data is a must, then push notifications or perhaps websockets are a way to go (keep in mind that websockets mean one open-connection per active user then!).
Push notifications would probably break down when the update interval is too high (i.e. if data gets changed in the backend very quickly and you keep spamming them), but would work nicely otherwise, plus they would update views that are already on screen if used correctly.
In 90 % of the cases I've seen, however, going with regular HTTP requests and a properly designed UI is the best choice. Properly decoupling the UI code from the data loading code and the code that displays the data is also very important. Here's how I would handle this:
Properly persist the data in some way in the app that does not require on views owning the data alone. If you want to persist beyond app runtime that means CoreData (or an equivalent), otherwise an in memory storage may be fine (that is kind of a global state then).
In your UI, show any data you currently have, even if it is "outdated" (in your case: "left over from the last time the user was on this tab"). Design the UI so that this is clearly apparent (grey it out, put tiny activity indicators next to the data while it is being loaded anew/updated, or something similar).
As said in 2. do show if the app is loading data. Initiating the loading when the users go to a tab is okay, but don't make a UI that is completely dominated by it (like one giant, empty view with a spinner on it).
Functionally, the loading should not directly update any views, instead it writes new data to your storage and just informs views and view controllers that they need to update themselves (if you're using CoreData and/or Combine you get a lot of this logic basically for free, especially for a SwiftUI app).
Such a design also lends itself to later being adapted for push notifications: While at first the re-loading is triggered by a tab switch (or a "refresh" button, for example), once (silent) PNs are available, they trigger the reloading. Even websockets can be integrated into this more or less, though there's probably a bit more to do that.
In any way, as said it all depends on your use-case and also available resources, but the gist of it is probably "If the current loading icon you have destroys the UX, redesign it properly". My gut feeling here would be that anything else might be over-engineering for your needs...
I have a contact flow that is using a pre-recorded voice prompt with a lex bot for voice rec. This is the main menu verbiage:
“Thank you for calling. If you would like to use your keypad to select the menu options, say “keypad”, otherwise please listen to the following menu options. For billing questions, say “billing”. To report a missed pickup, say “missed pickup”. If you are a current customer with recycling or other account questions, say “other”. If you are not a current customer, and have questions, say “sales”. To hear the menu again, say “repeat menu”. For all other questions, please remain on the line.”
I have set the error handling in the Lex bot to speak "Sorry, I'm having a hard time understanding you. Let's try using the keypad instead to make sure we route your call properly."
This is working when an utterance is not matched or an invalid option is spoken or pressed. However, I cannot figure out if it's possible to allow the lex bot to timeout like in a normal DTMF contact flow and send the caller to the next step in the menu without playing the error handling in from the Lex bot.
Is this possible?
That's the thing, Lex is not meant to be used this way. It MUST have an input to process, and if it reaches Lex's timeout, then it will always return an error and deliver the error handling response.
So you will have to get fancy in the Connect Flow to catch the Lex error message, and turn it into your own handling of it. But it will be hard to know whether Lex is erroring because it didn't understand, or because the user chose not to respond.
Therefore, I would personally avoid building the bot in a way that allows the user to remain silent. The user must direct Lex every step of the way and have easy ways of backing out of an unwanted action.
Remember that Lex is much more powerful than the old automatic call systems, so trying to force Lex into that old system won't work well. Depending on how you design your bot, you can make the conversation much much more natural, accepting a very wide range of responses and directing those into proper actions.
Tips:
Things may have changed more recently, but when I was building Lex/Connect, it was not possible for the user to interrupt a playback message. So I had to also avoid what you are trying to do in the welcome message:
If you would like to use your keypad to select the menu options, say “keypad”, otherwise please listen...
Naturally, a user who does want to use the keypad will try to immediately say "keypad" and probably get frustrated by having to listen to the rest of the playback message. So I design every playback message to be short, deliver information first, and always end on the question. Often breaking the conversation up into more branching points to make the questions as specific as possible.
Don't worry about going back and forth with the user too many times. It gives the user comfort knowing they are on the right path to what they want and are able to control the conversation in smaller steps. They will get stressed, having to listen to long list of options and remembering what they are while figuring out which one best applies to them.
So make each question as clear as possible and avoid spoonfeeding options. It feels less natural to explicitly state to the user what they should say:
To report a missed pickup, say “missed pickup”.
That is unnatural.
A good middle ground would be asking one question with a list of options and pausing between each option. The user will understand that these are responses they should make, but won't feel unnaturally pressured into exact phrases. For example:
Would you like to, check your billing, report a missed pickup, ask about sales, or something else?
That is natural.
We are comfortable handling those types of questions because we often do that when speaking with humans. You may even want to use a question mark instead of commas so that the playback voice uses a questioning intonation with each option. It looks less natural in written form, but would probably sound more natural.
Last tip: Don't design your bot based on your experience talking with bots. Design your bot based on your experience talking with humans.
I'm struggling with a problem of implementing dynamic search.
Here what i want to achieve:
In my application there is an option that user (program manager) will be able to search his team members. Each PM has its account on the server side (web service) where it is a table team_members which contains all the team members that correspond to this manager.
Their amount can be more than hundreds.
And client side app which I develop has an option search team members.
I want to implement it dynamically:
e.g When the user print first letter a I make a query to the server and get all the matches with a letter: Antuan, BArrow, etc.
Then user print ab and I make a query which must return Abraham, Abdulla, etc. And so on. All the matching results is shown in UITableView.
HTTP query to server is made each time text in UITextField shanges. I implement it with dispatch_async: on UITextFieldTextDidChangeNotification I create a dispatch_async where i make an HTTP request with searchbar.text.
The problem: it works very slow. I often get an exception bad selector was sent to the instance.
So my question:
Why is my approach bad? What is a better solution for this?
Or dynamic search it is a VERY bad idea and I must do search only on clicking some button?
Thanks. I hope some experienced iOS developers will give me good advice.
Making an HTTP request every time someone types a character is probably never going to be fast enough (nor does it really make sense -- read on). For a certain size of list, the answer would be to pull over the whole list in the background as soon as you present the field (but before the user starts typing in it). Once you have the list, you can start matching, in memory, on the local device. "More than hundreds" isn't very specific, and it depends on network speed, but I'd guess that if your list is less than 50K in payload size, pulling the whole thing will be the easiest way.
If the list is too big for that to be practical, but the list limited by the first character the user types is not too big, then the best approach might be to wait for the first character, fire off your HTTP request asynchronously, and only start the dynamic match once you've received the response containing all items that start with that letter. One thing to keep in mind is this: if you have the list limited by the first character, that's the only HTTP request you ever have to make (unless the user changes the first character) because all possibilities starting with that letter will be in that list. From there, you can pare down the list locally without any further HTTP requests.
As for why you're getting exceptions, it's hard to say without seeing your actual code. Try setting an exception breakpoint in Xcode. This will allow you to stop in the debugger when the exception is thrown, which will show you what's causing it.
My team communicates a lot with IM. We'll sometimes use IM to ask a question even to someone who's in the next cube over. The reason for this is that we all find that answering an IM is much less disrupting than talking.
Still, I find that the blinking message window can be disrupting when I'm heads down coding. I can't help but look at what people have written and it often keeps me from finishing my thought. This type of multitasking is a productivity killer. I've therefore turned off the alert feature (I'm using Pidgin). My Windows task bar is hidden so I need to drag my cursor to the bottom of the screen, let the task bar pop up, and look if the pidgin tray icon is flashing orange to find out about new messages.
This works well except that sometimes people have a quick question to ask for which they need a quick answer.
It would be great to have the ability to send priorities on messages:
Priority 3: Check this out when you can
Priority 2: Normal chat
Priority 1: Please reply quickly
The priority level would then be used to determine the alert method. E.g. (1)Give focus to window, (2)blink in task bar, (3)blink in tray.
Any ideas on an easy way of accomplishing this?
Thanks
We use e-mail or internal twitter for your Priority 3.
We use IM for Priority 2.
We use walking over to someone's desk for Priority 1.
Edit: I'm sorry I didn't realize you were asking an implementation question. If you didn't want to institute new policies/standards for methods of contact (ala introducing an internal twitter or the like), you would need to standardize everyone in the office on the same IM application/protocol. And then you'd need to modify one. Trying to add something into the jabber spec (if it doesn't have it, I don't know) would be tedious and not worth the effort.
If you really wanted to pursue that route, you would probably be better off moving to IRC and using scripts to alert you if people talk to you while preceding their message with a pound! or something similar.
I think that as soon as you introduce a "priority message" function, all messages will start to be high priority. Human nature. I just set my status to "busy" and don't reply to messages that come in when i'm "busy" unless it is important. People get the point quickly.
While I agree with the statement that being able to make certain messages a higher priority will result in ALL messages being high-priority, you can always just shut off the IM, and then people will have to actually talk to you. If they are on your team, they should know when you are heads-down, and take some personal responsibility in making the decision to disrupt you.
I do roughly the same thing that Codingscape does - I set my status to Away. Many clients will display an 'away text' message when your status changes, so I just use "I'm very busy" or a similar message.