Does the fact that different mobile platforms can use similar languages implies that you can reuse classes between these platform ? For example c++ code on iOS, Android and Symbian devices. Or is there some other things to take into account, libraries, etc. ?
In the same spirit would it be possible to share C# code between iOS, Android and Windows Phone using MonoTouch and MonoDroid(eventually) ?
Edit: Would it be possible to share the UI code between MonoTouch, MonoDroid ?
No, the languages are definitely too different. To be able to reuse classes they would have to be written in the same language. And since Apple have been kicking out every language except Objective-C from iOS, you won't be able to reuse code. The state of MonoTouch after Apple's (outrageous [subjective]) decision [1] is now very much in doubt.
However, in typical dictatorship fashion [subjective again], Apple have not been completely consistent, so they have not prohibited the use of technologies like PhoneGap ( http://phonegap.com ) or Titanium ( http://www.appcelerator.com/ ). There you write your application in HTML5, Javascript & friends. If you can live with writing apps using these techniques, a cross-platform approach with only one codebase is still possible.
And of course, remember that algorithms are not language specific. Classes in different langages can often be made almost identical in function, although you'll have the disadvantage of having to maintain several of them.
Edit:
Clarifications from discussion:
There is actually support for using C++ classes [2]. That opens up possibilities of code sharing of more abstract parts of an application.
The state of MonoDroid seems to very much unclear. The discussion referred to in [1] is long and have several strong answers pointing in both directions. It's important to remember that Apple's de facto target in their new licencing clauses are Flash, not cross-platform frameworks in themselves, no matter what Steve Jobs says [3]. That leaves open the possibility that Apple may want to silently allow apps based on MonoDroid or other cross-platform frameworks.
[1] As usual, this is not 100% clear, for example see this question: Is MonoTouch now banned on the iPhone?
[2] http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html#//apple_ref/doc/uid/TP30001163-CH10-SW1
[3] http://www.apple.com/hotnews/thoughts-on-flash/?aosid=p204&siteid=1503186&program_id=2554&cid=OAS-EMEA-AFF&tduid=fb90c7ac85c9a334decb42b892cda59b
Related
I am a python programmer looking to make my first mobile app. I'd like to make make an app for both iOS and Android that looks and feels native. I thought I'd start with a simple iPhone app, just to see how everyting works. Mono seems like the obvious solution. However, I was surprised to find that almost all of the example Monotouch code I found, as well as the answers here on Stackoverflow, relied heavily on the IOS frameworks, essentially making the code not cross-platform at all. For example, I was looking into using a timer. All the examples I read use NSTimer. Surely this is possible to do in C# itself so that that part is cross platform? But then, why do all these people use NSTimer?
So, my question is, how cross platform is Mono development for IOS/Android? Is it still worth considering for smallish apps, or only for very large apps with lots of business logic?
Your question is too general. I'll answer it for two scenarios:
Specific examples
If you are looking for how do create timers, create arrays, traverse lists, then why not just look for regular .NET examples and compile this into a single class library that can be in both projects.
Sharing code as a whole
If you just mean in general sharing of code between the two platforms, you should look at frameworks that already have the templates and examples created for you. Two such patterns are http://www.monocross.net/ (MVC) and mvvmcross (MVVM). This can help you architect your project from the beginning to support cross-platform development (iOS, Droid, Wp7, desktop, etc).
There are timers, arrays, and strings in the .NET Base Class Library. As you have seen, there are some in the Cocoa library that MonoTouch wraps. For example you have your regular run of the mill string in .NET, but in monotouch you also have the option of NSString. I think to answer your question, the reason people may use the iOS specific types sometimes, is either because they weren't trying to make that code cross-platform and it was a matter of preference, or they had to do something specifically that required the use of that type which wouldn't be the case for everyone.
Mono's purpose isn't just to help with cross-platform development. I come from a C#/.NET background so even if I was building an app with one screen and two buttons, I would use MonoTouch because I would rather use C# with the .NET BCL than Obj-C. But that is my own personal choice and enough of a deciding factor, for me.
EDIT
I added the links.
I think the key point is that in order to use Mono and NOT use platform specific types etc like NSSTring you need a platform specific wrapper (abstraction layer) that lets you write code that only uses Mono types.
i.e. You are asking about using Mono but what you actually need are MonoTouch and MonoDroid (the frameworks referenced by #valdetero, depend on having those wrappers underpinning them).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I try to find a way to develop real native mobile apps, cross-platform. The amount of tools I found is huge, very huge.
All of the tools I have tried 'said' that the end result will be native, but in fact it isn't true. It is an executable with a webbrowser in it and some extra native layer/framwork to device specific features.
The reason I want a real native app is:
Speed and compact
Avoid browser issues
Market acceptance
Avoid easy/'script kiddie" reverse engineering
The products I have tried:
Appcelerator (does not work correctly on my system)
PhoneGap (does not create REAL native apps)
Embarcadero radPHP EX2 (uses PhoneGap)
Embarcadero radStudio EX2 (cannot create mobile/android apps?)
Adobe Flash Builder (Works very well but relies on Air, so apps are huge and no
native devices such as vibration (posible, but must write it
yourself)
Flash Develop (but same as Adobe Flash Builder)
..... and some others ;-) like moSync......
Currently I have downloaded "RhoStudio" but has some doubts about it because in the introduction video they talk about the things that I don't want.
Target directions are in the first place Android, iOS and maybe in the future Windows Phone.
Note: I don't have a Mac so I cannot compile it on a Mac.
Is what I want impossible or is there such product around that can do this?
EDIT:
See my answer, the answer is NO!
After 2 years asking this question I can say: NO, it is NOT possible, it's a myth.
All products I have tried use some kind of wrapping or use a second language as a layer to the call the native stuff. Although the libraries are native, the main program is not. The latest answer of Cosku with smartface.io is a good example, they claim it is native but it is NOT.
Why is it so difficult? The problem is the programming language (differences in language that makes it complex) that is required for a platform. It is too complex to translate a second language into the platform's main language and it's specific libraries, you can only achieve this by wrapping things with native binaries. Second obstacle is the needed compiler that must be able to run cross-platform.
But why rely on a second language or third-party development tool to build apps when the output is mostly the same is bad, the problem is perfectly illustrated in this image:
http://xkcd.com/927/
The image is about standards, but that's what happen, creating a new standard for a standard. For example, when using PhoneGap, you have to learn the basics of the PhoneGap API. You rely on a 'new standard' calling PhoneGap. The problem with this is that you completely rely on PhoneGap support and it existence. It can introduce a second weakness in the lifecycle of an app.
IMO, if you want to wrap things to make it cross-platform it is not a smart idea to rely on third-party products and libraries. Better is to write a wrapper yourself, like I did and skip the bloat. A real benefit of this all is that you wrote the wrapper code yourself and you understand underlying structures. Besides it is easier to extend or change and you can skip the things you don't need.
Today I create and design the UI of an app in the longest existing and stable 'language' HTML with a javascript interface. The app can also run in a browser too and does not break when there is a specific function missing, like vibrate for example. You can not get the same results with phonegap, try it! You can design the app with responsive techniques at ease like a normal website (try this in Android for example ;-)). Technically, it can run everywhere, on any platform in a browser or webview but don't use any special Mobile javascript libraries! You don't need these special libraries, really, use the 'normal' library versions instead.
I have wrote a compiler/obfuscator for it to 'pack' the UI-source into just one file that will be loaded by the native shell. This is to protect the source, so it is not easy to view or modify the source.
The only thing I have to do, to support the app platform is write a native wrapper for it. If a platform dies for some reason (for example Windows Mobile in the past), I only have to write a new wrapper for it. This is easier to do than write the whole program again from scratch. Besides, when there is a new platform it can also run in the platforms browser too.
If your app not rely on specific hardware (like a game) or can run without special hardware requirements, this is the way to go to extend the life-cycle of your app. Use HTML5 and javascript to design the GUI and use a native shell to use specific OS features.
Is it slow? I have to say no. At least don't use any bulky and bloated special designed mobile javascript library stuff and don't use the click event on touchscreen devices, use touchstart instead. Also the HTML engines will/are improved these days and there is better support for HTML5 features that enables you to write powerful HTML5 webapps without the need to implement this in a native language.
IMO, this the way to go (for me) and my journey to find the best way develop mobile apps cross-platform and to extend the life-cycle. Hopefully, it can help you too to decide what is the best to do.
For cross-platform native iOS, Android, Mac, and Windows apps, check out Xamarin. Code in C#, compile to native. For iOS, you can leverage the XCode tools for app layout, and Xamarin Studio integrates very cleanly with it.
And for the sake of completeness, PhoneGap has a worthy (yes, WebView based) competitor in TRIGGER.IO. While it's approach is similar to PhoneGap/Cordova, it improves the API for accessing native functionality, simplifies push notifications, and performs much faster cloud builds.
I am not associated with either of these products in any way... I just like them both.
Have you tried www.codenameone.com? It's open source, java based, only need eclipse or netbeans to develop.
Firstly
Appcelerator (does not work correctly on my system)
Is there a certain issue your facing ? are getting java errors or something, might not have been setup correctly.
Short answer is no, you have to have some level of abstraction in order to achieve this, java and objective-c are completely different languages, as well as Android and IOS SDK's having different methods, procedures, styles, design's etc. There is no way to have something work on both without there being a middle layer to convert or render.
Appcelerator will be the closet thing to what your looking for as its not a webview wrapper like the others, true it does interpret javascript, but because its not wrapped in a webview you avoid the browser issues.
Speed and compact comes more down how you code the app more than what its coded on, true Titanium apps will be bigger in size because of the library but that doesn't make it bad as such, the benefits of getting 2 apps far out weighs the extra few megabytes I would think.
I'm pretty sure all of these tools have market acceptance as they wouldn't be successful without it, again for the likes of apples requirements its down to the way you design it, not the tool in the background.
If you want to use IOS you will need a mac, if you want to publish in the app store alone you need xcode and the built project to use the application loader, I'm not aware of any tool (even the webview wrappers) that don't require you to have the IOS SDK as it can't run in the simulator, package the app or run any of the code without it.
If you want to make apps you have 2 choices, learn each platform or use one of these tools, if there was some magic tool that did everything I guarantee it would be the most popular thing on the planet and you would have heard about it / found it.
This is one reason why "the cloud" is so popular. Instead of writing your app several times over, you write all of the functionality on a server. The actual "apps" are then simply your user interface to the functionality, which can be really simple depending on your needs. If it is that simple, then you could write the apps separately for each platform, but they would all use the same "cloud" backend.
If I am not mistaken, this is representative of what most apps by companies who have a cloud architecture do, and is also why many require a data connection.
I don't think that it is possible to write once and run everywhere without some kind of wrapper or layer, this is due to the fact that each platform has separate APIs and even programming languages. You would be hard pressed to write one set of source code that runs natively on both Apple and Android devices, for example. This is not to say that it isn't technically possible, desktop operating systems have had such cross-compiling portability for years with C/C++, and Java only made that much easier. Of course, the engineers of Mobile operating systems don't seem to share a vision of interoperable APIs.
To conclude, I would recommend A) writing the app twice (awful I know, but it will provide the reliablity of native execution on both devices, and can be done with minimal pain) or B) breaking down and using one of the "script-kiddie" frameworks. These actually may not be that bad if your app is simple enough, and it may not be that reverse-engineerable at all. If anyone has any suggestions as to the best "near-native" cross platform framework, that would be useful.
Well, there are several things to consider, if you want native look and feel there are frameworks like Sencha(www.sencha.com) and Kendo UI(http://www.kendoui.com/) that simulate it on JavaScript side. I found them both good looking on Android and iPhone but no support for Windows Phone yet.
If you are looking for real native widgets combined with HTML you can look into MoSync's Native UI(http://www.mosync.com/documentation/manualpages/jsnativeui-library), which support windows phone Metro UI too, or Titanium(http://docs.appcelerator.com/titanium/2.1/index.html).
Anyway one other thing is that you can use packagers like Phonegap or MoSync or AppMobi(which I think uses something similar to PhoneGap build) to wrap your app and put it on App markets. from these list PhoneGap especially is not designed to provide you with any specific UI functionality although I have seen some attempts to add tab bar plugins to Phonegap.
I have a C# app that I've managed to get working with Mono and running on OS X. The application itself runs just fine, but it doesn't really look all that good when run on OS X. The button fonts look jagged, and many of the default features that are there for the Windows 7 version aren't present. To me it sort of looks like a Win98 application with an OS X top border taped to it.
I'm looking into possibly learning Objective-C so that I can write 'proper' OS X apps, but for the moment I'd like to be able to get my projects working on an Apple without having them look Frankensteined together.
Is it possible to convert a WinForms app over to Cocoa? Is Cocoa the correct interface to use?
If possible, what's the best way to go about it, and do any of you know of a good tutorial/writeup on the process to get me started? It'd be nice to see something that actually shows the process being done. I learn far more from example code along with a short explanation than I do from a generic article.
Thanks again!
If you want to create a native looking OSX application, you are correct that you want to use Cocoa. If you still want to use C#, you can use MonoMac.
MonoMac allows you to build your GUI natively on OSX (in fact, using the Interface Builder shipped by Apple), but allows you to write your app in .Net/C#. This way you can continue to use your existing application logic and only have to change the GUI code.
It's pretty much universally true that a ported app will always look like a ported app. Even large companies with huge budgets can't pull off anything better (I cite Adobe - what a mess).
Slapping a Mac face on a Windows app port will show its seams. If you want the application to behave like a native application (and take advantage of the performance-related goodies the platform offers), the absolute best approach is to use the architectural documentation, specs, and requirements I know you have - conscientious developer that you are - to adapt the design to the native platform. That's the Cocoa Frameworks (the API), which are written in Objective-C (the language).
There's quite simply no other path that doesn't end with a crappy-looking port that's riddled with bugs and behavioral problems born of the porter's insufficient familiarity with the target platform. This isn't just limited to Mono/C#-to-Cocoa/Obj-C. The opposite is just as true. Even Java-for-PlatformA-to-Java-for-PlatformB ports of desktop apps suffer these problems. Start with a solid architecture and build for the platform if you want the best user experience.
That said, you're already a step ahead by realizing this and wanting to do better. Bravo! :-) Though I don't know of any tutorials for this path, I'd suggest even that's not the correct approach since you indicated you're looking for quality. Avail yourself of the many Cocoa books and many more online communities (like this one) and learn the platform before committing to your Cocoa-adapted architecture and code base.
Update based on comment debate
To be clear: I'm not saying there's no way or that there's no tool out there that makes it possible. There're actually plenty I've seen but don't recall and won't bother googling. My point remains: the OP is concerned with quality of native appearance (and I assume behavior and possibly performance) and porting tools / translation layers don't achieve this due to inherent differences in the platform's architecture and user experience idioms. The OP suspects it might be best to learn the platform and build specifically for it and I'm agreeing. Your opinion may vary. Have at it.
Now that Nokia will soon ship my pre-ordered n900, I thought I would familiarize myself with mobile development - maemo seems friendly enough for a guy who's done development only on Linux since days of Amiga and C=64 and is in love with Python.
However, I have no clue whatsoever on stuff like UI:s and especially mobile UI:s - also, I would not like to learn to code just for n900 but in a more broad sense. Looks like most guides etc are very platform or device specific, so any suggestions on like "UI best practices" tutorials, books or websites that are general to all mobile platforms - not just for say Maemo or iPhone.
Actually, that is not really true. If you learn how to use the two main windowing toolkits (GTK+ and Qt) in Maemo, you will be able to write GUIs for all sorts of devices. Nokia has purchased Trolltech, the makers of Qt, and they have released all the GTK+ changes back to GNOME. This means that both Qt and GTK+ are open source so you can port them to any platform.
In fact, Nokia has already done some of the porting for you - they are porting Qt to Symbian which runs on millions of mobile phones. Both Qt and GTK+ run on many platforms, not just linux, so you can write programs for Windows with these two toolkits as well. Note that you are not going to be able to create applications that take advantage of the native operating system's Windowing software, like Aqua, but you'll be able to get a native look and feel.
Learning either one of these Windowing systems will stand you in good stead for developing GUIs and nearly any platform you can think of.
Everything you're finding is platform specific because device development simply is very platform specific. The API sets are widely different. The UI paradigms, including how controls are created and layed out, are different. The processes themselves are handled are vastly different.
There simply are no "one size fits all" rules or recommendations other than maybe broad hand-waving like "remember you have limited resources, so keep your memory footprint low" or "the processor is not a desktop, so things take longer. Code complex algorithms accordingly". As you can see, not terribly concrete or useful.
The unfortunate thing is that you really have to just pick a platform and start to learn it. If you want to try your hand at multiple platforms, you basically have to learn multiple separate skill sets (and often multiple development tools as well).
Forum Nokia has good documentation about user interfaces for mobile devices, of course these are simple general rules as already said here, but take a look to this page: http://www.forum.nokia.com/Technology_Topics/Design_and_User_Experience/ (see also the essential links at the bottom)
The mobile UI isn't GTK+/QT folks. And there is a "one size fits all".
It's called the Web. Learn HTML5 and start writing mobile applications.
I am in the beginning stages of creating software for a mISV-to-be. The program is a desktop application and in the long run I want to have a native version for both Windows and OS X (I have a looked at various cross-platform APIs, and none of them meet my needs). Initially though, I don't think it makes sense to develop for two platforms at once. With that in mind, I have been looking at WPF for Windows and Cocoa for OS X, and they seem similar.
Has anyone had experience porting one to the other? Are there particular techniques/paradigms to follow that will make porting easier? Ignoring business considerations, would you recommend developing on one of them first?
Well. Once you've written an app for Cocoa, it is possible to port it to Windows. This could be done using gnustep or Cocotron.
If you do it the other way, WINE is meant to make porting easier.
I would rather write the OSX version first. This is because Windows users have no clear idea what they want an application to look like. In my experience, they are quite able to suffer through all kinds of user interfaces. Consistency has little value to them. Since there is no common agreement, what a Windows app should look like, nothing stops Windows users from actually liking OSX designs, and they even frequently do. iTunes for windows looks like a very typical OSX app and you hear very few complaints that it would not be enough Windows-ish.
Going the other direction, this is not true. OSX users have a clear preference for Cocoa apps and very little tolerance for, as an example, things like GIMP or Inkscape which work under OSX just as well as anywhere else, but look plainly ugly to the OSX trained eye.
I think that you're on the right path by choosing windowing environments that are specific to each platform. This approach allows you to create a user experience on each platform that isn't restricted by the compromises inherent to cross-platform windowing toolkits.
A good first step is to break your design down into two parts: platform specific and platform neutral elements. You can already put any UI code into the platform specific column, but maybe your app will need some data persistence that can be written in platform-neutral C++. What you may find with this approach is that there is quite a bit of logic and infrastructure that you can write in a platform-neutral way, leaving just the UI and glue code as platform-specific.
There was a recent episode of Late Night Cocoa titled Porting Large Applications to the Mac platform. Your app may not qualify as "large" but this podcast gives quite a bit of great porting knowledge from someone that's done it a few times.
I'm currently working on porting tools in this space and have many years of oft-painful experience in either using or writing cross-platform frameworks on Mac and Windows.
One of the biggest problems in the past has been Apple's refusal to open up the nib format for Cocoa (Carbon nibs were open XML files years ago). That changed with XCode 3 and the .xib format, as well explained by Frasier Speirs.
At the basic layout level, at least, there is now an opportunity to automate porting from one XML format to another. I regard WPF (XAML) as cleaner and so I'm using that as my base format and migrating to Cocoa.
When it comes to the code behind, whilst you can use C# under Mono, the CocoaSharp project seems either stalled or very slow and I wouldn't recommend it.
If you are comfortable with C++, consider having as much logic as possible in C++ with a thin platform-specific layer in C# and Objective-C.
Another approach worth investigating is using a dynamic language like Python or Ruby. I'm not sure which is more mature at present between IronPython and IronRuby but both are now supported by Microsoft people. On the Cocoa side, I think the flexibility of Ruby syntax will triumph and RubyCocoa is probably overtaking PyObjC.
Otherwise, work in C# and Objective-C and maintain two completely independent code bases with identical designs. Fortunately the frameworks have comparable semantics for most things, especially if you make use of bindings.
Well, there is not a straightforward path. The best method is to use something like Model-View-Controller pattern or some other architecture to separate business logic and so forth from the presentation. However, unless you are using Mono, there will be very little code for you to share, I think.If you are developing WPF then you surely doing .NET and, other than Mono, Objective-C is the standard programming tool under Mac OS X.
Keep a good design and you can have most of your code simply be an Objective-C version of your .NET code and vice versa rather than trying to find a migration path.