How does the notification area on Facebook works?
I'm taking about the automatically red box that appears.
If I have a message/something new on my wall.
I believe it is also in Stack Exchange, is that a Javascript interval?
Please see this thread
How does one do realtime updates of a web page?
Not sure about this, but I'd wager that both Facebook and SO use an implementation of Comet. Basically, you make a request to the server which is designed to be kept open a really long time, and the server only responds when it has something to say. When the request times out (or receives data back) you simply start up another one. This way you get as close to real-time data as you can without wasting a ton of bandwidth on empty requests.
Related
For the google actions that i am developing some responses are complex and take more than 5 seconds to process.
Could someone please suggest how can this be handled.
Generally i would consider using loading dots and then replacing that message with the result but i don't see any Google Action API for it. Also is there any endpoint to which we could async send back the result later ?
Thanks
PS: I am using Conversation API.
We don't really have a good way to handle this right now, but we have a couple of approaches that sorta work based on your needs.
Notifications are currently available for the Assistant on smartphones, and they're coming for speakers. In some cases, it might make sense to say that you're working on the problem and you'll send a notification when you have it, and then resume the conversation from the notification.
Another approach is to use the Media Response to play a bit of "hold music". At the end of the segment of music, your webhook will get a notice that the music has completed. If you have the result available, you can report it at that time.
In my conversation dialogflow, I would like to add some progress messages like hang in with me, I'm looking up for that data or similar in the conversation. Is there any guidance or best practice to do this?
Unfortunately, there is no good way to do this at this time. If your webhook takes longer than about 5 seconds, Dialogflow will return one of the default responses it is set with. If you're not using Dialogflow, the Action SDK will say your webhook isn't responding and will close the conversation.
There is currently no way to send a reply, and then send another reply without the user saying something first.
One workaround might be to have the default response be something like "I'm looking that information up. Ask me again in a few seconds." When your lookup finally completes, cache the information so when/if the user asks the question again, you can return it more quickly.
Depending how long it takes, you may also wish to register a dynamic reprompt. This will send an event to your webhook if the user doesn't say anything. In a situation like this, they may say nothing for a few seconds, but that may be long enough for you to have computed the reply. So after a few seconds of silence you can suddenly announce "I've figured it out, the answer you were looking for is..." or something similar. This has some limitations - you can only reprompt twice like this before Google sends you a final reprompt and closes the conversation.
Although the platform does support notifications, these are still in developer preview and don't work with all devices. They also don't quite continue the conversation (it doesn't just start talking) - they just send a notification to a phone that there is a message and that they can restart the conversation. Depending on your use case, this may be useful combined with the above.
Update
The Media Response includes a feature that we can take advantage of to handle this. Similar to the dynamic reprompt method above, you'll get a call automatically when the media you're playing ends. So you can play a short "hold music" and your webhook will be called when it is finished. You can then either give the result or say you're still working on it and play more hold music.
I know there's a few questions knocking around on this topic but none quite the same.
I'm currently searching by location for all the pages relating to a particular geographic location and caching their events in a database. The problem being I have to currently loop through all the pages i'm watching frequently to check for updates.
At the moment the >10,000 Pages I'm keeping track of takes a good while to update. It would be much neater (and nicer to fb) to be notified instead of polling.
Does anyone know of a more efficient to do this?
Thanks
Ben
There is an API called Real-time Updates. You will have to register an http-server. Facebook will send a POST request with the related changes. You cannot subscribe to all connections but events are okay. I haven't tried it but it should work for you.
Searching for "[facebook] real time updates events" here on Stack Overflow gives 5000+ results. So I think, there should be some usable code somewhere.
I've decided to integrate OpenFeint into my new game to have achievements and leaderboards.
The game is dynamic and I would like user to be rewarded immediately for some successful results, but as it seems for me, OpenFeint's achievements are a bit sluggish and it shows visual notification only when it receives confirmation from the server.
Is it possible to change something in settings or hack it a little bit to show notification immediately as soon as it checks only local database if the achievement has not been unlocked it?
Not sure if this relates to the Android version of the SDK (which seems even slower), but we couldn't figure out how to make it faster. It was so unacceptably slow that we started developing our own framework that fixes most of open feint's shortcomings and then some. Check out Swarm, it might fit your needs better.
There are several things you can do to more tightly control the timing of these notifications. I'll explain one approach and you can use this as a starting point to explore further on your own. These suggestions apply specifically to iOS apps. One caveat is that these suggestions refer to internal APIs in OFSDK 2.8 for iOS and not ordinarily recommended for high level use and subject to change in future versions.
The first thing I recommend is that you build the sample app with your own product key. Use the standard sample app to experiment before applying the result to your own code.
You are going to get the snappiest response by separating the notification pop-up UI from the process of submitting the achievement. This way you don't have to worry about getting wrapped up in the logic for deciding whether the submission is going just to the local db or is doing the full confirmation on an async network transaction.
See the declaration of "showAchievementNotice" in "OFNotification.h". Performing a search in the sample app, you will see that this is the internal API used for displaying the achievement pop-up when an achievement is earned. It does not actually submit the achievement. You can call this method directly as it is called from "OFAchievementService.mm" to directly control when the message appears. You can then use the following article to disable the pop-up from being called when the actual submission occurs:
http://support.openfeint.com/dev/notification-pop-ups-in-ios/
This gives you complete freedom to call the submission at a later time provided you keep track of the need to do so. For example, you could locally serialize a flag to take care of the actual submission either after the level is done or the next time the app starts up. Don't forget that the user could quit out of a game without cleanly finishing a level.
I'd like to integrate something like a welcome panel (welcome screen) into our iPhone application to inform our users about updates and new offers when they launch the application. I have the following thoughts and doubts:
No user input required
Shows generic HTML without any action from the user point of view, the thing closes after 2 or 3 secs and has a close button if you want to close it manually. This is for advertising and tips.
This should be very simple to implement
User input required
Shows generic HTML with an action required from the user point of view, for example a survey. The user should be able to skip it
same as above, but is it possible that the user submits something on a HTML page and that causes also something to happen within the iPhone app (maybe via Java Script)? For example the user submits a survey on the HTML page and then app closes the current screen and continues to the next screen (i.e. the real application)?
Is it also possible to receive parameters (e.g. an ID) via a HTML website? e.g. if the user receives an offer on the HTML welcome panel, then he clicks on it and it takes him directly to a screen in the iPhone app with content loaded from a server (via JSON) depening on the offer id retrieved through the HTML page.
We prefer implementing it via HTML, because it gives us more flexibility. But I'm also open to hear other suggestions.
Thanks
Rengers answer is the correct one to accomplish what you want. However, the real correct answer is "Don't do that in the first place."
From a design perspective, a "Welcome Panel" or any kind of startup/splash-screen is a bad idea and the Apple Documentation tells you explicitly not to use them. Even for games, they're a bad idea that should be avoided if possible.
It's not a "Welcome Panel" it's a "wade-through-all-our-marketing-crap-before-you-can-actually-use-our-app" panel.
Mobile apps aren't like apps for regular platforms. Non-mobile hardware is faster so the obtrusive startup screens load faster and can be dismissed faster. Non-mobile apps tend to accomplish many task and people use them sitting down for prolonged periods. Users will tolerate a few seconds wasted clicking through startup screens so they can get into an app they will use for many minutes or even hours.
By contrast, mobile apps are often used by people on the go and in a hurry. The apps are small and ideally perform a single task. As quickly as possible, people need to be able to get into the app, perform what ever task the app accomplishes and then get back out again. If you're only using an app each time for 30 seconds or so, having to spend 5 seconds each time wading through startup screens is massively annoying.
Mobil hardware is slower and operations can take longer. Depending on its complexity and resources an app can take as much as 10 seconds to launch. In your case you want to add to a startup screen that has to load, connect to a url, display and then have the user perform an operation. That will take another 5-10 seconds minimum. So you're looking at users having to spend 20 seconds or more just getting into your app.
That doesn't sound like much but try mocking up your app and then using it on the go i.e. while walking, waiting for an elevator, going up the stairs, waiting for a red light etc. Test it in social situations. In the middle of conversation say, "Let me check on that" then take out the iPhone launch your app and try to get some information from it. 20 seconds becomes a very long time in all these circumstances.
Even shorter launch times are very annoying if you have to take some action every single time you open the app just to get to the functional part of the app. It's arguably even worse to spring a startup screen on them intermittently so they never know when they open your app how long it will take to get in it. User surprise is not good design.
Instead of forcing users to do something, you should embed advertisements and update notices unobtrusively in the app itself so that people can see them while they are using the app. In the case of advertising, this has the added advantage of putting the adds in view the entire time the user is looking at the app.
I don't know how many times some idiot from marketing has come in and started a feature request with, "We need to force the user to..." The only response to those types of request is to set the marketing weeny on fire. Do that several times and they'll stop trying to systematically alienate your customers.
UIWebViewDelegate has a method that allows you to respond to interaction in a HTML page:
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
Using this, you can catch any links clicked and respond to them in your application by presenting a different view.
Recieving parameters like an id can be done in a few different ways.
1) You can parse the HTML and determine it from the source.
2) You can have a javascript function in the HTML that returns the id. Call it by using
- (NSString *)stringByEvaluatingJavaScriptFromString:(NSString *)script
3) You can also use the delegate method I mentioned.
If you make a link like this: get offer you can catch it in the delegate and retrieve the id from the NSURLRequest.
I hope this will point you in the right direction.
If you do need some kind of startup screen a good option is to use the default.png. The app loads and displays that image before it does anything else.
It's usually used to display the illusion of the user interface before the UI loads completely. However, you could use it to display startup information. Since it displays almost instantly (within 1 sec) it does give your user something to look at while the app loads. In the case of a mock interface, it lets the user see the location of the interface elements and begin moving to activate them before the elements finish loading.
The catch is that the image disappears as soon as the first view loads so you have to load a view behind it that is a duplicate of the image (more ofter the image is screenshot of the view)
In your case you would need to dynamically generate the default.png when the web page updated. Upon launch it would display the information and buy the time the user read it, made a decision and touched the interface, the real web page would have replaced it.
Of course, this system won't work if you want new info at the start of each launch. Instead you'll have to generate the image during one run for use in the next.
In any case, if you launch into a web page the user did not select, I advise that you create a default.png that displays a message along the lines of "Checking for Updates and Info" (or whatever your doing) so the user won't think your app launched and hung.