91–100 of 149 posts
I'm huge fan of Xamarin but somehow missing how is this different from MonoMac? For anyone who is thinking to start development of cross-platform GUI app in .NET, I encourage to check Eto project - https://github.com/picoe/eto
How do you feel about Mono Xwt? - https://github.com/mono/xwt
Interesting that Apple allows this, not just on Macs but on iOS devices. When Adobe wanted to cross-compile Flash for iOS, here is what Steve Jobs wrote: "We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party de…
You must have missed the part where Apple relented on that: http://news.cnet.com/8301-30685_3-20015954-264.html http://www.apple.com/pr/library/2010/09/09Statement-by-Apple... "In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we n…
My experience with MonoTouch has generally been very positive. Why I love MonoTouch: - C# goodness, especially event handlers instead of overly verbose ObjC delegates - It's fun to port ObjC loops to oneliners using LINQ and lambdas - I prefer somewhat ugly MonoDevelop to pretty-but-very-odd Xcode - I can reuse both C# and ObjC code, and ObjC code is straightforward to port, if needed - Xamarin support is friendly an…
- You need to make sure you _understand_ how MonoTouch GC works together with ObjC reference counting, or you'll get memory leaks - You'll need to learn to use Instruments to find those memory leaks Interesting, reading that makes it sound like a C# developer that wants to work with MonoTouch will have to verge off to learning at least some Objective C if they want to have shippable code. The coder side of me is alwa…
Interesting, reading that makes it sound like a C# developer that wants to work with MonoTouch will have to verge off to learning at least some Objective C if they want to have shippable code.
The closest analogy to C# develop would be COM and P/Invoke. C# provides tools to interface with COM and native libraries, but you still need to learn some marshalling fundamentals so you can ensure GC doesn't collect objects while they are being used by native code, you need to implement IDisposable and not forget to free unmanaged resources, etc.
It's similar with MonoTouch: you need to understand that MonoTouch classes “wrap” native objects, that disposing of wrappers doesn't necessarily kill native objects because other native objects may still link to it, and that sometimes GC can't know for sure if an object is eligible for killing, and will never collect it.
In general, this comes down to: don't rely on .NET GC to kill native objects, do it yourself. My life got so much better after I started doing so.
Things that confused me most (and which are all you really need to know about ObjC memory management):
http://stackoverflow.com/questions/13058521/is-this-a-bug-in...
http://stackoverflow.com/questions/13064669/why-cant-monotou...
This is a great screencast I wish I saw before I started coding in MonoTouch:
http://forums.xamarin.com/discussion/33/finding-memory-leaks...
It explains how to find native memory leaks.
How much time does it take to learn this? No more than a week. But it takes more to find memory leaks in existing app so it's better to get some understanding and learn to profile early. For me, “fixing” a two-month-old codebase took about week and a half.
Earlier quoted context omitted.
A few diferences: 1. Xamarin.Mac comes with a commercial license, so you can ship to the Mac App Store (not allowed under MonoMac's LGPL license). 2. Xamarin.Mac comes with commercial support. 3. Xamarin.Mac includes bindings for several new APIs, including CoreBluetooth, GameKit, StoreKit, SceneKit, and the new Mountain Lion AppKit classes. You can see a full list of differences here: http://docs.xamarin.com/mac/gui…
MonoMac appears to be ASL/X11. MacCore too. https://github.com/mono/monomac The code is licensed under the terms of the open source Apache License version 2 or the MIT X11 license, at your own choice. Also, the Mono wiki indicates you can already deploy to the App Store (which I've been looking at doing for a project): http://www.mono-project.com/MonoMacPackager With the new release of the MonoMac add-in for MonoDeve…
Now that we are launching a product, we offer the license as part of Xamarin.Mac.
I will update the page accordingly.
Earlier quoted context omitted.
Personally, I think computing power has hit the point where Java desktop apps and applets aren't that big a deal. I've got one running on my desktop right now. It runs for day's on end without being a significant burden to the rest of the system.
It's the quality of the experience, GUI, not just the resource-hoging of Java Desktop app. And even for that "It runs for day's on end without being a significant burden to the rest of the system" is hardly something to write home about.
Earlier quoted context omitted.
- You need to make sure you _understand_ how MonoTouch GC works together with ObjC reference counting, or you'll get memory leaks - You'll need to learn to use Instruments to find those memory leaks Interesting, reading that makes it sound like a C# developer that wants to work with MonoTouch will have to verge off to learning at least some Objective C if they want to have shippable code. The coder side of me is alwa…
Interesting, reading that makes it sound like a C# developer that wants to work with MonoTouch will have to verge off to learning at least some Objective C if they want to have shippable code. Yes, you'll definitely need to learn some things about Objective C. This isn't really about learning the language itself though. It's more about understanding iOS and ObjC runtime. The closest analogy to C# develop would be COM…
For example, I spent a lot of time making sure I don't load heavy .NET objects, but most memory crashes went away when I started using JPG instead of PNG pictures in a picture-heavy app.
Then it got a lot better when I took time to learn about best iOS practices such as keeping a pool of about ten reusable views and re-filling them with new content as they go offscreen when the user is scrolling, instead of creating hundreds of views at once. What is really nice, iOS6 UICollectionView class enforces this memory usage pattern by providing a neat API with view pool. Use it instead of rolling out your own collection view.
Another hard lesson was to never block UI thread and do any computational intensive stuff such as parsing JSON in .NET Tasks on another thread. This is obvious in retrospect, but I thought parsing JSON wasn't intensive. It was.
Finally, if your app crashes randomly, it's most probably your fault! I really need to stress it because I fell into this trap, thinking MonoTouch is buggy when my app crashed every minute. Turned out, it had insane memory leaks and aggressively allocated large amounts of memory at once—but I didn't bother to learn about “right” techniques until it was too late. Learn to profile early so you don't panic later.
Earlier quoted context omitted.
It costs $399 for an individual license, so there is a cost barrier. I balked at the cost of MonoTouch, but since playing around with it, I've got to say- I think it'll be worth the money. I just wish it was a little more affordable to hobbyist developers like myself. EDIT: I just noticed that they had a 25% Black Friday offer. Damn.
Thanks for the feedback. We definitely have two classes of customers - businesses and professional developers who can't believe how cheap our products are relative to the value they're receiving, and hobbyists who are more price-sensitive. It's tricky to balance these two.
Earlier quoted context omitted.
Not at all. This offers a completely different solution than java. With java, you write once and run on everything. This lets you write C# on OS X, but it won't compile and run on Windows or Linux. Windows software can't be as easily ported to OS X either, the entire GUI, at the least, will have to be rewritten. I would argue that Python would make more sense as a java-killer. It has the write once, run everywhere th…
Yes, but write-once-run-anywhere solutions deliver mediocre user experiences on every platform. You don't want your Mac app to look anything like your Windows 8 app. With Xamarin you separate the presentation layer of your app from the rest of the app, and the only thing you're rewriting from platform to platform is the UI. Typically this is only about 25% of the code (though of course it can vary). This is how our c…
You can do this today with C, but I'd sure rather work in something more modern but which didn't require dragging around half an OS worth of runtime infrastructure. Something more like Go or D, I imagine, if they ever get any traction as client ("desktop") languages.
I downloaded the trial and tried to create a Xmarin.Mac.Project and I got an error that I need to buy the software. Did I choose the wrong option? If so, which one should I be testing? Why can't I test out all features of the tool? Also, I agree with everyone else that the price point being $399 is way too high for personal development. Would it be possible to get something cheaper for personal development to see if…
Also you could try MonoMac which is almost the same thing, and is OpenSource. The Xamarin version is supposed to have Wider API coverage and do a bit more (for the cost).