Image Meta Data workaround for iOS

[Lorin Beer]

I've written a small workaround for getting at image meta data for images
taken through camera.getPicture on iOS

Currently, UIImagePickerController embeds only a couple exif data entries
in the jpeg header of the resulting image. We've put together exif support,
and it should make it to 2.6.0. Until then, if anyone's interested, I have
a workaround in my github forks

The branch:
https://github.com/lorinbeer/cordova-ios/tree/cb1285_hack
The change:
https://github.com/lorinbeer/cordovaios/commit/a0ba48700c8e13f1d873ded361bf91a1a2271dce

This modifies the camera return value, converting the metadata dictionary
returned by UIImagePickerController to a json string, and returns it
bundled with image url in the return value.

Example usage can be found here:
https://github.com/lorinbeer/cordova-mobile-spec/tree/camdatahack]
here specifically:
https://github.com/lorinbeer/cordova-mobile-spec/blob/camdatahack/camera/index.html

Note that this is a temporary workaround, and not a suggestion to alter the
camera.getPicture return values in any official way.

Ping me if you are interested in any further details.

- Lorin

Re: cordova-cli plugin add/remove/prepare proposal

[Jesse]

Do we have a time set for this?
I won't be able to attend in person, but I will be in the hangout.

Cheers,
  Jesse

On Wed, Feb 27, 2013 at 4:42 PM, Al Harding  wrote:

> ...and the BlackBerry guys! :)
>
>
>
> On Wed, Feb 27, 2013 at 4:37 PM, Jeffrey Heifetz  wrote:
>
> > Actually I'm lucky enough to be heading down to join in on the fun,
> > looking forward to meeting all of you.
> >
> > On 2013-02-27, at 6:26 PM, Al Harding wrote:
> >
> > > Awesome! We've got a room booked at Adobe SF with projector, camera,
> > beer,
> > > so we can loop anyone in who is remote.
> > >
> > > Look forward to meeting the Google guys!
> > >
> > > -Al
> > >
> > >
> > >
> > >
> > > On Wed, Feb 27, 2013 at 2:44 PM, Michal Mocny 
> > wrote:
> > >
> > >> Oh sweet, we were just saying how we still haven't met most of you.
> > >>
> > >> Sadly, Braden is not coming on this trip, but Andrew, Max and I will
> be
> > >> there (and working from Adobe Friday) we will have time to chat.  Can
> > bring
> > >> Braden in via Hangout.
> > >>
> > >> -Michal
> > >>
> > >>
> > >> On Wed, Feb 27, 2013 at 5:40 PM, Filip Maj  wrote:
> > >>
> > >>> Yep! There's an online code review planned for March 22nd for both
> the
> > >> cli
> > >>> tools as well as the plugman tool.
> > >>>
> > >>> Also: next week most Adobe cordova folk will be in SF, and so will
> you
> > >>> Googlers ya? We can talk specifics and hash out our ideas better then
> > and
> > >>> bring it back to the list.
> > >>>
> > >>> On 2/27/13 2:26 PM, "Michal Mocny"  wrote:
> > >>>
> >  I think we have a hangout scheduled for that conversation (among
> > others)
> >  right?  Its good that Braden is setting up topics of conversation :)
> > 
> >  -Michal
> > 
> > 
> >  On Wed, Feb 27, 2013 at 4:37 PM, Filip Maj  wrote:
> > 
> > > I think this is a good conversation to have.
> > >
> > > Note that, if we do split up how plugins are treated and when we
> copy
> > > files around (I.e. Move the www assets on every prepare, but the
> > >> native
> > > files only on platform/plugin adds), then the plugman tool will
> > either
> > > need finer-grained support for these types of actions or we need to
> > > assimilate/couple the plugman code closer to cordova-cli.
> > >
> > > On 2/27/13 1:32 PM, "Braden Shepherdson" 
> > wrote:
> > >
> > >> I'm on the fence about native plugin code. I think iOS has some
> > >> complications there.
> > >>
> > >> Over the course of my work on the installation prototype, I've
> > >> actually
> > >> moved to copying plugin www files on every prepare, that works
> > great.
> > >>
> > >> For native code, I wonder if that's best done on add/remove. I was
> > > mostly
> > >> thinking about www files for the original proposal.
> > >>
> > >> Braden
> > >>
> > >>
> > >> On Wed, Feb 27, 2013 at 4:24 PM, Filip Maj  wrote:
> > >>
> > >>> Couple notes before I add some comments:
> > >>>
> > >>> - in general plugin add and rm is COMPLETELY delegated to the
> > >> plugman
> > >>> tool. See [1]. Most of the code linked is error checking,
> otherwise
> > > it
> > >>> shells out to plugman.. With one exception..
> > >>> - what happens in [2]. Which is the point Braden brought up about
> > >>> polluting the user's www. Totally agree this should change. At
> the
> > > time
> > >>> of
> > >>> writing that I dropped a TODO [3] that this was a likely bad
> > > assumption.
> > >>> - the "what plugins are installed" code is already a `ls
> plugins/`
> > > run
> > >>> [4].
> > >>>
> > >>> Now going back to your proposal:
> > >>>
> > >>> 1. Never pollute user's www. I completely agree with this. Time
> to
> > >>> refactor that out.
> > >>> 2. Use existence of directories under the ./plugins dir to
> identify
> > >>> which
> > >>> plugins are installed. Yep. Already does that as shown in [4].
> > >>>
> > >>> If I understand correctly, you are proposing we run a plugin
> > >>> installation
> > >>> (I.e. Copy over appropriate files and edit config files) every
> time
> > >>> cordova prepare is run. This would mean that every time we run
> > > prepare,
> > >>> we
> > >>> have to recreate a native cordova project (otherwise we'd be
> > > installing
> > >>> plugin files into the native project on every command). I'm not
> > >> sure
> > > I
> > >>> agree with this.. I have to think more about it..
> > >>>
> > >>> I think this conversation boils down to: should we be recreating
> > > cordova
> > >>> projects on every command, or keep the native projects
> "persistent"
> > >>> across
> > >>> commands (which is currently how it operates).
> > >>>
> > >>> [1]
> > >
> https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L72
> > >>> [2]
> > >
> https://github.com/apache/cordova-cli/b

