Re: Google Team's Task Backlog: Android
On Sun, Jul 28, 2013 at 12:32 AM, Joe Bowser bows...@gmail.com wrote:
OK, since we're not talking about each individual one in their own
thread (or at least a thread I can find), let's talk about them here:
On Thu, Jul 25, 2013 at 10:48 AM, Andrew Grieve agri...@chromium.org
wrote:
cordova-android:
- Change plugins to have distinct package names
How does this work with plugin discovery? It's better to change it now
before we get plugin discovery fully setup and this becomes a problem.
Doing this for 3.0 was too much work last minute but this could be
done on 3.1
It's unrelated to plugin discovery.
- Look at using requestAnimationFrame to throttle exec bridge (advice
from
a PGD talk)
There better be tests for this before it lands since this touches the
exec bridge. Do we have JUnit tests for the exec bridge? We probably
should!
We have mobile-spec tests for the bridge. Both automated manual benchmark
ones.
- Move JSONUtils out of core (to minimize API surface) (was added by our
intern a while ago)
So, this isn't being used by our plugins?
Nope.
- Move FileHelpers out of core (Most functionality now lives in
CordovaResourceApi)
The last time I checked, our plugins depended on this. If we're not
supporting it, it should go.
A few of our plugins use one or two methods from it. On the whole, I think
the class causes more harm than good because it has bugs uses Strings
instead of Uri. Step 1 is to move it into plugins, step 2 would be to
refactor the plugins to not use it at all.
- Move ExifHelpers out of core and into Camera (used only by Camera)
This may also be used by Capture when we capture an image. I have no
idea why we have two ways of taking a photo.
Confirmed: It's not used by Capture, only Camera.
- Extract Database plugin out of core (and into... cordova-labs?
cordova-android?)
What Database Plugin? If we have a storage plugin still in core, it
should die.
Yeah, my motivation is the same I think. Wanted to extract it so that I
don't have to use it. Are you sure no one depends on it? Moving it to labs
might be a safer move.
- Change CordovaWebview constructors to accept a CordovaInterface instead
of a Context (get the Context from the getActivity() of CordovaInterface)
I recommend creating a second constructor instead, since there are
examples of CordovaWebViews that use CordovaInterfaces that aren't
activities and it's probably easier for CordovaWebView to provide a
Context than CordovaInterface to do so in those cases. I don't see
why we can't add a second constructor and keep this for those cases.
All of our constructors look like this:
public CordovaWebView(Context context) {
super(context);
if (CordovaInterface.class.isInstance(context))
{
this.cordova = (CordovaInterface) context;
}
else
{
Log.d(TAG, Your activity must implement CordovaInterface to
work);
}
So, we're currently forcing people to pass in a Context that implements
CordovaInterface.
Instead, we should do:
public CordovaWebView(CordovaInterface cordova) {
super(cordova.getActivity());
- Make private (or package-private) any api that is likely unused by
third
party plugins
We should warn people that we're doing that this release.
Yeah, this will definitely require code review before we even really know
what we're up against.
- Use source instead of .jar
We should allow for both! Using a jar is easier to do from the
command line, and this is more CLI work (which there is no shortage
of).
- Easier to debug, faster project create, consistent with how
plugins
work
- Extract splashscreen logic out of core
It can't be done, we've gone through this numerous times. The
splashscreen has to appear before we even have a PluginManager
instantiated. Someone has to put a Java chicken there to stall while
we get the JS Egg ready.
:) awesome. I haven't looked into this yet, but look forward to meeting
this Java chicken!
Re: requestAnimationFrame Re: Google Team's Task Backlog: Android
I'm not sure the exact details, but it was something Andrew Trice said he did in his PGD talk. I may not have understood correctly. I think the issue might be that our bridge doesn't have any throttling built in. On Mon, Jul 29, 2013 at 12:01 AM, Jesse MacFadyen purplecabb...@gmail.comwrote: Hopefully the subject change started a new thread. Why would you use reqAnimFrame for exec? Native calls have nothing to do with repaints, so this makes no sense to me... Sent from my iPhone On Jul 25, 2013, at 10:49 AM, Andrew Grieve agri...@chromium.org wrote: We've done some planning around what we'd like to get done over the next quarter, and so I thought I'd share. This isn't to say that we'll be going and doing these things without further discussion or proper JIRA issues. It also doesn't mean we will be solely focused on this list, nor that we'll actually end up completing everything on the list. Just that we *currently* think that these things should get done. cordova-android: - Change plugins to have distinct package names - Look at using requestAnimationFrame to throttle exec bridge (advice from a PGD talk) - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) - Make private (or package-private) any api that is likely unused by third party plugins - (CB-3900) Have PluginResult that gets populated lazily - at the time of being sent over the bridge. - Use source instead of .jar - Easier to debug, faster project create, consistent with how plugins work - Extract splashscreen logic out of core
Re: Google Team's Task Backlog: Android
On Mon, Jul 29, 2013 at 7:29 AM, Andrew Grieve agri...@chromium.org wrote:
On Sun, Jul 28, 2013 at 12:32 AM, Joe Bowser bows...@gmail.com wrote:
OK, since we're not talking about each individual one in their own
thread (or at least a thread I can find), let's talk about them here:
On Thu, Jul 25, 2013 at 10:48 AM, Andrew Grieve agri...@chromium.org
wrote:
cordova-android:
- Change plugins to have distinct package names
How does this work with plugin discovery? It's better to change it now
before we get plugin discovery fully setup and this becomes a problem.
Doing this for 3.0 was too much work last minute but this could be
done on 3.1
It's unrelated to plugin discovery.
Except that 3.0 version of the plugin will have
org.apache.cordova.core.foo and 3.1 will have
org.apache.cordova.foo.bar. So, is this an issue yet for upgrading
the plugin or will it be an uninstall/install thing. I have no idea.
- Move FileHelpers out of core (Most functionality now lives in
CordovaResourceApi)
The last time I checked, our plugins depended on this. If we're not
supporting it, it should go.
A few of our plugins use one or two methods from it. On the whole, I think
the class causes more harm than good because it has bugs uses Strings
instead of Uri. Step 1 is to move it into plugins, step 2 would be to
refactor the plugins to not use it at all.
Sounds good. I hope nobody else is using it, because we made no
promises about this one.
- Change CordovaWebview constructors to accept a CordovaInterface instead
of a Context (get the Context from the getActivity() of CordovaInterface)
I recommend creating a second constructor instead, since there are
examples of CordovaWebViews that use CordovaInterfaces that aren't
activities and it's probably easier for CordovaWebView to provide a
Context than CordovaInterface to do so in those cases. I don't see
why we can't add a second constructor and keep this for those cases.
All of our constructors look like this:
public CordovaWebView(Context context) {
super(context);
if (CordovaInterface.class.isInstance(context))
{
this.cordova = (CordovaInterface) context;
}
else
{
Log.d(TAG, Your activity must implement CordovaInterface to
work);
}
So, we're currently forcing people to pass in a Context that implements
CordovaInterface.
Instead, we should do:
public CordovaWebView(CordovaInterface cordova) {
super(cordova.getActivity());
I believe that a View MUST have a constructor with a context, so we
still need the constructor there in some form, even if it just calls
super. It won't just infer that it has two constructors on its own.
Re: Google Team's Task Backlog: Android
On Sun, Jul 28, 2013 at 12:32 AM, Joe Bowser bows...@gmail.com wrote: - Move ExifHelpers out of core and into Camera (used only by Camera) This may also be used by Capture when we capture an image. I have no idea why we have two ways of taking a photo. The reason we have two ways to take a picture is that we already had the Camera class implemented before the W3C Media Capture API was released. Once released the spec did not fully encapsulate what we already had in Camera, hence the overlapping of capabilities. - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) What Database Plugin? If we have a storage plugin still in core, it should die. Yeah, any work around Storage should be creating an IndexedDB plugin. - Extract splashscreen logic out of core It can't be done, we've gone through this numerous times. The splashscreen has to appear before we even have a PluginManager instantiated. Someone has to put a Java chicken there to stall while we get the JS Egg ready. Agreed and LMFAO! Simon Mac Donald http://hi.im/simonmacdonald
Re: requestAnimationFrame Re: Google Team's Task Backlog: Android
Hopefully the subject change started a new thread. Why would you use reqAnimFrame for exec? Native calls have nothing to do with repaints, so this makes no sense to me... Sent from my iPhone On Jul 25, 2013, at 10:49 AM, Andrew Grieve agri...@chromium.org wrote: We've done some planning around what we'd like to get done over the next quarter, and so I thought I'd share. This isn't to say that we'll be going and doing these things without further discussion or proper JIRA issues. It also doesn't mean we will be solely focused on this list, nor that we'll actually end up completing everything on the list. Just that we *currently* think that these things should get done. cordova-android: - Change plugins to have distinct package names - Look at using requestAnimationFrame to throttle exec bridge (advice from a PGD talk) - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) - Make private (or package-private) any api that is likely unused by third party plugins - (CB-3900) Have PluginResult that gets populated lazily - at the time of being sent over the bridge. - Use source instead of .jar - Easier to debug, faster project create, consistent with how plugins work - Extract splashscreen logic out of core
Re: Google Team's Task Backlog: Android
The changes looks pretty basic to me. Lets see what Joe has to say about the deprecation. Also, I would like to add one more to my interest list: Change plugins to have distinct package names On Sat, Jul 27, 2013 at 1:51 AM, Andrew Grieve agri...@chromium.org wrote: Cool, all of those seem not too bad, but let's discuss a bit first: On Fri, Jul 26, 2013 at 11:01 AM, Sharif Ahmed sharifdu...@gmail.com wrote: Andrew - The following peeked my interest: - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) These three are just a matter of deleting the files from cordova-android, and adding them into the plugins that use them. Joe - is this what you thought we should apply the deprecation policy to? I'd like to just delete them since these aren't documented in our plugin guide at all, but it wouldn't hurt to just add @Deprecated to them for a while as well. If we do add @Deprecated, we should still put copies of them in the relevant plugins so that our plugins aren't using deprecated classes. FileHelpers is used by multiple plugins, so it should be copy pasted into each plugin that uses it (but delete the unused methods in each). Before this can be done, we'll need to put each plugin in its own package, or else the files will conflict. This has already been discussed, but I don't think there's been an issue created for it yet. - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) For sure we should rip this out. But to where I'm not sure. Anyone have opinions? Maybe put the plugin right in cordova-android? - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) This should be a harmless / easy change unless I'm missing something. Having said that, I will study on them further. And yes there are a good list of issues, I am going through them. On 7/26/13, Andrew Grieve agri...@chromium.org wrote: Sharif - I don't think anything has been spoke for, anything in particular that peeked your interest? There's also a good list of issues on JIRA available for Android: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CB%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20Android%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC On Fri, Jul 26, 2013 at 2:34 AM, Sharif Ahmed sharifdu...@gmail.com wrote: @Andrew I want to contribute to the upcoming features/issues you have just given. Please let me know, how can I go forward in doing it. Maybe assign a few to me, I don't know you tell me :) Thanks. On 7/25/13, Andrew Grieve agri...@chromium.org wrote: We've done some planning around what we'd like to get done over the next quarter, and so I thought I'd share. This isn't to say that we'll be going and doing these things without further discussion or proper JIRA issues. It also doesn't mean we will be solely focused on this list, nor that we'll actually end up completing everything on the list. Just that we *currently* think that these things should get done. cordova-android: - Change plugins to have distinct package names - Look at using requestAnimationFrame to throttle exec bridge (advice from a PGD talk) - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) - Make private (or package-private) any api that is likely unused by third party plugins - (CB-3900) Have PluginResult that gets populated lazily - at the time of being sent over the bridge. - Use source instead of .jar - Easier to debug, faster project create, consistent with how plugins work - Extract splashscreen logic out of core -- Regards, Sharif Ahmed Junior Software Engineer Therap Services, LLC +01715438290 -- Regards, Sharif Ahmed Junior Software Engineer Therap Services, LLC +01715438290 -- Regards, Sharif Ahmed Junior Software Engineer Therap Services, LLC +01715438290
Re: Google Team's Task Backlog: Android
OK, since we're not talking about each individual one in their own thread (or at least a thread I can find), let's talk about them here: On Thu, Jul 25, 2013 at 10:48 AM, Andrew Grieve agri...@chromium.org wrote: cordova-android: - Change plugins to have distinct package names How does this work with plugin discovery? It's better to change it now before we get plugin discovery fully setup and this becomes a problem. Doing this for 3.0 was too much work last minute but this could be done on 3.1 - Look at using requestAnimationFrame to throttle exec bridge (advice from a PGD talk) There better be tests for this before it lands since this touches the exec bridge. Do we have JUnit tests for the exec bridge? We probably should! - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) So, this isn't being used by our plugins? - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) The last time I checked, our plugins depended on this. If we're not supporting it, it should go. - Move ExifHelpers out of core and into Camera (used only by Camera) This may also be used by Capture when we capture an image. I have no idea why we have two ways of taking a photo. - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) What Database Plugin? If we have a storage plugin still in core, it should die. - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) I recommend creating a second constructor instead, since there are examples of CordovaWebViews that use CordovaInterfaces that aren't activities and it's probably easier for CordovaWebView to provide a Context than CordovaInterface to do so in those cases. I don't see why we can't add a second constructor and keep this for those cases. - Make private (or package-private) any api that is likely unused by third party plugins We should warn people that we're doing that this release. - Use source instead of .jar We should allow for both! Using a jar is easier to do from the command line, and this is more CLI work (which there is no shortage of). - Easier to debug, faster project create, consistent with how plugins work - Extract splashscreen logic out of core It can't be done, we've gone through this numerous times. The splashscreen has to appear before we even have a PluginManager instantiated. Someone has to put a Java chicken there to stall while we get the JS Egg ready.
Re: Google Team's Task Backlog: Android
@Andrew I want to contribute to the upcoming features/issues you have just given. Please let me know, how can I go forward in doing it. Maybe assign a few to me, I don't know you tell me :) Thanks. On 7/25/13, Andrew Grieve agri...@chromium.org wrote: We've done some planning around what we'd like to get done over the next quarter, and so I thought I'd share. This isn't to say that we'll be going and doing these things without further discussion or proper JIRA issues. It also doesn't mean we will be solely focused on this list, nor that we'll actually end up completing everything on the list. Just that we *currently* think that these things should get done. cordova-android: - Change plugins to have distinct package names - Look at using requestAnimationFrame to throttle exec bridge (advice from a PGD talk) - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) - Make private (or package-private) any api that is likely unused by third party plugins - (CB-3900) Have PluginResult that gets populated lazily - at the time of being sent over the bridge. - Use source instead of .jar - Easier to debug, faster project create, consistent with how plugins work - Extract splashscreen logic out of core -- Regards, Sharif Ahmed Junior Software Engineer Therap Services, LLC +01715438290
Re: Google Team's Task Backlog: Android
Yep, that was my intention. On Thu, Jul 25, 2013 at 1:56 PM, Joe Bowser bows...@gmail.com wrote: Can we break these out and talk about a couple of these? I'm certain that many of these features will be subject to the Deprecation Policy. On Thu, Jul 25, 2013 at 10:48 AM, Andrew Grieve agri...@chromium.org wrote: We've done some planning around what we'd like to get done over the next quarter, and so I thought I'd share. This isn't to say that we'll be going and doing these things without further discussion or proper JIRA issues. It also doesn't mean we will be solely focused on this list, nor that we'll actually end up completing everything on the list. Just that we *currently* think that these things should get done. cordova-android: - Change plugins to have distinct package names - Look at using requestAnimationFrame to throttle exec bridge (advice from a PGD talk) - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) - Make private (or package-private) any api that is likely unused by third party plugins - (CB-3900) Have PluginResult that gets populated lazily - at the time of being sent over the bridge. - Use source instead of .jar - Easier to debug, faster project create, consistent with how plugins work - Extract splashscreen logic out of core
Re: Google Team's Task Backlog: Android
Sharif - I don't think anything has been spoke for, anything in particular that peeked your interest? There's also a good list of issues on JIRA available for Android: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CB%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20Android%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC On Fri, Jul 26, 2013 at 2:34 AM, Sharif Ahmed sharifdu...@gmail.com wrote: @Andrew I want to contribute to the upcoming features/issues you have just given. Please let me know, how can I go forward in doing it. Maybe assign a few to me, I don't know you tell me :) Thanks. On 7/25/13, Andrew Grieve agri...@chromium.org wrote: We've done some planning around what we'd like to get done over the next quarter, and so I thought I'd share. This isn't to say that we'll be going and doing these things without further discussion or proper JIRA issues. It also doesn't mean we will be solely focused on this list, nor that we'll actually end up completing everything on the list. Just that we *currently* think that these things should get done. cordova-android: - Change plugins to have distinct package names - Look at using requestAnimationFrame to throttle exec bridge (advice from a PGD talk) - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) - Make private (or package-private) any api that is likely unused by third party plugins - (CB-3900) Have PluginResult that gets populated lazily - at the time of being sent over the bridge. - Use source instead of .jar - Easier to debug, faster project create, consistent with how plugins work - Extract splashscreen logic out of core -- Regards, Sharif Ahmed Junior Software Engineer Therap Services, LLC +01715438290
Re: Google Team's Task Backlog: Android
Andrew - The following peeked my interest: - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) Having said that, I will study on them further. And yes there are a good list of issues, I am going through them. On 7/26/13, Andrew Grieve agri...@chromium.org wrote: Sharif - I don't think anything has been spoke for, anything in particular that peeked your interest? There's also a good list of issues on JIRA available for Android: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CB%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20Android%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC On Fri, Jul 26, 2013 at 2:34 AM, Sharif Ahmed sharifdu...@gmail.com wrote: @Andrew I want to contribute to the upcoming features/issues you have just given. Please let me know, how can I go forward in doing it. Maybe assign a few to me, I don't know you tell me :) Thanks. On 7/25/13, Andrew Grieve agri...@chromium.org wrote: We've done some planning around what we'd like to get done over the next quarter, and so I thought I'd share. This isn't to say that we'll be going and doing these things without further discussion or proper JIRA issues. It also doesn't mean we will be solely focused on this list, nor that we'll actually end up completing everything on the list. Just that we *currently* think that these things should get done. cordova-android: - Change plugins to have distinct package names - Look at using requestAnimationFrame to throttle exec bridge (advice from a PGD talk) - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) - Make private (or package-private) any api that is likely unused by third party plugins - (CB-3900) Have PluginResult that gets populated lazily - at the time of being sent over the bridge. - Use source instead of .jar - Easier to debug, faster project create, consistent with how plugins work - Extract splashscreen logic out of core -- Regards, Sharif Ahmed Junior Software Engineer Therap Services, LLC +01715438290 -- Regards, Sharif Ahmed Junior Software Engineer Therap Services, LLC +01715438290
Re: Google Team's Task Backlog: Android
Cool, all of those seem not too bad, but let's discuss a bit first: On Fri, Jul 26, 2013 at 11:01 AM, Sharif Ahmed sharifdu...@gmail.comwrote: Andrew - The following peeked my interest: - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) These three are just a matter of deleting the files from cordova-android, and adding them into the plugins that use them. Joe - is this what you thought we should apply the deprecation policy to? I'd like to just delete them since these aren't documented in our plugin guide at all, but it wouldn't hurt to just add @Deprecated to them for a while as well. If we do add @Deprecated, we should still put copies of them in the relevant plugins so that our plugins aren't using deprecated classes. FileHelpers is used by multiple plugins, so it should be copy pasted into each plugin that uses it (but delete the unused methods in each). Before this can be done, we'll need to put each plugin in its own package, or else the files will conflict. This has already been discussed, but I don't think there's been an issue created for it yet. - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) For sure we should rip this out. But to where I'm not sure. Anyone have opinions? Maybe put the plugin right in cordova-android? - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) This should be a harmless / easy change unless I'm missing something. Having said that, I will study on them further. And yes there are a good list of issues, I am going through them. On 7/26/13, Andrew Grieve agri...@chromium.org wrote: Sharif - I don't think anything has been spoke for, anything in particular that peeked your interest? There's also a good list of issues on JIRA available for Android: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CB%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20Android%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC On Fri, Jul 26, 2013 at 2:34 AM, Sharif Ahmed sharifdu...@gmail.com wrote: @Andrew I want to contribute to the upcoming features/issues you have just given. Please let me know, how can I go forward in doing it. Maybe assign a few to me, I don't know you tell me :) Thanks. On 7/25/13, Andrew Grieve agri...@chromium.org wrote: We've done some planning around what we'd like to get done over the next quarter, and so I thought I'd share. This isn't to say that we'll be going and doing these things without further discussion or proper JIRA issues. It also doesn't mean we will be solely focused on this list, nor that we'll actually end up completing everything on the list. Just that we *currently* think that these things should get done. cordova-android: - Change plugins to have distinct package names - Look at using requestAnimationFrame to throttle exec bridge (advice from a PGD talk) - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) - Make private (or package-private) any api that is likely unused by third party plugins - (CB-3900) Have PluginResult that gets populated lazily - at the time of being sent over the bridge. - Use source instead of .jar - Easier to debug, faster project create, consistent with how plugins work - Extract splashscreen logic out of core -- Regards, Sharif Ahmed Junior Software Engineer Therap Services, LLC +01715438290 -- Regards, Sharif Ahmed Junior Software Engineer Therap Services, LLC +01715438290
Google Team's Task Backlog: Android
We've done some planning around what we'd like to get done over the next quarter, and so I thought I'd share. This isn't to say that we'll be going and doing these things without further discussion or proper JIRA issues. It also doesn't mean we will be solely focused on this list, nor that we'll actually end up completing everything on the list. Just that we *currently* think that these things should get done. cordova-android: - Change plugins to have distinct package names - Look at using requestAnimationFrame to throttle exec bridge (advice from a PGD talk) - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) - Make private (or package-private) any api that is likely unused by third party plugins - (CB-3900) Have PluginResult that gets populated lazily - at the time of being sent over the bridge. - Use source instead of .jar - Easier to debug, faster project create, consistent with how plugins work - Extract splashscreen logic out of core
Re: Google Team's Task Backlog: Android
Can we break these out and talk about a couple of these? I'm certain that many of these features will be subject to the Deprecation Policy. On Thu, Jul 25, 2013 at 10:48 AM, Andrew Grieve agri...@chromium.org wrote: We've done some planning around what we'd like to get done over the next quarter, and so I thought I'd share. This isn't to say that we'll be going and doing these things without further discussion or proper JIRA issues. It also doesn't mean we will be solely focused on this list, nor that we'll actually end up completing everything on the list. Just that we *currently* think that these things should get done. cordova-android: - Change plugins to have distinct package names - Look at using requestAnimationFrame to throttle exec bridge (advice from a PGD talk) - Move JSONUtils out of core (to minimize API surface) (was added by our intern a while ago) - Move FileHelpers out of core (Most functionality now lives in CordovaResourceApi) - Move ExifHelpers out of core and into Camera (used only by Camera) - Extract Database plugin out of core (and into... cordova-labs? cordova-android?) - Change CordovaWebview constructors to accept a CordovaInterface instead of a Context (get the Context from the getActivity() of CordovaInterface) - Make private (or package-private) any api that is likely unused by third party plugins - (CB-3900) Have PluginResult that gets populated lazily - at the time of being sent over the bridge. - Use source instead of .jar - Easier to debug, faster project create, consistent with how plugins work - Extract splashscreen logic out of core
