Google Android client

[GoogleCodeExporter]

What feature or enhancement would you like to see in Remuco?

It would be really nice to have also the Google Android client.

Please describe a use case that motivates this feature:

Google Android is going to be installed on significant number of mobile
phones in near future, so it would be really good idea to create a client
for it.

Original issue reported on code.google.com by jiri....@gmail.com on 22 Sep 2009 at 10:25

[GoogleCodeExporter]

Totally agree! Any Android developer out there who would like to contribute 
here?

Original comment by obensonne@googlemail.com on 23 Sep 2009 at 8:28

• Changed state: Accepted
• Added labels: Component-Client

[GoogleCodeExporter]

Fixing issue #35 could fix this one too. But still a native client for Android 
phones
might be a better solution.

Original comment by obensonne@googlemail.com on 23 Sep 2009 at 8:50

• Added labels: Device-Android

[GoogleCodeExporter]

Currently the client code is quite JavaME focussed. Before starting to work on 
this
issue the client code should get split in general client code and a JaveME 
specific part.

Original comment by obensonne@googlemail.com on 29 Sep 2009 at 9:41

[GoogleCodeExporter]

Original comment by obensonne@googlemail.com on 29 Sep 2009 at 9:42

• Added labels: NeedsContribution

[GoogleCodeExporter]

I would like to contribute with this issue when you will split the code.

Original comment by ivashyst on 12 Oct 2009 at 6:18

[GoogleCodeExporter]

Great! Now I have a good to motivation to actually do the splitting :)
I'll post news on this here. Hope to have it done next week.

Original comment by obensonne@googlemail.com on 12 Oct 2009 at 6:45

[GoogleCodeExporter]

This issue was updated by revision a765c69169.

This commit adds an inital Android client project. It has been created
using the following command:

$ android create project --target 1 --name Remuco --path . \
      --activity Remuco --package remuco.client.android

The `local.properties` file has been added to `.hgignore`, but an
example file `local.properties.example` is available in the repository.

Except the `local.properties` changes no other changes have been made to
the project after calling the `android` tool.

Original comment by obensonne@googlemail.com on 14 Nov 2009 at 1:52

[GoogleCodeExporter]

This issue was updated by revision 231498d99d.

There is an intial Android client which already communicates with a
player adapter if the client runs inside an emulator. This initial
client version is a kind of starting point for the Android client which
shows how things principally work in the context of Remuco.

This is my first Android code and it is not meant to be productive. It
is only intended to demonstrate the connection setup to and interaction
with a remote player (adapter).

Original comment by obensonne@googlemail.com on 14 Nov 2009 at 1:52

[GoogleCodeExporter]

@ivashyst:
Feel free to start to experiment!
Take the initial Android project as a starting point and just let me know in 
case you
need some information. In general it is also worth reading the Java doc in the
client/common sources - I tried to document the most important components.

Original comment by obensonne@googlemail.com on 14 Nov 2009 at 1:58

[GoogleCodeExporter]

Ok, great! I'll start as soon as possible.

Original comment by ivashyst on 14 Nov 2009 at 2:21

[GoogleCodeExporter]

@ivashyst:
Any news on this? Do you need some assistance to get started? I'd be happy to 
help out :)

Original comment by obensonne@googlemail.com on 11 Dec 2009 at 10:25

[GoogleCodeExporter]

@obensonne
Don't have enough free time now - my job takes all the time right now. I looked
through the code you provided as initial version - looks understandable.
I'm planning to get time to start the actual coding closer to the end of the 
month.
Definitely I'll have some question, but I'll email it to you :)

Original comment by ivashyst on 11 Dec 2009 at 11:20

[GoogleCodeExporter]

Fine. Didn't want to hurry you. Just wanted to know if you still have it in 
mind.

Original comment by obensonne@googlemail.com on 11 Dec 2009 at 11:31

[GoogleCodeExporter]

You should post here instead of mailing Oben.
I may have some fellow coders which could be of assistance.

Original comment by igor.con...@gmail.com on 13 Dec 2009 at 1:02

[GoogleCodeExporter]

Good point!

Original comment by obensonne@googlemail.com on 13 Dec 2009 at 5:03

[GoogleCodeExporter]

Any progress on this one?

