Closed GoogleCodeExporter closed 9 years ago
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
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
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
Original comment by obensonne@googlemail.com
on 29 Sep 2009 at 9:42
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
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
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
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
@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
Ok, great! I'll start as soon as possible.
Original comment by ivashyst
on 14 Nov 2009 at 2:21
@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
@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
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
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
Good point!
Original comment by obensonne@googlemail.com
on 13 Dec 2009 at 5:03
Any progress on this one?
Original comment by fha...@gmail.com
on 31 Jan 2010 at 9:12
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
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
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:
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:
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
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
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
sure ... i'd respect that
Original comment by fha...@gmail.com
on 12 Feb 2010 at 8:17
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
@duoran.nurt:
I hope we get this done in March.
Original comment by obensonne@googlemail.com
on 2 Mar 2010 at 2:42
@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
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
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
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
@obensonne: thanks for the info!
Original comment by duoran.n...@gmail.com
on 3 Mar 2010 at 10:28
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
Issue 95 has been merged into this issue.
Original comment by obensonne@googlemail.com
on 8 Apr 2010 at 6:45
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
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
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
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
Original issue reported on code.google.com by
jiri....@gmail.com
on 22 Sep 2009 at 10:25