Related
My scenario: trying to port a small part of an application created by our company from native code (ObjC for iOS / Java for Android) to C-Sharp. The project will interact with our webservices. Goal of this project is figuring out how feasible it is to port our whole app to Mono.
To create URLs, I'd like to use String.Format(). I thought it'd be a wise idea to put this 'service layer' inside a Portable Class Library (PCL) since I don't expect this code to change across platforms. Sadly, it seems the String library is not available for PCLs.
So my question is the following:
I think the main advantage of PCLs over "normal" libraries is that they shouldn't need a recompile for different platforms. Is this assumption correct?
This experience makes me think that for the moment PCLs are rather limited. Should I try to stick with PCLs and work around these kinds of issues, or might it be better to stick with a "normal" library for now? --- I'll assume the "normal" library has more functionality exposed.
You can use PCLs currently across many platforms, but it does require some small hacks to your setup.
These hacks are listed in http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
Once you've got those working then the functionality available is quite broad - and it definitely includes things like String.Format
For the situations where the PCL profile is not broad enough, then you can use several techniques for extending them - see http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx . The technique I generally use is to use MvvmCross Plugins - which are basically PCL interfaces with platform specific implementations. But these plugins are generally at the level of 'make bluetooth work' rather than at the level of String.Format
I do lots of PCL work across WinRT, WP, WPF, MonoTouch and Mono for Android - see http://slodge.blogspot.co.uk/p/mvvmcross-quicklist.html for lots of links to PCL work.
It's true that Xamarin have recommended not using PCLs for a couple of years, but that situation has now changed and the official support for PCLs is under way - see http://slodge.blogspot.co.uk/2013/02/the-future-is-portable.html
From a development perspective - especially from the point of view of using refactoring and testing tools - I don't hesitate to recommend you use PCLs now... especially for operations at the String.Format level. However, each project is unique... so it's not always the right answer.
One important note: right now it's better to not reuse the PCL binary files across to the MonoTouch platform - for now, build your portable libraries against the specific MonoTouch library platform. See http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html?m=1
Perhaps you want to look at the efforts other who have got PCLs working to a considerable degree with monotouch and monodroid.
For example see http://www.slideshare.net/cirrious/mvvm-cross-going-portable . You'll also find instructions on how to setup PCL support for MVVMCross here http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html .
Xamarin has recently committed to providing far greater PCL support rather than some of the workarounds that people have been having to make, but it is worth the effort.
I just caught one of Google's commercials for Chrome where at the end they mention that it runs on Linux, Mac, and PC. So I started wondering how they are able to develop a program that can run on multiple platforms like that? I have experience with Java, and .Net but only on a windows machine. Java is by design portable, but I wouldn't think Google is using Java for something like Chrome where performance is such a concern.
I understand that each version is going to have some platform specific code, such as for the UI. But there must also be some central code that is reused across each platform. What language is this written in?
Here is an entire article about the development of Chrome. It's mostly written in C++.
Chrome is written in C++, so they will have a significant amount of platform-specific code for each OS. They most likely maintain a separate branch for each OS.
Any reasonably standardized and popular language will do, because the goal is to compile it on all platforms, not create one binary that will work on Windows, MacOSX, Linux, and z/OS. C and C++ are popular choices, because they'll work readily with pretty much anything. Java is a good choice, because it runs on pretty much everything. For applications with low performance requirements, Perl and Python are good.
The important point is to separate out what is platform-dependent from what isn't, since (except in the case of Java or scripting languages) it will probably be necessary to rewrite platform-specific stuff for each platform, and not necessarily in the same language. MacOSX is best programmed in Objective-C, and that's true for no other popular platform.
The programs are supposed to be portable in source level, not binary level. So you only need to compile it for different platforms, not necessary to make one universal binary. In fact, most languages are supported in all modern platforms including UNIX/Windows/Mac, so you can choose from almost all modern lanagues, which C/C++ is prefered by many people. BTW, C++ is the language of Chrome.
Scripting languages like Python/Perl are also good choices. One more thing, Java can be faster than you think - see Eclipse. Even without JNI Technology, Java is still good enough for most applications like JDownloader.
Google had to build different distributions for each OS (ie compiled for each platform as Francis's answer explains) - in fact the Mac OS version only recently became available - the Windows version has been around much longer.
Google Apps are 'thin applications' - the grunt-work is done on their servers.
The Apps are portable in the sense that the front-end is put together using HTML, CSS and Javascript - which are standard (in theory at least) across all browsers.
Google put a lot of effort into building Chrome's Javascript engine to be performant - to ensure any client-side logic is run quickly.
I've been developing for Windows and *nix platforms for quite some time, and am looking to move into Mac development. I am tossing up between using ObjC/Cocoa and C++/Qt4.5.
The C++/moc semantics make more sense to me, and improving knowledge in Qt seems like a sensible thing to do given that you end up with a skill set that covers more platforms.
Am I likely to handicap my applications by skipping Cocoa?
The sample Qt applications look pretty Mac-native to me, but they are quite simple so potentially don't tell the whole story. Are there other pros to the Xcode way that Qt doesn't have, such as packaging, deployment, etc.?
Here's an easy way to answer it:
If you were developing a Windows app with .NET or MFC, would you handicap your applications by using Qt? If the answer to that is yes, then the situation is likely to be the same on the Mac.
A few negatives I can think of off the top of my head:
Licensing
Qt apps, while good, are not completely a native UI experience and there's things a native UI designer can do in Cocoa which boggle the mind. While I can't be sure that all the same functionality isn't available in Qt, I doubt it.
Qt is always a little behind. If Microsoft or Apple come out with a great new technology, you have to wait for the Qt developers to update Qt.
However, with all that said, only you can determine the business value of using Qt. If you think cross-platform development is going to be a major part of your development, then Qt might be worth it, despite the issues mentioned.
Ask yourself: how many of the best Mac applications that you know of use Qt instead of native Cocoa?
For our robotic systems, we originally wrote our control software in C++ using the cross-platform wxWidgets library (we avoided Qt due to some licensing concerns), because we felt that we had to target Windows, Linux, and Mac platforms for our end users. This is what we shipped for over a year until I started tinkering with Cocoa.
Right away, the thing that most impressed me was how quickly you could develop using Cocoa. Eventually, we decided to drop support for Linux and Windows and rewrite our entire control applications in Cocoa. What had taken us years to put together in C++ required only three months to completely reimplement in Cocoa.
Aside from the "lowest common denominator" interface issues that others have pointed out, the rapid development allowed by Cocoa has become a competitive advantage for our company. Our software has advanced far more quickly since our conversion to Cocoa, and it has allowed us as a new company with one developer to pull even with 10-year-old competitors that have 20-man development teams. This appears to be a common story in the Mac development space, where you see a lot of small teams who are able to create products that compete with those of much larger companies.
As a final note, using Cocoa gives you the ability to stay on top of the new APIs Apple is continually rolling out. We're now working on a new control interface that will make heavy use of Core Animation, something that would be painful to deal with using Qt.
I'm currently developing both with QT (actually PyQT, but it makes no difference to your question) and native Cocoa app. For me it's no brainer, I'd chose Cocoa. It's really worth time to explore Cocoa in general, there are many great concepts within the Cocoa framework, and Objective-C 2.0 as well.
I'd use Qt if you want this to be a crossplatform application.
You can have a look at the QMacCocoaViewContainer class. It acts as some kind of wrapper for generic Cocoa views, so you can also have Cocoa elements which are not officially supported by Qt.
Of course this means learning a little about Cocoa and Objective C and how a Cocoa UI would need to look like. But if you already know Qt well and if it’s not like your application is all and only about the GUI this could be a good way to go.
And don’t forget about the QMacStyle::WidgetSizePolicy or you won’t understand why your tables come out so huge.
Obviously, the best option is to use a cross platform suite that supports native widgets.
With QT4 you can build your base user interface. Then just add native support for your specific target platform.
Sure, Cocoa has a lot of fancy stuff (and you can still use them trough QT4), but let me be clear. I see a lot of fancy Apps on the AppStore, pretty ones, but most of then are just crap, expensive.. what ever. I really missed my Kate text editor, my okular viewer, my krita drawing software... those are just better than the commercial and expensive alternatives and are free. so i just tweak the source code a little bit too have a REAL native and great experience.
What if i have to use a linux app on my main computer with is a mac os x? or windows? or whatever? only?
For example, why on earth i have to buy a expensive ,fancy but far less featured image editor software for my mac like pixelmator when i can use a full featured real image manipulation software like Gimp? YES Gimp is gtk2 based which is a pain on any platform, specially on Mac because is really ugly. Gimp should be ported to QT4. Inkscape should be ported to QT4 too, and it would feel so great.
Is so simple to do.. gosh!
http://doc.qt.nokia.com/4.7-snapshot/demos-macmainwindow.html
Even you can add support for the the new native lion fullscreen feature, unified title and toolbar menus, etc
I , as a user, i really care about efficient, featured, good and cross platform apps, i don't really care about developer's convenience or laziness .
I do a lot of cross-platform development (Mac, Windows, Linux), and for some projects use Qt. It is a fine framework, and provides a rich class library. If you need to deploy on multiple platforms, cannot afford to spend the time/effort on platform-specific front-ends, or the "generic" support for each platform is sufficiently good, then use Qt.
However, Qt inevitably suffers in some ways from the lowest common denominator syndrome, and sometimes does not feel quite native enough. There are also certain features that are either difficult to support, or are simply not provided in the Qt libraries. So if you can afford the time and effort, or your app really demands the attention to detail and fit & finish, then developing separate front-ends may be worth it.
In either case, you ought to be writing your back-end (aka domain) code in a platform-neutral and front-end neutral manner. This way, the front-end is easily replaced, or modified between platforms.
You could always start with a Qt front-end and go for a quick time to market, then develop a native front-end down the line.
In practice, I've noticed that a Qt app on Windows looks most "native", while on Mac there are certain subtle telltale signs that make it look/feel not quite right. And Mac users tend to have much higher expectations when it comes to UI/UX!
Since posting this, i've been learning the Cocoa / Objective-C way, and have been quite impressed. Despite what I initially thought was quite a quirky syntax, Objc appears to be a very effective language for implementing UI code, and the XCode sugar - things like Core Data and bindings - make short work of all of the boring bits.
I spent a while with the QT examples and documentation before digging into cocoa, and tend to agree with what has been said above w.r.t being slightly behind the curve and less 'aqua-ish' - albeit from a fairly trivial inspection. If I absolutely had to be build a cross-platform app i'd probably use QT rather than trying to separate out the UI code, as it seems like it would provide close-enough visuals, but for mac only purposes, Cocoa seems like a definite win.
Thanks all for your responses, they've all been very helpful!
DO NOT use Qt for a Mac app. You will get no hardware acceleration for 2D rendering, and you will not be able to deliver ADA compliance.
Depending on what kind of apps you want to write, another contender is REALbasic now called Xojo.
The move from C++ is pretty easy (I have 15 years C++ experience) and the framework and IDE extremely productive. You have the added bonus of being able to deploy to Linux and Windows with trivial effort. Their framework compiles to native code and uses native widgets so you don't have an emulated look and feel.
The big reason for learning Cocoa and coding in Objective-C is if you want to hone your iPhone skills or are chasing a really fancy user experience. If you wanted to rival the cutting edge of WPF development then I'd recommend Cocoa.
Is there any other scripting language that can be used to embed scripts inside applications, which can access Mac OS X, or application classes with the same features, or most of the features seen in F-script?
The scripting language with the best support on the Mac is still AppleScript. But unlike F-Script, it cannot directly access the Objective-C level, it can only use what the target application chooses to expose for scripting.
There are Objective-C bridges for Perl, Python, and Ruby. I suppose those can embedded to provide scripting to your application.
Nu is an interesting option, although it isn't very popular yet.
A lot of people seem to like JSTalk.
But probably Applescript is your best bet: integrated into the system and all that.
I would say F-Script for many reasons. It has many unique features and is extremely tightly integrated with Cocoa and the Objective-C runtime. You can for example inspect various Finder classes (windows, icons, coverflow view...) and it's very easy (one or two lines of code) to start or control other processes. I don't think there is any good reason to prefer AppleScript. It's good for very short scripts, but will probably drive you crazy if you want to do something more complex.
Also, MacRuby is going to rock when it's a bit more stable, and some serious stuff has been accomplished using PyObjC as well, although I don't think it's very actively maintained anymore.
If you don't need F-Script graphical introspection tools, which are quite unique, there are some decent scripting languages that you can embed in applications. See in Particular RubyCocoa (for Ruby), PyObjC (for Python), JSTalk (for JavaScript) and CamelBones (for Perl). They are based on bridges between Cocoa and a foreign object model, which leads to some complexities. This is different from F-Script, which is directly built for the Cocoa object model. When ready, MacRuby might be an option too, but the syntax for manipulating Objective-C objects is not very nice (it improves on RubyCocoa, though). Nu is also an option: directly built for Cocoa like F-Script, but with a strong Lisp flavor.
MacRuby is an implementation of Ruby 1.9 that uses the Objective-C runtime and garbage collector. It can be embedded in a Objective-C application.
Even if the last available version is only 0.6, it is reported to be stable enough to be used in applications.
I've been making my way through The Little Schemer and I was wondering what environment, IDE or interpreter would be best to use in order to test any of the Scheme code I jot down for myself.
Racket (formerly Dr Scheme) has a nice editor, several different Scheme dialects, an attempt at visual debugging, lots of libraries, and can run on most platforms. It even has some modes specifically geared around learning the language.
I would highly recommend both Chicken and Gauche for scheme.
PLT Scheme (DrScheme) is one of the best IDEs out there, especially for Scheme. The package you get when downloading it contains all you need for developing Scheme code - libraries, documentation, examples, and so on. Highly recommended.
If you just want to test your scheme code, I would recommend PLT Scheme. It offers a very complete environment, with debugger, help, etc., and works on most platforms.
But if you also want to get an idea of how the interpreter behind the scenes works, and have Visual Studio, I would recommend Tachy. It is a very lightweight scheme interpreter written in c#. It allows you to debug just your scheme code, or also step through the c# interpreter behind the scenes to see what is going on.
Just for the record I have to mention IronScheme.
IronScheme will aim to be a R6RS conforming Scheme implementation based on the Microsoft DLR.
Version 1.0 Beta 1 was just released. I think this should be good implementation for someone that is already using .NET framework.
EDIT
Current version is 1.0 RC 1 from Oct 23 2009
Google for the book's authors (Daniel Friedman and Matthias Felleisen). See whether either of them is involved with a popular, free, existing Scheme implementation.
It doesn't matter, as long as you subscribe to the mailing list(wiki/irc/online-community-site) for the associated community. It's probably worth taking a look at the list description and archives to be sure you are in the right one.
Most of these are friendly and welcoming to newcomers, so don't be afraid to ask.
It's also worth searching the archives of their mailing list(or FAQ or whatever they use) when you have a question - just in case it is a frequent question.
Good Luck!
Guile running under Geiser within Emacs provides a nice, lightweight implementation for doing the exercises. Racket will also run under Geiser and Emacs, though I personally prefer Guile and Chez Scheme a bit more.
Obviously installation of each will depend on your OS. I would recommend using Emacs version 24 and later since this allows you to use Melpa or Marmalade to install Geiser and other Emacs extensions.
The current version of Geiser also works quite nicely with Chicken Scheme, Chez Scheme, MIT Scheme and Chibi Scheme.
LispMe works on a Palm Pilot, take it anywhere, and scheme on the go. GREAT way to learn scheme.
I've used PLT as mentioned in some of the other posts and it works quite nicely. One that I have read about but have not used is Allegro Common LISP Express. I read a stellar review about their database app called Allegro Cache and found that they are heavy into LISP. Like I said, I don't know if it's any good, but it might be worth a try.
I am currently working through the Little Schemer as well and use Emacs as my environment, along Quack, which adds additional support and utilities for scheme-mode within Emacs.
If you are planning on experimenting with other Lisps (e.g. Common Lisp), Emacs has excellent support for those dialects as well (Emacs itself can be customized with its own dialect of Lisp, appropriately named Emacs Lisp).
As far as Scheme implementations go, I am currently using Petit Chez Scheme, which is an interpreted, freely distributable version of Chez Scheme (which uses a compiler and costs money to obtain a license).