We create non-game programs that run on mobile devices; iPhones, Windows Mobile, Android, Palm WebOS and the like. Our main program is written in C# for Windows Mobile and we've been asked to port it to iPhone. We are not looking forward to:
The learning curve to pick up
Objective-C, XCode, and Cocoa Touch.
The pain of maintaining two
sets of code to keep the product in
sync on two different platforms.
We've decided that as a strategy we want to create all new products on as many mobile platforms as possible simultaneously, a formidable task.
We know we'll have to bend on these, but we'd prefer to:
Avoid forcing our users to be
connected to the web to use a product.
Not have a bunch of different sets
of source code.
Support as many mobile platforms as
we can.
My question is this; What is your suggestion for the best strategy to develop for the 2 - 5 most popular mobile platforms?
EDIT: Based on the comments, I wanted to clarify that we have a product that we well-received on both PalmOS and Winmobile. It works exactly the same on both platforms, making it easy for a user to switch handhelds and still use it.
Now we're on the verge of creating many new business apps and want to expand that to other hardware/OSes. What are your suggestions to deploy on many new platforms with the minimum of pain?
Consider implementing your applications via the web. This violates your preference for "avoiding your users to be connected to the web", but consider the web for the following reasons:
If your C# applications were written the right way, you could expose a web front-end to these applications by reusing your existing libraries.
Web 2.0 is supported by nearly all modern mobile platforms.
Your developers could continue writing in the language they're used to (C#).
There are many advantages to writing web apps vs platform-specific apps.
Consider Appcelerator Titanium, Rhomobile's Rhodes, PhoneGap, xmlvm.org, or other cross-device toolkits.
I make the assumptions that you have already done your market research and actually knows that all platform will be profitable, and not just drain your resources developing for one or two.
There is no great answer unless you break the "no connect to internet" rule. But there is a good answer; plain old C.
Implement all application logic in plain old C. Then;
iPhone - Objective-C is a strict superset of C, so just use the code as is. And write a UI in Objective-C using Cocoa Touch.
Android - Android's Java have JNI for calling native code written in C. Write a thin glue layer, and implement your UI with normal Java for Android.
Windows Mobile - You can call native code from any .NET application. So write another thing glue layer, and implement your UI using C# or your prefered .NET language.
Symbian - Symbian uses a variant of C++, so just like on iPhone you can call your C code as is. Write your UI using C++ and Symbian API:s.
If you break the "no connect to internet" rule then implementing the server with your existing C# code and exposing it as a web service using HessianC# is a snap. And then Hessian implementations are available for every phone that you can install an application on, that has been sold since 2002 or so.
I suggest you to separate the core of your application and the GUI. So you can continue to develop your applications in C# for Windows mobile and iPhoneOS (thanks to monoTouch). With this strategy you have only to develop the specific GUI on Windows mobile (C#) and iPhone (Cocoa Touch).
For other mobile os you can not use a cross platform dev env (for now). You need to redevelop all you application.
So:
Windows Mobile: Core(C#) & GUI(C#)
iPhone: Core(C#) & GUI(Cocoa Touch)
Android: Core(Java) & GUI(Java)
Other: depends on OS
Virtualization
Depending on your hurry I heard that VMWare is working on a mobile virtualization product that would make it possible to unify platforms into a single execution point within VM on a mobile device. It will almost certainly support majority of smartphone platforms (Windows Mobile, Android, Symbian, Blackberry and maybe even iPhone). They (and we) would definitelly benefit the most when they'd support all of them.
If you're not in a hurry, maybe wait a bit.
With a c# application for the Iphone check out Monotouch. Its the OSS version of the .net framework for the iphone.
I'll go against the grain and give you some tough love instead of simply answering the question you asked.
My thought is, why would you want to make 2-5 versions of your application that will receive, at best, a lukewarm reception across all platforms? Because that is what you are going to get.
If you want to make applications that are well received and make users excited to use them, make them take advantage of the platform. iPhone apps should have well thought out user input and take advantage of as many platform features as possible, like mutl-touch, easy data storage, accelerometers, camera and so on.
Palm apps work great in the background so write something that takes full advantage of that. it might even be more than one app to keep to Palm's simple and small approach to apps.
Android apps can integrate much more tightly with the system, so let them do just that to the benefit of the user.
Your main benefit with any app should be that you understand the domain completely, and can describe what aspects of the problem domain work best with the strengths of any given device. Mobile apps are small(ish) and any small gain you get from trying to share code across devices (and how does that work exactly across Java/Obj-C much less Android to Blackberry library differences?) is totally lost in the distortion of your understanding through the prism of accommodation.
Try using PhoneGap! All you need to know is web technologies.
A bit late to your question. But you can use Rhodes (http://rhomobile.com/products/rhodes) to write for every major smartphone OS. Tens of thousands of other developers do. Rhodes was the first smartphone app framework and the only one to provide the benefits of Model View Controller enjoyed by web developers to native smartphone development.
Related
This question is specifically related to a recommended architecture and people's previous experiences for cross-platform WP7, iOS, Android apps developed using C#, Monotouch and Monodroid respectively. I have researched previous questions here, here and here. They provide good answers but not quite what I'm looking for. I have also found this excellent question which does go into the cost benefit so there is some overlap.
I have a requirement to develop a cross-platform iPhone/iPad, WP7 and android app for a health & fitness company, which will integrate with their website. The app requires a small amount of local data storage for offline mode and synchronisation with the website when a network is available. I am a Windows (C#/C++) developer through and through and don't really want to go down the route of three Objective C, Java and C# apps, although I will if I have to. I will also be operating as tech lead and farming out some work to a team on this project.
I would like to know if anyone here has experience with cross-platform development using Monotouch, Monodroid and WP7 and to share their experience on application architecture to re-use as much code as possible. The architecture I am considering is as follows:
My question is as follows:
Has anyone here tried something like this?
Are these frameworks (Monotouch, monodroid) worth their salt for this sort of work?
Can I setup the entire project in Visual Studio 2010 with separate projects (dlls/exe) for the Monotouch, Monodroid and Wp7 target (but shared code using 'Add as Link')?
What sort of code-reuse can I realistically expect with this (or a similar) architecture? i.e. what strategies/patterns can I use to re-use local data access, webservices, and business logic?
You might want to look into the MonoCross project which is designed to help you reuse C# code with multiple presentation layers:
http://code.google.com/p/monocross/
The authors of MonoCross (ITR Mobility) have created multiple mobile cross platform solutions for a variety of customers and have written two books on the subject one is "iPad in the Enterprise" (http://amzn.to/zAhQK6) and the upcoming "Cross-Platform Mobile Development with C#" (http://amzn.to/wM6RsF).
In the meantime, you can watch Scott Olson's presentation that he did at Monospace 2011 that describes how to use MonoCross to target multiple mobile and desktop platforms at once reusing the business logic:
http://www.infoq.com/presentations/The-Rise-of-Mono-in-the-Enterprise
They enforce a strict MVC split in their code:
(source: tirania.org)
The biggest benefit of designing an application with this model is that you can run the same application with native user interfaces on each platform. You get native iOS, Android, Windows UI and they even have an ASP.NET front-end that allows you to publish Web versions of the same business logic.
This technology was used successfully by the Medtronic sample app that is showcased by Apple in their iPad business:
http://www.apple.com/ipad/business/profiles/medtronic/
I suggest you also check out Scott's blog where he posts regularly about his experiences with cross-platform architecture.
Based on your comments your requirements are for a cross-mobile platform that will integrate with their existing services, but also work offline. You are specifically interested in C# via Mono, however you have indicated that you are not discounting other approaches.
I feel that HTML / PhoneGap / JavaScript is a route that you should explore in some detail. The WP7 version of this framework has just been released, and I have had experience of releasing an application to the marketplace using this approach.
PhoneGap wraps your HTML / JavaScript code, in the case of WP7 this is loaded into local storage. This enables the application to work entirely offline. This is true for all versions (iOS, Android etc...)
Probably the biggest issue with PhoneGap / HTML5 is the same issue we have when developing complex web based applications for the browser. The tooling for JavaScript is not great and browser differences are a constant issue. However, it is a tried and tested solution.
Finally, it is possible to create an application UI that is entirely different for each platform. By using the MVVM pattern I have managed to share all my JavaScript business logic between WP7 and iOS applications whilst having a totally different UI:
Compare this to the WP7 screens:
NOTE: I plan to have the iOS version of Property Finder in the AppStore shortly, I just need to work out how to use PhoneGap Build!
Just adding another alternative to the mix - mvvmcross
This project was developed out of experiences with monocross, mvvmlight, and opennetcf.
It's quite an opinionated mvvm framework (with my opinions in it!), it includes data-binding support for Droid and Touch, and it really does encourage code reuse between the platforms.
The source is available from https://github.com/slodge/MvvmCross, it's been used in at least a couple of large projects already and it's still under active development.
There's an introductory presentation on it on slideshare: http://www.slideshare.net/cirrious/dev-evening-monotouch-monodroid-mvvm-mvvmcross-and-databinding
One of the more fully featured samples is a conference app:
The question is very hard to answer, yet I would like to share some thoughts.
The situation with the mobile development is very similar to the development at the first half of the 90s. Phone have limited resources as computers had, mobile OSes are making their baby steps, hence the ecosystem is relatively small. They have own philosophy, tools and even languages. And this is a good thing, but leads to a headache for cross-platform development. As a result, there are many attempts to clear this a bit. People build frameworks, wrappers etc. which is a kind of abstraction and abstractions are leaky. This is extremely important for mobile devices not only the performance as numbers of CPU cycles, but also the performance of the battery, which is far more important for the user.
If I were you I would build apps in a native environment especially if you have some performance considerations. Best support, tools, educational resources etc. pays for the duplicated business logic. All in all, it's not a OS or Database Management System, codebase won't be huge ;)
That being said. Regarding Monotouch and Monodroid I would be very careful since Apple blocks iPhone OS apps created by many third-party compilers and The King doesn't really care about developers. The case that mono will be flushed to the toiled by patent infringement or proprietary software vendors is very likely. This is sad for me cause C# is my favorite language.
PS. I don't believe that HTML5 for mobile will take over any time soon.
I am quite aware of both java and C# .Net .when i try to create a new windows application which are the factors that decide which technology should be opted?
I know of one thing ,for great and faster UI development Visual studio helps a lot.
There are several factors I would consider...
What are your programmers used to working with already? What third party libraries are you likely to need, what's available on both platforms?
Does platform independence matter to you?
Would LinQ be advantageous?
If you're starting from scratch, costs for the platforms?
Both platforms have strong communities around them...
Hope this helps...
Dotnet is pretty much native in Windows which obviously makes it more suited to writing Windows programs. Using Java in a Windows-only environment makes it much harder for you since it effectively just adds another unnecessary API layer.
You will soon realise that all integration points between your Java code and Windows are a bit problematic. For instance, creating installation programs, access file system, reading/writing the registry, starting/stopping services, task bar icons, using Windows GUI components (media player, IE...), help file system...
It all boils down to this imo: The Dotnet framework is much richer in terms of functionality than the Java dito, mainly becuase Java is cross-platform and thus needs a "one-size-fit-all" approach to its API. My experience is that you will only get frustrated trying to "emulate" a Windows native program in Java.
Choose the one with which you are most familiar. The two platforms are different enough that skills from one does not transfer easily to the other.
In any case, try making a trivial application in both your scenarios and see how it works for you. The initial impression is important as it is probably indicative of how well the rest of the work will be.
It also depends on what kind of windows application you want to build. If it's just a question of building a simple standalone application then, considering you know both languages equally well, I wouldn't hesitate and would go for a 100% microsoft solution, especially if you have to do specific things like accessing ActiveDirectory, the windows registry, etc.
Not that you can't do it in Java : you can always use AD through LDAP in Java for example, but the APIs are just "a bit" more complicated than the .Net ones (try to decode objectSIDs in Java without a few tricks).
Now if you have to build an enterprise app. I just feel that popular frameworks like Spring and Hibernate are always coming out after their Java counterparts (disclaimer : this is a personal opinion; I didn't do any research on this, thoroughly comparing frameworks in both languages, but that's just the feeling I have). I don't know how good the .Net implementations are though, so I don't have a point of view on that. I just remember writing .Net 2.0 apps and not liking ADO.Net at all.
My view is that the frameworks I like do exist in both languages, but they are first developed for Java, then ported to .Net.
Now I'm not the kind of developer trying to defend his favourite language over the others. If I don't have external constraints to develop, then I choose whatever language gets my app up and running faster and in the most efficient way.
...But with java you will have crossplatform application on scratch.
Also coding UI in java is not difficult - if you read some guides before and use some frameworks as swing application framework or SWT framework.
If its Exclusively for Windows then .Net is best bet.
Yeah for a pure cross platform application Java can't be beat, but if you can manage it Silverlight is a subset of WPF and a pretty compelling cross-platform proposition on its own.
Productivity-wise I think WPF has an edge as it has a nice XAML markup language that can be easily created with the built-in designer in VS.NET or integrates nicely with MS' suite of expression products.
I need to write a web app (that also works offline) for windows and mac (and linux as well perhaps).
I was wondering if I should use something like air/flash/java for this, the advantage being I will only need to write the app once.
However, I was wondering if there are any disadvantages of doing it that way as opposed to writing it in c# for windows specifically and then objective-C/cocoa/whatever for mac. Will the functionality of the app be limited if i do it in Air/Java? Are there any advantages to writing it in the language specific to the platform?
If possible it would be nice to know what the advantages/disadvantages of both methods are as it would help me (and hopefully others) come to a decision on the best way to create such an app according to ones needs.
Any help would be much appreciated! Thanks.
The first thing to realise is that writing cross platform applications that look and behave native on each target platform is a hard thing to do.
Using a cross platform kit (AIR/java):
Less work, in theory should be quicker to build
Common language and toolkit, only one thing to learn
Adding a new supported platform should be easy(ish), build installer, debug provide any native platform integration etc
There is a tendency towards only implementing the lowest common denominator feature. An example of this would be the java File api. It only supports the basic concepts of files where as Windows, OSX and linux all have addition
May still require platform specific integration code (maybe native) in order to get an acceptable level of integration.
Using the native toolkits:
A lot to learn, moving between Windows MFC (or .Net winforms) and Cococa is going to be quite jaring
Not only will you have different languages, you will also have different tooling
There is no limit or false ceiling to what can be achieved using the native toolkit gives you access to everything
Making your app look like it belongs on the platform (important for Macs) is pretty much out of the box
Personal recommendation: go with the language tool kit you know the best, depending on how thick your app is (you mentioned it's part online) you may be able to rewrite it in another language latter once you have a successful application.
Much depends on the kind of app you will be writing. I use Adobe AIR for a lot of in-house tools.
If you write for AIR what you'll get is something that looks like a web page. That's fine, because people feel at home operating a browser interface--maybe even more at home than with a native app.
But, yes, you'll absolutely have limitations.
So what's your app?
I work on an experienced and diverse development team and we are preparing to approach our first mobile development which will be for Windows Mobile 6 (platform changes are not an option).
We have skills and experience in both Visual C++ and .Net technologies for Windows desktop and server development.
The mobile development will include some image processing, and read/write access to a bluetooth device. Unfortunately I can't really give any more details than that.
We are trying to choose between writing the mobile client using managed code or native code. We would use C# or C++ respectively.
My questions are:
How big is the expected performance differential between these languages? I have heard that native code is significantly faster on mobile devices, but I would love to hear from someone with experience.
Are there any major advantages to either language in terms of working with the Windows Mobile services for accessing bluetooth devices?
Is there an impact on battery life between managed or native code?
Are there any other major should-knows for us to consider?
I appreciate your feedback.
Another consideration is the issue of memory usage and module size. We have run into significant problems in mobile development simply trying to get the OS to load all our DLLs into memory. Unlike regular windows development, there is a very strict limit of 32Mb into which all modules must be loaded. We've had to perform a lot of very dirty tricks to get all our stuff loaded successfully. We have found that even if a user turns on the cell phone or uses a bluetooth device, the drivers for those devices would cause our application to fail because they would use up the space for our modules.
With all that in mind, we have been unable to add in support for .Net into our application, because of the extra module weight that this would have introduced into our application. You may need to take this into allowance, if your application has a lot of dependancies.
A very similar question was asked and answered just a few days ago. You can find useful information there.
Short answers to your questions:
Native code is faster, but for many applications the speed difference won't be noticeable. Don't use native code just for the speed, unless this is a key factor for your application. Managed applications can also run fast - it may take them longer to launch.
There is a good Bluetooth library for .NET applications. I am not aware of a similar library for C++ applications.
It is up to your design to achieve good battery life. Choice of platform doesn't matter.
In addition to the great - and long - answer in the other question mentioned by kgiannakakis I have to add a few thoughts and points.
At my workplace we've been writing applications for Windows CE 5.0 using C++ and ATL/WTL. This ends up being nice to work with and very light compared to both MFC and .Net.
The other point to take into consideration (as explained by a senior developer here) is that the .Net compact framework needs to recompile the byte code into machine code each time the application is switched to. This could potentially take a long amount of time and processor power so be careful.
I have written a server/client application using sockets in C# for .NET 3.5. I'm interested in porting the client part to some kind of mobile device and am pondering the best way. The client is actually an underlying library and a GUI depending heavily on touch interface capabilities.
As I see it I have a few options:
Just get an EEE PC and run it on, that's kind of portable but I loose the touch part
Rebuild the library for mobile platforms and make a new, reduced, GUI app
Start a web server and make some kind of web interface to run on iPhones and what not
What would be the best route? What problems can I run into in my alternatives above? I'd really prefer alternative 1 or 2 over 3 because of how the server is currently done and the fact that I know nothing about webservers or ASP.NET. Oh and I'd like to stay with the environment I'm alredy in, that is .NET, so no Ruby on Rails suggestions please. (Not saying Ruby is bad or anything, I just don't know it and don't have the time to learn).
I'd go for option 2 then. It wont take you too long (hopefully) to port the libraries over to the Compact Framework, and providing it's just sockets, etc, you're dealing with then I'm sure the CF will handle it fine.
EDIT: The only problems you'll have with option 2 is if you use any .Net functions that are not in the CF. If that is the case, you'll usually be able to find it within OpenNETCF.
You will need to create a new GUI, but providing you've coded your libraries well, it should just be a case of assigning methods/events where applicable on your device.
I'd say though that option 3 is the best option - it expands your customer base dramatically, especially with the growing number of WM and iPhone users.
I would opt for Option 2.
Most of the members of the TcpClient Class class in System.Net.Sockets namespace are implemented in the .Net Compact Framework.
I would be interested to understand what your requirements are in selecting a mobile device. There are a lot of differences between a Windows Mobile Smartphone and EEE PC.
Niklas,
Before you decide on the technology stack to use on the client for mobile you need to work out what mobile devices they are going to have available this tends to decide the technology for you.
iPhone - Objective C
Blackberry - Java
Nokia - C/Java
Windows - .NET CF
Otherwise would it be possible to turn the client into a mobile web site, that then communicates server to server via your TCP Socket stuff ? That way you do not need to worry about the technology on the mobile.