Well I've been coding in qt for about 6 months now and I have a pretty good grasp of QWidget and c++ coding for desktop apps but I run a small company and we are developing phone apps and desktop apps for a project that we are doing and as the project manager I fell that qt is the answer for not having to have separate teams coding for android and iPhone.
So the solution is coding in qt. but I'm a little confused about a few things. I see that a lot of the event handling of button clicks and things are handled actually in qt quick but as our apps would be quite complex in the bg we would have to be able to code in c++ the QWidget conventional way. So my question is:
Which is better QWidget or Qt quick better for developing our apps which should be compatible across most platforms, mostly tablet and smart phones.
If we go the qt Quick way then can you simultaneously use qt quick for most of the visual and then link up these files to c++ files (the engine of your app)? m if so any examples of how I might get started on learning how to do this.
Is there any really good resources on how to develop these phone apps, tutorials and things like that, as I'm a little worried about the lack of resources for learning.
Am I correct in thinking that if we did go with qt quick that these apps would also be compatible with Ubuntu phone?
I've developed applications for maemo and meego, and I'd say that QtQuick is better and much easier.
I'd say that QML and C++ qt-backend introduces an MVC pattern where QML is View and C++ is model and controller. QML is not just a script you can run. You need an object of QDeclarativeScript in C++ and pass main qml file to it to be able to start. So, anyway you will run C++ application first, which will parse QML script. To the last part of question: you may create C++ classes to export into QML and use it there. It is very simple, you may read official guides of QtQuick, it is goodly explained there.
Here is nothing special. Simply import files into qml-project and just use controls, containers and etc. Each project, be it ubuntu phone or sailfish, have a tutorials, guides and wiki. More, I'm KDE contributor and developed plasma widgets on QML - the same thing here, - all you need is to import and just use.
Of course. Why not? But you need to have a toolchain for QtCreator to be able to compile your project for target architecture and be able to run it there.
Related
As an experiment, I have a pure Qt C++ application (without QML) compiling (with cmake & ninja) and running on:
Windows
macOS
Linux (ubuntu and centos/redhat)
FreeBSD
It uses basically QMainWindow, QGraphicsItem and QDialog, iostream and a few C++ containers and iterators.
I am wondering if the port to Android is:
possible
easy or complex (if possible)
and if there are examples online
The same with iOS.
Yes, it is possible. I have worked in many Qt apps developed for iOS and Android. However, never used cmake, but qmake. it is good that you started experimenting using cmake which is the future as qmake is going to be deprecated sometime in the future. Qt's official documentation started adding cmake getting started tutorial.
https://doc.qt.io/qt-5/cmake-manual.html
I would like to suggest to use Qt Quick for GUI on mobile devices.
Technically, it's possible:
It's easy to compile C++-Qt applications for both Android and iOS.
For iOS, you'll still need a Mac with Xcode.
Deploying, debugging, and running the app is quite simple and seamless, too.
Practically, it's a horrible idea to try to port the GUI of a non-trivial desktop-application to mobile.
Graphical user interfaces designed to be used with a large screen, mouse and keyboard just don't work well on small touch screens.
Since you've mentioned QDialog: Some concepts work very differently on mobile compared to desktop.
E.g., Dialog is replaced by Activity and users usually don't deal with files.
You can (I've done it), however, design a Qt GUI-application without any QML, that works well on small touch screens and is at least usable on desktop.
It requires a lot of manual tweaking and hacking, but It's possible.
Notes:
qmake is easier than cmake for mobile apps (that should change in future)
although Qt has some abstractions, you'll probably need some platform-specific code (i.e., JNI, snippets of Java and Objective-C and many #ifdefs)
I am currently planning the development of a multiplatform app, and I am not sure wich way to do it fits my requirements best, since all possibilties I could think of failed to satisfy me.
First I want to write an app for android, which should feel like a normal typical android app. So I want to use the standard actionbar and android design look and feel in my other gui elements. After finishing the android app I am planning on developing an ios app, which should have a different design, so i am going to redevelop the gui for this anyway.
But I don´t want to rewrite the other code wich represents the intelligence of the app, independent from the gui. I came up with the following possibilities:
1. Java GUI With native library
Here I abstract all the code of my app in a C++ library (since as far as I know ios supports the usage of c++ libraries too) and develop the gui android typically in java. The library would than have a function to start and would inform the gui about every change via callback functions.
Pro
I can reuse all the code that would be the same on both platforms. I just would implement the gui seperately
The design of the android gui is straightforward as I want it to be. It looks like typical android because it is typical android.
Cons
I dislike the usage of JNI very much. Especially the signature and names of the callback functions (calling java functions from c++) are not checked at compile time and require a lot of manual work. If I rename a function and forget to rework the native part I only notice this mistake at runtime.
2. Build the GUI on the native side
Here I had difficulties finding out what is possible, especially for 2.2
2.1 Use Qt
I have only a few first step experiences with Qt in general but as far as I understood i would have the following pros and cons:
Pro
Reuse most parts of the code for ios and Android. I would than redesign the gui for each platform to make them feel natural. I can´t evaluate how much qt may even assists me at doing that
Cons
I have to copy the android gui by using other qt widgets. This is more effort and I don´t know if one can replicate the android gui elements (like the actionbar) so that the user wouldn´t notice it.
2.2 Using the android framework from the native side
I dont know if this is possible at all, I wasn´t able to find this information. Can I use the class "NativeActivity" and use the android framework to build the gui and use e.g. the actionbar? If this is possible somehow it would have the pros from 1. and maybe wouldn´t have it cons?
Do you have any feedback to my ideas or maybe even new approaches I didn´t think of? How do other multiplatform apps like WhatsApp solve this problem? Do they have redundant code for each platform?
Thank you,
Tobi
I would say that it depends very much on your application requirements. By my opinion, a better solution is to develop a separate application for each platform using recommended SDK's for that platform, and implement in native C++ only the time consuming data processing algorithms.
Application runtime on mobile platforms is not so straightforward as on desktop platforms. You should take into account background and foreground processing, specific application life cycling, accessing system resources such as network, file system, etc. And all these issues do differ on iOS and Android.
Regarding possibilities that you listed.
Qt/QML is ok only in case two requirements are met:
1.1 Your application is a foregroud application without any background operations.
1.2 You purchase a commercial Qt license because only commercial Qt can be submitted to Apple iTunes app store (even GPL apps are under
question).
Using NDK Native Activities on Android with cross-platform C/C++ backend. Android NDK API offers much less API then Android Java SDK, so a lot of things you will have to implement or wrap manually. It is a hard road.
Mixing Java code and C/C++ using JNI gives you more of Android SDK API. But you should remember that an Android activity's life cycle is not somewhat that you're used to deal with when developing on C/C++.
Approach that we are using
We've been developing an application with a huge amount of cross platform functionality that should work on Windows/Linux/Mac OSx/Android/iOS. We're using the approach as follows.
Cross-platform core is written in pure C++.
We have adaptors to GUI interface for each platform.
On desktop we use Qt as it reaches all desktop platforms with minor adapting to each platform.
On iOS the GUI is built using iOS SDK with Objective-C and C++ core is linked as a Framework. Still, we had to patch our core in some way for iOS background requirements and so.
On Android we wrap our C++ core in a background process and build all the GUI using only Android Java SDK. Foreground GUI activities interact with the core via local sockets, so we don't need to bother with activities life cycling in our C++ core. But the adaptor is a litle bit complicated.
Nevertheless, both mobile platforms often require workarounds and adaptations in C++ core which add a number of #ifdef'ed branches in code for each platform.
I want to develop application in android and iOS both.
But i am confuse between native development and development using react and node.js etc.
Please help me to choose (If possible specify reason).
P.S Here cost is not an issue.
If you need high performance and attractive UI and don't want to be blocked by some functionalities that may not br provided by cross platform, I recommend you to use native platform. But if your app doesn't need to be very attractive and doesn't need too much processing, then you can use cross-platform. Actually for many features you need to add plugins if you are building cross platform app and adding number of plugins makes your application slower.
OK, well there isn't much data to go on, but there are several options if you want to write cross platform apps.
There is:
Sencha Touch - HTML and JavaScript
PhoneGap - HTML, JavaScript and CSS
QT - C++ and QML
Appmethod - C++ and Object Pascal
Xamarin - C#
Visual Studio - looks like you can do C# or C++, or Unity for games.
and probably a lot more...
Why would you choose one of these instead of writing in the native language for the platform?
Well, the pros seem to outweigh the cons. If you are targeting several platforms, I would choose one of the options above, simply because you only have to write everything once. If you did it native for each platform, you would write everything twice or maybe three or even four times. Using one of the above tools will be much easier and save you time, and they might be just as seamless and workable as native development.
To simply answer your question, If you would like to be able to write your app once, and be able to manage all future updates by managing only one code base, do cross platform using one of the above tools. The only downside is that you might have to learn a new language (but with a place like Stack Overflow, learning new languages is pretty awesome). It will save you time in the long run.
I have game (of cards based on Contract Bridge) written in Qt (QML) for KDE, now I'm supposed to port the entire game to Android (with Android apapted UI of course). At first I considered to use Necessitas (a Qt port for Android) but found that it is still under development and is currently in 3rd Alpha. I'm new to Android development (as well as game development), while I have experience working in Java, C++ and web technologies like HTML5, JavaScript.
Hence based on my skills, I considered using MoSync. But I'm not sure if I'll be able to use any existing modules of game already developed in Qt (while in MoSync its possible to invoke C++ code from JavaScript and vice-versa), and since I didn't worked on the Qt version of the game, I'll first have to refer to that code and then I'll be working on Android version of the same. So I need suggestion that from where should I start. Also, I have 1.5 months of duration to complete the project (without any working hour constraints), so also suggest me if its a good idea to work from scratch using Android APIs.
Please let me know if I need to elaborate the question even further.
Thanks.
I recommend taking a look at V-Play (v-play.net). It's a cross platform game engine based on Qt/QML .
If your game is already written in QML, you have the least porting effort because you can use almost all of your existing code, and use V-Play QML game components for handling multiple display resolutions & aspect ratios, animations, particles, physics, multi-touch, gestures, path finding and more (API reference).
You can also take a look at Benefits to find out if V-Play satisfies your demands.
Qt is more cross-platform than ever now. instead of porting, just modify it a little and continue with Qt, then compile for iOS, Android, etc.
I know C# rather well and just love Visual Studio as IDE. :) Yet now I want to start developing for android...
I found out about MonoDroid and wanted to ask if it has any downsides to it that would make Java more preferable, or should I uninstall Eclipse and dive straight into MonoDroid?
If I understand right, MonoDroid deploys/compiles native android applications and does not need any additional .net-like framework or anything?
Are there any significant limitations to what I can do with MonoDroid? For example, having the app run in the background or using some external .net libraries for image editing, etc. ?
I've been worrying about the same thing - productivity in C# instead of playing with an unfamiliar language, vs developing how the OS developers intended it to be.
Its easy to list pros vs cons -
pros (of monodroid, for C# developers)
familiar dev environment, can develop using Visual Studio
C# instead of Java
Reusable code assets - you can use a lot of code in your iphone project or Windows phone 7 project using monotouch and the WP7 SDK.
cons -
debugging could be difficult, due to lack of api documentation from Google. Will have to depend solely on monodroid documentation.
there could be a lag when it comes to latest cutting edge features - safe to assume that the monodroid team will require some time to wrap around the latest android features every time there is a new OS release
availability of libraries - I am not sure how you can use the open source libraries that would have evolved around the android platform, that could cut down on development time
Much of the documentation available is in Java: so if you run into difficulties with phone behavior when using MonoDroid you won't really find that much help or debugging information so you may want to stick with Eclipse.
There's a lot more than just a set of wrappers running under davlick, truth to be told, there is much more of a horizontal relationship between MonoDroid and Android;
When did using the same language as the OS developers become a big issue? There's lots of C++ programmers wondering how to use BSD or SVR5 and many C programmers who want to know what the heck to do on Windows++...
If you will write in c# anyway you will be have to wrap it into a Java code, so what's the point ? Also you may head with a very difficult issues while trying to understand the APIs who written for Java programming...
Here are some points that you can mull over:
Android applications are predominately written with Java. The Android SDK itself is natively written in Java.
Working in Mono may not provide all the functionality available in the Java SDK.
If you are a C# Developer you wont be able to find, in Java, some of the (cool) features available in C# (like Property Delegates etc).
Code written in .NET can be re-used for other environments - this may save a lot time that would have been spent learning a new language/environment (like Objective C), and coding in it.
.NET extends the Android development stack with it's existing libraries and API's.
I think both are good for certain reason. It will be very hard to say which one is preferable for Android development - in the end that is up to you too decide.
Also note that any release build using monodroid adds an additional 4mb to the apk filesize and increases app startup time with a few seconds.
For simple apps this can mean a 500-800% increase in filesize - whic is pretty bad in my book.