Original comment by fha...@gmail.com on 31 Jan 2010 at 9:12

[GoogleCodeExporter]

AFAIK ivashyst started to work on this but I don't know about the progress
(@ivashyst: still working on this? no problem if not, but it would be good to 
know).

Personally I have only time to work on the Remuco core and the JavaME client.

Contributions welcome!

Original comment by obensonne@googlemail.com on 3 Feb 2010 at 11:51

[GoogleCodeExporter]

I'm working on it from time to time, when it's possible. I have a lack of free 
time
currently, but as soon as I will get a day off, I will have something to commit.

Original comment by ivashyst on 3 Feb 2010 at 6:13

[GoogleCodeExporter]

hi there ... i honestly haven't looked here after my last request so i started 
my own
little Android client yesterday.

Based on the code in the repository i got basic playback control and information
retrieval in place.

It works pretty well up to the point where the MainLoop class interacts with 
Androids
Lifecycle structure but i guess i'll have that one worked out in some more days.

What's missing in my eyes is volume control and playlist browsing (but i'm using
banshee so that'll run on low priority).

so far
Florian

Original comment by fha...@gmail.com on 12 Feb 2010 at 3:39

Attachments:

• remuco2.png

[GoogleCodeExporter]

Another shot of the application, this time in landscape mode ... switching 
between
landscape and portrait mode gives me some headaches as the application is more 
or
less killed in the progress. Currently i'm working around this by reconnecting 
to the
server everytime but it takes a moment to get the picture back.

Also: could someone tell me how to use the ctrlSeek(int dir) method?

Original comment by fha...@gmail.com on 12 Feb 2010 at 3:55

Attachments:

• remuco3.png

[GoogleCodeExporter]

Awesome, looks pretty cool!

Next to volume control I'd love to have rating support (Banshee 1.5.3 finally 
supports rating via DBus, so this 
feature will be in the Banshee adapter soon).

ctrl_seek():
This should be called repetitively, approx. 3 times a second, as long the user 
holds the seek respectively 
next/previous keys (or in your screenshot, push'n'holding the progress bar - 
does it work like this?). Currently 
seeking only is relative because this works with all player adapters, in 
contrast to absolute seeking.

MainLoop:
The main loop works good for the JavaME client so it would be great if we could 
use it similarly on the 
Android client. However, in case the main loop concept crucially conflicts with 
the Android's life cycle 
management, we'll have to see if there is another solution.

Any code there to check out?

Man, that's really great :)

Original comment by obensonne@googlemail.com on 12 Feb 2010 at 6:14

• Changed state: Started

[GoogleCodeExporter]

Rating Support: i'm not quite sure how to handle that one on the design side 
... in
landscape mode there is enough space under the meta informations ... in 
portrait mode
there isn't ... but i'll include that one, it's not that much work

Seeking: that's a shame ... maybe i'll have a look into the workings of the 
progress
bar and'll work something out

MainLoop: i actually realized the lifecycle problems just recently ... i guess 
i'll
be able to work them out eventually. If i understand the whole thing correctly 
the
MainLoop should be used to send Commands in a threadsafe matter right?

Code: currently the application is crashing sometimes when changing the 
orientation
... i'd bet on threading related problems ... if i work that one out i'll share 
the
code (under the premise that i may put it in the Market)

Florian

Original comment by fha...@gmail.com on 12 Feb 2010 at 7:50

[GoogleCodeExporter]

Of course it's up to Oben, but I don't think that anyone except of him have any
rights to put it into Android Market. He did the whole the thing working. 
Android
client implementation is more trivial thing in comparison to what Oben did.

Original comment by ivashyst on 12 Feb 2010 at 8:15

[GoogleCodeExporter]

sure ... i'd respect that

Original comment by fha...@gmail.com on 12 Feb 2010 at 8:17

[GoogleCodeExporter]

Hi again ... i stumbled about a problem here:

i tried to shutdown the connection by calling the close()-method on a reference 
like
this:

TimerTask tt = new TimerTask() {
  @Override
  public void run() {
  connection.close();
  }
};

MainLoop.schedule(tt);

i also tried it the 'direct' way but there is no reaction

... (5 minutes later) ...

ok i found the problem ... the line 176 in remuco.client.common.io.Connection 
should
read:
connectionListenerNotifiedAboutError = false;
(instead of true)

