Is three20 still actively being developed? From the three20.info site, I see no new features/UI elements since earlier this year when I looked into it.
Besides three20, is there another good framework out there?
As far as i know, Three20 is only maintained by community (bug fixes). Jeff left the project and decided to clean up that mess & provide solid documentation.
He recently started a new project on github called Nimbus, his plan is to port all features of Three20 to Nimbus without the problems we face today with Three20.
I haven't given up on three20 yet. It's a good framework and it saves me hours of work. I'm submitting bug fixes and small improvements to the framework from time to time and I see some activity in github. (not as much as it used to be)
I tried using nimbus, and I was really impressed with the documentation and existing classes. However, note that the developer went to work in CA and said he'll contribute less to his new framework.
The three20.info site is not maintained, but you can download the latest version from github.com/facebook/three20.
Related
Very little has changed in a while for BIRT. Since the project seems still heavily used, it would be interesting to know if there are future plans and if so, what is entailed in those plans. Subsequently, based on the development status: Is BIRT still a safe platform to base development on or is it expected to just be conserved in the current state such that occuring bugs probably won't get fixed?
We decided to use BIRT instead of Jasper 8 years ago.
We are still using 4.2.1 for development and 4.3.0 for production runtime.
I reported several bugs since then and only very few of them got fixed.
Furthermore, I developed some patches to enhance the word emitter output - with no reaction from any one at all.
I also developed a patch to allow kind of a vertical tab (to place something at a fix y position on the page (but not in the page footer). With my previous experience of the community, I did not publish that one.
I can say that while the source code is quite easy to read, it is nevertheless almost impossible to understand what is actually going on, because the functions are extremely deeply nested.
My conclusion with 8 years experience of using BIRT for production:
PROS:
BIRT is very powerful and flexible, you can achieve some very cool results.
The quality of the resulting PDFs.
There are only very few things I miss and cannot work around.
The runtime engine is very stable and fast enough, very few problems.
The community is helpful.
CONS:
From an open-source perspective, it is one of the weakest projects I know of.
New versions tend to introduce more bugs than they fix.
Bugs, ideas and patches from the community seem to be ignored most of the time.
Lack of internal code quality and documentation.
Update Dec 2021:
BIRT is back again!
The open source project is quite busy (see answer by Alexander Fedorov) and every help is welcome.
It looks like there will be a new release soon.
Until then, building BIRT yourself (with Eclipse 2021-09 and Java 11) has become quite easy thanks to the common effort of the community.
Metadata and information about the health of an Eclipse project can be found on projects.eclipse.org:
The Birt project is still alive, but not as active as before:
there has been only one release per year since 2016 and
in the last three months there have been more than 20 commits from 11 contributors.
Like all open source projects, the success of the project depends on participation. Therefore, I encourage everybody to report bugs and propose changes to Birt and other open source projects.
Update: Good news, Eclipse Birt has been rebooted. It is under active development again, there have been more than 100 commits in two and a half months and the release 4.9.0 is scheduled for March 16, 2022.
The Eclipse BIRT project has been restarted recently, and we are working to prepare Eclipse BIRT 4.9 release.
Contributors are very welcome. Here is the brief instruction regarding steps how to join this effort: https://eclipse.github.io/birt-website/docs/community
Latest versions of BIRT are not available in maven.
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 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.
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.
The Eclipse Visual Editor project seems to be dead, no commits, no updates. Any one know what is happening?
Update 2: The project has been archived (i.e. dead) since June 2011 again.
Update: The project has been revived and is now under active development again.
Its pretty much dead due to a lack of developer support. Here are some recent posts from their mailing list talking about a lack of movement on the project.
What's happening? It's called NetBeans, and it's already happened.
I'm going to get voted down for this but they know it's true. I love eclipse and have used it religiously since I started Java. I'm not saying I like Netbeans, it's just all I hear whenever the concept of a Java visual editor is brought up.
The Jigloo plug-in for Eclipse is a pretty great alternative to the Visual Editor. Though still not quite as nice as the Netbeans GUI editor it is fairly robust and fully featured, especially compared to what was available in the Visual Editor plug-in. Definitely should give it a shot.
Actually NetBeans has gotten MUCH MUCH better. I've used Eclipse, Netbeans and IntelliJ for a few years each, and NetBeans is at least as good (performance, usability & features) as the others now.
It's also improving more quickly than the others are.
They have people working full time on alternate language support, so you'll find they have the best Ruby support in the industry, and I believe Python is about to become that good as well.
Of course, Eclipse still has that crazy-cool todo list that remembers which files you worked on for each bug and can take you back to the set of files/edits for any bug you've worked on, that's really amazing to use and I don't think it's available on either of the other platforms.
--- Revision from years in the future ---
I have used Netbeans more and really have to give the award to Eclipse. The difference has been in vertical programming environments--most will target Eclipse and ignore netbeans. You rarely need these, but when you need them there is often no way around them. If Netbeans does have an equivalent, it's often buggy to the point of not being usable, generally the biggest issue is emulator support.
You won't run into these unless you are working in a specific industry--Android development is one, the primary drive was to support Eclipse, NB seems to trail. Another I've worked on is in the TV/Cable industry.
For raw java development, however, I'd still give Netbeans a little edge because it's the environment that was targeted and supported by sun.
Visual Editor is doing a new release, 1.4, on September 16. Installation instructions for the RC are here:
http://wiki.eclipse.org/VE/Update
FWIW, the project did stall for a while. But there is a new, and relatively diverse group of folks working on it again. Most of the recent work is concerned with making the new release compatible with Eclipse Galileo.
It's officially dead as of May 2011. It's archived here, but slow to download and tricky to install. Instead, there's a new editor, WindowBuilder Pro.
Currentlty Google have Open Sourced the Windows Builder Pro. It seems nice
yeap,
http://www.eclipsezone.com/eclipse/forums/t91368.html
Yes, sadly, it is dead. Looking at the aforementioned email threads regarding it's revival I get the feeling that even if it does get picked up it will quickly collapse under the weight of some new requirements ("make it universal, edit everything from SWT to HTML").
WindowBuilder can be a good alternative. I had several problems with VE and I end up with WindowBuilder who worked for me perfectly.
http://www.eclipse.org/windowbuilder/