RetroShare Client for Android

Android specific usage questions

Re: RetroShare Client for Android

Postby heini » Sat Apr 05, 2014 6:55 am

electron wrote:I just uploaded my android branch to github:
https://github.com/electron128/retrosha ... .5-android


Great!!!

Bye...

Dirk
heini
 
Posts: 59
Joined: Sun Feb 02, 2014 8:37 am

Re: RetroShare Client for Android

Postby handsomefella » Mon Apr 07, 2014 7:34 pm

no disprect intentended by the following statement: I don't think that would be "better".

I got much bigger plans
handsomefella
 
Posts: 8
Joined: Wed Apr 02, 2014 8:41 pm

Re: RetroShare Client for Android

Postby electron » Wed Apr 09, 2014 2:31 pm

handsomefella wrote:I don't think that would be "better".

Would you mind to share the reasons your opinion?

From the users point of view, using Qt does not make any difference. But from the developers point of view, there are many advantages.

I want to use Qt, because
- other platforms can profit from the work. Qt runs on many desktop and mobile operating systems.
- less code is needed and less is time spend, because more code can be shared between platforms. This includes logic code, common widgets and translation files. Whats more, we need less JNI glue code. The JNI glue code is really something i want to avoid as much as possible. Qt has helpers to interface with Java.
- more developers are willing to help. I'm in contact with others interested in a QML/QtQuick UI. Even the main Retroshare developers can fix bugs.
- we can concentrate on libretroshare improvements. We need three things: a good backend, a nice UI and integration into the Android system. The UI is the only place where we could save time by using Qt. Backend work and Android integration has to be done no matter what we use for the UI.

Qt does not force us to use C++ only. It is possible and desired to use Java for some parts. Qt is just a tool which can save us some work.

I first ported retroshare-nogui to Android and added a basic Java UI. Then Qt 5.2 came out and i tested Qt on Android. Later i made the qt project files for Android. So i saw enough to decide that i like Qt more than a Java only based UI.

handsomefella wrote:I got much bigger plans

I'm happy to hear this. Even with big plans, you are allowed to use tools to make life easier. It is up to you if you want to use Qt.
I hope i can convince you to use the Qt project files. Else let me know, so i can help you with the Android makefile.
electron
 
Posts: 96
Joined: Sun Aug 12, 2012 9:39 am

Re: RetroShare Client for Android

Postby heini » Wed Apr 09, 2014 4:19 pm

I'd be willing to do some alpha/beta testing once you have the chat part working.

Bye...

Dirk
heini
 
Posts: 59
Joined: Sun Feb 02, 2014 8:37 am

Re: RetroShare Client for Android

Postby handsomefella » Thu Apr 10, 2014 5:25 pm

electron wrote:
handsomefella wrote:I don't think that would be "better".

Would you mind to share the reasons your opinion?

From the users point of view, using Qt does not make any difference. But from the developers point of view, there are many advantages.


For *some* developers. I know c++ fairy well but it is far far slower to develop in c++ than Java (have u ever used Eclipse? phenomenal)


I want to use Qt, because
- other platforms can profit from the work. Qt runs on many desktop and mobile operating systems.

As does Java.

- less code is needed and less is time spend, because more code can be shared between platforms. This includes logic code, common widgets and translation files. Whats more, we need less JNI glue code. The JNI glue code is really something i want to avoid as much as possible. Qt has helpers to interface with Java.

That's ok. SWIG is also excellent for generating glue code, don't sweat it.

- more developers are willing to help. I'm in contact with others interested in a QML/QtQuick UI. Even the main Retroshare developers can fix bugs.

That's fine but its still c++ and needs to be switched away from... imho c/c++ nowadays is only for performan critical stuff which the GUI is not, as compared to libretroshare... and even though, I am considering a full Java implementation of libretroshare at some point because god knows how many buffer/stack smashing explots lay in waiting (just see that heartbleed crap floating around on the intertubez.... its a dumb name btw, i renamed Heartbleed to Buttnugget, less dramatic than these attention gluttons)

- we can concentrate on libretroshare improvements. We need three things: a good backend, a nice UI and integration into the Android system. The UI is the only place where we could save time by using Qt. Backend work and Android integration has to be done no matter what we use for the UI.
- yes, im thinking stuff like share links, files, integrate into "activities" whatever the heck that is

Qt does not force us to use C++ only. It is possible and desired to use Java for some parts. Qt is just a tool which can save us some work.

