Open GoogleCodeExporter opened 9 years ago
Due to reactions I received in issue 238, I will make further explanations on
this
issue.
- Inbuilt application is good enough for playing music but it lacks some
valuable
features which could be implemented seperetaly, so I'd like Mobbler to be an
enhancement "add-on" for the inbuilt application, definitely *not* a stand
alone
music player.
- I'd love if Mobbler could automatically execute the inbuilt application
(based on
an option in settings or asking at startup, surely) and save me from opening
both of
the applications.
- If the feature I'd like above is not possible, I'd like to have an
autostarting
server application (with small footprint) included in Mobbler which will
monitor the
inbuilt music player and start main application if inbuilt music player is
executed
by user (again, optional feature which can be turned off in settings).
I'd prefer first way over second way.
- In either way described above, since my phone doesn't have dedicated music
keys,
I'd like to use Mobbler UI for performing operations on music player (which may
be
called "Local mode", since then Mobbler would be a front-end to the music
player).
So the left direction key could be binded to "rewind", right key to "forward",
center "play/stop" or "play/pause", up to "love" and down to "ban" or "stop"
(if
center is "play/pause"); or the whole d-pad could be configured manually by
user
based on a list of actions in settings.
- In local mode, Mobbler could search for image files within the same directory
of
current track and if found, show it as track image.
- If music player is not executed, Mobbler could behave as a pure Last.fm
client as
it does at the moment; current condition (being a client) is good, with
enhancements
mentioned in issue 238 it'll be perfect (I'd still prefer the whole d-pad to be
manually configured in the same manner above)
To sum things up..
a) If Mobbler is executed by user, its behaviour could be implemented as:
1. Ask the user about music player execution
2. If "Yes" selected, switch to "local mode" with local mode specific key
bindings
and functionality.
3. If "No" selected, switch to "online mode" with online mode specific key
bindings
and functionality.
4. Whatever selection is made at startup, be ready to switch to other mode
because
user may want to do that (connect to last.fm / disconnect and use music player)
at
anytime after this, but do not ever prompt user for this unless there is user
input.
If there is any user input that needs mode switching, be sure to get a
confirmation
before listing access points / disconnecting.
b) If Mobbler is executed at phone startup, its behaviour could be implemented
as:
1. Start in background
2. If user opens UI from menu, then ask about music player execution.
The rest could be the same with (a).
c) If Mobbler is executed automatically by a small server application described
above, its behaviour could be implemented as in (b)
I don't have anymore ideas atm, but will add later if any comes up.
Original comment by gece.bekcisi@uniturk.net
on 14 Jan 2009 at 9:16
I think I must add some more stuff about 4th behavioural step.
- If "local mode" is selected at startup and user wants to switch afterwards,
Mobbler should check inbuilt application's state and if it's playing a track,
Mobbler should stop or pause playback and connect after this.
- If "online mode" is selected at startup, but user does not connect to any
station
and inbuilt application is running and playing, key bindings & functionality
should
be switched to "local mode" behaviour with a small difference; online
scrobbling
enabled = tracks are not queued like in issue 243.
I think all those suggestions are the pointing the right way to be followed for
Mobbler development, because my mind is based on this conjecture:
The inbuilt application doesn't need any extra stuff (other than the track
itself)
to listen but last.fm stations need "online connection" and maybe more battery
power
(that needs testing with nokia's energy profiler to be exact); so users are
more
likely to play tracks locally especially if they have expensive access or if
they
think being online drains battery faster.
I hope I've explained my mind comprehensibly and clearly.
Original comment by gece.bekcisi@uniturk.net
on 15 Jan 2009 at 11:09
Ahh, so you want Mobbler to be a fully featured front end to the music player?
Starting the music player and controlling the music player can both be done from
Mobbler, but we have previously rejected the idea of controlling the music
player
because we wanted to keep things simple and behave in a similar way to the
desktop
client (you don't control iTunes with that). When you are using the music
player it
is expected that you are looking at that and Mobbler is just scrobbling away in
the
background. It seems that people prefer to look at Mobbler when listenning to
music.
I am coming around to the idea that we shouldn't keep the paradigms of the
desktop
client as the mobile quite different. I now agree with you and think that
controlling the music player would be a good feature for Mobbler.
As you mention, the difficult thing would be keeping it simple for the user and
getting the behaviour and key bindings right. I am not a big of user definable
key
bindings or introducing a new mode. Automatically changing key bindings
depending on
what you are doing might be a bit confusing too. It's just something we need
to put
a little bit of thought into though.
I should also mention that it is not technically possible for Mobbler to
autostart or
be started if the music player starts. It would be possible in the future, if
we
decide to spend the time to get symbian signed.
Thanks for your suggestions! Does anyone want to do this piece of work?
Original comment by eartle@gmail.com
on 15 Jan 2009 at 11:12
I prefer to look at Mobbler, because I can "love", "ban" or "add to playlist"
etc. I
don't exactly know why desktop client doesn't do this, but in a mobile phone
lack of
a mouse to speed things up changes environment a lot.
About the autostart issue, I'd like to repeat what I said in last.fm grup
forum: why
not include an unsigned version besides selfsigned one in new releases which
has
autostart function for people capable of signing it by Symbian Signed - Open
Signed
Online or with a developer certificate just like I have?
Original comment by gece.bekcisi@uniturk.net
on 15 Jan 2009 at 11:22
To release an unsigned version, that includes a few more features, we would
have to
change all the UIDs to protected ones from unprotected ones. This is not a big
deal,
but has a few problems.
1) It would require a bit of work to make it easy to build both versions
configurably
2) These features would have to be added configurably.
3) I think that because the two versions have different UIDs, the OS would
think they
are different applications. You would get an install error if you tried to
install
both when you may just be expecting it to update.
4) Because of (3) checking for updates from the unsigned version would not work.
Original comment by eartle@gmail.com
on 15 Jan 2009 at 11:59
I didn't know UID's would cause so much trouble. OK, forget it then.
(I am not a big fan of user definable key bindings or introducing a new mode.)
What if users, even including you, would benefit more from the features Mobbler
presents in a new mode?
(Automatically changing key bindings depending on what you are doing might be a
bit
confusing too)
Well, current key bindings is more confusing, I think. Why?
Let's assume I am a new and unexperienced user. I am a last.fm user and heard
Mobbler somehow, installed it for the first time. I opened music player, start
playing a song; and then remembered Mobbler and executed it. Mobbler would try
to
get online by default and I said "why not?". I look at the screen and see
"music
player" at top, "play/stop" and "forward" buttons in the middle and think
they'll
work in music player since Mobbler knows I am using music player and displays
the
current track, but, hey! If I press those buttons Mobbler would try to open a
station and even crash. "Logical"? "Unconfusing"?
Taking suggestions to further step; what about a user selectable option,
"simple"
and "advanced" modes? In "simple" mode, just as you said, keys should be fixed
(but
I still think they should behave accordingly, reason is explained above) layout
would not be unconfusing etc. But in "advanced" mode user would be already
accepting
the difficulties he/she would face; so he/she should be free to set Mobbler the
way
he/she wants it to behave; an advanced user will use Mobbler more efficiently.
Original comment by gece.bekcisi@uniturk.net
on 16 Jan 2009 at 4:52
Mobbler does not try to get online by default. It will only do this if you have
selected to be in online mode. offline mode is default on a new installation.
We
are also planning to put online/offline in the status bar when the music player
is
playing.
I think that the left joypad button will always be skip backward and will only
work
when the music player is running.
I will 'grey out' the buttons that are not currently useable by drawing them
with
around 50% alpha.
Nothing happening:
All buttons are greyed except for play.
Music Player:
Only ban is greyed.
Radio Player:
Only skip backward is greyed.
Original comment by eartle@gmail.com
on 20 Jan 2009 at 10:52
Well, sorry about the default mode delusion.
I can be wrong and things doesn't need to be done in the way I describe; but as
far
as I see you at least get my point: mobbler should behave according to music
player's state.
Original comment by gece.bekcisi@uniturk.net
on 20 Jan 2009 at 8:08
I know I'm not supposed to post "+1 Me too!", but just so the meaning of my
vote is clear....
I also think the "Mobbler as front end for built-in music player" idea is
great. Just this second had the same idea myself! Glad to hear that it is
indeed possible. Has there been any progress on this feature?
Thanks for the Mobbler app as-is btw :)
Original comment by colin.cu...@gmail.com
on 15 Apr 2011 at 8:47
We're adding pause for the radio, so it'd be good to add it for the music
player too.
Original comment by hugovk@gmail.com
on 15 Apr 2011 at 4:31
Original issue reported on code.google.com by
gece.bekcisi@uniturk.net
on 9 Jan 2009 at 1:51