i am right now exploring the capabilities of Monotouch (by Xamarin) with other solution such as
Monocross?
So can any one explain when to use Monotouch and when to Monocross.
What is the advantage & disadvantage of these framework w.r.t native app development?
Just to try to add visually to Stephane's answer, here's a diagram slightly adapted from one of my presentations:
Note that you don't have to use a shared library like MonoCross, MvvmCross, etc. You can always write your own architecture. This is like in web apps - you don't have to use WebForms, ASP.Net Mvx, FubuMvc, etc - you can just use Request and Response and talk more directly with the web server.
So, you can just write your own code to adapt your app to each platform like:
Which approach you should take - depends on the requirements of you and your app... and on personal opinion too.
Monocross is a cross platform MVC framework. As a framework, it's open source. But you need either monotouch or mono for android in order to deploy on the devices.
Those 2 stuffs doesn't compare. They sum up.
With tools like Monocross or MvvmCross, you really get a crossplatform code sharing framework, and that's your advantage over coding in native languages.
Related
This one is a quick question regarding the possibility of having the same LnF (same look) on Android and iOS, is there an API that can provide something like this? SImilar to MAUI in MoSync or IwUI in marmaladeSDK?
Basically what I would like to do is to create my UI once for both iOS and Android using monodeveloper.
Note: Before anyone downvotes anymore, please take into account that this is a real requirement for a real project. The question is not without reason, since after looking at the documentation, I can see that Xamarin does not provide such solution, but other multi-platform SDKs do provide such solution, and since the mono ecosystem is vast, perhaps there is a third party library that can provide such functionality.
Unfortunately most of your code portability will be on the backend (non UI) when leveraging Monotouch. There are far too many inconsistencies with how an Android UI vs iOS UI are implemented respectively to their OS's.
Have you checked out http://ifactr.com/overview ? It is a paid product so I haven't tried it, but it might be at least work looking into. Other than this, no there is no cross-platform UI if you go the Mono route.
Taken directly from their page:
"But we learned that even with as much code sharing that MonoCross provides, for applications with significant UI layers, the burden of creating platform-specific UIs can be overbearing. So we created the iFactr UI abstraction layer, which allows developers to code to an abstract UI interface, and then reference our iFactr concrete implementations of that interface for all the mobile platforms, both as native UI implementations and HTML5 UI implementations.
While not a silver bullet for all mobile development, it is designed and optimized for rapidly creating data-driven UIs that enterprise users tend to demand. And because it’s integrated with MonoCross, you can mix-and-match your iFactr UI screens that are shared across platforms with screens that you can code to target specific platforms using the entire set of native APIs available on each mobile OS."
The problem is Android and iOS have different UI / UX metaphors.
Take this for example: http://kintek.com.au/blog/portkit-ux-metaphor-equivalents-for-ios-6-and-android-4/
The differences are fairly significant. If you use a development wrapper then you'll have to 100% rely on their tools. We've had experience with Titanium in the past and it wasn't good at all.
My scenario: trying to port a small part of an application created by our company from native code (ObjC for iOS / Java for Android) to C-Sharp. The project will interact with our webservices. Goal of this project is figuring out how feasible it is to port our whole app to Mono.
To create URLs, I'd like to use String.Format(). I thought it'd be a wise idea to put this 'service layer' inside a Portable Class Library (PCL) since I don't expect this code to change across platforms. Sadly, it seems the String library is not available for PCLs.
So my question is the following:
I think the main advantage of PCLs over "normal" libraries is that they shouldn't need a recompile for different platforms. Is this assumption correct?
This experience makes me think that for the moment PCLs are rather limited. Should I try to stick with PCLs and work around these kinds of issues, or might it be better to stick with a "normal" library for now? --- I'll assume the "normal" library has more functionality exposed.
You can use PCLs currently across many platforms, but it does require some small hacks to your setup.
These hacks are listed in http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
Once you've got those working then the functionality available is quite broad - and it definitely includes things like String.Format
For the situations where the PCL profile is not broad enough, then you can use several techniques for extending them - see http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx . The technique I generally use is to use MvvmCross Plugins - which are basically PCL interfaces with platform specific implementations. But these plugins are generally at the level of 'make bluetooth work' rather than at the level of String.Format
I do lots of PCL work across WinRT, WP, WPF, MonoTouch and Mono for Android - see http://slodge.blogspot.co.uk/p/mvvmcross-quicklist.html for lots of links to PCL work.
It's true that Xamarin have recommended not using PCLs for a couple of years, but that situation has now changed and the official support for PCLs is under way - see http://slodge.blogspot.co.uk/2013/02/the-future-is-portable.html
From a development perspective - especially from the point of view of using refactoring and testing tools - I don't hesitate to recommend you use PCLs now... especially for operations at the String.Format level. However, each project is unique... so it's not always the right answer.
One important note: right now it's better to not reuse the PCL binary files across to the MonoTouch platform - for now, build your portable libraries against the specific MonoTouch library platform. See http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html?m=1
Perhaps you want to look at the efforts other who have got PCLs working to a considerable degree with monotouch and monodroid.
For example see http://www.slideshare.net/cirrious/mvvm-cross-going-portable . You'll also find instructions on how to setup PCL support for MVVMCross here http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html .
Xamarin has recently committed to providing far greater PCL support rather than some of the workarounds that people have been having to make, but it is worth the effort.
So GWT best practices encourages one to use some flavour of MVP, which should in theory allow one to write different native views while sharing the presenter business logic.
This seems to be at the heart of the GWT spin off Google project http://code.google.com/p/j2objc/ which converts the non-UI part of your code to Objective-C, allowing you to write the rest natively in Objective-C.
So my question is: If this really hard part of the puzzle is being solved, how hard would it be to include an HTML5 mobile library (like MGWT or Touch4j [Sencha]) into this MVP pipeline to have the best of all worlds?
Having dabbled with http://code.google.com/p/playn/ , this clearly seems to be the blue-print for having a cross-plaftform build system (native android & html5 & java &...), but that project is geared for single screen drawing and event loop for game dynamics and doesn't allow for keyboard input and other typical mobile goodies.
It seems a shame that if so much of the problem has been solved, that it's not possible to go the extra mile. The answer to this question would be the best plan for actioning a solution, including such nigglies as which MVP structure to choose that would ease accommodation of the various widget libraries (GWTP vs MVP 2.1), and if the best approach is to start with the PlayN code base, and start to hack it.. what are the gotchas? Or if another path is chosen, why that one? and why would it be the best??
Thanx a lot. :-)
It is not clear whether your question is - evaluation options for multi-platform app development or mvp.
You can evaluate additional technology which are used with Sencha and GWT
1) mgwt
2) titanium
3) phonegap
You can also reference - Creating a mobile app using Google App Engine and GWT?
Note: PlayN as you mention is more of gaming platform and not suitable for business app.
MVP is definitely doable... and at times you may feel like its a lot of work, but it pays off in the end. Check out the Touch4j Kitchen Sink, which is written using MVP. You can take that down to the device with Cordova if you wish. The code is on GitHub:
https://github.com/emitrom/touch4jks
The repo is actively being worked on (we are updating ourselves to Touch4j 4.0) so it won't run out the gate, but at least you can see and follow the model :-)
Titanium4j is to Appcelerator's Titanium as Touch4j is to Sencha Touch. You may want to check that out as well. Titanium4j and Touch4j rely on GWT.
Cheers.
I've been looking over Sproutcore, Ember and Blossom and other competitive framework efforts (e.g. Sencha) to select for a HTML5 client side application project. The state, information, and documentation from these projects is a bit fragmented and in need of clarity, so I am presenting this to the community.
My project is to be a native-like HTML5 application with desktop level complexity in need of a complete application framework, that will work well on desktops and run with good speed on mobile devices with touch awareness. The widgets should be native-like (not web-like), but customizable so to be unique to the application.
Questions/framework Requirement:
Native vs. Web style Applications. Framework should make it easy to
build native-like user experiences with the ability to make a custom
native feel (not just wholly imitating mac/win/iOS). Some of the text
surrounding Ember indicates it is really meant for web-style apps - which given no
UI layer maybe goes without saying. Frameworks like Sencha, can it easily accommodate custom widgets?
Mobile Appropreatness. Framework should be appropreate for mobile devices and have facilities for touch input and
gestures.Several notes I've seen in my research indicate that Sproutcore and
Blossom aren't very appropreate for mobile, and that Ember is better
geared towards mobile (size?). It isn't clear whether the
touch/mobile libraries are very developed in Sproutcore/Blossom and if they will be supported it the
current state going forward. (and blossom compile to native is not acceptable). On the otherhand, Frameworks like Sencha, do they have the facility to work well on desktop as well as mobile?
Framework Completeness. The framework should be a fairly complete application framework, with desktop-like OO expectations and management for automatically and efficiently syncing, managing, and serializing the data model with the server. Not sure if there is much difference between Ember and Sproutcore, how do other efforts like Sencha stack up?
Your question covers a lot of ground. I will pick some quotes and answer them directly.
My project is to be a native-like HTML5 application with desktop level
complexity in need of a complete application framework
Ember.js specifically bills itself as a "web-style" framework, not a an RIA framework. That said, you can build anything you want, but you would be trailblazing.
Sproutcore bills itself as an RIA framework. You have complete control over the DOM, so if you can do it in the browser, you can do it in Sproutcore.
Ext-Js is also a good application framework for desktops (Sencha Touch is for Mobile). If you like the way its examples look, then its a good choice. You can of course customize the dom and write your own widgets.
Blossom is basically Sproutcore with a canvas based view layer. It just went into beta, so you would definitely be trailblazing if you went with it.
So, you can basically use any of the frameworks you mentioned for the RIA part of your enterprise. I would eliminate Ember.js simply because the framework itself purposes itself for web-style (e.g. twitter) as opposed to RIA (e.g. iCloud) apps, which is not what you want.
The widgets should be native-like (not web-like), but customizable so
to be unique to the application.
All three of your remaining options can do this. If you like Senchas widgets, its a good choice. I don't know if they are native enough for you. That said, with any of the remaining frameworks you can customize the DOM to your heart's content.
Mobile Appropreatness. Framework should be appropreate for mobile devices
This is a tough one. Sencha Touch (which is separate but similar to Ext-Js) is very popular and gets the job done. It is performant too; a non-trivial app ran fine on my original Droid (which surprised me).
Sproutcore is very heavy weight. It has mobile support (i.e. for touch events) but you need to very careful about the dom you create, so as not to overwhelm the browser. I wouldn't choose Sproutcore for mobile, although you could if you are very careful.
and blossom compile to native is not acceptable
That does not seem reasonable to me. To be clear, NONE of these frameworks run natively on mobile devices; they ALL run in the browser. Blossom comes closes as the canvas API is mapped directly to the native API, giving you a truly native app. The only way you could get closer would be to use objective-c/java for iOs and Android.
So basically, at this point your left with Sencha(Ext-Js) and Blossom. Blossom is still in Beta, you would be trailblazing if you tried it. Sencha is established, has great support (Blossom support is good on irc), and a large developer base.
So Sencha is the choice, unless you really want to be cutting edge, and take a little risk.
Troy. Indeed, ember can run with another view layer framework such as jQuery Mobile which can provide a "app-like" look and feel.There is a github project: https://github.com/LuisSala/emberjs-jqm. In my view, if you need very cool animation you can use blossom.If you want to build a app, SC or ember should be OK. I'll choose ember because it 's loosely coupled.
I am new to smartphone application Development, I have worked with .NET web and Windows Forms applications and only used the C# language.
I am planning to make a simple application which can run on all mobile OSes, like BlackBerry, Windows Mobile, Android phones, iPhone, etc. On searching I found that all have different OSes and uses different languages. I can use the C# language and .NET since I am aware about it. After some thinking, is it possible to make a web-based application using normal website coding but make it work like an application?
Please suggest some method to make a application which is possible to run on all smartphones. What technology or tools can be used for developing it?
The best approach to create truly cross platform app is to use HTML5 and JavaScript. All the other options will be painful. However, of course you can't access all the features with these web applications.
One interesting framework for creating HTML5/JavaScript based apps is PhoneGap (http://www.phonegap.com/). It has quite many API's available and wide support for different platforms. (Note that browser performance varies between devices so make sure not to add too much effects and glitter)
For native apps, there's no that many frameworks but one interesting is MoSync (http://www.mosync.com/)
There can be multiple approaches to create a Cross Smatphone plateform apllication.
If you want to code just once and want to to run on multiple enviroments without any change you must go for some javascript/HTML5 bassed solutions. One that I work with is NGCore. It is a development framework that allows games to be authored in JavaScript but with native application performance by leveraging ngmoco's ngCore libraries.
Other approach that will best suit your needs is to go for a Environment like MonoTouch. Its C# based and AFAIK you can use most of the .net API in MonoDevelope. It lets you reuse most of your code on another environment.