I first ported retroshare-nogui to Android and added a basic Java UI. Then Qt 5.2 came out and i tested Qt on Android. Later i made the qt project files for Android. So i saw enough to decide that i like Qt more than a Java only based UI.

Eh, faster get away from c++ the better

handsomefella wrote:I got much bigger plans

I'm happy to hear this. Even with big plans, you are allowed to use tools to make life easier. It is up to you if you want to use Qt.
I hope i can convince you to use the Qt project files. Else let me know, so i can help you with the Android makefile.[/quote]

I really loathe the qt build system, so I want to make it androidified.... just need to setup a repo or something and i dont like messing with all that stuff... so ill just put the code up a residential apache server
handsomefella
 
Posts: 8
Joined: Wed Apr 02, 2014 8:41 pm

Re: RetroShare Client for Android

Postby handsomefella » Thu Apr 10, 2014 8:48 pm

my main holdup right now is Avahi. How did you get it working?
handsomefella
 
Posts: 8
Joined: Wed Apr 02, 2014 8:41 pm

Re: RetroShare Client for Android

Postby electron » Fri Apr 11, 2014 9:15 am

Thank you for the explanation, now i understand better why you want what want.

C++ is not my favourite language, but with Retroshare i have to take what is there. I don't think writing a Java UI is faster than writing a Qt one. And QtCreator is also a nice IDE. Someone else already started with creating a SWIG wrapper[1]. I'm really surprised that you don't like the Qt build system. I'm very happy to have one project file for Windows, Linux and Android.

Now the hints for Android.mk:
- trunk is very different from the stable v0.5.5 branch. Trunk is now v0.6 which cannot talk to v0.5 nodes. v0.6 has many bugs. I'm not sure what is better: start with v0.5 or v0.6.
- all the gxs files are for v0.6 and are not needed in v0.5.5
- there are some platform specific files, like p3zeroconf.cc which is only used on mac. You can see this in libretroshare.pro.
- i used the makefiles generated by Qt to get a list of sourcefiles
- my v0.5.5-android branch contains changes to make libretroshare compile on android
- see the attachment for my makefiles and more notes

[1] https://github.com/TheRealSAC/libretroshare-java
Attachments
libretroshare-android-makefiles.zip
(8.16 KiB) Downloaded 326 times
electron
 
Posts: 96
Joined: Sun Aug 12, 2012 9:39 am

Re: RetroShare Client for Android

Postby Svampen » Fri Apr 11, 2014 12:25 pm

With QML/QtQuick you can have contributors to the GUI who don't know jack about C++.
Svampen
 
Posts: 71
Joined: Tue Jan 20, 2009 2:35 pm

Re: RetroShare Client for Android

Postby handsomefella » Tue Apr 15, 2014 7:08 pm

electron wrote:Thank you for the explanation, now i understand better why you want what want.

C++ is not my favourite language, but with Retroshare i have to take what is there. I don't think writing a Java UI is faster than writing a Qt one. And QtCreator is also a nice IDE. Someone else already started with creating a SWIG wrapper[1]. I'm really surprised that you don't like the Qt build system. I'm very happy to have one project file for Windows, Linux and Android.

Now the hints for Android.mk:
- trunk is very different from the stable v0.5.5 branch. Trunk is now v0.6 which cannot talk to v0.5 nodes. v0.6 has many bugs. I'm not sure what is better: start with v0.5 or v0.6.
- all the gxs files are for v0.6 and are not needed in v0.5.5
- there are some platform specific files, like p3zeroconf.cc which is only used on mac. You can see this in libretroshare.pro.
- i used the makefiles generated by Qt to get a list of sourcefiles
- my v0.5.5-android branch contains changes to make libretroshare compile on android
- see the attachment for my makefiles and more notes

[1] https://github.com/TheRealSAC/libretroshare-java


Yeah... that was "my" project... I've since abandoned it..no desire to use github, its easier to just work on it locally and not involve all this web shenanigans. u know, like the real slim shady, please stand up!
handsomefella
 
Posts: 8
Joined: Wed Apr 02, 2014 8:41 pm

Re: RetroShare Client for Android

Postby handsomefella » Tue Apr 15, 2014 7:10 pm

I will check out your patches... does it address the Avahi issue?
handsomefella
 
Posts: 8
Joined: Wed Apr 02, 2014 8:41 pm

PreviousNext

Return to RetroShare for Android

Who is online

Users browsing this forum: No registered users and 1 guest

cron