I'm a little ashamed for asking this, because, you know, I've been very anti-MS for a long time. I have been fortunate enough as to make a living outside Visual Studio. As I grown older there are "some" things I would like to try, and to be very honest, this Q&A site has inspired me and I realize that VS and Windows Development doesn't suck that much. Hey, after all C# was designed after Java, and now Java is copying back some features from the child language. And Windows vista is the first decent version since windows came to light.
Anyway, to any +3,000 user in the audience, you may delete all the above crap and keep the following:
Do you have, links, resources, tutorial aimed to learn Windows development coming from strong Java background?
I'm very interested in Windows manipulation (that is the actual window, the frame, get the name, get foremost app etc., resize it programatically, etc.) and in Windows Search API among other minor API's. My interest after all is to integrate them with my Java apps through JNI or JNA.
I've read many tutorials and links over the MSDN, and I actually understand the API it self. I've grabbed a copy of C# and C++ Express and actually got some basic samples running.
My problem is I don't get the big picture of the whole architecture (because, well, it is big). The classes have hundreds of methods, and it not that clear to me who calls them. (I had this same opinion when I first look at the Java's Javadoc API.) I don't know some basic common objects, for instance HWCD (or something like that) that it turned out to be the very window handler, but every single tutorial I read give that for granted (as if WHCD or what ever it is, was a very descriptive name).
I don't know exactly the difference between Win32, COM, COM+, DCOM, Windows SDK ADO, and some other technologies. I mean, I know them at some degree and by common sense, but while reading the tutorials or the API I get confused. I've tried to grab some "beginner" tutorials, but they are aimed for absolute 0 programmers using Visual Basic (yiak! , THAT was the main reason I kept away from MS for so many years in first place.)
I do understand .NET framework, managed code, unmanaged code, C# basics, CLR and related stuff, because well, they are SO similar to the Java platform that it is almost transparent.
So, after all my rants and honest opinions about MS development:
What's the best way to learn Windows Development for a non absolute beginner (in programming) but absolute new to Windows APIs itself? What would be a good path?
The Petzold is your new best friend, and MSDN is your new Javadocs. Make sure you have a good understanding of C before you dive into it though. The Forger has a great beginner tutorial too if you're interested. A great place to hang out while learning is #WinProg on efnet irc, plenty of win32 gurus ready to help.
I'm going to suggest an alternate path (with less resistance). Have you looked at WPF yet? It's the new GUI toolkit that lets you create sexy interfaces (like those found in Vista).
That may be enough to keep you interested while easing into more advanced development. From there you can jump into the jungle of the Win APIs (if you choose).
Just a thought, as that path would be more interesting for me. Your mileage may vary, of course.
I strongly recommend getting yourself a copy of "Win32 Programming". It explains the basic DNA of WINDOWS - and this is valid if you are programming with the old C++ win32, the new C# WinForms and also the future Windows Presentation Foundation.
In a nutshell, a Windows program consists of a WinMain. When first started the app registers its window class with the system, initializes and then starts a message loop which continues till WM_QUIT is encountered. The system (OS) keeps pumping messages like keyboard or mouse click etc to the message Q of the application. In Windows, at any point of time there is only one active Window - so the OS knows whom to send the message to.
Well things like these are described in detail in the above book.
COM (COM+, DCOM) are not really related to Windows. When Word, Excel became popular and it was required to be able to access Excel from Word (viceversa) they came up with the AcitveX technology which is kind of the root for COM etc. You can get started with "Essential COM" by Don Box.
One warning: in the Microsoft world, there are two ways to program - to go the boiler plate way (write everything yourself) or use frameworks (MFC, ATL-COM....). It is recommended to do a bit of boiler plate so that you know the basics.
Having made the same conversion a year ago I can say that there's a lot of literature specifically for learning c# from a Java background. This was my first into which I found really useful for learning the important differences / features of C#:
C# from a Java developer's perspective
And there are also books which may be worth a look at (google 'c# for java programmers'). As JohnT said MSDN library is the equivalent of JavaDocs API, but I found it really frustrating to use. The best way to learn is to grab a copy of Visual Studio express and start playing around. Use intellisense to explore classes and methods. Find a small program you wrote in Java and try to reproduce it in C#. Start with simple problems, use google to solve them. You'll find it hard for the first week, but trust me, it will come to you surprisingly quickly!
Related
I have just finished my first real commercial application written in C++ / MFC.
The application consisted of agent installed on users workstations which in turn was controlled from a GUI Application on an administrators workstation. I choose C++ / MFC for these reasons.
Because I didn't know C#
Because I was not sure how long it would take for me to become as productive in a new lanuage
Because I did not want the hassle of installing the .NET runtime on workstations some of which might be W2K.
Now I am thinking of my second application which will again consist of an agent & a GUI Application. I am happy to continue on the same track with the agent for the reasons above but the GUI application will be much more complicated then the first. The first GUI app took a very long time to develop, was torturous and looked out of date even though it was freshly made.
Should I just bite the bullet with .net c# or look into something like QT.
TIA.
If you want really fast results, use .NET WinForms. Nothing beats the speed of putting together a GUI app and filling it with life, except maybe Delphi. The C# language and the .NET Base Class Library will also give you a huge productivity gain, even over the already great Qt framework. If you stick to the basic Windows Forms controls, it will even run on Mono.
WPF is even more productive once you're used to it, but getting used to it takes way more time than for Windows Forms.
.NET C# is a very good choice for GUI applications more generally. It's simple, to-the-point and there are vast resources on the internet.
The only thing against it I can think of, is platform compatibility, but if you're limiting yourself to C++/MFC, that shouldn't be a concern to you.
Even if you want to go platform-independent some time later, you can make a separate Gtk in .NET on Linux (Mono, the open-source .NET framework). Heck, there's even a Cocoa (Mac OS X) binding, I just don't know how mature it is. Furthermore Windows Forms is largely supported in Mono already... it really surprised me how mature it is when I was trying it out, although my primary experience with C# is on Windows.
For GUI application, you won't regret using C#. Even if you want to go cross-platform, and certainly not if you intend to only target Windows clients.
C# will almost definitely make you more productive!
Delphi. Produces stand-alone Windows executables which will work fine on Win2K (best OS Microsoft ever produced - this post is being written on it). Only disadvantage is Object Pascal, but if you know C++ it's very easy to pick up - and its was designed buy the guy who designed C#. The IDE is several orders of magnitude more productive than MFC with VS.
I've done them all - a monkey can use C#, it's all drag and drop interfacing and public accessors. I wouldn't wish using MFC upon my worst enemy, and QT just wasn't as intuitive as C# for me. It's also really easy to make C# look nice. Difficult things like changing colors and flashing controls are trivial in C#. It also has built in styles to use. I use it professionally daily. The only time I use C++ is if I'm programming a server where every microsecond counts.
The first question would be exactly what caused the difficulty in developing the GUI with MFC. Was it inherent to MFC, or what it because you were learning something new, and didn't really know what you were doing? To put it slightly differently, if you had to do it again today, how would the difficulty compare?
Make no mistake about it -- MFC is an old design with far more than its share of problems, shortcoming and design flaws. .NET is a lot newer, but has far more than its share of problems, shortcoming and design flaws as well.
Along with that, .NET is just plain huge. It's reasonably well organized, which helps, but it still takes quite a while to digest the sheer volume of information necessary to use it well. Likewise, while C# (for the most obvious example) is a perfectly decent language, learning to use it well isn't an overnight task either. This is probably a smaller issue though: C# doesn't really have many new concepts compared to C++. Just for example, a competent C++ programmer can easily read C# almost immediately, and while he may not use it optimally, can also write bits of C# immediately as well.
on which platform will your second app run on?
if it's XP and up i'll suggest C# / WinForms / GDI.
C# isn't that hard to adapt to, and there are literally a ton of examples online, and great books (the Head First one caught my eye as you can code a nethack clone and other fun projects). I've had to transition from C++ to C# myself, and it wasn't that rough at all (in fact it seemed like a pretty easy transition), and allowed me to rapidly prototype.
Good luck!
I am new here and new to windows mobile development. But I have seen and experienced, for new developers having no trainers or experienced people around windows mobile development is like a hell shaking one. In complex topics you are going to find help from nowhere except you are lucky.
So my question is how should I gain expertise in windows mobile without having any trainer. The thing that i only know is C# and have a rough experience of one and a half months in windows mobile development
Yea.... it's quite a step to be honest. It's evil as well because at first glance it looks to be so very simple but then it turns around and bites you.
I speak from experience as I made this journey starting in 2003. Oh, I had no trainer either so I just learnt via bitter experience.
Know your limitations
I remember the first ever CF application. I was such an idiot..... I wasn't much good at developing back then either. First mistake I made was overestimating CF 1.0. I couldn't possibly imagine that the CF didn't have a read-write datagrid so I specced it...... then found out that oh yes, there wasn't one. So I had to write one myself (and remember I was rubbish at this time too). I hacked one into the existing datagrid (although tbh I should have just started from scratch). I remember that the "delete" function where I had to remove a row and then select the "now currently selected row" was hellish because it would go up or down depending on how many items were in the collection and where the scrollbar was.
There are many times that my desktop development buddies will categorise me as mad when I tell them what i'm working on.
"You're doing manual Xml Parsing? Are you crazy?"
"Ewwww code gen?"
"You.... re-use your windows forms?"
Yes, working on CF will make you look crazy to outsiders.
Performance
This can be taken to extremes but every little does help. If your building a big flexible application then think very carefully about perf. Consider replacing Reflection with codegen. Consider using an XmlReader instead of an XmlDocument. Sure this advice might be crazy in most cases for desktop but for CF it is sensible.
Know your PInvokes
In desktop land you can live in pure managed. No chance of that happening on CF. Some of the simplest things (playing a sound, setting the time, changing the volume, networking, etc etc) still only exist in the unmanaged world in Mobile. OpenNETCF have done an awesome job in exposing some of these but you will always stumble into one or two where you will need to write your own.
There is true, there is false but there is also FILE-NOT-FOUND
PowerManagement, how I love thee. In a usual C# app code goes the way of the logic (like a fork with an IF), perhaps an exception will be thrown and perhaps there will be many threads treading the path of the code. This is already complex. Add into the mix the idea that the power might vanish at any point. That's right, the using statement you were relying on to call Dispose might never call dispose because the device was turned off and then it ran out of power.
Device specific fun
Another big difference in desktop/mobile world is hardware and manufacturers. On the PC you can generally assume that the hardware will be okay and firmware updates should do the job. In CF a firmware update may well kill your code. Some hardware might sorta, kinda work if you bash it round the head in a certain way. Basically your device integration can (worst case) be a big black hole of time. Remember to work this into your estimates.
Learning to write actual maintainable, saleable and usable applications for the Compact Framework is difficult. The CF is way, way scaled down, so there is a lot that a desktop developer will not have that they are used to. I'd been developing CF applications since before the CF existed and I still find many things difficult (just try getting a control with transparency drawn into a container on a form with a background image and doing it without looking at the code in Project Resistance).
In my opinion, there really are 2 things that are essential.
You must be able to read and understand C/C++. All of the SDK docs are in C and a large amount of samples for using anything useful on the device tend to be in native code. If you can't translate that, you're at a serious disadvantage and you have to hope someone else has already done the work. Even if they have, they you have to rely on them having done it right.
You need CF experience. Desktop experience is largely worthless in the CF environment once you get past syntax. Laziness like data binding, using Data Sets, not cleaning up objects and all of those things that desktop developers do every day will kill a CF app. You need to throw out what you think you know and start re-learning. You do that by simply writing code every day.
Don't expect miracles either. I've been writing code for Windows CE for over a decade now and the amount of things I don't know about the platform still far outweighs the things that I do know.
If I understand your question....
If you have c# experience, you will not really need a trainer.
Building on Windows Mobile is very straight forward and easy if you know .net.
If you have Visual Studio (I think any edition apart from express), it is simply a matter of starting a new project and selecting mobile device.
I honestly love it! I build small applications all the time for my phone... little calculators for when I go shopping, programs that fire off a trigger and get a response from a web service and more... basically to make my phone do what I want (and no one else would be interested in).
I go by the method of simply writing an application the way I want and then if a feature is not supported by the cut down .net compact framework, I try and search for an alternative method that is - however, I have found little that doesn't work.
Developing in the CF can be challenging. Knowing C# is important before moving forward with the Compact Framework - to which you have. I would suggest that you start with smaller applications. Once you get the feel of Visual Studio and working with the emulator, I would suggest that you play around with a setup project. Once you get an idea on the flow of CF development, deployment will probably be your next step.
One area that I find that I spend time on is Designer support. If you are writing controls for other developers - design time support is crucial. Checkout the article at http://www.mooseworkssoftware.com/VS2005%20Control.htm for more information (I know its for VS2005, but it really helped our development).
As you move forward, create small projects in different areas and learn the pitfalls to each. An example would be GUI and dealing with different screen resolutions that are supported by different devices. Next, maybe DB support. After you get comfortable with a couple of areas, bring them together in a project and build from there.
Give it time - sometimes it will be painful, but the possiblities are endless in writing applications for the CF and what the market is calling for.
Craig
To answer your question, Windows Mobile is like paradise for new developers. You use the same tools and languages you are used to from the desktop world and essential things like in device debugging and emulators are just there for you. You can build simple applications with no training, just by following one of the many beginners tutorials available.
After that, there are of course many complicated and difficult issues to overcome, but in my opinion the fact that you will be able to start quickly is very important.
Also, you need to also need to compare Windows Mobile with other mobile platforms. Compared to platforms like Symbian, Brew and J2ME Windows Mobile is much more advantageous for new developers. I don't have experience with iPhone and can't comment about it, but comparing to everything else, Windows Mobile is easier.
So I've been learning C# for like a year now (I'm 20 years old) and I'm getting pretty confident with it. I've also been meddling with C++ every now and again. For example just recently I've been following the Nehe OpenGL tutorials for C++ and I find it a fun way of learning.
I want to start looking at creating cross platform GUI software after I stumbled across this library called FLTK (fluid something rather). After finally and painfully getting it to work I found it refreshing to know that there are solutions for GUI creation in C++, however I think FLTK looked pretty old.
So I googled around for some newer GUI frameworks and decided to start playing with wxWidgets (decided against Qt because of licensing).
I downloaded it, compiled it, and looked to see if there were any IDE plug-ins for RAD development, as you can imagine going from drag and drop a component onto a form in C# I was hoping for something similar.
I learned that code::blocks has something of the sort so I tried that out. It was alright but the thing that turned me off was the horrible code completion; it would only show members and methods in the current object and nothing for the #included header files. I understand that code completion/IntelliSense isn't easy for C++ but Visual Studio 2008 handles it pretty good. I did find some other RAD tools like wxFormBuilder but it costs money, not something I want to do for simply learning.
So my TLDR question is if anyone has had experience with wxWidgets? Do you just develop in whatever IDE you're comfortable with and just code the GUI? Meaning no visual helpers? Perhaps you could give me a nudge in what direction I should be going :)
Thanks, this is also my first post on this site albeit I have read many threads before that have helped me solve copious problems. Cheers!
My suggestion is to learn how to do GUI layout with wxWidgets in code, then when you get good at it learn how to use the GUI tools.
Doing this kind of work manually for a while gives you the understanding about what you need ("Ok, I need a wxSizer, vertical, to put these two horizontal wxSizers into, where I put my a wxStaticText and a wxTextCtl for each line ...")... where as I think if you started out with the GUI tools you'd just tend to get annoyed because (last time I looked) none of them were Drag And Drop editors like you get with .NET.
Definitely give Code::Blocks another try. It is a WONDERFUL environment to work with wxWidgets in. It comes with a form designer and templates for wxWidgets projects, so I can't imagine working without it.
Also, for a good beginner's introduction to wxWidgets, try this page. It helped me alot when I started with it.
I use wxWidgets without using a drag and drop designer. There are obviously drawbacks to that approach but an advantage is that you don't have any horrible automatically generated code to deal with. In the past I've found having such code in the middle of my project has caused various types of grief - especially if you decide it needs some serious changes it is often necessary to start from scratch because form designers are so much better at "writing" as opposed to "editing".
For simple applications you can assemble a UI using a mixture of customized and standard widgets without too much difficulty. Check out the wxWidgets samples and demos, which use that approach. My chess app (see my website) uses this approach too.
A more elaborate UI could possibly be implemented by writing something special at a higher level of abstraction. The kind of thing I am thinking of would be a subsystem that accepts high level flexible requests to provide different types of user interface functionality, and then sorts out the details of the controls to create and the positioning etc. of those controls itself. That is kind of a technical fantasy of mine but I haven't ever really attempted to do it. Actually, a fairly primitive facility of this type is already available and used by the demos I mentioned; It is called a "Sizer" (class wxSizer) and is basically a control container.
Finally I would point out that problems with the Qt licence have basically gone away since Nokia bought Trolltech and made it "more" free (LGPL licence). Many people think Qt is the way to go these days. I am pretty happy with wxWidgets but will definitely evaluate Qyt seriously one day. Good luck with your projects.
I have developed a number of application GUIs using wxWidgets - you can see screenshots at http://ravenspoint.com/
IMHO, you should distinguish between designing a GUI and implementing it. Expecting to use the same program to design your GUI and to automatically emit all the code to implement the design is expecting too much.
A design program should be fast and simple. I recommend http://www.balsamiq.com/
Once you have settled on the design, then you can turn to the coding. Personally, I find that placing widgets on a panel using the wxPosition and wxSize parameters of the wxWidget constructors to be trivial - easier than trying to nudge widgets into their exact positions using the mouse.
The trouble with using some kind of form builder to emit all the code for a significant GUI is that you end up with a morass of automatically generated code that is hard to find your way around in. If the code has been handwritten, then you already know where everything is located.
wxFormBuilder but it costs money
wxFormBuilder is Free and Open source
Also Visual Studio is best for C++ coding in wxWidgets, but you will run into lots of issues on Linux due to the way Visual Studio handles a lot of things, like file names you have to take extra care for case sensitivity.
Also regarding the GUI, add the wxFormBuilder to the Visual Studio solution, add the file type handler to Visual Studio. Now just double click on it and add your dialogs, like you do it in C#.
Just add the generated code files to the Visual Studio project once and you are done.
It's very easy to use Visual Studio with GUI programming in wxWidgets.
Also don't forget to watch the CodeLite editor if you want to port on Linux. It is very much compatible with the Visual Studio projects and shortcut keys.
There is wxGlade and wxFormBuilder.
I don't know if there is another one, but the wxFormBuilder I know is free and open source.
You will find links to other tools on the homepage
of wxGlade (http:// wxglade.sourceforge.net/).
Most of these programs are able to output xrc files, which are are an XML representation of your GUI. It address the issue of complexity of the generated code but is not as powerful.
Yet personally I don't use any of these tools, except sometimes to see what it's going to look like before I do it but never to actually generate code.
I just finished doing a hello world program in both wx and fltk using the netbeans IDE. Microsoft Visual Studio WinForms or MFC was much easier than either. I needed cross platform capability so I could not use it for this application. I finished fltk in much less time than wx. The program was simpler, smaller, faster, and easier to write. Wx had pretty disjointed documentation and organization. Fltk was designed back in the "old days" when small fast and efficient was valued. That's probably why it seems "old" to you. I'm an old guy so it worked for me. YMMV
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 3 years ago.
Improve this question
After sitting through a session today on Mono at a local .Net event, the use of MonoTouch was 'touched' upon as an alternative for iPhone development. Being very comfortable in C# and .Net, it seems like an appealing option, despite some of the quirkiness of the Mono stack. However, since MonoTouch costs $400, I'm somewhat torn on if this is the way to go for iPhone development.
Anyone have an experience developing with MonoTouch and Objective-C, and if so is developing with MonoTouch that much simpler and quicker than learning Objective-C, and in turn worth the $400?
I've seen this question (and variations on it) a lot lately. What amazes me is how often people respond, but how few answer.
I have my preferences (I enjoy both stacks), but this is where most "answers" start to go wrong. It shouldn't be about what I want (or what anybody else wants).
Here's how I'd go about determining the value of MonoTouch - I can't be objective, obviously, but I think this is pretty zealotry-free:
Is this for fun or business? If you wanted to get into consulting in this area, you could make your $399 back very quickly.
Do you want to learn the platform inside-out, or do you "just" want to write apps for it?
Do you like .Net enough that using a different dev stack would take the fun out of it for you? Again, I like both stacks (Apple and Mono), but for me MonoTouch makes the experience that much more fun. I haven't stopped using Apple's tools, but that's mainly because I really do enjoy both stacks. I love the iPhone, and I love .Net. In that case, for me, MonoTouch was a no-brainer.
Do you feel comfortable working with C? I don't mean Objective-C, but C - it matters because Objective-C is C. It's a nice, fancy, friendly OO version, but if pointers give you the heebie-jeebies, MonoTouch is your friend. And don't listen to the naysayers who think you're a dev wuss if it happens that you don't like pointers (or C, etc.). I used to walk around with a copy of the IBM ROM BIOS Pocket Reference, and when I was writing assembly and forcing my computer into funny video modes and writing my own font rendering bits for them and (admittedly trashy) windowing systems, I didn't think the QuickBasic devs were wusses. I was a QuickBasic dev (in addition to the rest). Never give in to nerd machismo. If you don't like C, and if you don't like pointers, and if you want to stay as far away from manual memory management as possible (and, to be fair, it's not bad at all in ObjC), then... MonoTouch. And don't take any guff for it.
Would you like to target users or businesses? It doesn't matter much to me, but there are still people out there on Edge, and the fact is: you can create a far smaller download package if you use Apple's stack. I've been playing around with MonoTouch, and I have a decent little app going that, once compressed, gets down to about 2.7 MB (when submitting your app for distribution, you zip it - when apps are downloaded from the store, they're zipped - so when figuring out if your app is going to come in under the 10MB OTA limit, zip the sucker first - you WILL be pleasantly surprised with MonoTouch). But, MT happiness aside, half a meg vs. nearly three (for example) is something that might be important to you if you're targeting end users. If you're thinking of enterprise work, a few MB won't matter at all. And, just to be clear - I'm going to be submitting a MT-based app to the store soonishly, and I have no problem whatsoever with the size. Doesn't bother me at all. But if that's something that would concern you, then Apple's stack wins this one.
Doing any XML work? MonoTouch. Period.
String manipulation? Date manipulation? A million other little things we've gotten used to with .Net's everything-AND-the-kitchen-sink frameworks? MonoTouch.
Web services? MonoTouch.
Syntactically, they both have their advantages. Objective-C tends to be more verbose where you have to write it. You'll find yourself writing code with C# you wouldn't have to write with ObjC, but it goes both ways. This particular topic could fill a book. I prefer C# syntax, but after getting over my initial this-is-otherworldly reaction to Objective-C, I've learned to enjoy it quite a bit. I make fun of it a bit in talks (it is weird for devs who're used to C#/Java/etc.), but the truth is that I have an Objective-C shaped spot in my heart that makes me happy.
Do you plan to use Interface Builder? Because, even in this early version, I find myself doing far less work to build my UIs with IB and then using them in code. It feels like entire steps are missing from the Objective-C/IB way of doing things, and I'm pretty sure it's because entire steps are missing from the Objective-C/IB way of doing things. So far, and I don't think I've sufficiently tested, but so far, MonoTouch is the winner here for how much less work you have to do.
Do you think it's fun to learn new languages and platforms? If so, the iPhone has a lot to offer, and Apple's stack will likely get you out of your comfort-zone - which, for some devs, is fun (Hi - I'm one of those devs - I joke about it and give Apple a hard time, but I've had a lot of fun learning iPhone development through Apple's tools).
There are so many things to consider. Value is so abstract. If we're talking about cost and whether it's worth it, the answer comes down to my first bullet item: if this is for business, and if you can get the work, you'll make your money right back.
So... that's about as objective as I can be. This is a short list of what you might ask yourself, but it's a starting point.
Personally (let's drop the objectivity for a moment), I love and use both. And I'm glad I learned the Apple stack first. It was easier for me to get up and running with MonoTouch when I already knew my way around Apple's world. As others have said, you're still going to be working with CocoaTouch - it's just going to be in a .Net-ized environment.
But there's more than that. The people who haven't used MonoTouch tend to stop there - "It's a wrapper blah blah blah" - that's not MonoTouch.
MonoTouch gives you access to what CocoaTouch has to offer while also giving you access to what (a subset of) .Net has to offer, an IDE some people feel more comfortable with (I'm one of them), better integration with Interface Builder, and although you don't get to completely forget about memory-management, you get a nice degree of leeway.
If you aren't sure, grab Apple's stack (it's free), and grab the MonoTouch eval stack (it's free). Until you join Apple's dev program, both will only run against the simulator, but that's enough to help you figure out if you vastly prefer one to the other, and possible whether MonoTouch is, for you, worth the $399.
And don't listen to the zealots - they tend to be the ones who haven't used the technology they're railing against :)
There is a lot of hearsay in this post from developers that have not tried MonoTouch and Objective-C. It seems to be mostly be Objective-C developers that have never tried MonoTouch.
I am obviously biased, but you can check out what the MonoTouch community has been up to in:
http://xamarin.com
There you will find several articles from developers that have developed in both Objective-C and C#.
So, my answer to a previous similar question is to learn Objective-C. (Also, don't forget about debugging support)
This will probably offend some but to
be honest, if you are going to do any
serious development, you should learn
Objective-C. Not knowing Objective-C
in iPhone development will just be a
hindrance. You won't be able to
understand many examples; you have to
deal with the quirks of Mono whereas
if you had a working knowledge of
Objective-C you could get a lot more
out of the platform documentation.
Personally, I don't understand the
position that says increasing the
amount of information you need in
favor of using Mono over the
platform's native language. It seems
somewhat counterproductive to me. I
think if this is a very expensive
proposition (learning a new language)
then it may be worthwhile spending
some time on fundamental programming
concepts so that learning new
languages is a fairly cheap
proposition.
Another user also wrote this:
Monotouch is easier for you now. But harder later.
For example, what happens when new seeds come out you need to test against but break MonoTouch for some reason?
By sticking with Mono, any time you are looking up resources for frameworks you have to translate mentally into how you are going to use them with Mono. Your app binaries will be larger, your development time not that much faster after a few months into Objective-C, and other app developers will have that much more of an advantage over you because they are using the native platform.
Another consideration is that you are looking to use C# because you are more familiar with the language than Objective-C. But the vast majority of the learning curve for the iPhone is not Objective-C, it is the frameworks - which you will have to call into with C# as well.
For any platform, you should use the platform that directly expresses the design philosophy of that platform - on the iPhone, that is Objective-C. Think about this from the reverse angle, if a Linux developer used to programming in GTK wanted to write Windows apps would you seriously recommend that they not use C# and stick to GTK because it was "easier" for them to do so?
Using Mono is not a crutch. There are many things that it adds to the iPhone OS. LINQ, WCF, sharable code between a Silverlight app, an ASP.NET page, a WPF app, a Windows Form app, and there's also mono for Android and it will work for Windows Mobile as well.
So, you can spend a bunch of time writing Objective-C (You'll see from many studies where the exact same sample code in C# is significantly less to write than OC) and then DUPLICATE it all for other platforms. For me, I chose MonoTouch because the Cloud App I'm writing will have many interfaces, the iPhone being only one of them. Having WCF data streaming from the cloud to MonoTouch app is insanely simple. I have core libraries that are shared among the various platforms and then only need to write a simple presentation layer for the iPhone/WinMobile/Android/SilverLight/WPF/ASP.NET deployments. Recreating it all in Objective-C would be an enormous waste of time both for initial dev and maintenance as the product continues to move forward since all functionality would have to be replicated rather than reused.
The people who are insulting MonoTouch or insinuating that users of it need a crutch are lacking the Big Picture of what it means to have the .NET framework at your fingertips and maybe don't understand proper separation of logic from presentation done in a way that can be reused across platforms and devices.
Objective-C is interesting and very different from many common languages. I like a challenge and learning different approaches... but not when doing so impedes my progress or creates unnecessary re-coding. There are some really great things about the iPhone SDK framework, but all that greatness is fully supported with MonoTouch and cuts out all the manual memory management, reduces the amount of code required to perform the same tasks, allows me to reuse my assemblies, and keeps my options open to be able to move to other devices and platforms.
I switched. Monotouch let's me write apps at least 3-4 times as fast (4 apps per month compared to my old 1 per month in Obj C)
Lots less typing.
Just my experience.
If this is the only iPhone app you will ever develop, and you also have zero interest in developing Mac applications, ever, then MonoTouch is probably worth the cost.
If you think you'll ever develop more iPhone apps, or will ever want to do some Mac native development, it's probably worth it to learn Objective-C and the associated frameworks. Plus, if you're the type of programmer that enjoys learning new things, it's a fun new paradigm to study.
Personally I think you'll have a better time just learning Objective-C.
In short:
"Learning Objective-C" is not a daunting as you might think, you may even enjoy it after just the first few weeks
You are already familiar with the "C style" syntax with lots of *&(){}; everywhere
Apple has done a very good job of documenting things
You'll be interacting with the iPhone the way Apple intended, which means you'll get the benefits directly from the source not through some filter.
I have found that the projects like Unity and MonoTouch are supposed to "save you time" but ultimately you'll need to learn their domain specific language anyway and will have to side-step things at times. All that is probably going to take you just as long as it would to learn the language you were trying to avoid learning (in calendar time). In the end you didn't save any time and you are tightly coupled to some product.
EDIT: I never meant to imply anything negative about .NET I happen to be a big fan of it. My point is that adding more layers of complexity just because you aren't yet comfortable with the quirky objc bracket notation doesn't really make much sense to me.
2019 update: It's 7 years later. I still feel the same way if not more so. Sure, 'domain specific language' may have been the wrong term to use, but I still believe it's much better to write directly for the platform you are working with and avoid compatibility layers and abstractions as much as possible. If you are worried about code reuse and re-work, generally speaking any functionality your cross platform app needs to perform can probably be accomplished with modern web technologies.
To add to what others have already said (well!): my feeling is that you're basically doubling the number of bugs you have to worry about, adding the ones in MonoTouch to the ones already in iPhone OS. Updating for new OS versions will be even more painful than normal. Yuck, all around.
The only compelling case I can see for MonoTouch is organizations that have lots and lots of C# programmers and C# code lying around that they must leverage on iPhone. (The sort of shop that won't even blink at $3500.)
But for anyone starting out from scratch, I really can't see it as worthwhile or wise.
Three words: Linq to SQL
Yes it is well worth the $.
Something I'd like to add, even though there's an accepted answer - who is to say that Apple won't just reject apps that have signs of being built with Mono Touch?
I would invest the time in Objective-C mainly because of all the help you can get from sites like this. One of the strength's of Objective-C is that you can use C and C++ code, and there is a lot of projects out there that are well tested.
Another thing is that you're code (language of choice) will be supported by apple. What it iOS 5.x for instance removes the support for a third party solution like MonoTouch? What will you tell your customers then?
Maybe its better to use a platform independent solution like HTML5 if you're not entire ready to move to Objective-C?
I've been using MonoTouch for a few months now, I ported my half finished app from ObjectiveC so I could support Android at some point in the future.
Here's my experience:
Bad bits:
Xamarin Studio. Indie developers such as myself are forced into using Xamarin Studio. It is getting better every week, the developers are very active on the forums identifying and fixing bugs, but it's still very slow, frequently hangs, has a lot of bugs and debugging is pretty slow also.
Build times. Building my large (linked) app to debug on a device can take a few minutes, this is compared to XCode which deploys almost immediately. Building for the simulator (non-linked) is a bit quicker.
MonoTouch issues. I've experienced memory leak issues caused by the event handling, and have had to put in some pretty ugly workarounds to prevent the leaks, such as attaching and detaching events when entering and leaving views. The Xamarin developers are actively looking into issues like this.
3rd party libraries. I've spent quite a time converting/binding ObjectiveC libraries to use in my app, although this is getting better with automated software such as Objective Sharpie.
Larger binaries. This doesn't really bother me but thought I'd mention it. IMO a couple of extra Mb is nothing these days.
Good bits:
Multi-platform. My friend is happily creating an Android version of my app from my core codebase, we're developing in parallel and are committing to a remote Git repository on Dropbox, it's going well.
.Net. Working in C# .Net is much nicer than Objective C IMO.
MonoTouch. Pretty much everything in iOS is mirrored in .Net and it's fairly straight forward to get things working.
Xamarin. You can see that these guys are really working to improve everything, making development smoother and easier.
I definitely recommend Xamarin for cross platform development, especially if you have the money to use the Business or Enterprise editions that work with Visual Studio.
If you're solely creating an iPhone app that will never be needed on another platform, and you're an Indie developer, I'd stick with XCode and Objective C for now.
As someone with experience with both C# as well as Objective-C, I'd say for most people Xamarin will be well worth the money.
C# is a really good designed language and the C# API's are good designed as well. Of course the Cocoa Touch API's (including UIKit) have great design as well, yet the language could be improved in several ways. When writing in C# you will likely be more productive compared to writing the same code in Objective-C. This is due to several reasons, but some reasons would be:
C# has type inference. Type inference makes writing code quicker, since you don't have to "know" the type on the left-hand side of an assignment. It also makes refactoring easier and more saver.
C# has generics, which will reduce errors compared to equivalent Objective-C code (though there are some work-arounds in Objective-C, in most situations developers will avoid them).
Recently Xamarin added support for Async / Await, which makes writing asynchronous code very easy.
You'll be able to reuse part of the code base on iOS, Android and Windows Phone.
MonoTouch largely implements the CocoaTouch API's in a very straightforward way. E.g.: if you've got experience with CocoaTouch, you'll know where to find classes for controls in MonoTouch (MonoTouch.UIKit contains classes for UIButton, UIView, UINavigationController, etc..., likewise MonoTouch.Foundation got classes for NSString, NSData, etc...).
Xamarin will give users a native experience, unlike solutions like PhoneGap or Titanium.
Now Objective-C has some advantages over C#, but in most situations writing apps in C# will generally result in less develop time and cleaner code and less work to port the same app to other platforms. One notable exception might be high-performance games that rely on OpenGL.
The cost of the MonoTouch library is entirely beside the point. The reason you shouldn't use Mono for your iPhone apps, is that it is a crutch. If you can't be bothered to learn the native tools, then I have no reason to believe that your product is worth downloading.
Edit: 4/14/2010 Applications written with MonoTouch aren't eligible for the iTunes Store. This is as it should be. Apple saw plenty of shallow ports on the Mac, using cross-platform toolkits like Qt, or Adobe's own partial re-implementation of the System 7 toolbox, and the long and short of it is they're just not good enough.
I wanted to learn to program and looked at both Java and C#. I decided to go with C# because it was so easy to just open a form and plop some buttons and text boxes on it. With just one download, C# Express got me going.
From what I saw with Java that couldn’t be done. At least not without downloading and configuring other software. All of which I found no easy instructions for. But I really wanted to learn Java.
I really don’t want to learn how to create UIs AND a new language. I’d rather just to concentrate on the code itself. Is there an easy way (like C# basically) to create Java apps?
Are you talking about a GUI builder?
There are many GUI builders out there. Some IDEs like Netbeans come with nice GUI builders for Java.
There are options in the Java community for 'one-stop downloads' like you mention. They are out there, they're just not as public as Visual Studio is. EasyEclipse is one of my favorites.
I've done a fair bit of work (> 4 years) on both platforms and the biggest difference I have found is not so much with the languages per se, but with the whole development environment. Specifically:
In .Net (be it ASP.Net, C# or VB.Net) the examples you find on MSDN or elsewhere tend to just work without a whole lot of tweaking, and the documentation is more reliable, whereas Java examples - especially the open source ones - often don't work out of the box and the documentation (yes, Apache Slide and Shindig - I'm looking at YOU!) is sometimes non-existent.
Having said that, the sheer amount of choice for plugins, libraries and the like for the Java platform is enormous, which is unsurprising considering its (largely) non-proprietary nature.
It seems to me the best and easier way to get what you want is to use Netbeans (JDK 6u14 with NetBeans IDE 6.5.1 Bundle).
It has both the JDK and the IDE in one download. And it has a easy and very good GUI builder.
Java is a very good platform and as you said it is easier to create cross platform applications, however, don't except this from the Desktop UI which, although still cross platform, not always gets right on all platforms with out modification.
You would have to add some code specific for each target desktop, but definitely that's a lot easier than write three different application ( One in Visual C#, other in GTK, and other in Cocoa )
I been learning to program in C# for a few months, but recently I signed up for a course which required Java. So I started playing around with java, first tried Netbeans then Eclipse.
I'm kinda a computer programming noobie (background mainly in web design) so take my perspective as a student. After messing around with Java for a bit i still prefer C#. While both are excellent the factors that tipped C# in my case are as follows
Easier documentation and a large variety of easy to view Video Tutorials, yes I know netbeans have a very large collection of video tutorials as well, they are encoded at such a terrible resolution and bitrate that they are largely unwatchable
Slightly easier to learn, maybe it's cause of the IDE or the syntax, but I found C# easier to pick up.
More functionality exposed right after using the IDE, you will find more controls in visual studio than compared to Netbeans. Eclipse was quite confusing for a noobie like me wading through it's massive plugins.
I think the only thing java has going for it, is that it's supported on more platforms. Though Mono is making up for the linux and Apple side so i guess it's not that bad. Either way they are both extremely productive environments, just in my humble noobie opninion C# is just slightly more intuitive to pick up.
The ability to learn to program in one language or another should most certainly not be based upon how to drag and drop GUI controls, especially since that measure is irrelevant to the language itself.
Side note: Java and C# are so similar that you'll pretty much be learning both as you go regardless.
I'd have to agree with dxmio, I switch back and forth between c# and java quite often. The two languages are quite similar.
The best way of learning programming .. is to write code!
If you know your way around Java, It's a mater of syntax to learn C#.
Programming is just as much a way of thinking in code, as knowing a language.
Personally, I didn't start with GUI. I started with BlueJ, a free "learning" compiler, for Java code.
No programmer in the world knows any language 100%. Their all sitting in their office, and playing with stackoverflow and google all day. Remember, Google is your best friend! (May be a bit of caffe too !)
Reminder: The best way to learn to write code, is to write code! If it's C, C++, C#, Java, PHP, Python or whatever you prefer, it's a matter of framework and syntax.
If you have Java in your browser, all you need is the latest Eclipse bundle.
I would suggest the Java EE edition for your platform from http://www.eclipse.org/downloads/
It appears that there are video tutorials starting from scratch at http://eclipsetutorial.sourceforge.net/totalbeginner.html
Using Netbeans, you can create Java based Swing GUIs pretty easily. Netbeans comes with a pretty nice GUI builder.
If you learn how to program in Java, I don't think it would really be that much of a stretch to create Java Swing applications from scratch. It's just a matter of learning the Swing libraries.
Not being from a .NET background, I can't comment on learning C# GUIs, but from my experience Swing was very easy to learn and it helps A LOT to understand the code underlying what the GUI builder in Netbeans generates.
I decided to go with C# because it was so easy to just open a form and plop some buttons and text boxes on it.
You can do this using builders in either language without writing any code.
With just one download, C# Express got me going.
Netbeans is the same deal for Java.
From what I saw with Java that couldn’t be done. At least not with out downloading and configuring other software.
True, you cannot develop Java with C# Express and you cannot develop in c~ using Netbeans. You do need to install two pieces of software.
All of which I found no easy instructions for.
I suggest you try http://www.google.co.uk/search?q=netbeans+gui+builder+tutorials 55,100 hits or http://www.google.co.uk/search?q=java+gui+tutorials 1,340,000 hits
But I really wanted to learn Java.
It doesn't appear you want to actually write any code or install more than one program at a time. You will find that learning to program in a language will be asking more from you than this.
Was I missing something?
Quite a bit I imagine.
I really don’t want to have to learn how to create UI’s AND a new language.
You can use a GUI builder to layout your windows, but if you want your program to do something useful, you will have to do some programing in a language.
I’d rather just want to concentrate on the code itself.
That appears to contradict everything you have just said. You can't concentrate on the code without learning the language.
Is there an easy way (like C# basically) to create Java apps?
To write apps that do something useful you are going to have to learn how to program and at least one language. I suggest you also learn how to debug and profile your program.
i found this for designing java winform application for you .
please check out
www.formdev.com
JFormDesigner™ is a professional GUI designer for Java™ Swing user interfaces. Its outstanding support for JGoodies FormLayout, GroupLayout (Free Design), TableLayout and GridBagLayout makes it easy to create professional looking forms.