I have had an app for a long time now, there are a few hundred people who play it daily but I no longer actively do Facebook development.
Today I got a bunch of emails complaining it no longer works, sure enough it's just a blank page.
I don't want to rewrite anything and am looking for the bare minimum I can do to get things rolling.
I have no desire to upgrade my Facebook library. I use $facebook->require_login() which seems to be where the problem is.
It is an FBML app and viewing source shows that it has outputted the correct JavaScript redirect it just simply does nothing.
Previously I had turned a bunch of options off in the app settings to correct other problems created by constant updates but now it seems they no longer give that option.
https://github.com/facebook/php-sdk/blob/master/examples/example.php is about all you need to know.
I didn't upgrade some functionality (some fql queries etc) simple because they are not critical to the application although I don't think that would take much longer.
Less than an hour to get things rolling.
Related
I don't quite know if my question fits here, but I don't know who else to ask...
I recently upgraded my socialengine plugin, which should allow me login to my site via Facebook. The reason I had to upgrade it because it didn't work anymore since Facebook changed the API (API-KEY --> APP-ID). I think this was around 2010!?
Now I bought the latest version of the plugin, just to find out that it still requires an API-KEY. Their support told me that it's not supported anymore because the version of my CMS is not supported anymore (nice to find that out after paying for it). However they offered me to make the plugin work for me, if I am willing to pay, with a hint that due to the massive changes in the API it will need a lot of work.
To come to my question: Have there really been such massive changes? Has a task like logging into a site via Facebook become that different? I am coming from a programming background, may i be able to fix this myself?
The Facebook API is constantly evolving with breaking changes all the time. 2010 is a long time ago for the FB API, so it sounds likely it'll be a lot of work updating the plugin (if the required API features are even still available!)
I want to build simple web based app, where users, for example, could push the spacebar button, and then do something further, like answer a question, and while other users at the same time only sees that this question is not available any more for answer. When user submits answer, everyone see it.
All right, here is an example. I have seen TV shows, where four players have one button, if one or two of them know answer, they hit a button, and one lamp turns on and the first is allowed to answer, while other keeps their mouths shut. I want to build the same idea, but in the web.
But problem is that, I don't know where to start, what keywords I should search for help on google and so on. I see, that it might work on HTML5, maybe JavaScript and so on.
I have idea using Ajax, but request it every second to get latest actions made seems rubbish. Also I found one service called Pusher, but it has limited users in one time, which doesn't fit my needs.
I need just ideas. Thanks.
Before you read the rest, a disclaimer: I work for Realtime.co but I do believe I can help here so I'm not trying to "pitch a sale".
You can check out Realtime (www.realtime.co). It's basically a set of tools for developers to use real time technologies on their projects. It uses websockets but does fallback to whatever the user's browser supports (such as long polling, for example).
Behind Realtime you have a one-to-one/one-to-many/many-to-many messaging system that will transport your messages to and from your users.
There's also a plus which is the fact that the Realtime framework is actually cross-platform. This means that you can even have your web users communicate with iPhone users, Android, users, Windows Phone, desktop applications, server applications, etc..
You can learn about the JavaScript API here: http://docs.xrtml.org/getting_started/hello_message.html#javascript.
You only need to register at Realtime.co as a developer and start using the free license.
I really hope that helps.
Okey, I think I will go with node.js.
Writing all this previous post, made me think in right way :)
We are looking at building a b2b application for the iPhone. A major concern is the possible delay in publishing updates to the applications. I would like to believe that all updates will be orderly, but the reality of a newly found bug for a client or an upcoming trade show could mean that updating the application NOW is critical. Even an "expedited" day wait would not be acceptable.
One option I have thought of is having a flag for each page that we send down when the user logs into our server. If the flag is set, then instead of the native screen for a given page, there would be a page with a UIWebView that would get the latest HTML from the web or stored HTML loaded at the time of login.
I would prefer storing the HTML and using it "offline" because a data connection cannot be guaranteed.
The questions are:
1) Does this violate any of Apple's licensing?
2) Is this feasible or is there a hole I am not thinking of?
It doesnt violate Apple's guidelines and as far as I know you are not missing anything here...in fact, we have the exact same problem in my company (which on top of the issue that you have, we have customers that would like to "brand" the app for their users, and thats how we accomplish that) and there are no issues with apple (for now...:)). Obviously, you need to think of user experience implications...hope that helps.
I am about to start a new project in the Google Analytics API & PHP.
I read that Google Analytics will be deprecating XML v2.3 and v2.4 and in 6 months time, so aparently you will only be able to use v3 and retrieve information in JSON format.
http://analytics.blogspot.com/2011/12/introducing-google-analytics-core.html
My question is the following: Does this means that GAPI class won't work any longer? Anyone who has used this class before can help me answering this question ??
http://code.google.com/p/google-api-php-client/
In that case, any alternative suggestions of PHP classes that do the same thing.
Thanks so much
I've been using GAPI for a while now. And I can say with some confidence that yes it will break, if not due to XML it will be due to some other change google makes.
Having said that GAPI is the best solution I have found out there for php. It does break every 6 months to a year, usually needs one or two lines changing to fix. But GAPI is pretty popular so at least you know when your clients are calling saying analytics is throwing errors at them, you wont be the only dev tearing your hair out.
9 times out of 10, by the time I've got a problem someone else has found the fix - which is nice.
There are a few other php options out there but GAPI seems to be the most popular (usually the best way to go imho)
My approach is to build an analytics summary in the dashboard and provide a link to google analytics underneath so clients can see the full data or go there when GAPI breaks. I have been putting all my sites on the same modular system for a while now. I keep GAPI as a library in my admin layout module, this means I can make the fix once and roll it out to all my sites without too much drama.
In summary, use it but expect it to break - that way you wont be disappointed when it does.
I'm scratching my head over this.
I have a moderately successful app which has a free "LITE" version in addition to the full one. This is a utility app, not a game with levels, and I'm having trouble figuring out what Apple will accept for the lite version. The reason this is now an issue is that I've brought both code bases together with different targets and my new improved lite version will be iPad compatible as well.
There are two fundamental differences in the versions. In the lite version, the data displayed is only displayed for the current day, whereas the full version allows users to choose any date. Additionally, one of the data screens shows 3 data points in detail, whereas the full version shows much more. The lite version is perfectly functional in its own right and has no greyed out features.
What I would like to do is use the spare space on the lite version data screen to explain that more data is available in the full version and offer a button to upgrade, however I can't figure out if Apple will classify this as "upselling" (well how else am I going to mention the full version?) and from reading the new app store review guidelines, I was disappointed to note that absolutely no further clarity seems forthcoming from Cupertino in this regard. All the examples I find from Apple are games with additional levels and this simply doesn't match a "utility" application.
Is there any recent advice on what is and what is not allowed? I'm aware of not having greyed out functionality and nagging the user - but does having an upgrade button on one of the tabs (in the case of the iPad in a popover) count as nagging? Am I allowed to mention the additional features in the premium version or does that count as upselling? If not, what can I actually say?
Clues welcomed!
Frankly speaking, there is no way to be 100% sure without submitting the app. There might be someone who have already tried this and get rejected. It's not very easy to be sure. But as a user personally I won't be happy to see the upgrade button in every page. Rather I would like to get the summery of full version in a different page. This might not be a better design to have an upgrade button in every page, though this is my personal opinion. Apple gives importance to be consistent with the convention, and the convention is to have different upgrade page, I think.
You can download a number of lite apps and check whether any one has done this kind of thing. The policy should be same for both game and utility. If after checking many you don't find a single one, then you should reconsider this. But yes, you can't be 100% sure.
The rules appear to be inconsistently applied.
I think it boils down to the perceived difference between "Ha! You don't get $feature unless you pay us!" and "By the way, we also offer $more_expensive_app with more features." The two are effectively the same thing, but they leave a different impression. Yes, it's a big grey area — I've seen apps across the spectrum (I don't recall any persistent nagging/mentions, but certainly "buy $full_app to get more levels").
"Other apps by $company" might be a good way to go, perhaps in an "about" tab or similar.
Reviewers are also far from consistent. Before Apple did any "private API" checks (they didn't seem to until mid-2009; apparently not even the frameworks you linked to which is dead easy), private API usage was determined by whether your app did anything in $list_of_suspicious_behaviour, which seemed to be applied inconsistently by different reviewers.
I've also used "$full_app" because that's the impression I got; I think part of the guidelines is that you're not supposed to give the impression that your app is not "full". I also hate crippleware (artificially limiting a feature, e.g. a navigation app limited to 8 waypoints and telling you to buy the full version if you want more, as opposed to simply not including a feature), but Apple doesn't seem to mind.
Apple allows ads in apps if they are presented in a reasonable manner.
Developers can choose which ad network to run, even from competitors such as admob.
There's nothing to say you can't be your own ad network.
Just make sure your ad for your products (which occasionally just so happens to be an ad for the full version of the same app) follows the same presentation rules as the ads for admob, iAd, etc. follow. Your own ad network may or may not be the campaign you choose to run during the review period.