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).
Related
I'm currently investigating the alternatives for crossplatform development for Android and iPhone (Windows 8 could be a nice addition). The app is basically a "map with an asociated app", and certainly not a game.
Searching here I see many outdated advice and tools from 2010/2011, but since then Apple has changed their policies and surely new things have appeared.
My current list and light research (might have facts wrong) is:
Monotouch/Monodroid: .NET (Mono) framework. Create "native" apps on both platforms. Requires rebuilding UI code (or similar things).
Appcelerator: Javascript framework to compile native apps.
Corona: Similar to Appcelerator.
Phonegap: Similar idea, but looks like it uses a wrapper to appify HTML5 content
SenchaTouch: Another HTML5 based platform.
Wink: Yet another HTML5 toolkit.
XVLM: Android to ObjC compiler, probably creating ugly iOS apps.
Unity3D: For games only.
Moai: For games only.
So, there are three main ideas, with some frameworks implementing each, it seems to me:
Have an abstraction layer over native iOS/Android code and build for each platform using the provided layer. (Monotouch, Unity3D)
Use HTML5 (coding in Javascript) and some kind of wrapper to "appify" the web content. (PhoneGap,Sencha,Wink)
Code using a framework that will output as a compilation pass (or similar) a native app for each supported platform (Moai, XVLM,Appcelerator,Corona)
The questions:
Is there a fourth idea I haven't yet found?
Is there any blatant mistake in my research for any of the specified frameworks?
Is there any known problem for map integration with any of these ideas or specific frameworks?
Only a partial answer:
Ad 2. Appcelerator / Titanium is more than just HTML5. I read this pretty extensive comparison between PhoneGap and Titanium the other day on Hackers News. I found it very informative. The link points to the HN comments, the link to the actual article is at the top.
My main experience is with Mono for Android and MonoTouch, so I can't personally speak much to the other options. I personally find it to be the best option there is, as it allows you to share a large amount of your code across the platforms (even extending to non-mobile platforms if you stick with .NET), while still allowing for a 100% native UI, which is extremely important. If you're looking for resources on getting started, I have this video which discusses approaches and libraries for sharing a lot of code across platforms, and also this book which covers the same thing, but also expands to talk about how to do things like store data, use maps, access the network, etc.
I also want to mention MonoGame, which is absent from your list. MonoGame is an open source XNA implementation that sits on top of Mono to allow you to target iOS/Android/Max OS X.
From what I have experienced, if you want to have a native app go Mono, if you don't need native go PhoneGap. Native is best of the UI is very important, ie games or fairly graphical apps. But from business type app, CRUD, Phone gap works well.
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.
I'm looking for some arguments to pitch to my boss and fellow developers.
We're currently finishing up the preliminary UI mockups and getting ready to move on to the next phases of development. In the meantime, I've been digging through the depths of the Carbon, Win32, and wxWidgets APIs attempting to make some of the controls have a more native look and feel on the Mac and Windows platforms.
The more I dig into the Win32 and Carbon APIs to implement the things we want in our project's UI, the more antiquated they feel, and the more I'm beginning to think that we should be implementing the project as described in the last paragraph here.
We're using wxWidgets for our current projects. wxWidgets is coming along on the wxCocoa port, but it doesn't look like it's going to be ready for prime-time before we start major development efforts on our new application. On the Windows side of things, it wraps the Win32 API rather than WinForms or WPF (likely due to native vs. managed code).
We're already designing the system with the MVC pattern in mind, thus aside from having to write two native UIs, it should be very doable, and, IMHO, easier to get the desired UI effects using modern APIs such as Cocoa and WPF.
I've been trying to push these points subtly, but the start of major development is coming soon. Does anyone have any suggestions on how to pitch using native UI toolkits in our next application vs sticking with wxWidgets?
Thanks in advance.
Create your core code in Standard C++ and use Objective-C++ with Cocoa to create your user experience on the Mac and C++/CLI plus C# with WPF to create your user experience on Windows. Follow the platform guidelines for the Mac in your Mac version, for Windows in your Windows version, and don't even bother thinking about trying to share user interface code.
One good way to manage this is, instead of just Model-View-Controller, following a Model-Model Controller-View Controller-View architecture. Your Model Controllers are platform-independent and manage the higher-level functionality of your application. (For example, its entire concept of documents, file format, job queues, and so on.) Your View Controllers are platform-dependent and mediate between your Model Controllers and your user experience.
Of course you'll probably also want some platform-dependent code at the model level too; for example to use NSOperation on the Mac and thread pools on Windows to implement job queues. Just create your own lightweight abstractions for that sort of thing.
Actually I think using Qt has become very interesting since it's now LGPL
Every time you add a layer of abstraction, you trade control over the details for more rapid development. You'll be able to get a lot done up-front using some cross-platform framework. On the flip side, when you want to do something that the framework doesn't support—and lets face it: it isn't going to implement all possible things those native APIs can do—you either have to implement it (for all platforms) using the native API, or do some other wierd hackery to get a "good enough" solution. And of course, when things go terribly wrong, having that extra layer of code you don't own makes it harder to debug. There really is something to be said for owning your entire stack as much as possible.
Writing two font ends is a lot of work, maintaining two front ends is a huge amount of work, if you need your program to run on multiple platforms go with a multi-platform toolkit.
If you write platform specific front-ends, each using the state of the art tools for that particular platform, you will get a much better user experience - but the cost of developing and maintaining those will be on the same order of magnitude as developing the entire application from scratch for each platform (yes, even with MVC).
Personally, I'd rather stick multiplatform and don't give a damn for that eyecandy, but if I wanted to pitch the use of those native APIs, I'd work out the (end-user-visible) differences between how things are done in different GUIs. If you can convince them that, in order to feel native, the program's user interface has to look and feel very differently on Windows and OSX (because of different design guides/philosophies/whatever), they should understand that, even with wx, you would still have to implement it twice, to accommodate those different requirements, so you might just as well use the real thing, i.e. the native API.
Also see this thread on the Google Chrome mailing list discussing the same choice of UI for Chrome on different platforms.
Win32 is definitely waay to old, but you might want to look into something like Microsoft Foundation Classes which is designed to do native development with C++. I assume that a similar thing exist for MAC.
Personally if I was in your situation I would properly also go for QT or WX.
Does anyone have any suggestions on how to pitch using native UI toolkits in our next application vs sticking with wxWidgets?
No one likes a corridor-wiseass.
I think action speak louder than words...make a small prototype of how you think it could be done, and show it. Maybe you have to do this in your spare time.
Cocoa is really great so I think that with little code you can show an idea...well, this require that you know Cocoa enough.
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.