Return-Path: 
 <dev-return-25384-apmail-cordova-dev-archive=cordova.apache.org@cordova.apache.org>
X-Original-To: apmail-cordova-dev-archive@www.apache.org
Delivered-To: apmail-cordova-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 88549108E2
	for <apmail-cordova-dev-archive@www.apache.org>;
 Fri,  2 Aug 2013 15:34:15 +0000 (UTC)
Received: (qmail 22274 invoked by uid 500); 2 Aug 2013 15:34:15 -0000
Delivered-To: apmail-cordova-dev-archive@cordova.apache.org
Received: (qmail 22049 invoked by uid 500); 2 Aug 2013 15:34:13 -0000
Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cordova.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cordova.apache.org>
List-Post: <mailto:dev@cordova.apache.org>
List-Id: <dev.cordova.apache.org>
Reply-To: dev@cordova.apache.org
Delivered-To: mailing list dev@cordova.apache.org
Received: (qmail 22041 invoked by uid 99); 2 Aug 2013 15:34:11 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Aug 2013 15:34:11 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of lorin.beer.dev@gmail.com
 designates 209.85.214.179 as permitted sender)
Received: from [209.85.214.179] (HELO mail-ob0-f179.google.com)
 (209.85.214.179)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Aug 2013 15:34:06 +0000
Received: by mail-ob0-f179.google.com with SMTP id fb19so1449487obc.10
        for <dev@cordova.apache.org>; Fri, 02 Aug 2013 08:33:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=Y/fv/QWYsoBAMYwMk8bhKuznORJqrFhc7C7MoiFIxdI=;
        b=eS0faS36BDxpBWTuYECAmo8G/LAIC2Rn9fene/3uwUtovfaFG6IsBXCqbtBWb+vgzU
         P/aJgbLGNMbTqnzXF0p1Uj2LzsDSGTFAOnYCghlGqLE+9iP/2X8Ve0DbEoBbSuVEfS/h
         oQTfcqv8YotTb616PEepKxAyNAFU+eYIvZRBVDeWiaOptO6LN2lrMWxqHFT8Y5zgJysC
         V+KVNcfa+hfJU8SVnjvoDt0uolQW7AWqFfegctdbunYkFW1wmVctLU8PJ+pZy4Nrj83a
         6LRrr3pqG3PgyZEf4LI66rBp9a1uPn/sy+LrkNZ4dNI4ArG7pkKmvfdA1BmoduljToqX
         HlVQ==
MIME-Version: 1.0
X-Received: by 10.43.168.67 with SMTP id nh3mr631515icc.33.1375457625711; Fri,
 02 Aug 2013 08:33:45 -0700 (PDT)
Received: by 10.64.102.10 with HTTP; Fri, 2 Aug 2013 08:33:45 -0700 (PDT)
In-Reply-To: 
 <CAJOjTCih3XvuxsuvKZFdf-6=cWiPKNJrS+x58Rq4iYkcZCGY_A@mail.gmail.com>
References: 
 <CAJOjTCih3XvuxsuvKZFdf-6=cWiPKNJrS+x58Rq4iYkcZCGY_A@mail.gmail.com>
Date: Fri, 2 Aug 2013 08:33:45 -0700
Message-ID: 
 <CAASJe7_jCKBcDoQPAfJUAn+=wATPrTPa1=YAvYpeJ3Q2XXjNfw@mail.gmail.com>
Subject: Re: [plugins] Proper handling of subsequant calls in Media plugin
From: Lorin Beer <lorin.beer.dev@gmail.com>
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11c20edc2f329204e2f8af12
X-Virus-Checked: Checked by ClamAV on apache.org

--001a11c20edc2f329204e2f8af12
Content-Type: text/plain; charset=ISO-8859-1

I ran into this sometime ago on the android media API. The relevant
conversation is likely deeply buried, and we should consider documenting
the appropriate behavior somewhere permanent.

My opinion is that appropriate behavior is dependent on the function being
called and the current state. A FSM could capture this.
In terms of <play> during <play> state, I would recommend that the plugin
executes the latest command normally, playing media from a new source or
restarting the currently executing media as if the play command had been
received in the <stopped> state.

- Lorin


On Thu, Aug 1, 2013 at 1:47 PM, Benn Mapes <benn.mapes@gmail.com> wrote:

> Working on https://issues.apache.org/jira/browse/CB-3783, it appears that
> there is no documentation on how the media plugin should handle subsequent
> calls of the same function.
>
> An example would be calling my_media.play() multiple times when the
> my_media is already playing. Should this be swallowed by the plugin and
> ignored? Should we respond with a
> MediaError<
> http://cordova.apache.org/docs/en/3.0.0/cordova_media_media.md.html#MediaError
> >.MEDIA_ERR_ABORTED
> and a message saying the media is already playing? What about subsequent
> calls to my_media.pause() when the media is already paused?
>
> Was just wondering what other platforms have implemented for this and what
> the proper way of handling subsequent calls is.
>
> ~Benn
>

--001a11c20edc2f329204e2f8af12--