Original comment by fha...@gmail.com on 12 Feb 2010 at 9:27

[GoogleCodeExporter]

RatingSupport:
Yes, this is a design decision. On the JME client, I have reserved space for a 
top
button bar and on touch screens also a bottom button bar. The space between is 
used
for track meta data and rating stars. Any space left is used for the cover, 
i.e. it
gets scaled to whatever space is still available. So here the cover has lowest
priority. Covers look nice and are great for screenshots :) but IMHO in daily 
use
track meta information (incl. rating) is much more valuable than the cover.

Seeking:
Well, it's KISS: no problems with false track length information and minimal
requirements on player APIs. By the way, a progress bar like seeking never 
seemed
useful on the rather small screens of JaveME devices.

MainLoop:
It's partly used for thread-critical operations and partly it is used to 
decouple
certain actions from UI events to keep the UI responsive. And it's used for
repetitive actions like seeking. As you probably recognized it's just a wrapper
around a Java Timer class. I think the JavaDoc of the MainLoop class help here 
too.

Connection shutdown:
In the JME client I don't use the mainloop to close a connection as here things
usually should happen synchronously for a clean shutdown.
The line 176 should read 'connectionListenerNotifiedAboutError = true'. This 
means
that IO errors during connection shutdown (which usually happen in the 
Connection
receiver thread which hangs an a read()) should not be reported to the user as 
those
are no real errors. What reaction do you finally expect when calling close()? 
What
exactly does not work?

Code and Market:
In theory nobody can prevent you from distributing the client in the Android 
market
as long as you go with the GPL. Which of course includes the sharing of your 
code :) 
In practice I'd expect to integrate the Android client into the Remuco project 
in
order to allow others to review and contribute and in order to align the 
development
and releases with the other Remuco components. Integration is as easy as 
forking at
BitBucket or GitHub (see Wiki page Contribute). That way we can ensure the 
Android
client in the download section and in the Market are the same and components 
work
together as expected. In other words, I've no problem if you release the client 
in
the market, I'd even vote for it, but the Market releases should be aligned with
regular Remuco releases (we can do them more often if needed). Don't be afraid 
to
share "unfinished" code! Getting reviews and testers early usually is fun and 
helpful
:) ivashyst may have some valuable feedback or contributions.

Cheers,
Oben

Original comment by obensonne@googlemail.com on 12 Feb 2010 at 11:09

[GoogleCodeExporter]

Layout: early on i was trying to imitate the remuco layouts ... but then i went 
with
something that looked more like the native player. Last night i had the idea of
layering the rating buttons over the cover ... i'll try that as soon as i get 
there.

Seeking: on most android devices there is pretty much available space ... but i 
guess
i'll include a 'hold the next song button pressed'-style seeking

Mainloop: decoupling the GUI is handled by Handlers on Android so i wouldn't 
need the
Mainloop there ... do the Connection and Player classes rely on the Message 
handling?
Else i wouldn't have to use it at all.

Connection shutdown: I actually expected that the notifyDisconnected method 
would be
called. But if this is by design i can work around it. Currently i'm stopping 
the
connection everytime the application looses focus (which happens when the user
presses the home button or starts another application).

Code: is now online at https://code.google.com/r/fhaust-androidremuco/ yay! :)
The whole thing is compilable via ant and should play nice with every device 
running
Android 1.5 and above. Feedback is of course welcome.
(i noted, that my 'initial commit' messages weren't that great ... any way to 
change
those afterwards?)

Market: i hope you haven't got the wrong idea there ... i didn't to keep the 
code or
make money from that one ... the plan was always to release the code as part of 
the
remuco project. On the other hand i'd be happy to have an application in the 
market
and would be able to support it (at least in the next 1-2 years).

Florian

Original comment by fha...@gmail.com on 13 Feb 2010 at 10:08

[GoogleCodeExporter]

The layout finally is your choice, simply do it the best way ;) 

On big screens with a progress bar absolute seeking would be nice. This 
requires an extension to the player 
adapter API and checks in the client if the currently used player (adapter) 
supports absolute seeking. But I 
think this not that high priority now.

