Now, I see many apps that will say "started using [Name of App] "Is that simply a call to StreamPublish or is there a new function call to achieve this?
I am currently using facebook to allow people to log in with their facebook accounts similar to turntable.fm and then going to my webpage. How do I make it so that other friends can see that they started to use the application, I have not been able to find this anywhere.
There is a setting on your application for "social discovery". Enable it and those posts will show up.
sorry, this is not an answer but clarification of the questions and answers (I don't seem to have enough points to be able to comment)
Firstly I'd like to say that if you are developing a Facebook app this would seem to be a very important question as it would have a huge impact on the virality of your app. It would mean that every single registered user is potentially advertising your app to each of their friends. Without out this happening your only options for viral spread through facebook are:
asking for 'publish_stream' permission and using the 'Post to wall' API call. Asking for this may deter many users from using your app in the first place.
User initiated sharing (like button, post to wall). Unless your app was amazingly awesome you'd be lucky to get a 5% rate with this (as opposed to the 100% rate you'd get with the mysterious 'started using' feed post)
I created a fake account for testing, created a facebook app (as a webpage, not as a facebook app/iframe), made sure social discovery was enabled, but I could not see any activity on my ticker or my feed. However, I did learn that there is a thing called the 'canvas ticker' which is completely separate from the 'main' ticker and can be seen when you use any facebook iframed-app. A notice did appear in the 'canvas ticker' but it said 'a is using b' not 'a started using b'. Getting a message on the 'canvas ticker' is not nearly as significant as getting a 'main ticker' or news feed post as relatively few people use 'facebook iframe apps'. I thought that this is what I must have remembered seeing (not seeing 'started using' in my news feed or main ticker), so I gave up worrying about it.
However, recently I started using Graph API Explorer http://developers.facebook.com/tools/explorer/ and a 'started using' post appeared in my alter-ego's news feed. That is exactly what I remember seeing with other apps ('started using' rather than 'is using') but it seems to be quite a rare occurance. I'm not sure if anything appeared in my alter-ego's main ticker.
Now I am really confused. This feels alot like figuring out how google's pagerank algorithm works.
update:
this link has proved quite useful: http://developers.facebook.com/blog/post/410
I think 'started playing' only applies if you app is set to having the 'games' category. Apparently these 'started playing' stories only show on the newsfeeds of people who have already started playing the game. So they can't really be of much use to gaining new users (as only user who are already using the app see it). However, the blog post states,
"By showing fewer but more impactful News Feed stories based on
friends’ activity and social context, we hope to drive new user growth
for games. For example, instead of the typical story saying that
someone just bought a new item, it could say “Dave, Jonny and 3 other
friends” just started playing a game."
I am really confused by this. How can the 'started playing' story possibly 'drive new user growth' if they only appear to people who are already playing??
The 'x started using Graph API Explorer' seems to be a really odd one. I think because it's an app made by Facebook it has special priority and that's why it showed as a story in all of my friends's newsfeed. I've been installing a lot of non-game apps to see if the 'started using' story appears but I could not find one that did. I'm now not sure if I ever remember seeing a 'started using' story. I installed games such as Farmville and Sims Social and yes i did see a 'started playing' story on my alter ego's newsfeed.
Why is that incredibly hard to find blog post above not part of the official documentation? And why doesn't the blog post explain exactly how things work with good and thorough examples instead of being really vague. I think every app should have an equal chance for viral growth without having to spend hours conducting psuedo scientific experiments with fake user accounts just to figure out how things works because the documentation is poor. I'm sure players like Zynga have the resources to figure out facebook inside and out but this is getting really frustrating as a sole developer.
This is why I'm hoping for a day when the prominent social network's code is open source. Nothing beats being able to directly read the source code when documenation is poor. That is one of the great things about open source.
Hey this is a common question I hear from my clients whom I write FB apps for.
It's called the FB User Discovery Story and it's automatic. Facebook eventually enables it for applications. There's nothing you can do to make sure it's displayed and it's visibility is effected by the evoking users privacy settings as well as the receiving users settings.
Also, note that it does not require your application being in the app directory.
The new facebook application interface allows you toggle the feature on and off but it still relies on the users settings as well.
Related
In my app, I've got a share button for facebook and twitter etc. I want that people can tweet and post the link of my app, but the app is not yet available in the app store, so i can't have a link to the app.
In some apps there is a link to the app if you are composing a tweet, how do they do that?
As H2CO3 pointed out, having that AppStore URL delivered from a server you control would likely be something you would prefer. Naturally, the first question to pop to mind would be something of the form 'Why do I have to use a server at all? Can't I just code it into my app directly?'
In short form, you are not required to use a server, but you may find that the benefits and flexibility it offers you in at the cost of a little more networking code and complexity in your app helpful. Let's expand on this a bit, by imagining we lived in the perfect world where we knew with 100% accuracy what that AppStore URL would be and that it would never ever change. We could get away with just coding that URL directly into our app and we would never again have to think about that part of our app -- it would always tweet the correct URL, users would be happy, and you as the developer can turn your attention to more important matters.
Unfortunately, things often don't work perfectly and as software developers we have to consider the ugly edges of reality and write code to handle them gracefully. Here are just a few of the potential problems with hard-coding a URL:
We don't actually know the full AppStore URL.
Apple may decide to change AppStore URL formats and render old URLs invalid.
Despite our best efforts to carefully type the URL into our code, we made a mistake and now we have to issue an update and wait for our app to be reviewed to get a simple typo fixed - Eep!
H2CO3's suggestion to use a server builds likely stems from experience in writing software coupled with developer's inherent risk management driven thought processes -- if there is something I can do to make my software handle these ugly edges more gracefully and make my software more reliable, it may make sense to take the extra time to implement my feature differently to protect it from the shadowy unknowns the future may have in store for my app.
For the sake of a balanced argument against putting the URL on a server:
If your users are in a place that has spotty cell or wifi coverage, they may not be able to connect with your server to get the AppStore URL from your server
Your server might not be working properly so it can't deliver information to your app when requested.
Adding a network request like this can be very easy to do, but also introduces its own set of risks to have to consider (isn't writing software great?)
As indicated above, you do not need to make your app snag the URL from a server you control, but you may want it to do so. Only you, as the app's developer, can determine what degree of risk you are willing to accept and which of the available options you've researched, invented, or otherwise acquired seem to fit your specific needs the best.
Since I don't know your background, I'm going to stay relatively high level and give you another couple of nudges in some directions you can go and do some additional research:
On the 'setup a server' idea -- you can purchase a hosting account from a number of hosting providers around the Internet or if this is a school or work project you may be able to speak with your IT people to request space for a website. After you have that setup, you can put a file on that space with a placeholder URL and write some code in your app to connect to your server and read your file (that has your fake URL in it!) the put it into your Tweet. Once your app is approved, you can change the fake URL on your server with the real one, and your App will work like you want. For the App part of things, you might look into some of the simple +stringWithContentsOfURL: methods on NSString (though do remember to consider things like what happens if the Internet is down, or if you don't get anything back from your server, etc.!)
On the 'just hard code the URL into the app' idea -- Apple makes some marketing resources available to developers even before they release an app. Checkout (https://developer.apple.com/appstore/resources/marketing/index.html) with an emphasis on the Shortlinks section, and also checkout Technical Q&A 1633 (https://developer.apple.com/library/ios/#qa/qa1633/_index.html). Both of these links give you information about how to build a link directly to an application or vendor on the AppStore given just their name(s). Like before, do remember to consider what happens if you ever decide to rename your app, or if linking elsewhere (or maybe nowhere!) would make more sense.
Hopefully this will help you think a little more about what you are actually trying to achieve, and give you a sense about what other developers think about when faced with decisions like the one you've posed here.
While i agree with Bryan i always avoided using servers for basic things. With ios 5+ you can send tweets from inside the app ( and you can add default tweet (i.e. a link to the app)
Your problem can be solved easily this way : make a short link with the link to the app store ( the link to the app store is formatted like this : https://itunes.apple.com/app/id <app id> , and the app id the the one in itunnesconnect under Apple ID )
For example you can make a default tweet like this : " Check out this awesome app!! goo.gl/buya " and then the user can edit it as he wishes.
Also..it's extremely unlikely that Apple will change the format of theyr links...too many users depend on this format to do..a lot of things
Looking at a lot of web applications (websites/services/whatever) that have a 'streaming' component (typically this is a 'Social' app): Think: Facebook's 'Wall', Twitter 'Feed', LinkedIn's 'News Feed'.
They have a pretty similar characteristic: 'A notice of new items is added to the page (automatically assuming via a background Ajax call', but the new HTML representing the newest feed items isn't loaded to the page until the users click this update link.'
I guess I'm curious if this design decision is for any of the following reasons and if so: could anyone whom has worked on one of these types of apps explain the reasoning they found for doing it this way:
User experience (updates for a large number of 'Facebook Friends' or
'Pages' or 'Tweets' would move too quickly for one to absorb and
read with any real intent, so the page isn't refresh automatically.
Client-side performance: fetching a simple 'count' of updates
requires less bandwidth (less loadtime), less JS running to update
the page for anyone whom has the site open, and thus a lighter
weight feel on the client-side.
Server-side performance: Fewer requests coming into the server to
gather more information about recent updates (less outgoing
bandwidth, more free cycles to be grabbing information for those
whom do request it (by clicking the link). While I'm sure the owners
of these websites aren't 'short on resources', if everyone whom had
Twitter or Facebook open in the browser got a full-update fetched
from the server every-time one was created I'm sure it would be a
much more sig. drag on resources.
They are actually trying to save resources (it takes a cup of coffee
to perform a Google search (haha)) and sending a few bytes of data
to the page representing the count of new updates is a lot lighter
of a load on applications that are being used simultaneously on
hundreds and thousands of browser windows (not to mention API
requests).
I have a few more questions depending on the answer to this first question as well...so I'll probably add those here or ask another question!!
Thanks
P.S. This question got trolled off of the 'Web Applications' site -- so I brought my questions here where they're not to 'broad' or 'off-topic' (-8
Until the recent UI changes to Facebook, they did auto-load new content. It was extremely frustrating from a user perspective, as you'd be reading through the list of your friend's posts and all of a sudden everything would shift and you'd have no idea where the post you were just reading went.
I'd imagine this is the main reason.
How/Where is the Wp7 AppRank stored/calculated from? A number of sites and app display it but where are they getting this information from?
A Code example (Its got to be a screenscrape from one of the official sites?) where applicable would be interesting
Take a look at Brandon Watson's post on crawling the Windows Phone Marketplace as a good starting place; http://catalog.zune.net provides xml data on the marketplace, and the information you're looking for (the application rank) can be retrieved through specifying the orderby as downloadRank as he's done, and the first app returned is #1, then #2, etc.
http://catalog.zune.net/v3.2/en-us/apps?clientType=WinMobile%207.1&store=Zest&orderby=downloadRank
Note that this post is a little old, so you may need to play around with the query parameters (like the clientType) to make sure you're getting the right data back. This post might also be helpful.
We should be able to access some of it so that we can edit the placement of each GUI object inside of CoreGui. So, other than security reasons, why are we not allowed to edit placement of GUI objects?
Also, why can't trusted users use CoreScripts? What if they need to access HttpGet so they can provide a nice display showing where their best friend is at the current time and place? SocialService won't always do the trick.
Can a developer (or any other experienced Roblox player, particularly one that knows the UI in and out) please answer these questions to the best of his/her ability?
I asked this in the OBC cast, specifically about editing the UI inside CoreGui. I'm not sure what security reasons could be preventing this, however. They did reply - the answer was, "Well, we definitely don't want you moving the little help icon, or the exit button."
I got the feeling the general reason is because users would become confused if everything was misplaced. For example, if you went into a website where you could play several games all made by that company (like ROBLOX), would you expect the exit or help buttons to me placed differently in every game?
They did say we will be able to change the colours.
Hope this clears things up.
Some GUI objects like the report abuse button we don't want users to have the ability to be able to remove. Another sensitive area is the chat window. If it was completely scriptable, you could write a script to make it look like another user was saying something that he wasn't. This is not really desirable.
HttpGet is currently a privileged function for two main reasons:
It would allow users to get dynamic content into levels, which would make moderation a more difficult task.
Poorly or maliciously written scripts could HttpGet roblox.com in an infinite loop, sapping our server resources.
There was no obvious benefit, but some obvious downsides. We prefer to solve only the problems that need to be solved in order to ship features, so we err on the side of caution for things like this. If we later decide to open up new functionality, like making the ROBLOX social graph available through an API, we can do that with a dedicated interface that limits the number of requests you can make to the website in a given period, and only return the info that we are sure we want you to be able to get.
It's interesting to note that for a very long time Adobe Flash player didn't support TCP sockets for the same reason.
I have built a little Web UI for Pidgin(respectively all libpurple based messengers) together with DBus and Sinatra.
It was for fun and learning purposes and now I'm looking for ideas to extend it.
Can you think of any useful applications or extensions for it?
Since I work on this project to learn something new, ideas for other technologies to be used/combined are welcome.
Finally here is the link: pidgin-web-ui
I few things that that might use to many many people would be:
good and simple to configure https support, so that users in "monitored" countries to be able to still chat freely (if the server is somewhere else).
Unified Message Archive . Many IM clients have various archive functions, but are different, limited, hard to search, and many are "client only", so not accessible when one needs them the most. Since Pidgin can connect to so many IM networks, it would be cool to have such a "global message hub archive". This would ensure that everything the user is talking is archived (very useful for businesses too), easy to search, available on a server (so always at hand).
File Archive on the server. The same as the Unified Message Archive, but for the files/images users exchange. Having them on the server (with a hash for easy sync) as a backup and archive would greatly reduce the traffic if they need to be shared more than once.
The would be many more nice features, that would help many users, but the above 3 seem to miss from usual IM software.
My idea after a brainstorming minute:
Dropbot
Create a messaging account anywhere and add this account as a contact to your messenger. This contact is your Dropbot.
Change your interpreter UI so it does not display a conversation but a log. In this way you can just drop things to the contact like interesting links. There could be a Dropbot for a read later queue, your favorite citations or for a list of funny findings.
You could then extend your UI to a little mashup. It could follow the links and grap the title of the page and a content preview just as Facebook does it when posting a link to your wall.
You could further extend your app by adding post-drop behavior to the Dropbot.
Dropbot could post your link (probably with a message) on Twitter or Facebook.
Dropbot could automatically distribute the link to the other contacts of it (like your friends)
Ok, that sounds fine... but you could do that without a message bot inbetween. What's the deal?
For me the advantage would be that my IM is always open and it would be fairly easy to drop a link. You could do the link dropping with Delicious or post stuff to a Google Wave, yeah. But I don't like to go to a web page, log in and organize stuff in the UI. Actually I stumble upon those links when I should do more important stuff instead. So just dropping it to my IM Dropbot contact would be cool.
Why not extend it to cover all the basic features of instant messaging (sending/receiving messages, adding contacts, etc...)? Seeing how many features you can reproduce may be a fun exercise. Create your own little Meebo...
Want to have fun?
Make a Markov-chained-based chatbot integrated into the web app. Make it use scraped web search results for the content, after searching for terms parsed out of the human's responses. That should be fun, and will give you funny, and sometimes eerily smart-looking results. Have fun!
I have seen your code. Why not split dbus_thread into a event_machine daemon for further scalability?
Integrate it with Twitter. Trace conversations (#Replies), including multi-party involvement. Log them. And so on.
Many interesting features and a popular, original API to learn.