Re: Writing binary data to disk

[Lorin Beer]

Andrew:

that makes sense to me. It brings us closer in line with the w3c FileWriter
spec.


On Thu, Mar 7, 2013 at 9:57 AM, Andrew Grieve  wrote:

> The w3 spec says that FileWriter.write() accepts a Blob. Cordova's
> currently accepts only strings. What I was suggesting is that we allow
> either to be passed in.
>
> This will work only on iOS6+ and Android 3+ due to the lack of Blob support
> on older versions. If we want to support older versions with this binary
> ability, then maybe we could do something like:
>
> var base64str = ...;
> var binaryData = CordovaBinary.fromBase64(base64str);
> fileWriter.write(binaryData);
>
>
> The exec() bridge could then check the type of the parameter and do the
> right thing.
>
>
>
> On Wed, Mar 6, 2013 at 9:41 PM, Lorin Beer 
> wrote:
>
> > opps, amend the last message
> > "the user *DOES* want to specify a hex or binary encoded string, and have
> > that written as binary data on the native side"
> >
> >
> > On Wed, Mar 6, 2013 at 6:40 PM, Lorin Beer 
> > wrote:
> >
> > > Andrew:
> > >
> > > the Cordova docs on FileWriter state that the data sent is written as a
> > > UTF-8 string
> > > http://docs.phonegap.com/en/2.5.0/cordova_file_file.md.html#FileWriter
> > > The user doesn't want to specify a hex or binary encoded string, and
> have
> > > that written as binary data on the native side. As it sits now,
> > providing a
> > > hex string would write a unicode string of hex characters.
> > >
> > > In order to to have a hex or binary string actually be written as
> binary,
> > > we'd need to:
> > > 1. pass an argument which explicitly sets the write mode, either to
> > > FileWriter constructor or FileWriter.write
> > > 2. set a state on FileWriter stating that the data string it receives
> is
> > > to be written in binary mode
> > >
> > > neither of these two options is explicitly part of the W3C spec on
> > > FileWriter
> > >
> > >
> > > On Wed, Mar 6, 2013 at 5:47 PM, Michal Mocny 
> > wrote:
> > >
> > >> We've added a way to send binary data across the android and ios
> bridge
> > >> (ArrayBuffers are a supported argument/message type).
> > >>
> > >> If you wanted to write a simple plugin to support writing binary data
> to
> > >> disk, it should be quite easy.
> > >>
> > >> Note: There are various limitations to the current way we send
> > >> ArrayBuffers, such as being limited to very small sizes per call.  We
> > are
> > >> soon going to be working on improvements here, expect JIRA issues and
> > >> tests
> > >> to come soon.
> > >>
> > >> -Michal
> > >>
> > >>
> > >> On Wed, Mar 6, 2013 at 7:02 PM, Lorin Beer 
> > >> wrote:
> > >>
> > >> > Hey folks,
> > >> >
> > >> > I was going through the unassigned jira issues, and came across
> > >> > CB-2406
> > >> >  ((https://issues.apache.org/jira/browse/CB-2406), which requests a
> > >> method
> > >> > to write binary data to disk. Before commenting to the user on the
> > >> issue, I
> > >> > thought I'd get some feedback from you guys.
> > >> >
> > >> > My feeling is that while there might be a use case or two,
> specifying
> > a
> > >> > binary write mode doesn't fit in with the W3C FileWriter
> > >> > api,
> > >> > and shouldn't be a change to the File API of cordova. As such, the
> > issue
> > >> > should probably be closed.
> > >> >
> > >> > The way in which the user would/should accomplish this kind of
> > >> > functionality would be to create a very simple plugin which takes a
> > hex
> > >> > string and uses the native file writer api to open in binary mode.
> > >> >
> > >> > Before commenting to the user on the issue, I thought I'd get some
> > >> feedback
> > >> > from you guys.
> > >> >
> > >> >
> > >> > - Lorin
> > >> >
> > >>
> > >
> > >
> >
>

Re: Writing binary data to disk

[Andrew Grieve]

The w3 spec says that FileWriter.write() accepts a Blob. Cordova's
currently accepts only strings. What I was suggesting is that we allow
either to be passed in.

This will work only on iOS6+ and Android 3+ due to the lack of Blob support
on older versions. If we want to support older versions with this binary
ability, then maybe we could do something like:

var base64str = ...;
var binaryData = CordovaBinary.fromBase64(base64str);
fileWriter.write(binaryData);


The exec() bridge could then check the type of the parameter and do the
right thing.



On Wed, Mar 6, 2013 at 9:41 PM, Lorin Beer  wrote:

> opps, amend the last message
> "the user *DOES* want to specify a hex or binary encoded string, and have
> that written as binary data on the native side"
>
>
> On Wed, Mar 6, 2013 at 6:40 PM, Lorin Beer 
> wrote:
>
> > Andrew:
> >
> > the Cordova docs on FileWriter state that the data sent is written as a
> > UTF-8 string
> > http://docs.phonegap.com/en/2.5.0/cordova_file_file.md.html#FileWriter
> > The user doesn't want to specify a hex or binary encoded string, and have
> > that written as binary data on the native side. As it sits now,
> providing a
> > hex string would write a unicode string of hex characters.
> >
> > In order to to have a hex or binary string actually be written as binary,
> > we'd need to:
> > 1. pass an argument which explicitly sets the write mode, either to
> > FileWriter constructor or FileWriter.write
> > 2. set a state on FileWriter stating that the data string it receives is
> > to be written in binary mode
> >
> > neither of these two options is explicitly part of the W3C spec on
> > FileWriter
> >
> >
> > On Wed, Mar 6, 2013 at 5:47 PM, Michal Mocny 
> wrote:
> >
> >> We've added a way to send binary data across the android and ios bridge
> >> (ArrayBuffers are a supported argument/message type).
> >>
> >> If you wanted to write a simple plugin to support writing binary data to
> >> disk, it should be quite easy.
> >>
> >> Note: There are various limitations to the current way we send
> >> ArrayBuffers, such as being limited to very small sizes per call.  We
> are
> >> soon going to be working on improvements here, expect JIRA issues and
> >> tests
> >> to come soon.
> >>
> >> -Michal
> >>
> >>
> >> On Wed, Mar 6, 2013 at 7:02 PM, Lorin Beer 
> >> wrote:
> >>
> >> > Hey folks,
> >> >
> >> > I was going through the unassigned jira issues, and came across
> >> > CB-2406
> >> >  ((https://issues.apache.org/jira/browse/CB-2406), which requests a
> >> method
> >> > to write binary data to disk. Before commenting to the user on the
> >> issue, I
> >> > thought I'd get some feedback from you guys.
> >> >
> >> > My feeling is that while there might be a use case or two, specifying
> a
> >> > binary write mode doesn't fit in with the W3C FileWriter
> >> > api,
> >> > and shouldn't be a change to the File API of cordova. As such, the
> issue
> >> > should probably be closed.
> >> >
> >> > The way in which the user would/should accomplish this kind of
> >> > functionality would be to create a very simple plugin which takes a
> hex
> >> > string and uses the native file writer api to open in binary mode.
> >> >
> >> > Before commenting to the user on the issue, I thought I'd get some
> >> feedback
> >> > from you guys.
> >> >
> >> >
> >> > - Lorin
> >> >
> >>
> >
> >
>

[DISCUSS] Add Ripple support to cordova-cli

[Gord Tanner]

Hello everyone,

I made a quick prototype to add support for using ripple from the
cordova-cli [1].

Currently I just added a new command called ripple that calls the cordova
emulate command and then starts the ripple server to point to it.  It will
then launch the default browser (cross platform) which will launch your App
in ripple.  This does not require the plugin to be installed as Ripple is
functioning as a proxy / web app.

I have a question on how to handle this command:

- Should this be a flag on the "cordova emulate" command?

The Command could ether be:

cordova serve  [port] --ripple

or

cordova ripple  [port]

There are also a couple of todos:

- Ripple needs to be published to npm and we should install it via that,
currently I am just cloning via git.  This will happen soon and is just a
temp hack.
- Ripple is currently starting its own server, we should allow the "cordova
emulate" middleware to be usable by ripple
- Ripple should allow us to pick the device we want to launch on.  If I
launch using blackberry I shouldn't have ripple emulate an iPhone.


[1]
https://github.com/gtanner/cordova-cli/commit/cf499d53b3e6f6631513fd5110c0861f8f01

Re: Prototype for automatic JS installation in cordova-cli

[Michal Mocny]

On Wed, Mar 6, 2013 at 6:39 PM, Anis KADRI  wrote:

> I read [1] and looked at your pull request and I believe I agree with most
> of it. I will have to take your code for a spin to see how this new
> js-module tag works with its merges/clobbers/runs features.
>
> However, I strongly disagree with this feature only being available in
> cordova-cli (specifically your src/plugin_loader.js in your pull request).
> If I don't use cordova-cli I should still be available to install plugins.
> I believe this should be handled by the plugman tool.
>
> Now that I think more about it, I think plugman should just be a separate
> library that can be included in cordova-cli. Nothing prevents it from
> having its own command line interface as it does today.
>

This sounds fine to me.  I think Braden wasn't really considering decisions
at that level for this first proof of concept.
We also have a call scheduled soon to go over exactly these issues, and he
did this work here precisely so that we have the background to know what to
discuss.
(So, thanks Braden!)


> The performance gain from having one file vs multiple files should
> be insignificant in our case. As far as I know, pages loads can be impacted
> from having multiple script tags because:
> - multiple HTTP requests are initiated to download/parse external resources
> (some browsers have limitations to the # of simultaneous connections).
> Since they're all packaged with the app in our case I don't think this will
> have an impact.
> - Parser performance. I have no numbers to back this up but I think the
> impact should be insignificant.
>
> Indeed, having multiple files instead of one does however improve our
> debugging abilities. I think we should drop the performance discussion
> until we hit a real-world problem.
>

I agree.


>
> -a
>
>
> On Wed, Mar 6, 2013 at 12:03 PM, Braden Shepherdson  >wrote:
>
> > I haven't measured this. I certainly didn't see a visible delay in load
> > times, but I was also launching a freshly pushed app and waiting for the
> > debugger to connect, so it was hardly a good test for using the app like
> a
> > user.
> >
> >
> > On Wed, Mar 6, 2013 at 2:45 PM, Patrick Mueller 
> wrote:
> >
> > > On Mon, Feb 25, 2013 at 1:52 PM, Braden Shepherdson <
> bra...@chromium.org
> > > >wrote:
> > >
> > > > We decided that if loading two dozen script tags is too slow
> (probably
> > > not)
> > > > then we can make the decision whether to sacrifice error message
> > clarity
> > > > for speed.
> > > >
> > >
> > > Do you have any #'s?  Seems like something we can time.  Avoiding
> > > concatenation seems like a good thing to me.
> > >
> > > --
> > > Patrick Mueller
> > > http://muellerware.org
> > >
> >
>

Re: [Android] Seriously, WTF does baseUrl actually do?

[Bryce Curtis]

If I recall, baseUrl was used for for a simplified whitelist checking
scheme.  It was the url path of the HTML page loaded with loadUrl().
If there are any problems with removing it, they would show up during
the manual tests.

On Wed, Mar 6, 2013 at 6:55 PM, Joe Bowser  wrote:
> And when I say the tests pass, it didn't appear to break anything. :P
> On Mar 6, 2013 5:54 PM, "Joe Bowser"  wrote:
>
>> OK, I deleted it and all the tests pass. I'll check that in tomorrow.
>> On Mar 6, 2013 5:46 PM, "Andrew Grieve"  wrote:
>>
>>> Yeah, I had a look at baseUrl last week and couldn't figure out what it
>>> was
>>> for. I figured it was something that you (joe) had added, but guess not!
>>> :P.
>>>
>>> Definitely agree that the best docs are inline with the code, except for
>>> maybe architectural type things.
>>>
>>>
>>> On Wed, Mar 6, 2013 at 8:42 PM, Marcel Kinard  wrote:
>>>
>>> > I'd suggest putting the internal documentation inline with the code,
>>> such
>>> > as javadoc or block comments. Keep the docs right next to the code so
>>> they
>>> > are less likely to diverge over time.
>>> >
>>> > -- Marcel Kinard
>>> >
>>> > On Mar 6, 2013, at 7:31 PM, Joe Bowser  wrote:
>>> >
>>> > > Side note: We have too many weird obscure things in Cordova-Android
>>> > > that aren't well documented, like how we handle offline storage.
>>> > > Should we throw this in the wiki? Somwhere else?
>>> > >
>>> > > Joe
>>> >
>>> >
>>>
>>

Re: Prototype for automatic JS installation in cordova-cli

[Patrick Mueller]

On Wed, Mar 6, 2013 at 6:27 PM, Michal Mocny  wrote:

> personally if the overhead is measured in 100's its not acceptable.  So,
> <100ms? (hopefully far less than).
>

yup

-- 
Patrick Mueller
http://muellerware.org