In principle you don't have to use the main loop. But be aware that it's used 
by some classes in the common 
package - so at least you must enable and disable it at application startup and 
shutdown.

The notifyDisconnected is only used for disconnection not issues by the users, 
i.e. when errors occur. In case 
a user disconnects explicitly, there is no need to notify this again.

Thanks for sharing the code. To provide better commit messages (e.g. I would 
recommend to prefix the 
summary line with "Android: ..." and to use a user name like "John Doe 
<john.doe@somewhere.org>") you 
could simply create a diff of what you have changed since forking and recommit 
this on the tip revision of the 
fork, i.e. before you made any changes - this will create a new head - the one 
I'd preferably use for merging.

Concerning the market issue I was simply not sure about your intentions but now 
I think we have the same 
ideas here. Having the Android client in the regular Remuco source tree is just 
great and if you put it into the 
market once we have something working is good (as I don't have an Android 
device except the simulator, you 
are probably the best candidate for the market release anyway).

I don't have time to have a look into the code or do some tests right now. I'll 
do that at the end of the next 
week.

Oben

Original comment by obensonne@googlemail.com on 13 Feb 2010 at 6:02

[GoogleCodeExporter]

small update after this weekend:

I implemented volume and rating controls and worked out the crashing (at least I
think so). 

Volume is controlled by the hardware buttons which works well and is (in my 
eyes)
pretty intuitive. Maybe I will throw in a gui based method to do the same but 
for the
moment it's fine that way.

Rating is more an esthetically question (actually most of the stuff is more 
about the
layout as the backend library works great ;) ), but I think even that one looks 
good now.

Truth be told: this is my first 'real' Android application and I am now hitting 
some
design boundaries so I guess i will have refactor the code next. Currently it's 
a
pain to get data from and to custom dialogs ...

Florian

Original comment by fha...@gmail.com on 14 Feb 2010 at 9:25

[GoogleCodeExporter]

hi again

@Oben: i think i have recreated the head. Could you please confirm that i did 
that
one correctly?

Original comment by fha...@gmail.com on 15 Feb 2010 at 3:48

[GoogleCodeExporter]

Looks good, except that there is a directory '.fr-4yJDys' which looks like it
shouldn't be there, Or is this by intention?

To be pedantic: I would put the 'recommit to ...' line in the commit message 
into the
commit summary, like 'Android: recommit to ...' (this is not critical, just for
style, so don't take it too seriously :) ).

Original comment by obensonne@googlemail.com on 15 Feb 2010 at 6:39

[GoogleCodeExporter]

This issue was updated by revision eec275d9a1.

Banshee adpater now supports rating control (needs Banshe >= 1.5.3)

Original comment by obensonne@googlemail.com on 15 Feb 2010 at 11:02

[GoogleCodeExporter]

Strange Folder: no ... the folder is just wrong ... i have no idea were that 
one came
from ...

Commit Messages: i am using the hgEclipse Plugin and as it seems it doesn't 
support
commit summaries ... sorry about that

Attached: another screenshots (notice the little stars? ;) )

Original comment by fha...@gmail.com on 16 Feb 2010 at 11:10

Attachments:

• remuco5.png

[GoogleCodeExporter]

By commit summary I simple mean the first line of the commit message. Following 
is a
sketch of a good (but nonsense) commit message.

<<< snip
Android: add feature X

Feature X allows foo to bar. It uses boo to retrieve the far.
...
>>> snip

The idea is to start the summary with the Remuco component and a short 
description
what has been changed. Then comes a blank line followed by some optional 
detailed
description. Most graphical changelog interfaces recognize such commit message
structures, which improves readability.

Screenshot:
For sure I noticed these starts :) great!

Original comment by obensonne@googlemail.com on 16 Feb 2010 at 12:01

[GoogleCodeExporter]

ok ... done my refactoring thing

current features remain:

- basic playback control (play,pause,prev,next)
- volume control via volume rockers
- rating support (see below)
- information retrieval (title,artist,album,coverart,rating)

i tried your new remuco-banshee adapter and the client is able to get the 
rating from
the server but isn't able to set it (using banshee 1.5.3 and your 
remuco-banshee adapter)

what should be included next?

Original comment by fha...@gmail.com on 16 Feb 2010 at 8:27

[GoogleCodeExporter]

