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.
Related
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 would like to know what do you think in which is the best technology to do an content display interface (ads, weather, news) for screens.
What I've found is that QT, Silverlight and java FX could be an option. Is there a better one? I prefer open-source. (LGPL is fine too)
You didn't mention it, but you might also want to consider web technologies (HTML5, Javascript). They are widely supported (by multiple vendors) and well standardized, so it should be a safe bet. It's also quite easy to hire competent people.
Flash is slowly dying so I wouldn't bet on it. Silverlight is basically only backed by Microsoft and its adoption doesn't seem great, so it looks like something Microsoft could decide to kill overnight. Its multi-platform support is also sub-par.
Qt is nice but I'm not sure if it's the best tool for what you want to do. I don't know JavaFX, so I won't comment.
What you want is a widely used technology and a pretty cool graphics.
Silverlight and Flash are on the edge of each other, since if you depend on (even successful) other technologies they may not be popular enough, i.e. the users want everything easily and believe me for an end-user it is a tough task to install Adobe Flash Player or Silverlight run-time, here comes the popularity benefit, by using something that is dominant.
I would like to develop on a mobile device, probably with Windows Mobile platform, which device would you guys recommend for me to use? But one requirement on the device is that I need that device to be able to capture signature (human writing on the device).
Many Thanks
Sounds like any PocketPC (or "Professional") device would do. Personally I currently have an HTC Touch Pro, which would be suitable for what you describe. For testing purposes, it might also be a good idea to also test on a device with smaller resolutions (I have an HTC Elfin for example that would do well here, but it shows its age..). Or on the emulator provided with the SDKs.
However some of the newer ones have capacitive touch screens and no stylus. (For example HTC HD2.) So while HD2 is otherwise an excellent phone, capturing a human writing on it probably wouldn't work as well as older devices with resistive screens and a stylus.
Any Windows Mobile 6.0/6.1 based phone with resistive touch screen. A good example is HTC Touch Pro2.
Also, some S60 5th edition phones, such as N97, may be a good choice.
It depends on the languages you intend to use to write the application.
If it's Java, I'd go with an android system.
If you're a c# coder I'd say any windows device would be ok.. You could likely get one on EBay for dirt cheep and for the most part you can be sure your code will run on most of them (I know this is a generality), especially if you keep the code simple.
If you're a c++ developer then the same as above, any pocket PC/winmobile will do.
If you own a mac, and you've written apps in objective c then IPhone is a good choice.
In part you have to base decisions like this on what you know going in.
If you're a blank slate.... well then you've got to figure out what direction you want to take your knowledge. I've personally picked Java and Android because I've recently been convinced it's the road to the future.
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.