Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Coffee corner » Qt and Android...
Re: Qt and Android... [message #27983 is a reply to message #27981] Thu, 12 August 2010 18:38 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

My vote for Android too.
iPhone could be the second choice.
Others is much less important for U++ future.
Re: Qt and Android... [message #27991 is a reply to message #26378] Fri, 13 August 2010 08:57 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
OK. So it is agreed Smile We are going Android.

Personally, I like the challenge - I think my solution to "NDK problem" should work.

Perhaps somebody could test it? (I mean, the possibility of calling Java code from NDK C++).
Re: Qt and Android... [message #28031 is a reply to message #27991] Fri, 13 August 2010 12:11 Go to previous messageGo to next message
masu is currently offline  masu
Messages: 378
Registered: February 2006
Senior Member
Hi,

I have a Motorola Milestone with Android 2.1update1 installed, so I am able to test a few things ...

Matthias
Re: Qt and Android... [message #28033 is a reply to message #27991] Fri, 13 August 2010 12:41 Go to previous messageGo to next message
jeremy_c is currently offline  jeremy_c
Messages: 175
Registered: August 2007
Location: Ohio, USA
Experienced Member
This is great news and yes, Android is the best choice.

Jeremy
Re: Qt and Android... [message #28036 is a reply to message #28033] Fri, 13 August 2010 14:57 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
Some thoughts

- As now Android has increasing momentum
- And there are old established applications for PDA very difficult to port to Android
- Perhaps now there is a gap for new applications made in, lets say, U++, to have a relevance in mobile devices
- If we port U++ to Android not very late


Best regards
Iñaki
Re: Qt and Android... [message #28038 is a reply to message #26378] Fri, 13 August 2010 15:00 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
Hmm.. android is now hot stuff... and not only in good way. Smile
Oracle sues Google for patent infringement
Re: Qt and Android... [message #28052 is a reply to message #28038] Fri, 13 August 2010 19:50 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
mr_ped wrote on Fri, 13 August 2010 15:00

Hmm.. android is now hot stuff... and not only in good way. Smile
Oracle sues Google for patent infringement


Yes. I have the same opinion in other way. Without Java Android would be better Very Happy

Quote:

Oracle said in a statement that Google's Android system for mobile phones infringes on its patented Java technology.


Every successful device or project has to pass a lawsuit... I think Google will solve this.


Best regards
Iñaki
Re: Qt and Android... [message #28072 is a reply to message #28052] Sat, 14 August 2010 16:37 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
Excellent Miguel de Icaza post here

He ends it with:
Quote:

Google could settle current damages with Oracle, and switch to the better designed, more pleasant to use, and more open .NET platform.


Miguel has been leader of Gnome project and Mono (C# open implementation).
I was disappointed when he began C#-Mono in Novell instead of doing a good C++ platform based on Gtk+ experience.

C++ imitators like Java or C# are filled with patent traps. Working close to Oracle (Java), C# (Microsoft) or Qt (Nokia) is not safe terrain.

Sorry Miguel, I would change your words to say:
Quote:

Google could settle current damages with Oracle, and switch to the better designed, more pleasant to use, patent free and more open U++ platform.


Smile


Best regards
Iñaki
Re: Qt and Android... [message #28075 is a reply to message #28072] Sat, 14 August 2010 17:51 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

U++ is still a framework. It will be a platform after porting Framebuffer and Webkit. Still U++ has very strong requirements for developer level.
Re: Qt and Android... [message #28079 is a reply to message #28075] Sat, 14 August 2010 21:16 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
And this is the list of OS identified in SourceForge:

Windows, Mac OS X, Linux, BSD, Solaris, and Android


Best regards
Iñaki
Re: Qt and Android... [message #28139 is a reply to message #28079] Wed, 18 August 2010 16:27 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
i am starting with setting up development environment eclipse for android. hello world is running in simulater already. have regostered in adroid market as to be able to get a dev phone (nexus is out of stock though, till mid september).

now about NDK:
Quote:


Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.



so the solution will be as Mirek showed, to setup a starter app for ultimate++ applications, which passes its 'surface' and 'input messages queue' to underlying ultimate code, using ndk maybe.

the picture still needs to be sharpened. i dont know how it could be possible to have access to all the java classes there are, i.e. for accessing gps and the like..will we have to produce wrapper classes for each and every thing we need 'down there in upp'?
Re: Qt and Android... [message #28143 is a reply to message #28139] Wed, 18 August 2010 17:22 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
Good for your effort!

Yes Kohait:

Quote:

the picture still needs to be sharpened.


There are ports to Android of Curl, SDL, Ffmpeg. We have to learn.

For example to read gps data could something like doing a

cat /dev/ttySO


( http://stackoverflow.com/questions/2844384/how-to-define-gps -module-in-android)


Best regards
Iñaki
Re: Qt and Android... [message #28147 is a reply to message #28143] Wed, 18 August 2010 22:07 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
definitely..

here is a opensource vnc client for android, maybe we can grab some ideas from it, how to get and process events from user and how to draw things on android surface.

http://code.google.com/p/android-vnc-viewer/
Re: Qt and Android... [message #28154 is a reply to message #28147] Thu, 19 August 2010 09:18 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
btw: how to deal with multitouch?
android (or actually the hardware mostly) supports multitouch, but U++ is plain old point and click.. would such a behaviour be serialized to multiple invokations? maybe android supports to report only first occurance (filtering only one)
Re: Qt and Android... [message #28156 is a reply to message #28154] Thu, 19 August 2010 09:40 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
kohait00 wrote on Thu, 19 August 2010 09:18

btw: how to deal with multitouch?
android (or actually the hardware mostly) supports multitouch, but U++ is plain old point and click.. would such a behaviour be serialized to multiple invokations? maybe android supports to report only first occurance (filtering only one)

Hello Kohait

For sure U++ interface will change slightly after porting to Android.

After analising Android SDK and NDK you can propose new methods for U++ main classes like Ctrl that match with multitouch or other features specific to new mobile devices.

It would be great to see soon in U++ code things like:

#ifdef ANDROID



Best regards
Iñaki
Re: Qt and Android... [message #28157 is a reply to message #28156] Thu, 19 August 2010 11:52 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
another thing i stumbled over is an NDK shipped example
which upp could use to draw to..
Quote:


bitmap-plasma — a simple application that demonstrates how to access the pixel buffers of Android Bitmap objects from native code, and uses this to generate an old-school "plasma" effect.



alltogether, it seems that mirek is right again, need to first provide a 'generic' portable interface for CtrlCore, which than can be enhanced to be a /dev/fb0 port or to be a android port.

in android case, there is surely a message notification mechanism, that intercepts key strokes etc..mouse clikcs..this 'simply' need to be translated to upp and forwarded 'down' to upp. the invokation every 10ms of the main thread procedure is to be ensured somehow though. no idea about that so far.
Re: Qt and Android... [message #28158 is a reply to message #28157] Thu, 19 August 2010 14:40 Go to previous messageGo to next message
kohait00 is currently offline  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 Smile
Re: Qt and Android... [message #28160 is a reply to message #28158] Thu, 19 August 2010 16:00 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
Hello Kohait

Perhaps the simplest focus to Android would be to begin with Core, leaving GUI issues a little bit later.

It would be encouraging to have a console "hello world" application compiled with TheIDE with some NTL code inside.


Best regards
Iñaki
Re: Qt and Android... [message #28163 is a reply to message #28160] Thu, 19 August 2010 17:25 Go to previous messageGo to next message
kohait00 is currently offline  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...Smile

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 Smile

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

Re: Qt and Android... [message #28164 is a reply to message #28163] Thu, 19 August 2010 19:21 Go to previous messageGo to previous message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
Hello Kohait

You are doing it very well.

However it is possible to do console programs Smile.

This is an step by step sample to do a printf("Hello world"); program, including makefile and debugging.

http://betelco.blogspot.com/2010/01/buildingdebugging-androi d-native-c.html


Best regards
Iñaki
Previous Topic: Number of U++ Developers/Users?
Next Topic: About freelance..
Goto Forum:
  


Current Time: Thu Mar 28 22:54:35 CET 2024

Total time taken to generate the page: 0.01393 seconds