Banshee:
It works for me. Any related output in the log or on the command line when 
running
the Banshee adapter?

Next:
- big thing: media browser
- small thing: put some device info (e.g. name) into the ClientInfo sent to the
  server at connection startup - see the java-doc of ClientInfo constructor

Original comment by obensonne@googlemail.com on 17 Feb 2010 at 7:07

[GoogleCodeExporter]

Banshee: i haven't looked at the log yet ... just noticed that it doesn't work 
...
but i will do this tomorrow

Mediabrowser and Clientinfo: i'll see what i can do

i have used the client yesterday and i noticed that i keep getting crashes 
related to
calls from the MainLoop ... but i am not yet sure what causes that

could it be that there is a 'bug' in the Logging facility? shouldn't the debug()
method put something like [DEBUG] in the output?

btw ... what i forgot to mention since day one: i changed the remuco_48.png 
cause it
didn't look that great at high resolutions ... if you want you can take a look 
at it
(it's in the res/drawable folder) ;)

Original comment by fha...@gmail.com on 17 Feb 2010 at 10:17

[GoogleCodeExporter]

When can we this App in the Market?

Some of us humble users are dying to install it :-)

Original comment by duoran.n...@gmail.com on 1 Mar 2010 at 8:22

[GoogleCodeExporter]

@duoran.nurt:
I hope we get this done in March.

Original comment by obensonne@googlemail.com on 2 Mar 2010 at 2:42

[GoogleCodeExporter]

@fhaust:

Any news on the Banshee rating issue?

> could it be that there is a 'bug' in the Logging facility? shouldn't the 
debug()
> method put something like [DEBUG] in the output?

If you would like the debug() method to work that way, feel free to change it.
Actually I just used the debug() method only during the development process and
removed them manually on releases. Technically there is no difference to the 
regular
log() method. Using another method simply makes it easy to find and disable 
debug
output in the code. I know this sounds prehistoric .. just another dirty 
optimization
to keep things as simple as possible for old JavaME devices.

> ... i changed the remuco_48.png ...

you're right, looks better now

I'll checkout your Android client these days. Maybe I can reproduce the MainLoop
issue and find the problem.

Original comment by obensonne@googlemail.com on 2 Mar 2010 at 2:58

[GoogleCodeExporter]

Just tested the client in the emulator. Good work! Some open issues anyway:

Menu buttons:
Is it possible to show/hide them context dependent? For instance only show the
connect entry when not yet connected, hide the disconnect and rate entries when 
not
connected? Currently it is possible to connect multiple times and hitting the 
rate
entry throws an crashing exception when not connected.

Rating:
In a long term perspective I'd love to have this directly on the main screen. 
As you
seem to have other priorities here, what about a user option to configure this?

Progress Bar:
Absolute seeking currently is not supported in Remuco. The progress bar allows 
to
jump to arbitrary positions anyway. Is it possible to disable this?

Pause/Resume:
Currently connections get dis/enabled on pause and resume events. What about 
doing it
the way described in issue 82 (comment 10).

Repeat/shuffle/fullscreen:
Any chance to provide toggle buttons for these? Maybe within the menu?
(fullscreen is used for video players). If repeat, shuffle and fullscreen 
control is
available can be detected using the PlayerInfo.supports() method using a 
feature from
class Feature as argument. Ideally the repeat and shuffle control items reflect 
the
current repeat/suffle state (as in class State).

Source:
Please add a License header to your source files. Just copy'n'paste it form the 
other
Java files already there.

Until now I did not check the MainLoop issue. Did you experience this on a real
device only or also in the emulator?

Regards,
Oben

Original comment by obensonne@googlemail.com on 3 Mar 2010 at 4:53

[GoogleCodeExporter]

Menu Buttons:
My idea was to keep that one as simple as possible ... "disconnect" is actually 
a
debugging button as is not intended to be used. For the user there shouldn't be 
a
disconnected state, he fires up the application and if the server is available 
the
client is online.
Also i'll remove some of the toasts (the notifying popups) currently everytime 
the
application is restarted (or the device is turned) a toasts pops up ... that's 
kinda
annoying ...

