We're working on the next version of a tracking system. The previous incarnation used an LCD with a simple custom UI however as we've had usability problems and we've found development time-consuming, and as our display is going out of production, we're considering using a regular cellphone or PDA as the interface instead.
Our main worry is whether we can keep such a product on the market for five to ten years without having to continually keep porting and adapting the application to new devices. To make things somewhat easier we intend to bundle the phones with the system, though in an ideal world our (largely non-technical) users would be able to use their own.
So, what's our best bet? Are there a good platform-independent libraries we can count on being supported for a while? Or are we better of betting on a single platform at a time? Perhaps backward-compatibility is more likely to be maintained on a PDA? Truth be told I'm not even sure what language to bet on for the generic parts of the code.
I'm also a little anxious about the link to our hardware. Bluetooth SPP is attractive since it's particularly easy to use and there are plenty of ready-made modules available, but support on the phone side is far from universal.
Any pragmatic advice would be most welcome as I must admit to having no experience with mobile application development.
If you don't control the entire production chain for hardware like Apple does for example, you have no chance on long term. Unless your product is really innovative and market wants it so much, or if you are playing on a market niche (healthcare for instance). My proposal would be to make a market study and check what your customer use as mobile devices first. You should choose one or two top platforms first, and gradually add new platforms if market asks. If you are in US probably iPhone, Android, RIM would be the top choices, in Europe I would have to choose between iPhone, Android, Symbian, Windows. It's the same like developing a website you start with two top browsers and gradually add support for minor ones.
About portable libraries I wouldn't bet on this. Instead I would design an architecture using abstraction layers. For example I would have Bluetooth abstraction layer that would expose functionalities to my Business Logic Layer; underneath I would have BlueZ if I deploy on Android/Linux, maybe GameKit for iPhone, MS stack or Widcomm for Windows and so on.
PDAs are dead, actually they've merged into smartphones and tablets, they were an evolutionary step. So forget them.
HTML5 is a good idea but is only the front layer, you must deal also business logic and lower layers.
Bluetooth SPP is good because it is common, and interoperable it's like the webservices for enterprise. Instead of giving an API that is platform dependent you could provide a set of custom AT commands, that can be used by anyone that can connect on Bluetooth to SPP.
Cross platform sounds like HTML 5, CSS and Javascript, along with some javascript frameworks for mobile development like the ones listed here
Related
I am trying to evaluate whether Xamarin would be a good option for my project. The project is a large, complex app for Android and iOS with a lot of client-server communication. The user interface is a major focus and has to be really fast and smooth. Also, we plan to make large use of UX graphic effects (comparable to the Spotify app).
For now we are planning to go for two separate native apps using Java/Objective-C. However, the possibility of cross-platform code sharing would be very convenient for us of course.
Most opinions I've heard so far say that Xamarin - although far better than HTML5 apps - cannot match the UX of a native app. Also, I tested the following applications made with Xamarin (on Android):
Rdio
MarketWatch
Busch Gardens Discovery Guide
Sqor
Storyo
From my impression, none of them could quite match the speed and smoothness of a good native app.
If our focus is on a top notch user experience, would Xamarin really be a viable option? Can it really match a native UX? I am particularly looking for opinions from developers who have experience with large and complex cross-platform Xamarin applications. A few critical voices would be very helpful.
Thank you a lot!
I'm on the Rdio mobile development team, so I can make some personal reflections from that standpoint.
Xamarin allows you to write native applications in C#. Any slowness, jankiness, ugliness or bad-appiness usually has nothing to do with the Xamarin layer itself.
You save some time being able to share core business logic between your different clients, but you're still writing the UI from scratch, specific to the platform. You're just writing it in C#.
But while you save that time, you're spending it in other ways. All of those SDKs you want to use probably aren't compatible with Xamarin out of the box. You won't be pod install'ing that iOS framework, and you might be reinventing the wheel for handfuls of things. Xamarin takes advantage of the NuGet repo so you have a library of components that handle many of the things most people need (Analytics, Testing, Facebook SDK, JSON parsing, Database, etc etc) but it doesn't cover everything. And it certainly doesn't cover stuff that's out the day of an Apple or Google product announcement.
Any 3rd party code that you do want to import into your project will be done through writing custom bindings. While not usually difficult, it is time consuming. Xamarin has a team of people that specialize in assisting you in this. This fact speaks to the process being messy at times.
So while the slowness, jankiness, ugliness or bad-appiness probably isn't the fault of Xamarin, it might be the fault of you spending time in places you normally wouldn't, or not being able to take advantage of features you normally would. If that 3rd party partner SDK is giving you problems, your troubleshooting may take twice as long because there's a layer that you don't control.
UI is a wash. You're writing it from scratch anyway.
Business logic is shared. Depending on the app that might be a win if you architect your application to take advantage of it.
Compatibility / bleeding edge ability will be lacking. That might not matter to you at all, or you might be the person wanting to take advantage of that hot new API in the next OS release the day it's announced.
My personal thought, without knowing specifics, is if you want to build an application that you plan on being around years from now, and that will take advantage of the latest and greatest, I'd tell you to write natively for each platform. Unless you can really see huge gains in sharing that business logic the upfront gains are minimal. Or if you really like C#.
Xamarin uses native controls. So you design a fully native UI per platform. The users can't see that your App is made with Xamarin or Java/Objective-C.
There are sometimes performance issues in conjunction with the platform independent UI wrapper Xamarin.Forms. But you're not forced to use it. When you have still performance issues in your Xamarin.Android or Xamarin.iOS app then you produce them in your code.
There are benchmark results for Android apps comparing Xamarin.Android and Java apps: Does anyone have benchmarks (code & results) comparing performance of Android apps written in Xamarin C# and Java?
As you can see Xamarin's internal performance became better and better over the time.
Conclusion: Yes, you can write smooth native Apps using Xamarin.
I have to develop an application for Windows Mobile 6.x and version 7 and my skillset is .net and web based. Since version 7 is not backwards compatible I am thinking that I will end up with a lot of duplicate work.
I had a look at Rhomobile and Phonegap but the later does not support windows mobile 6.x and the former would require ruby knowledge.
I thought that I could have as much logic in class libraries as possible and then "include as link" the classes into projects so that they can be compiled for the specific platform. I feel like I may end up with a lot of #if PHONE7 style logic in that case and also the user interface code would have to be implemented for each platform.
What is the most efficient way to solve this problem?
If you can separate the UI from the logic you can begin to multi-target. The other consideration is the runtime of the phone (Silverlight 4?) and the phone sandboxing giving you limitations.
MVVM Light is multi-targeted and is open source, you could use this to review how they tackled it:
http://mvvmlight.codeplex.com/SourceControl/changeset/view/d546dc69fffd
In short though, your "add as link" idea is pretty much the basis of it.
The other question to ask is will the application fit on both platforms? The usage style from mobile to metro is a big change. People expect things to behave a certain way and look a certain way on metro. If you can confine this to the UI and move as much logic out as possible, then you should be ok. But there will come a point where it isn't worth sharing, it is simply easier to duplicate.
Sorry for a lack of detail in this answer, to be honest it is heavily app specific. I would personally start with separate applications and refactor as commonalities appear, using a combination of linked code files and hash defines.
A cute trick... you can always make the classes partial and have a partial code file for each hash define:
MyBusinessClass.CF.cs
MyBusinessClass.Silverlight.cs
I'm looking to get a windows phone to use as a development platform. What should I consider when comparing models? I'm not interested in opinions about individual phones, but about what features I should make sure exist.
I would recommend one with gyroscope and front facing camera, to be able to test the features of the last WP7 handsets. But overall, it's pretty good to develop on the slowest phone you can find. This way, you make sure that your app will provide good user experience on pretty much all available devices.
Is it true that web browsers as we know today have no future? That programmers should write native clients for their application on many devices?
I'm writing web application with AJAX but should I also prepare versions to many mobile devices?
The web will be around and web browsers are available on almost any device. Some say native development is the future, because it is closer to the device and gets the most out of the system. This is true and is applied in various cases, like XBOX games and Apple software that is especially designed for a single device.
Other developments show the other side. Google's OS is barely more than a webbrowser. All applications running on it are merely web applications that should run on any browser. Only difference is that the engine of Chrome OS is put directly onto the hardware, allowing the webpage to get a better performance, because it has only one abstraction layer to the hardware instead of 3 or 4.
So, the only advice I can give is not to worry about it. People on either side have been declaring the other technique to be dead since decades ago, but both are still here. When it is time to switch, you will know. :)
The first statement is definitely not true.
The second one depends on your case, but most things you can just do "mobile-browser friendly". I.e. make a mobile version of the website that looks good on mobile browsers. No need for mobile applications.
Of course, if you have the resources, a mobile app is a good addition to your portfolio / brand.
First of all no one knows and no one can know what the future will bring.
For me though, it is difficult to imagine a world without web browsers at least in the near/mid term future, especially with all the hype/support behind HTML 5.
The big advantage is of HTML 5 in this regard is write once, run everywhere.
My 2 cents ;-)
If anything, it is the other way around. Make a good web application, and everyone can use it. Mobile browsers get better and better all the time. Expect mobile website usage to increase, rather than custom applications for each device. (obviously, applications that need hardware access are not included in this statement.)
Furthermore, expect a convergence between mobile web and desktop web.
What Windows Phone 7 demo/reference applications have you seen which really made you interested in developing for the platform?
I know of Scott Gu's Twitter example and Foursquare. Also see here for MIX10 demo apps.
Other than developing games and re-creating functionality already present on other mobile platforms (iPhone, BlackBerry, Android), is there any good reference material and business benefits of developing for Windows Phone 7? Does the Silverlight dev environment really offer an advantage over what is already out there? My gut feeling is that this is definitely the case, but it will take some time for the platform to establish itself, if it does.
You can find a lot of examples and reference applications here www.reddit.com/r/wp7dev/ or search using the hashtag #wp7dev on twitter (full disclosure - some of my examples appear there).
There a examples of what people are openly working on, but one can assume it is a lot more - hopefully this is useful, as it shows what can be done, or is being done on the platform.
As a novice developer, other phone platforms came with a lot of overhead required to build even the simplest application. The fact that XNA will be available for game development is a huge thing for me, it means I can create simple games for me and my friends without having to spend time learning a new language or setting up awkward SDK's and deployment settings.
More advanced developers may scoff at that, but development tools that are already being used that can work right out of the box for the intended platform is important for the hobbyists. I think this will open up a huge arena for homemade games and apps just like XNA did for 360 development.
It should also help sales. I will buy a Windows 7 phone because of this, and I can imagine others will do the same. As it stands, I am going to port my existing XNA games over so I can play them on the go. It will be cool to show people at the office, airport, etc. projects I have made right on the spot, and even give them the option to play if they have the right hardware.