I have been looking to switch to OAuth for my Twitter integration code and now that there is a deadline in less than 7 weeks (see countdown link) it is even more important to make the jump to OAuth. I have been doing Basic Authentication which is extremely easy. Unfortunately OAuth does not appear to be something that I would whip together in a couple of hours.
http://www.countdowntooauth.com/
So I am looking to use a library. I have put together the following list.
MPOAuth
MGTwitterEngine
OAuthConsumer
I see that MPOAuth has some great features with a good deal of testing code in place but there is one big problem. It does not work. The sample iPhone project that is supposed to authenticate with Twitter causes an error which others have identified and logged as a bug.
http://code.google.com/p/mpoauthconnection/issues/detail?id=29
The last code change was March 11 and this bug was filed on March 30. It has been over a month and this critical bug has not been fixed yet. So I have moved on to MGTwitterEngine.
I pulled down the source code and loaded it up in Xcode. Immediately I find that there are a few dependencies and the README file does not have a clear list of steps to fetch those dependencies and integrate them with the project so that it builds successfully. I see this as a sign that the project is not mature enough for prime time. I see also that the project references 2 libraries for JSON when one should be enough. One is TouchJSON which has worked well for me so I am again discouraged from relying on this project for my applications.
I did find that MGTwitterEngine makes use of OAuthConsumer which is one of many OAuth projects hosted by an OAuth project on Google Code.
http://code.google.com/p/oauth/
http://code.google.com/p/oauthconsumer/wiki/UsingOAuthConsumer
It looks like OAuthConsumer is a good choice at first glance. It is hosted with other OAuth libraries and has some nice documentation with it. I pulled down the code and it builds without errors but it does have many warnings. And when I run the new Build and Analyze feature in Xcode 3.2 I see 50 analyzer results. Many are marked as potential memory leaks which would likely lead to instability in any app which uses this library.
It seems there is no clear winner and I have to go with something before the big Twitter OAuth deadline.
Any suggestions?
I've used bengottlieb's Twitter-OAuth without issues.
Build+Analyse finds only one issue (in SA_OAuthTwitterController.m) and that's just a variable that has a value stored during initialization that is never read. I've not seen any leaks in my use of it. It was simple to implement and so far (two apps in the store using it, a third in development) no problems at all.
A new single-file solution is TDOAuth: http://github.com/tweetdeck/TDOAuth.
It's well-tested in that it is used in the TweetDeck iOS clients.
I recently had to implement "post to Twitter".
What I found was that none of the various projects would work out-of-the-box. They're all close, but not quite there.
Eventually I settled on OAuthConsumer, Stig Brautaset's SBJSon, with some ideas more than code borrowed from Ben Gottlieb's Twitter-OAuth-iPhone for pin processing.
I probably would have looked at MGTwitterEngine, but I didn't need to hit that much of the API - just status updates.
I seem to recall having to hack OAuthConsumer to set a few parameters correctly - that was the biggest stumbling block.
Try this Framework out for size: https://github.com/materik/meauth-ios, works well for BitBucket's API and am in progress of testing it with more sites. Please give feedback and contribute.
Related
Can we write the Feature files and step definitions in Swift Automation framework using XCUITEST Framework ?Is yes , Any jar files or plugins we need to install ?
I am unable to find much support in this
While this is not an appropriate question for StackOverflow, I will oblige you an answer with Cucumberish. I have used it in the past, it works, but I generally steer clear of third party frameworks as they add a layer of complexity and leave you in the lurch if they lose support.
I have worked a bit with CucumberSwift and got it to work fine, reading German-language Feature files and letting me define steps in Swift using all the functionality that XCUITest provides.
However, we have not adopted this in the end but are writing Feature files in Gherkin and then write ordinary XCTestCases that we link to the Feature files by mentioning Scenario names in comments. We develop the same functionality for three platforms and it was difficult to see how BDD tooling would work across all three or how we could make it work given the resources we have. Like Mike Collins we also felt that running without the complexity of additional frameworks was an added benefit.
Having said this, CucumberSwift seems promising, perhaps check out this discussion about documentation and add to it?
I need some of your help.
I searched everywhere on the internet, but I could not find how to create a plugin for Gaim, the predecessor of Pidgin.
I do NOT want to create a Pidgin plugin. I want to create a Gaim plugin, but since Gaim is very old, well, it is hard to find documentation for it.
(PS : If you know how to write a plugin for Gaim, please note I want to make one for Windows - not Linux.)
(PPS : I'm french. Sorry for my bad English.)
You're going to run into a number of issues here...
First off, Gaim hasn't existed for 15 years, and of course we (the Pidgin core team many of who got involved during the Gaim days) aren't going to support it for that reason.
Secondly, building on windows has always been a pain for us as we had to carry all of the dependencies. I imagine most of the links that you might find are all long dead because of the 15 years that have passed since that. That said you might be able to get away with using our win32-dev directory from https://data.imfreedom.org/pidgin/win32-dev.7z but of course that's completely untested and that directory is used to build the Pidgin 2.x.y releases.
Finally, as you've found out, most of the documentation from Gaim has been gone for a very long time. We did set up https://gaim.pidgin.im as a joke which was the last copy of the site we had before the rename, but there's not much there when it comes to development documentation. So your best bet is to look at existing plugins. I still have the source code for guifications1 available at https://keep.imfreedom.org/grim/guifications1/file/default.
Anyone please let me know what is this all about? I am stuck since a week on this and no help from searching. I posted my query to the developer of Alamofire but still no response. Please help! I am totally confused what is wrong in the integration of Alamofire. I have followed every step and this issue is coming with XCode 6.3 as before it was running properly.
When I am adding the Framework under "Copy Frameworks", it is adding the Framework twice showing different paths but when I am Going to there location, it is taking me to the same location. Here is the screen shot.
I have also created the video for that issue. May be that can help in a better way. Please see HERE
Moreover, latest SDK contains framework for MAC OS as well but I didn't add that. I hope all the above information will help you in helping me. Thanks!
This is going to be incredibly difficult to debug without a sample project that is set up in the same manner as your actual one. If you had imported Alamofire project into your project, you wouldn't see two versions of Alamofire appear when you add it to the Copy Frameworks build phase. If you truly want to resolve this quickly, you have two options.
Option 1
Push up a sample project to Github and link it here. We can then take a look at the project and pretty quickly access what the issue is. The main reason it's so difficult here is that there are roughly 10 different things that could be the cause of the issue. Therefore, it's much faster for you to create a sample project than for us to go round-and-round (which we've already started with #Masterfego).
Option 2
Take the leap and try out CocoaPods. It is a fantastic dependency management system that will forever alleviate these annoying types of project management issues. CocoaPods itself has fantastic documentation. Also, the Alamofire README breaks down in detail how to add Alamofire to your project using CocoaPods.
Recommendation
I would highly encourage you to choose Option 2. That is definitely the fastest way forward and you won't regret moving to a more robust dependency management system. It makes managing library updates and new installations extremely simple.
If you do end up going with Option 1, then I'll take a look at your sample project and revise my answer.
I've just started getting into Catalyst, and I've been finding it really helpful. One of my favorite things about it was TTSite in that it got me going fast and gave me something to develop with without just black text (and it required no work from me to setup). However, I've been reading in a lot of places that it's buggy, or even deprecated as mentioned here on the actual Catalyst tutorial. However I've found it nothing but helpful and have had no issues, so basically I'm wondering is there reason for me to be worried and not use it? And if so, does anyone know of a similar alternative that kind of gives you a base template set up to work within? Thanks a lot!
I don't think TTSite is officially deprecated in terms of support .. it is still included in the Catalyst::View::TT distribution as of 0.39 (released 10-April 2012). I suspect it is more a case of some developers disliking the base templates that are provided and TTSite no longer being recommended as part of the default Catalyst tutorial.
TTSite provides a very simple base that has some quirks. For example, the context object is called Catalyst instead of c, and the use of TT's WRAPPER command can get in the way of AJAX and non-html views.
More background reading:
Discussion on the Catalyst-Dev mailing list regarding changing the Catalyst tutorial from TTSite to straight TT
Catalyst wiki: disabling TT wrapper for AJAX requests
A blog post on TTSite including changing Catalyst context reference to c
A modern base theme would probably start with something like Bootstrap or one of the 960 Grid HTML/CSS frameworks. I'm not aware of an actively maintained Catalyst::View helper that would be a better replacement for TTSite, but also don't find it too onerous to drop in the latest version of Bootstrap :)
The home page for gchart, a client side charting add-in for Google Web Toolkit (GWT), has a long screed about how the project's only maintainer thinks his Google account has been hacked and because of that he will be "disavowing/abandoning my own project and Google account". Does that mean the project is an orphan? Is somebody taking it over?
There is always a risk on basing your project on somebody else's code because they may stop supporting it or abandon it during your project's life time, but it seems to me that with the fast evolution of Java and GWT, using gchart in a new project may be a big mistake. Am I right?
I've released Client-side GChart 2.7 in a brand-new Google Code project (untainted by the previous rootkitting of my laptop) that you can find here:
http://clientsidegchart.googlecode.com
For details on the new security-related improvements I've instituted in an effort to prevent a future breach, follow the "release notes" link on the home page to the GChart 2.7 release notes.
I wish it had not taken me so long to re-release. I was attempting to correct the part of the problem that was under my direct control: my deep ignorance of all things related to computer security and systems administration.
I encourage you to give the re-released, better-secured and administered, Client-side GChart 2.7 a second look.
John C. Gunther, Client-side GChart author
I would have to say so. If the only maintainer of the project has lost control of his account, using any subsequent versions of gchart could mean you're implementing malicious code un-knowingly.
Unless he spins up another project to move the code-base forward, I'd avoid it.