|
|
| Re: Qt and Android... [message #26379 is a reply to message #26378] |
Wed, 28 April 2010 19:52   |
|
|
Interesting. If U++ gets supported on Android, I might start thinking about buying a new phone 
BTW: The videos looked like there is some kind of emulator - that should make the porting much easier...
Honza
|
|
|
|
|
|
|
|
|
|
| Re: Qt and Android... [message #26815 is a reply to message #26472] |
Mon, 31 May 2010 03:13 |
nixnixnix
Messages: 415
Registered: February 2007
Location: Kelowna, British Columbia
|
Senior Member |
|
|
If U++ can access the GPS through a virtual com port as well that would be fantastic! Has there been any progress on this? Is there likely to be a release of U++ for Android?
I've wanted to port my app to Android for a while but I wouldn't really know where to start. Java is not worth looking at for what I do as it is way too slow for a GIS style app.
Nick
[Updated on: Mon, 31 May 2010 03:14] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Qt and Android... [message #27840 is a reply to message #27823] |
Fri, 06 August 2010 10:25 |
 |
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| luzr wrote on Thu, 05 August 2010 06:45 |
| kohait00 wrote on Wed, 04 August 2010 02:53 |
thats true,
nevertheless, i i'am lucky, i might finish porting U++ to framebuffer till the end of the month.. this should also work for android then, which uses framebuffer as underlyinig layer. but this would be a intermediate solution only. since android brings in own window manager which we should be using to make upp applications run just as the normal ones.
|
BTW, possible interesting approach might be the "reversed library" (just made up the term).
Android certainly supports C libraries in Java. So make the U++ app as library and give it some Java encapsulation outer shell
|
Did some browsing:
http://java.sun.com/docs/books/jni/html/fldmeth.html#11202
Looks like calling java back from native code should be possible.
Given this fact, I wonder why is there so much fuss about Android not supporting native development. IMO, solution is simple - create Java interface class to Java SDK and pass a pointer to its instance to C++ code doing the actual stuff..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Qt and Android... [message #28158 is a reply to message #28157] |
Thu, 19 August 2010 14:40 |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
i've successfully built the 'android-vnc-viewer' app from source, it runs on my emulated android. pretty impressive. now i'm trying to finish setup of my android sandbox making the NDK examples work. this is a bit hairy as it seems. as soon as this is running, i will provide a short descritioin on how to setup an android built environment, the information is available, but as always, the difficulties show up trying..especially NDK, which needs a cygwin for compiling the native source code into a library, which then will be linked when building the .apk android application itself.
another problem show up concerning the popup windows etc..they are TopWindow derived isn't it? so far, android app is an Activity which is merly a logic surface to place controls to and that can react on user interaction overriding several base class functions. so it's pretty much a Ctrl. but here, we wont be able to invoke popup windows that easy.. i think we will need the android means, if it has stuff like 'popup a surface and draw things on it while the rest is visible, blocking other stuff'.
what about the android look and feel? i am not that fit in creating the apropriate Ctrl.iml for android
|
|
|
|
|
|
| Re: Qt and Android... [message #28163 is a reply to message #28160] |
Thu, 19 August 2010 17:25 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
this should be possible somehow, though printf redirection is not that easy espacially to graphics...
an interesting topic is by the way the 'ContentProvider', means to storing and retrieving data from within application, basicly data, that should survive onPause() time, when a user quits your application to switch somewhere else (as far as i understand)
i think it is closely related to their account management
| Quote: |
Content Providers
Content providers store and retrieve data and make it accessible to all applications. They're the only way to share data across applications; there's no common storage area that all Android packages can access.
Content providers are one of the primary building blocks of Android applications, providing content to applications. They encapsulate data and provide it to applications through the single ContentResolver interface. A content provider is only required if you need to share data between multiple applications. For example, the contacts data is used by multiple applications and must be stored in a content provider. If you don't need to share data amongst multiple applications you can use a database directly via SQLiteDatabase.
|
nice idea anyway, maybe upp could provide such an interface as well, this might reduce the need of Serialize persistance, but using SQL instead
[Updated on: Thu, 19 August 2010 17:34] Report message to a moderator |
|
|
|
|
|
U++ framework
Search
Help
Members
Register
Login
Home
.
. They think Maemo will leave Gtk+. No Android and mobile 7 move.
