Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Can anyone recommend a good IoC framework for iOS to facilitate dependency injection?
The only one I've found so far is Objection Framework which apparently is similar to Guice (which unfortunately is unfamiliar to me). Is this one a common choice for iOS and are there competing frameworks that are worth checking out?
Typhoon
The Typhoon-website lists the key features. A quick summary:
Non-invasive. No macros or XML required. Configuration is done using an Objective-C or Swift API that takes advantage of the Objective-C runtime.
Lightweight. Just 2500 lines of code. It has a very low footprint, so is appropriate for CPU and memory constrained devices. Tuned for performance.
Makes it easy to have multiple configurations of the same base-class or protocol.
No magic strings - supports IDE refactoring, code-completion and compile-time checking.
Supports injection of view controllers and storyboard integration.
Supports both initializer and property injection, plus life-cycle management.
Powerful memory management features. Provides pre-configured objects, without the memory overhead of singletons.
Excellent support for circular dependencies.
Battle-tested - used in all kinds of Appstore-featured apps.
An internationally distributed core team (we even monitor StackOverflow), so support for any of your questions are never far away :)
API Docs and sample app
API docs: http://www.typhoonframework.org/docs/latest/api/
We have some nice sample apps, including an Objective-C example and a Swift example.
...are there competing frameworks that are worth checking out?
Objection is the DI library I could find on google for iOS, so you might be stuck with it if you want a pre-built library.
DI doesn't specifically require a framework to use. If your app is small, you can simply create all your instances at the application root and inject by hand.
If you need more than this, and the existing frameworks aren't cutting it for you, you could roll your own Service Locator, then build a DI container on top of it.
You could also port an existing smaller framework from another platform. There are several "small" ones on .Net, for example - Ninject and SimpleInjector.
Is this one a common choice for iOS...?
It seems that it is a fairly small project as there is only one author/contributor listed. There aren't many issues filed. The iOS market is fairly large though. So I'm thinking that only a very small portion of all iOS developers use this library.
But this isn't necessarily a bad thing. It seems to be created, used, and supported by a small company. It has had fairly steady updates for the past year.
My anecdotal experience with similarly scoped open source projects: I don't always get new features super-often, and I'm often the one who ends up finding bugs. But I tend to get support on the existing feature set very quickly, and a lot of attention is paid to support e-mails I've sent. YMMV.
Well, I hope you forgive me a little plug here, but I just released my own DI framework for Objective-C: Syringe
https://github.com/tomekc/Syringe
It is simplistic and lightweight on purpose, my primary goal was to make it as not obtrusive as possible. I have a strong Java background, so I designed it after Google Guice and Spring.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm relatively new to RubyMotion development, but I already have an experience with iOS in Objective-C.
When I started using RubyMotion I found quite a lot libraries for that. There are some helpful libraries for networking, data storage and so on, but what confuses me the most are these layout (UI) libraries.
There are a bunch of them and the most popular are:
- SweetTea
- SugarCube (not really UI)
- MotionKit
- TeaCup
- RMQ (not only UI)
I'd like to now which of them are seriously useful and which one I should reject. I'm starting a brand new project from scratch so I am flexible what to choose and I want to start with most useful and commonly supported tools that let me easily develop especially layouts for iOS.
Can you suggest some must-have tools and libraries for RubyMotion?
Things most people use:
Bubblewrap
motion-cocoapods
afmotion (if you need networking )
motion-hockeyapp (or Testflight)
awesome_print_motion
From there, it depends. ProMotion is very popular, but some people want to be closer to the metal. My gem RMQ is popular, some people use it for everything (like we do) or just parts of it. Many people use ProMotion and RMQ together.
A lot of people use Sugarcube. It pollutes a lot of classes, so if you like that it's awesome with tons of sugar, if you don't it probably isn't for you.
Teacup is basically deprecated at this point. Use MotionKit or RMQ instead for stylesheets. I use RMQ of course, but MotionKit is really nice and I'd be totally happy using it as well. RMQ has grids, MotionKit has a very nice syntax and is less verbose. RMQ's stylesheets are more integrated with RMQ. MotionKit works in OS X and Android soon (RMQ is iOS only, although it should be portable to Android).
If you use Core Data, I recommend CDQ, there really isn't any competition to it (my company makes CDQ, full disclosure).
Normally people use a variety of CocoaPods, here a few common ones:
AFNetworking (this is the standard of course, and AFMotion uses this)
SVProgressHUD
JMImageCache
etc
I'd guess these are some common configurations:
Bubblewrap, RMQ
Bubblewrap, Sugarcube, MotionKit
Bubblewrap, ProMotion, Sugarcube, MotionKit
Bubblewrap, ProMotion, RMQ
Bubblewrap, ProMotion, Sugarcube, MotionKit, RMQ (used for events, animations, etc, not stylesheets)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We want to develop an application for iOS and Android smartphones. We are mainly using Microsoft technologies for developing our applications. We thought that if we would use MonoTouch and Mono for Android we would only have to maintain one code base with only a different UI layer for each device.
Because currently nobody in our small team ever developed a smartphone application and we need it quickly we want to outsource it. We asked other companies whether they perfer MonoTouch or Objective C for iPhone development. Most of them said, that the would choose Objective C. They said that Objective C offers more functionality and possibilities, it's faster and for MonoTouch there is a chance that Apple will not support it anymore in the future. Is all of that true or are there other reasons to prefer Objective C? I know there are other threads like this around, but they did not answer my questions, especially the one regarding Apple's support for MonoTouch.
applications. We thought that if we would use MonoTouch and Mono for
Android we would only have to maintain one code base with only a
different UI layer for each device.
this is a possibility IF you structure your app right. If not: no.
If you use Java+ObjC+C# (for WP7 / Win8 metro etc) then this is not an option AT ALL
Because currently nobody in our
small team ever developed a smartphone application and we need it
quickly we want to outsource it. We asked other companies whether they
perfer MonoTouch or Objective C for iPhone development. Most of them
said, that the would choose Objective C.
If you are outsourcing it, you should dictate what you want it written in, surely? If you need to support it in-house, and you only have C# skills, then MonoTouch etc makes more sense for you, the people paying the bills!
They said that Objective C
offers more functionality and possibilities,
FUD, and also incorrect. Monotouch has the full API available. If it's not there, as Xamarin to bind it (which they have done often before)
it's faster
I'd love to see the benchmark. Yes, technically, it can be faster in some circumstances, but in general use, MonoTouch the same or quicker.
Programmer error is a more common cause of iOS app performance problems. eg not getting things off the UI thread (which is easier to do in MonoTouch than in ObjC, tho blocks have helped that a lot), or taking too long to get out of FinishedLaunching (the "main" method, if you will, tho it's not really...)
Garbage collection and things like linq, xml/json parsing, generics and collections are also hugely valuable, and very quick.
and for
MonoTouch there is a chance that Apple will not support it anymore in
the future.
yes, there is a chance. There is also a chance that Tim Cook will run off with Apple's billions and buy all of Hawaii (rather than Larry Ellison's "I'll just have this island" purchase). But the chances are now rather slim.
Is all of that true or are there other reasons to prefer
Objective C? I know there are other threads like this around, but they
did not answer my questions, especially the one regarding Apple's
support for MonoTouch.
Apple doesn't support MonoTouch. Xamarin does, and they do it exceptionally well. Apple doesn't support anything except XCode, which is their product.
Apple DOES allow MonoTouch apps (there are lots). Another way to look at it: usually, 95% of the top 100 games are written using Unity3D, which is based on the same techniques (ahead-of-time compilation of C# code and embedding a cutdown version of the Mono/.NET framework).
There ARE reasons to prefer ObjC which would be:
You already know ObjC and CocoaTouch and like it.
Your team already knows ObjC and CocoaTouch or you can easily hire people who do (note: currently, as far as I know, iOS developers are CRAZY expensive to hire, if you can get them)
You need to use the beta's the day they come out. Keep in mind that you can use the current MonoTouch and deploy to your iOS[REDACTED] device with the beta on it. You just can't use the new stuff in iOS6 YET (Xamarin said "around 2 weeks" which should be about now...). Also keep in mind that you can not deploy an app to the store which is built with the beta SDK, even if you don't use any of the stuff in it. You can't even mention iOS[REDACTED] in your product description (I've tried)
you love [squareBrackets andTheOccasional:#"strange syntax things"];
Now, will building a cross platform, shared code app be an easy undertaking? HELL NO. It's a very complex piece of development for a non-trivial application. But thats the fun part of software development: if it was easy, it'd be boring! Grab Greg Shackles book ( http://www.amazon.com/dp/1449320236 ) to get an idea of whats needed for iOS+WinPhone+Android style development.
My hunch is that the companies you talked to simply are used to using Objective-C. That's where their skills lie, and that's the biggest reason why they would prefer not to deviate from their path. The other reasons can be argued both ways.
It's true that no one can predict what Apple will do, but there's a very small likelihood that Apple will ban third-party toolkits & APIs like they did in the summer of 2010. That was only a short period of time, and they completely reversed that decision. Their current focus is on making app development easier, which means keeping the field open to alternative development methods. I think MonoTouch is safe.
As for speed, C# generally produces very fast executables. They may not be quite as fast as Objective-C, but I doubt you'd notice a difference. I remember seeing a website somewhere that showed C# outperforming C/C++ in some tests, but that was in the .NET environment, not Mono... and unfortunately I can't find the reference anymore. I'll keep looking. But the bottom line on speed is that C# speeds are very good. It's not like BASIC vs C. More like Java/JIT vs C.
C# gives you many, many(!) advantages over Objective-C, and they have been enumerated in other Stack Overflow answers, so I won't repeat them here. You can find them easily enough.
I'm an obvious fan of MonoTouch, but I do have to say one thing: I think it's a mistake for companies to think that because they are fluent in C#/.NET that they will easily be able to develop and/or maintain iOS apps using MonoTouch. It's just not true, because MonoTouch is basically a C# layer over the CocoaTouch API, meaning that you have to learn the Apple way of doing things. You have app delegates and view controllers and all the UIKit stuff. There's a real learning curve there. But if you're fluent in C#, MonoTouch will be a huge help.
UPDATE:
I found the article on C# speed: Head-to-head benchmark: C++ vs .NET
I have actually used MonoTouch for every app I've ever developed. Performance has never been an issue, and I can't imagine how bad for me it would have been using Objective-C. I've had 2 top 10 apps in the US app store: "Draw A Stickman" and "Draw A Stickman: Episode 2" (don't worry we are working on more).
If you know C# and .Net your gains in productivity are going to be massive compared to what would happen trying to learn Objective-C. I was a C# .Net developer (Windows only) prior to iOS development and the transition to MonoTouch is great.
If you like Linq, parsing XML in fewer than 100 lines, garbage collection, generics, simple multi-threading, and no weird square brackets, MonoTouch is for you.
I use both Objective-C and c# (MonoTouch & Droid), and I really like both. When I'm coding in c#, there are plenty of features such as Linq which I'd love in Obj-C, & when I'm coding in Obj-C there are plenty of things I'd love to have in c#, but I adapt to whatever I'm coding in quickly enough. Re performance, I've detected no difference at all, even for fairly graphic-intensive stuff, so I wouldn't use that as a reason not to use c#.
I think it's ultimately down to what you're comfortable coding in, though of course with a well designed cross-platform project, you CAN have fully cross-platform core code if you use Mono, and you'll only have to do the UI stuff in a platform-specific way - when it comes to this obviously you'll need to know the native stuff to get your UIs working in a way which is appropriate to the platform and familiar to its users.
We have a line of business app that uses MS SQL as a data store, and has WinForms and web UI's. It integrates with our windows mobile 6.5 and tablet apps with web services. All c#.
We've fully committed to MonoTouch after some experiments in Objective-C and HTML-5 (we had working prototypes): we get to re-use our business logic, and we're comfortable developing new code in c#.
Our business logic is constantly being enhanced, and these enhancements are immediately visible to the mobile app - without having to replicate the logic in Objective-C or C++.
Our main issue is finding a c# programmer who's comfortable with the iPhone and iPad UI's.
MonoTouch is stable and we've encountered no limitations (we're binding to the same iOS API that Objective-C binds to). During our learning curve, we've had question, bumped into bugs and have had some misunderstandings - but the support from Xamarin is superb.
Performance has been a non-issue - our app is snappy even though it's doing a lot behind the scenes.
No body can tell you for sure what will apple support and what it will not support in the future, however apple had some issues with mono in the past, and since history tends to repeat itself, then it may be a possibility of that to happen again
Having said that, always go with the native application development SDKS and environments, it will be more flexible, and it will be updated real time, and performance will always be better in the native
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Please, share your favorite links on this language where one can learn the best of it.
And also, please describe in few words the most important features of this language differing it form others languages like Lua.
I just cannot understand why to reinvent another Lua/Python/etc. Maybe I just missed something...
But I like the idea of performance+scripting, so I have to understand it!
The best (and almost only) resource about the Squirrel language is it's official web site and forums: http://squirrel-lang.org
Compare to other well developed languages, Squirrel is still in it's early stage with a very small community, but it is very promising in certain ways among other modern scripting languages:
Inspired from Lua, with the usual concepts of tables, Lua stack etc, but with a MUCH cleaner syntax and C API.
Reference counting with supplementary garbage collector. The design of the run-time encourage the user to remove cyclic reference rather than totally rely on garbage collection (which can be slow or non-deterministic). The user can even re-compile the run-time with garbage collector disabled.
It's a language with C/C++ like syntax. It's kind of taste but it's the main reason of why I will favour Squirrel over Lua.
Build-in support of class, where in Lua you need to do some magic to simulate it.
Supporting C# like attribute, therefore you can supply meta-data to your class and properties. I use this feature to expose my script objects to .net property grid.
Undefined variables result in exceptions instead of silently creating a new null value like Lua.
Other features like lambda function, generator and co-routines are all built-in in this little but powerful scripting language which just made from ~6000 line of C++ code.
To conclude, the Squirrel language is suitable for interfacing with low level modules in a performance critical application (ie. a game engine), it absolutely can serve as a better Lua. Where as language like python is more towards a general purpose, day to day handy problem solving language.
emo framework, a free, open source game development framework for iOS and Android, is based on Squirrel. Its source code contains a few example programs/demos, as well as some library code written in Squirrel. Reading the source of them can be educational, I reckon.
I sincerely recommend having a look at emo for anybody wishing to learn the Squirrel language while having fun developing games or other apps for iOS and Android.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have been using Grails for the past few months and I really like it, specially GORM. However, I am getting interested into Scala's Lift. Therefore, I would like to know your opinion about which kind of web apps are better suited for which of those two frameworks or it is just a matter of taste, which framework to use?
Finally, which of those frameworks do you think will be more used in the future?
I have the feeling that Grails is far from reaching a critical mass and it still remains very obscure (in the past few months I had the opportunity to work with middle size companies and IT startups working mostly with the JVM stack and only one person knew and used Grails) and I am not even sure if it can become the "RoR" of the Java world (Indeed reports a drop of growth in the last few months even if other frameworks have a positive growing rate). And I love Groovy, it is really easy to learn but I have noticed how slow it can be for some tasks.
On the other hand, Scala seems to be more popular (Tiobe Index) and the fact that Twitter is using it now gave it even more presence in the blogosphere with lots of lovers and haters making buzz. It is famous for being fast and scalable. However, the language seems somewhat hard to understand and learn for lots of developers (so maybe it will never gain mainstream status). Lift is little known and I have read some reports that it is better suited for small apps (less than 20 domain classes).
By seeing the number of books published Groovy-Grails dominate right now, but many publishers have Scala books on the works, so I think this advantage will not last long.
Finally, we have the problem that both languages and frameworks still have poor IDE support (it is getting better by the day but far away from what Java shops expect to be productive).
I do not want to start a flame wars, but I would be very interested to hear other users' opinions.
The accepted answer here takes a really ignorant view on Groovy - it is a modern, dynamic language (dynamic vs. static is a huge debate in and of itself, and not particularly relevant here). This is by design, and therefore not a disadvantage, just a difference. It has a lot of modern language features that Java does not have such as closures, native regexp, polymorphic iteration, some optional static typing (matter of debate, but also look at groovy++), native syntax for lists and maps, etc.- you can see a comparison here http://groovy.codehaus.org/Differences+from+Java
To address the actual question of Grails vs. Lift, I'd say Grails hands-down. It has the SpringSource behind it, and just look at the plugins page http://www.grails.org/plugin/category/all - I can't even find what plugins or equivalent are available for Lift. Grails is also on top of the latest cloud-friendly technologies, with features like native RabbitMQ messaging support, and turnkey GORM support for MongoDB and Redis.
Grails is a nice idea(but only "stolen" from rails) but the fact that the groovy guys are not interested in getting proper Eclipse support is hindering it's success a lot. I've even seen Eclipse questions not being answered at all on the grails lists.
I agree with Tim that Netbeans 6.7 finally delivers the first half way usable Open Source IDE support for groovy/grails - and eventually, SpringIDE will also feature better groovy/grails support.
The reason many Java folks love Java is the static typing, which enables tools to help you a lot with many things. This is lost with a language as groovy.
Yes, I could write every really important piece of Code in Java and still use Grails - but then, why should I, just to save a bunch of lines of glue code, do that instead of learning to use a Java framework highly effectively?
To come to an end: I did not yet look at scala, but built some simple apps with grails - and I tend to go back to java, even reimplementing every app that needs further development in a plain Java framework - I think wicket and Seam.
I'll also look at Scala/Lift, I heard many good things about it!
BTW: I'd compare communities and look at mailing lists - how many peope are there, do they get good answers on their important questions?
Grails seems to have a non-answered rate from nearly 50%, which I feel is bad.
Grails support in netbeans 6.7 is really good, as well as the idea intellij support in Maia.
Eclipse is still pretty sucky.
I looked at lift, but was concerned about the resources available now; this will change in the future, but my projects can't wait.
I would like to specifically answer the question "for which kind of applications". The main difference between the philosophies of Grails and Lift seems to be that Grails enforces MVC whereas Lift seems to be more liberal i.e. it doesn't enforce MVC but provides enough avenues to use MVC if you want to.
Also Lift seems to be excellent for 'Single-Page Applications', especially if you need to implement a server-push functionality using technology like Comet (which obviously doesn't imply it's not good for other types of applications). On the other hand, Grails seems to be better for the 'Enterprisy' applications, especially if you are already familiar with Spring and Hibernate but want your app to be much more concise (using Convention over Configuration) than what a non-Grails app would be using these technologies.
References:
Simply Lift, chapter 13
Single-Page Application
Disclaimer:
I have just started exploring Lift and built some simple apps using Grails.
With all the performance improvements and advancements of Grails2.0, with great support provided by IntelliJ 11 for the framework, an ability to plugin pretty much any advanced web technology into your grails app., and yes - VMware weight behind it - I really don't see how Lift could be an advantage or a good choice. Just think of using two different languages in the same application, need for double expertise in the team, etc.
The original question has been posted like 2+ years ago and I think time showed on which side is the choice of the dev community ;)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Now that Google allows Java on App Engine, I'm wondering what effect this has on a choice of web framework for App Engine.
I realize Google provides the webapp
framework which is pretty barebones.
And the .96 version of django that's
available for App Engine is
restrictive.
web2py burns up resources, from what I've heard.
Rails (now available) can't use
ActiveRecord, ActiveResource,
restclient, rmagick.
Is there something I'm missing - do any frameworks work well on App Engine?
Actually web2py is very light and since ~1.50 on GAE, it caches all bytecode compiled models/views/controllers.
Nevertheless you need to consider that by default is has datastore based sessions and this may add some overhead when compared with framework that do not have sessions working on GAE (at least not by default).
The web2py DAL itself does not add a significant overhead when compared to the naive Google datastore APIs.
Personally, I have found Python to be more fun. That's just me. However there are several commited Java developers out there that will appreciate the Java support in GAE. Furthermore, supporting Java was a good choice by Google since it will allow the GAE platform to potentially host many other languages. It's obviously a little early to expect all JVM based languages to run on GAE, but the future looks promising. For now we can look at what is and isn't working by taking a look at this GAE Java Group Page.
Coming back to Python, I think small web applications will work great with the built-in webapp framework. Other applications will benefit more from Django 1.0. Have a look at the GAE articles under the frameworks section for a few good reads on this. In any case, you will undoubtedly have restrictions in any of your choices since most web frameworks are designed with relational databases in mind ... which datastore/bigtable is not. Furthermore, the GAE platform has to be sandboxed for security reasons which also restrict you to some extent. Hope this helps.
Try Spring. It supports JPA and JDO.
There's even a Python version for Spring now.
I don't know exactly the full range of options, but I can tell you a couple of things off the bat...
Google Apps is built on top of / using Django.
Django is pretty much what Google Apps cheer and support, so I'd expect it to integrate with Google Apps better than others.
Google Apps has restrictions built into it that you cannot circumvent (or shouldn't). These limitations are not related to any particular framework, rather they are built into the fabric of Apps, so to speak.
I wouldn't worry much about performance of the framework - try to improve your design/structure, it will certainly payback better.
Google will eventually move to Django 1.0 and newer, plus they are updating Google Apps too.
They do use memcache (or an equivalent) so take that into consideration and utilize it.
It really depends on what you want to do. In my experience something small hand made on top of Webob is really good for an API. But for full fledged sites that need templates/sessions/complex routing/caching django is hard to beat.
Take into account that if you huge frameworks (like django 1.0) the first request always takes around 3 seconds to load everything in memory and keeps it there until 15 secs after that request.
And while you shop around for frameworks take into account that:
ORM's don't apply to the platform so basically don't matter.
Fast templates (like Cheetah) won't be fast (or even work) as they can't use c extensions.
Caching might be the most important thing to make everything fast.
If you are looking for Python, then Django would be your best bet.
Struts 2 is purported to work on Google App Engine (at least in terms of the example applications). Follow this thread:
http://www.nabble.com/Google-App-Engine-support--td22972179.html
It appears that there are some issues with Sitemesh in terms of templating, but if you're using JSP you should be ok.
It's a good choice as a web application framework goes.
I recommend web.py if you're using Python.
I use new framework GAE framework. This is similar with Django, but work on AppEngine.
Best regards!
For Python use webapp2 (comes bundled with app engine)
If you want to build large scale application and need more flexible framework, then you can take a look at Pyramid Python Framework. Previously it is called as Pylons. There are lot of good companies using this framework.