I'm a .NET developer with some questions about a small Mac project coming up.
We are going to be creating a small program for Mac OSX. The software will need to have a simple UI (1 screen) and will need to consume a WCF web service.
Should we code on our Windows boxes or on Mac machines? We have a couple Mac Minis, but we mostly do Windows development.
What IDE/dev environment should we use? (Eclipse, Xcode, etc.)
How does Mac software deployment generally work?
...
No one has mentioned Java/Eclipse. Isn't that an option?
Here are two options:
Write in Objective-C, using Xcode on Macs
Write in C#, using Mono on Windows or on a Mac with SharpDevelop
The advantage of #1 is the resulting app will be much easier to deploy to others, but you might have trouble consuming the WCF service. It depends on what exact interface you are exposing and what the types of the parameters are.
The advantage of #2 is that you can use your C# skills. I don't know the state of WCF in Mono, and the GUI may not look native.
If you go with #1, the main issue will be using Objective-C. Since you are targeting the Mac, make sure you enable the Garbage Collector, or else you will have to also learn memory-management. If you use Xcode 4, it's similar in spirit to Visual Studio, although the details are different. For a simple project, following the tutorials will probably be enough -- I suspect the hard part will be interacting with WCF. To make your life easier, make the interface to the service extremely simple (simple parameter types and returns).
Your question is overly broad. You have two options:
When in Rome...: download Xcode, look at example apps, read Apple's documentation, find some tutorials, and learn Mac app development the usual way.
The Devil You Know...: look into stuff like the Mono project that will let you write a Mac app in C#, so you can use your existing libraries and don't have to learn Objective-C.
Which is better depends on your needs. If you just want to get a small app done and don't have a lot of time/money, I'd go with #2. If you're concerned about quality (compatibility libraries always have their quirks), I'd go with #1. My gut says #2 is better for you.
Related
I have a few questions that I hope clarity and facts can be fed all of us about this. First, the last release of ironpython had the feature of running on the mobile platform highlighting that on mono/android it runs best and not so much on the other platforms which are IOS and Windows phone. So does this mean one doesn't have to use the SL4A? Can i argue that monodroid hooks into the core of what android is capable of and so might give a more robust access/implementation/rendition of apps on android?
Next, I just want to be sure of this: As with python you can create full fledged desktop applications with ironpython right? Cos everywhere (almost) I see ironpython they refer to it as a scripting tool and how you can script aspects of excel etc which has prompted me ask such a question. some say that the speed of applications written using ironpython is not that great and I was arguing asking for why that opinion is held by those who were speaking and no one could say anything worthwhile.
Lastly, with the movement at novell and xamarin, I have not understood where mono stands in their release schemes. I have a mac and I installed a recent version of mono and when I typed ipy I saw something like mono 1.1.0 or something like that. Does anyone have a clue of what is going on with it.
I fell in love with python from learning ironpython and I think the ironpython concept is just sheer brilliance its a pity microsoft esteemed F# other it.
First off, for future reference, multiple questions should really be, well, multiple questions. :)
On IronPython for Android: it works slightly better than on other platforms (where it doesn't work at all right now) but it's still very, very early code. There are some limitations with what you'll be able to do (mainly, you cannot inherit from Java classes from dynamic code). It's very experimental.
On desktop apps: You can absolutely write full apps in IronPython. There are some samples that show how it can be done. In particular, PyWpfSample and PyGtkSample. Startup times are not great, but the actual runtime should be just fine for most GUI apps.
I'm trying to build a dual platform application for a company of my own I'm trying to start at night.
I have the .NET version done, but have not finished the UI part. I'm thinking of buying some 3rd party controls.
If I buy these controls, however, they clearly will only work in my Windows version. I'm wondering if I should try to do the UI in GTK# and use Mono with CocoaSharp or just build the thing in MS technology and teach myself the Mac side?
I'm just really unfamiliar with the Mac world and am wondering how much of a learning curve there might be.
I've thought perhaps of rewriting my core logic in Ruby or Python. This why I could use the .NET version with .NET controls and presumably hook the same code up on the Mac.
It's an educational app targeted at consumers. As such, it shouldn't require a lot of technical sophistication to install.
If the non-visual part of the .NET application is quite big compared to the UI, then you can go full .NET and adopt the following two-steps strategy:
Non-Visual Part
Develop the non-visual .NET part to be the most platform independent.
Platform dependent code for non-visual code should be isolated in small classes that provide the same interface so they could be plugged according to the platform.
User Interface
Use System.Windows.Forms (or your favorite toolkit) for Windows
Use a Cocoa bridge (see this page for the choices) for Mac OS X.
You still can benefit from learning Objective-C: as the Cocoa bridges are usually heavily based on the Apple's API, you will find a lot of help in the Apple's sample code (which are in Objective-C).
On Windows, the application will run with the Microsoft .NET runtime and on Mac OS X, the application will run with the Mono runtime.
The DeepMeta application uses this strategy. As you can see the user experience is quite good on both platforms.
Avoid using cross platform UI tools; the result will never be as good as a native implementation, which is especially bad on the OS X where most customers expect a certain level of polish in their applications. Implementing the core logic in a platform independent language like C++ and maintaining a different code base for the interface on each platform can be a good solution, especially if you have a very complex model.
Anyway, you shouldn't have too much difficulty learning Cocoa if you're a good .NET programmer; I did the reverse several years ago and didn't have much trouble. Objective-C is more C oriented than C#, but if you know the basics about pointers and such you're going to be okay. Cocoa and .NET definitely have their differences in certain areas, but they're both high level frameworks which you shouldn't have too much trouble understanding. Get a good book (Hillegass is the go-to author) and go through it so you understand how the two APIs use different design patterns in certain areas, and don't try to fight the framework if it's different than what you're used to.
In my experience this will make you a better programmer in the long run by expanding your knowledge, even if you don't write any more Cocoa applications.
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.
I have a Symbian 9.1 handset, Nokia E65, based on Nokia S60 series UI. I'd like to build a simple, full screen, graphic application. It should be able to display some text and pictures and have a basic interaction from the keyboard. That's for me only, not to be deployed.
Now, what do you think is the quickest and most painless way to have it done?
I have the following skills:
- HTML, PHP, ASP.net, JS
- ASP.net and C#, Silverlight
- Java, but mostly for networking, not UI
- Some C++
I have downloaded the Nokia IDE, but it is scary at first sight :)
Any tutorial or example are welcome!
Edit:
In particular, two questions:
is there a possibility to make a stand-alone flash application for that handset?
how about the QT mobile version?
For your device, definitely use Python for S60. It is much easier to start with than Symbian's C++ SDK and in case you ever need more low level functionality than python gives you, you can write small modules in c++ and use them in your Python program.
For a simple application like the one you are describing, Python will do just fine. You don't even need any of Nokia's IDEs / tools on the PC, you can just write the code in any text editor, copy it to the phone and test it live.
As others have mentioned, other options include:
Symbian C++ SDK : As you have discovered the tools and not the most intuitive to work with, development is not straight forward either.
Nokia's WRT : Using javascript/css/html, but it is not available for your phone.
Qt : Not available for your phone.
Java Me : Probably your second best option, your code will be slightly larger but more protable. The tools are not as straight forward as with Python, but definitely not as complicated as with Symbian.
If you think you may like to do some further development on the Symbian platform in future, I'd strongly suggest looking at Qt. Unfortunately, however, you can't use it on your E65, since Qt requires S60 3.1 or higher. (The E65 runs S60 3.0).
Since Qt coding in done in C++, you also have access to native platform APIs if required. For most apps however, the (considerably more user-friendly) Qt APIs provide all the functionality you need.
Depending on your background, the learning curve may be steeper than using Java or Python, but the pay-off is that you get access to a very powerful toolkit. And of course, as long as you use only Qt APIs, your app should be easily portable to other Qt platforms if necessary.
Go for Java ME.
All the things you list in your post is possible to do in Java.
The Symbian SDK for C++ can be downloaded here.
NSBasic is another option.
Kindness,
Dan
May I suggest Python? For newer Symbian handsets I'd recommend Web Runtime (WRT), but it is not supported on good old E65.
I'm obviously biased but I would suggest getting the 2D graphics example code from the "Quick Recipes On Symbian OS" book:
If you know HTML and JS already, you should be able to write a Web widget for your Symbian device pretty easily, using the tools available through Forum Nokia. More info here:
http://www.forum.nokia.com/Technology_Topics/Web_Technologies/Web_Runtime/
These widgets are standalone full screen applications that use the device WebKit browser engine for rendering and UI. You can also use keyboard inputs and customize the softkeys if you wish.
I'm looking at rewriting an eMbedded Visual Basic app I wrote years ago. I'm unsatisified with it because of various problems clients keep having with it now and then over the years, mostly along the lines of the app not loading anymore because a required dll/activex control has gone missing! This is so frustrating and naturally difficult to debug when a client is using it far away. In alot of cases reinstalling the app doesn't fix the problem.
My preference would be to rewrite it in C# since I'm comfortable with C# and DotNet, but I'm also open to other platforms like blackberry or iTouch/iPhone so long as the platform can support maps and GPS. I'd start rewriting it in C# now but I can't be sure that I won't have the same problems in .net.
Has anyone else had similar problems with eVB apps which have gone away/persisted when moving to CF DotNet? Or would you suggest a different platform again?
Edit: Note that I wish to move away from eVB anyway, but if I move to CF DotNet I want to make sure I won't have the same missing dll/control problems.
I recommend .NET CF strongly, especially if you already know C# and .NET. Mono has been ported to the iPhone, so it is possible to write apps that will run on Windows Mobile and the iPhone. No Mono for Blackberry (yet, if ever), so that's a definite limitation. I personally can't stand Blackberries (I have both a Blackberry and a WM smartphone and the Blackberry makes me want to hang myself), but they do have a huge user base.
You should have migrated away from eVB years ago, but that's water under the bridge. If you want to continue targeting Windows CE/ Windows Mobile I'd recommend going to the CF - language is irrelevant, use what you're comfortable with.
There's no way to guarantee that whatever your "missing DLL" problem is won't happen again, since we have no idea what DLL went missing. If it was a 3rd party control, then you're at the mercy of the market. If the provider survives, it's likely their control will.
If you want to target iPhone/Blackberry then Java is more likely to be your language of choice - the tools I'm not as familiar with. Eclipse for Blackberry - iPhone may have their own tool.
As for Silverlight, you might look at it, but so far it's just way too slow to be a viable platform, at least on any WinMo device I've ever seen. We've delevered many, many CF apps for all sorts of verticals and have never had any usability problems (though we've been doing it a long time and know every limitation and what we should and should not be trying).
I suggest you take it one step further and look at Silverlight. One of the premises is that it's a more long-term-stable, portable, lightweight download and install, and it hasn't gotten krufty yet.
I think it has the potential to be the next VB for embedded. One of the difficulties with CF is that I've found it to be an insufficient subset of the real thing.
Another option is NS Basic/CE. It's highly compatible with eVB, so you will be able to keep most if not all of your code. The product has been continually updated so it runs on current devices.
The installer that NS Basic/CE creates includes all the dll files your program requires, so they will be included on installation.