Yeah, I am not excited by emulate/deploy, they are the same thing. In my mind, the power of CL tooling is as much for programs/scripts as users, interactive steps screw that completely. Maybe the lack of -d: should signal that interaction is required, and the same/similar can be done for the avd
On Wed, Nov 7, 2012 at 10:54 AM, Anis KADRI <anis.ka...@gmail.com> wrote: > On Wed, Nov 7, 2012 at 10:33 AM, Jesse MacFadyen > <purplecabb...@gmail.com>wrote: > >> # get a list of devices >> ./bin/emulate -devices >> >> # launch emulator with index of 2 >> ./bin/emulate -d:2 >> > > Sure if you can select the one you want then why not. I like a list better > than auto-selection personally. The reason is that it is more interactive > and selecting the right device/emulator requires one step only (instead of > the two like you described). We can always provide the option to select the > device/emulator (without having a list). > > We already require user interactions for emulators. They need to select > which target Android Virtual Device they want to launch. And there can be > many (2.1, 2.2, 2.3, 3.0, 4.0…). > I don't think that picking up the first one just for the sake of not > requiring user interactions is a good idea. > > >> >> I have never liked our use of the term emulate, as it is for emulators >> only where I might want to do the same for a physical device that is >> attached. and presumably listed devices could include both physical >> and virtual. >> > > If you read this discussion [1], you'd see that Brian came up with the > `deploy` name (for physical devices) and keep `emulate` for emulators. > > >> >> >> >> On 2012-11-07, at 10:19 AM, Anis KADRI <anis.ka...@gmail.com> wrote: >> >> > On Tue, Nov 6, 2012 at 4:58 PM, Jesse <purplecabb...@gmail.com> wrote: >> > >> >> User interaction should NOT be required, if it annoys you then type >> >> the right thing. >> > >> > What would the right thing be ? >> > >> > >> >> >> >> adb devices >> >> - returns a list of usable devices, why not mimic that? >> >> adb -s <serialNumber> <command> >> >> - makes perfect sense to me >> >> >> >> When I did the WP7 tool : ( which is used by the script ) >> >> CordovaDeploy [ -devices BuildOutputPath -d:DeviceIndex ] >> >> -devices : lists the devices and exits >> >> BuildOutputPath : path to the built application, typically >> >> Bin/Debug/ or Bin/Release/ >> >> -d : index of the device to deploy, default is 0 >> >> >> >> >> >> >> >> On Tue, Nov 6, 2012 at 4:46 PM, Anis KADRI <anis.ka...@gmail.com> >> wrote: >> >>> Right now when you cordova/emulate and nothing is running, it displays >> a >> >>> list of AVDs to choose from. I believe that we should display a list of >> >>> running devices/emulators when there is more than one device/emulator >> >>> running. As a user, I'd get mad if you automatically picked up the >> wrong >> >>> device/emulator. >> >>> However, according to this discussion [1] I thought we would separate >> >>> running on a device (cordova/deploy) and running in the emulator >> >>> (cordova/emulate) http://markmail.org/thread/znkkjmwgoc23lhhq >> >>> >> >>> >> >>> On Tue, Nov 6, 2012 at 4:38 PM, Jesse <purplecabb...@gmail.com> wrote: >> >>> >> >>>> first device, or add an optional index param >> >>>> this is what WP7 did, haven't tested it a few versions though .. >> >>>> >> >>>> On Tue, Nov 6, 2012 at 4:17 PM, Filip Maj <f...@adobe.com> wrote: >> >>>>> If you have more than one device/emulator hooked up these scripts >> fail >> >>>>> along the lines of: >> >>>>> >> >>>>> [exec] error: more than one device and emulator >> >>>>> [exec] - waiting for device - >> >>>>> [exec] error: more than one device and emulator >> >>>>> [exec] - waiting for device - >> >>>>> [exec] error: more than one device and emulator >> >>>>> [exec] - waiting for device - >> >>>>> >> >>>>> >> >>>>> And indefinitely hangs. >> >>>>> >> >>>>> Is this a use case we should cover, and if so, how to solve this one? >> >>>> grep >> >>>>> for the first dev/emu and choose that one? Iterate over all connected >> >>>>> devices? >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> @purplecabbage >> >>>> risingj.com >> >> >> >> >> >> >> >> -- >> >> @purplecabbage >> >> risingj.com >> >> >> -- @purplecabbage risingj.com