Rating:
i downgraded banshee back to the last 'rating supported' version and it works 
fine
there. Otoh there is a bug in android sdk 2.0 (and up as it seems) that the 
rating
bar widget is displayed wrong. So i have to work around that one to make this 
one
usable. (Yes there is a special rating bar widget in android ;) )

Progress Bar:
should be possible ... i tried it when i realized that there was no absolute 
jump but
moved on quickly

Pause/Resume:
haven't kept track of that issue ... but that's definitly the way to go

Repeat/shuffle/fullscreen:
repeat and shuffle are on my todo list already ... no big thing actually
fullscreen should be a 'conditional button' or in the menu in my eyes

Source:
sure ... it'll be done in the next push

Mainloop issue:
i think that one is related to messages being send while not being connected 
... try
rotating the emulator (F12) some times ... eventually the program will crash

So far,
Florian

Original comment by fha...@gmail.com on 3 Mar 2010 at 5:23

[GoogleCodeExporter]

Menu Buttons:
Ah, I see. What about showing the connect dialogue when starting the app and 
there is
no last hostname or connecting to the last host failed? BTW, currently there is 
no
feedback for the user if connecting failed, right? I would strongly vote for 
such a
thing.

Repeat/shuffle/fullscreen:
Yes, fullscreen should be conditional. Placing it in the menu seems fine.

Other notes:
In the future we are planning to add navigation support to Remuco, targeting 
things
like DVD menus. As a consequence clients should be able to show different 
interfaces.
One as it is now (current track and basic playback control) and another one with
something like a compass rose. See issue 88 and DevelopmentIdeas for some 
thoughts on
this. This hasn't any impact on the Android client right now but you might want 
to
know this, maybe it has some influence on where you'd go with the Android 
development.

Mainloop issue:
Couldn't reproduce it yet, keep trying :) ..

Original comment by obensonne@googlemail.com on 3 Mar 2010 at 8:47

[GoogleCodeExporter]

@obensonne: thanks for the info!

Original comment by duoran.n...@gmail.com on 3 Mar 2010 at 10:28

[GoogleCodeExporter]

repeat and shuffle buttons done ... not much work there
but i came to the conclusion that i have to reimplement the backend/connection 
as a 
service if i want to implement a playlist browser. A android application 
restarts 
itself too often (for example if you turn the device into landscape mode).

At the moment the application is fine and i think we'll be able to release it 
with the 
next remuco version ... but i'll append a small 'beta' string there ;)

Original comment by fha...@gmail.com on 13 Mar 2010 at 10:01

[GoogleCodeExporter]

Issue 95 has been merged into this issue.

Original comment by obensonne@googlemail.com on 8 Apr 2010 at 6:45

[GoogleCodeExporter]

First, sorry for the delay, no 0.9.3 release yet. Let's hope it's coming soon ;)

fhaust:
I tested the client and I also think it's ready to get merged and released.
Could you please write a README for the Android client? It should contain the
following information:
- how to install using the market
- how to install using the binary in the release-package
- how to build
- how to test in the emulator

I'd really appreciate that!

(I know, writing documentation is -#?X/#&~ ...
http://geekandpoke.typepad.com/geekandpoke/2010/04/dont-april-fool-geeks.html)

Original comment by obensonne@googlemail.com on 12 Apr 2010 at 9:22

[GoogleCodeExporter]

hy ... another sorry for not responding to things like this lately.

I don't think the Client is ready for distribution yet. Running it in the 
Emulator is
fine cause there is a stable network connection. But on a real device there are 
lots
of crashes when the connection isn't there. And I can't get the connection check
methods to run (some help with ConnectivityManager.requestRouteToHost() 
anyone?) :(

I have to spend more time working on the client this week ... hopefully i'll get
those problems sorted out until the end.

Original comment by fha...@gmail.com on 13 Apr 2010 at 4:08

[GoogleCodeExporter]

Would you prefer to have a beta version of the Android client in release 0.9.3 
or to wait for 0.9.4?

Original comment by obensonne@googlemail.com on 16 Apr 2010 at 4:31

[GoogleCodeExporter]

Dear all,

As a humble Android user, I would like to help to test the remuco android 
client. I
use Rhythmbox, banshee, xbmc daily.
What steps should I follow to do that ?
Thank you for all your dedication.

Original comment by olivier....@gmail.com on 25 Apr 2010 at 9:24