[jira] [Commented] (WEEX-162) When Cell Position Changed , outOfVisibleRange not accurate, item.getCellPositionINScollable() get wrong position

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279714#comment-16279714
 ] 

ASF GitHub Bot commented on WEEX-162:
-

Github user gubaojian closed the pull request at:

https://github.com/apache/incubator-weex/pull/931


> When Cell Position Changed , outOfVisibleRange not accurate, 
> item.getCellPositionINScollable() get wrong position
> -
>
> Key: WEEX-162
> URL: https://issues.apache.org/jira/browse/WEEX-162
> Project: Weex
>  Issue Type: Bug
>Reporter: codefurture
>Assignee: Adam Feng
>
> When Cell Position Changed , outOfVisibleRange not accurate, 
> item.getCellPositionINScollable() get wrong positionuse  instead.
>  boolean outOfVisibleRange = !ViewCompat.isAttachedToWindow(view);



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WEEX-162) When Cell Position Changed , outOfVisibleRange not accurate, item.getCellPositionINScollable() get wrong position

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279646#comment-16279646
 ] 

ASF GitHub Bot commented on WEEX-162:
-

Github user weex-bot commented on the issue:

https://github.com/apache/incubator-weex/pull/931
  





  

  
  Warnings

  
  
  :warning:
  No Changelog changes!

  

  :warning:
  This PR should update related documents as well. 

  




  

  
  Messages

  
  
  :book:
  danger test finished.

  




  Generated by :no_entry_sign: http://github.com/danger/danger-js/;>dangerJS




> When Cell Position Changed , outOfVisibleRange not accurate, 
> item.getCellPositionINScollable() get wrong position
> -
>
> Key: WEEX-162
> URL: https://issues.apache.org/jira/browse/WEEX-162
> Project: Weex
>  Issue Type: Bug
>Reporter: codefurture
>Assignee: Adam Feng
>
> When Cell Position Changed , outOfVisibleRange not accurate, 
> item.getCellPositionINScollable() get wrong positionuse  instead.
>  boolean outOfVisibleRange = !ViewCompat.isAttachedToWindow(view);



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WEEX-162) When Cell Position Changed , outOfVisibleRange not accurate, item.getCellPositionINScollable() get wrong position

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279643#comment-16279643
 ] 

ASF GitHub Bot commented on WEEX-162:
-

GitHub user gubaojian opened a pull request:

https://github.com/apache/incubator-weex/pull/931

[WEEX-162][android] When Cell Position Changed , outOfVisibleRange not right

When Cell Position Changed , outOfVisibleRange not accurate, 
item.getCellPositionINScollable() get wrong position use instead.
boolean outOfVisibleRange = !ViewCompat.isAttachedToWindow(view);


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gubaojian/incubator-weex 
release-0.17-cell-position-not-right

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-weex/pull/931.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #931


commit ed65633cd503c820b9a31f0651c1f42f4e705e7e
Author: jianbai.gbj 
Date:   2017-12-06T04:20:32Z

[WEEX-162][android] When Cell Position Changed , outOfVisibleRange not 
accurate, item.getCellPositionINScollable() get wrong position, use 
attachWindow instead




> When Cell Position Changed , outOfVisibleRange not accurate, 
> item.getCellPositionINScollable() get wrong position
> -
>
> Key: WEEX-162
> URL: https://issues.apache.org/jira/browse/WEEX-162
> Project: Weex
>  Issue Type: Bug
>Reporter: codefurture
>Assignee: Adam Feng
>
> When Cell Position Changed , outOfVisibleRange not accurate, 
> item.getCellPositionINScollable() get wrong positionuse  instead.
>  boolean outOfVisibleRange = !ViewCompat.isAttachedToWindow(view);



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (WEEX-162) When Cell Position Changed , outOfVisibleRange not accurate, item.getCellPositionINScollable() get wrong position

[codefurture (JIRA)]

codefurture created WEEX-162:


 Summary: When Cell Position Changed , outOfVisibleRange not 
accurate, item.getCellPositionINScollable() get wrong position
 Key: WEEX-162
 URL: https://issues.apache.org/jira/browse/WEEX-162
 Project: Weex
  Issue Type: Bug
Reporter: codefurture
Assignee: Adam Feng


When Cell Position Changed , outOfVisibleRange not accurate, 
item.getCellPositionINScollable() get wrong positionuse  instead.
 boolean outOfVisibleRange = !ViewCompat.isAttachedToWindow(view);




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Moving Playground & Examples out of Weex repo

[Hanks Zhang]

I have created a personal website to put those demos [1]. It doesn't finish
yet and could be linked form Weex's official website when it's done.

It's a static website at present, developers can add examples through PR. I
think we could let developers modify or add examples online if it has a
backend.

[1] https://hanks10100.github.io/weex-vue-examples/


2017-12-06 10:33 GMT+08:00 方曦(千之) :

> Also very agree with Hanks.
> +1
>
> > 在 2017年12月6日，10:31，Jonathan Dong  写道：
> >
> > I love the idea about the online playground demos, things are kept
> online should be easy to publish, modify and revoke. And for the demo
> application itself, should be kept as simple as it can be, with minimum
> features like navigation, debug, QR scan, and maybe a easy access point to
> the online playground demo.
> >
> > I think I can follow this implementation on app side.
> >
> >> On 6 Dec 2017, at 10:21 AM, 谷宝剑(剑白) 
> wrote:
> >>
> >>
> >>   have an online playground demo like hao123 website, collect as
> many example as possible. so that developer can get lastest feature and
> example
> >>
> >> --From:Hanks
> Zhang Time:2017 Dec 5 (Tue) 21:41To:dev <
> dev@weex.incubator.apache.org>Subject:Re: Moving Playground & Examples
> out of Weex repo
> >> Moreover, I think our playground app should be redesigned.
> >>
> >> Most examples are based on the ".we" framework, which will be removed
> soon.
> >> Even those examples written in Vue are not the best practice and have no
> >> reference value. The UI of it is also rough and has not been updated
> for a
> >> long time. We should provide more practical examples and make it easy to
> >> use.
> >>
> >> Besides the examples, I think this app is also a link between Weex team
> and
> >> developers. It can be used to expose information and thoughts to
> >> developers, and can also be used to collect the feedback. We should make
> >> good use of it.
> >>
> >> Best Regards, Hanks
> >>
> >>
> >> 2017-10-31 17:49 GMT+08:00 Adam Feng :
> >>
> >>> +1
> >>>
> >>> The playground in Weex repo should be a simple “Weex browser”,  a Weex
> >>> examples viewer that lets you navigate to Weex experiences just like
> >>> websites.
> >>>
> >>> Thanks.
> >>> Adam Feng
> >>>
> >>> On 30 Oct 2017, 10:13 PM +0800, xing zhang  >,
> >>> wrote:
>  We should update the Playground App in App Store both on Android and
> iOS
>  frequently, so the developers can use it to preview their page using
> the
>  new feature, and we can fix the emergency bug at the same time.
> 
>  2017-10-30 21:59 GMT+08:00 Jonathan Dong <
> jondong.commun...@outlook.com
>  :
> 
> > Hi Weex folks,
> >
> > I’m thinking of moving Playground and Examples out of Weex repo to
> > simplify our code base, I hope we can fully discuss if it is
> necessary
> >>> to
> > make this move.
> >
> > Playground is a good entry to fiddle with the features of basic
> >>> components
> > and debug your pages, but it is kind of heavy if we take it as a demo
> >>> in
> > the Weex repo. As many of the Weex developers tend to create their
> own
> > applications based on the Playground project, I suppose it is
> >>> necessary to
> > create a simpler one, say AppShell, which only contains QR Scan and
> >>> page
> > load functions, it would be sufficient for users to test their Weex
> >>> pages,
> > and much easier for them to take it as an application template to
> >>> create
> > their own project. Playground should be maintained in a separate repo
> >>> in
> > WeexTeam, which can be maintained and distributed separately.
> >
> > Same things should also happens to examples directory, I suppose what
> >>> we
> > really need is one or few simplified example to demonstrate the usage
> >>> of
> > the main components and the way of implementing app using Weex in the
> > simplest way, not to keep those detailed example for each components
> in
> > Weex repo. Instead I think it is a good practice to move them into
> >>> WeexTeam
> > and maintains as a separate repo, and replace the .we implementation
> >>> with
> > .vue as well.
> >
> > Any thought? I hope we can fully discuss it and bring out a proposal
> to
> > make it happen asap.
> >
> > Cheers,
> > Jonathan Dong
> >
> >
> >>>
> >>
> >
>
>

[jira] [Commented] (WEEX-161) DURATION lost should not throw exception when toast

[codefurture (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279628#comment-16279628
 ] 

codefurture commented on WEEX-161:
--

E/weex: [WXModalUIModule] alert param parse error 
java.lang.NullPointerException: Attempt to invoke virtual method 'int 
java.lang.Integer.intValue()' on a null object reference
at 
com.taobao.weex.ui.module.WXModalUIModule.toast(WXModalUIModule.java:72)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at 
com.taobao.weex.bridge.MethodInvoker.invoke(MethodInvoker.java:46)
at 
com.taobao.weex.bridge.NativeInvokeHelper$1.run(NativeInvokeHelper.java:48)
at 
com.taobao.weex.common.WXThread$SafeRunnable.run(WXThread.java:49)
at android.os.Handler.handleCallback(Handler.java:815)
at android.os.Handler.dispatchMessage(Handler.java:104)
at android.os.Looper.loop(Looper.java:194)
at android.app.ActivityThread.main(ActivityThread.java:5682)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at 
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:963)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:758)

> DURATION lost should not throw exception when toast
> ---
>
> Key: WEEX-161
> URL: https://issues.apache.org/jira/browse/WEEX-161
> Project: Weex
>  Issue Type: Improvement
>Reporter: codefurture
>Assignee: Adam Feng
>
> DURATION lost should not throw exception when toast



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Moving Playground & Examples out of Weex repo

[方曦(千之)]

Also very agree with Hanks.
+1

> 在 2017年12月6日，10:31，Jonathan Dong  写道：
> 
> I love the idea about the online playground demos, things are kept online 
> should be easy to publish, modify and revoke. And for the demo application 
> itself, should be kept as simple as it can be, with minimum features like 
> navigation, debug, QR scan, and maybe a easy access point to the online 
> playground demo.
> 
> I think I can follow this implementation on app side.
> 
>> On 6 Dec 2017, at 10:21 AM, 谷宝剑(剑白)  wrote:
>> 
>> 
>>   have an online playground demo like hao123 website, collect as many 
>> example as possible. so that developer can get lastest feature and example
>> 
>> --From:Hanks 
>> Zhang Time:2017 Dec 5 (Tue) 21:41To:dev 
>> Subject:Re: Moving Playground & Examples out 
>> of Weex repo
>> Moreover, I think our playground app should be redesigned.
>> 
>> Most examples are based on the ".we" framework, which will be removed soon.
>> Even those examples written in Vue are not the best practice and have no
>> reference value. The UI of it is also rough and has not been updated for a
>> long time. We should provide more practical examples and make it easy to
>> use.
>> 
>> Besides the examples, I think this app is also a link between Weex team and
>> developers. It can be used to expose information and thoughts to
>> developers, and can also be used to collect the feedback. We should make
>> good use of it.
>> 
>> Best Regards, Hanks
>> 
>> 
>> 2017-10-31 17:49 GMT+08:00 Adam Feng :
>> 
>>> +1
>>> 
>>> The playground in Weex repo should be a simple “Weex browser”,  a Weex
>>> examples viewer that lets you navigate to Weex experiences just like
>>> websites.
>>> 
>>> Thanks.
>>> Adam Feng
>>> 
>>> On 30 Oct 2017, 10:13 PM +0800, xing zhang ,
>>> wrote:
 We should update the Playground App in App Store both on Android and iOS
 frequently, so the developers can use it to preview their page using the
 new feature, and we can fix the emergency bug at the same time.
 
 2017-10-30 21:59 GMT+08:00 Jonathan Dong  Hi Weex folks,
> 
> I’m thinking of moving Playground and Examples out of Weex repo to
> simplify our code base, I hope we can fully discuss if it is necessary
>>> to
> make this move.
> 
> Playground is a good entry to fiddle with the features of basic
>>> components
> and debug your pages, but it is kind of heavy if we take it as a demo
>>> in
> the Weex repo. As many of the Weex developers tend to create their own
> applications based on the Playground project, I suppose it is
>>> necessary to
> create a simpler one, say AppShell, which only contains QR Scan and
>>> page
> load functions, it would be sufficient for users to test their Weex
>>> pages,
> and much easier for them to take it as an application template to
>>> create
> their own project. Playground should be maintained in a separate repo
>>> in
> WeexTeam, which can be maintained and distributed separately.
> 
> Same things should also happens to examples directory, I suppose what
>>> we
> really need is one or few simplified example to demonstrate the usage
>>> of
> the main components and the way of implementing app using Weex in the
> simplest way, not to keep those detailed example for each components in
> Weex repo. Instead I think it is a good practice to move them into
>>> WeexTeam
> and maintains as a separate repo, and replace the .we implementation
>>> with
> .vue as well.
> 
> Any thought? I hope we can fully discuss it and bring out a proposal to
> make it happen asap.
> 
> Cheers,
> Jonathan Dong
> 
> 
>>> 
>> 
> 

Re: Moving Playground & Examples out of Weex repo

[Jonathan Dong]

I love the idea about the online playground demos, things are kept online 
should be easy to publish, modify and revoke. And for the demo application 
itself, should be kept as simple as it can be, with minimum features like 
navigation, debug, QR scan, and maybe a easy access point to the online 
playground demo.

I think I can follow this implementation on app side.

> On 6 Dec 2017, at 10:21 AM, 谷宝剑(剑白)  wrote:
> 
> 
>have an online playground demo like hao123 website, collect as many 
> example as possible. so that developer can get lastest feature and example
> 
> --From:Hanks 
> Zhang Time:2017 Dec 5 (Tue) 21:41To:dev 
> Subject:Re: Moving Playground & Examples out 
> of Weex repo
> Moreover, I think our playground app should be redesigned.
> 
> Most examples are based on the ".we" framework, which will be removed soon.
> Even those examples written in Vue are not the best practice and have no
> reference value. The UI of it is also rough and has not been updated for a
> long time. We should provide more practical examples and make it easy to
> use.
> 
> Besides the examples, I think this app is also a link between Weex team and
> developers. It can be used to expose information and thoughts to
> developers, and can also be used to collect the feedback. We should make
> good use of it.
> 
> Best Regards, Hanks
> 
> 
> 2017-10-31 17:49 GMT+08:00 Adam Feng :
> 
>>  +1
>> 
>>  The playground in Weex repo should be a simple “Weex browser”,  a Weex
>>  examples viewer that lets you navigate to Weex experiences just like
>>  websites.
>> 
>>  Thanks.
>>  Adam Feng
>> 
>>  On 30 Oct 2017, 10:13 PM +0800, xing zhang ,
>>  wrote:
>>  > We should update the Playground App in App Store both on Android and iOS
>>  > frequently, so the developers can use it to preview their page using the
>>  > new feature, and we can fix the emergency bug at the same time.
>>  >
>>  > 2017-10-30 21:59 GMT+08:00 Jonathan Dong >  >:
>>  >
>>  > > Hi Weex folks,
>>  > >
>>  > > I’m thinking of moving Playground and Examples out of Weex repo to
>>  > > simplify our code base, I hope we can fully discuss if it is necessary
>>  to
>>  > > make this move.
>>  > >
>>  > > Playground is a good entry to fiddle with the features of basic
>>  components
>>  > > and debug your pages, but it is kind of heavy if we take it as a demo
>>  in
>>  > > the Weex repo. As many of the Weex developers tend to create their own
>>  > > applications based on the Playground project, I suppose it is
>>  necessary to
>>  > > create a simpler one, say AppShell, which only contains QR Scan and
>>  page
>>  > > load functions, it would be sufficient for users to test their Weex
>>  pages,
>>  > > and much easier for them to take it as an application template to
>>  create
>>  > > their own project. Playground should be maintained in a separate repo
>>  in
>>  > > WeexTeam, which can be maintained and distributed separately.
>>  > >
>>  > > Same things should also happens to examples directory, I suppose what
>>  we
>>  > > really need is one or few simplified example to demonstrate the usage
>>  of
>>  > > the main components and the way of implementing app using Weex in the
>>  > > simplest way, not to keep those detailed example for each components in
>>  > > Weex repo. Instead I think it is a good practice to move them into
>>  WeexTeam
>>  > > and maintains as a separate repo, and replace the .we implementation
>>  with
>>  > > .vue as well.
>>  > >
>>  > > Any thought? I hope we can fully discuss it and bring out a proposal to
>>  > > make it happen asap.
>>  > >
>>  > > Cheers,
>>  > > Jonathan Dong
>>  > >
>>  > >
>> 
> 

Re: Moving Playground & Examples out of Weex repo

[谷宝剑(剑白)]

       have an online playground demo like hao123 website, collect as many 
example as possible. so that developer can get lastest feature and example

--From:Hanks 
Zhang Time:2017 Dec 5 (Tue) 21:41To:dev 
Subject:Re: Moving Playground & Examples out of 
Weex repo
Moreover, I think our playground app should be redesigned.

Most examples are based on the ".we" framework, which will be removed soon.
Even those examples written in Vue are not the best practice and have no
reference value. The UI of it is also rough and has not been updated for a
long time. We should provide more practical examples and make it easy to
use.

Besides the examples, I think this app is also a link between Weex team and
developers. It can be used to expose information and thoughts to
developers, and can also be used to collect the feedback. We should make
good use of it.

Best Regards, Hanks


2017-10-31 17:49 GMT+08:00 Adam Feng :

> +1
>
> The playground in Weex repo should be a simple “Weex browser”,  a Weex
> examples viewer that lets you navigate to Weex experiences just like
> websites.
>
> Thanks.
> Adam Feng
>
> On 30 Oct 2017, 10:13 PM +0800, xing zhang ,
> wrote:
> > We should update the Playground App in App Store both on Android and iOS
> > frequently, so the developers can use it to preview their page using the
> > new feature, and we can fix the emergency bug at the same time.
> >
> > 2017-10-30 21:59 GMT+08:00 Jonathan Dong  >:
> >
> > > Hi Weex folks,
> > >
> > > I’m thinking of moving Playground and Examples out of Weex repo to
> > > simplify our code base, I hope we can fully discuss if it is necessary
> to
> > > make this move.
> > >
> > > Playground is a good entry to fiddle with the features of basic
> components
> > > and debug your pages, but it is kind of heavy if we take it as a demo
> in
> > > the Weex repo. As many of the Weex developers tend to create their own
> > > applications based on the Playground project, I suppose it is
> necessary to
> > > create a simpler one, say AppShell, which only contains QR Scan and
> page
> > > load functions, it would be sufficient for users to test their Weex
> pages,
> > > and much easier for them to take it as an application template to
> create
> > > their own project. Playground should be maintained in a separate repo
> in
> > > WeexTeam, which can be maintained and distributed separately.
> > >
> > > Same things should also happens to examples directory, I suppose what
> we
> > > really need is one or few simplified example to demonstrate the usage
> of
> > > the main components and the way of implementing app using Weex in the
> > > simplest way, not to keep those detailed example for each components in
> > > Weex repo. Instead I think it is a good practice to move them into
> WeexTeam
> > > and maintains as a separate repo, and replace the .we implementation
> with
> > > .vue as well.
> > >
> > > Any thought? I hope we can fully discuss it and bring out a proposal to
> > > make it happen asap.
> > >
> > > Cheers,
> > > Jonathan Dong
> > >
> > >
>

Re: Moving Playground & Examples out of Weex repo

[Hanks Zhang]

Moreover, I think our playground app should be redesigned.

Most examples are based on the ".we" framework, which will be removed soon.
Even those examples written in Vue are not the best practice and have no
reference value. The UI of it is also rough and has not been updated for a
long time. We should provide more practical examples and make it easy to
use.

Besides the examples, I think this app is also a link between Weex team and
developers. It can be used to expose information and thoughts to
developers, and can also be used to collect the feedback. We should make
good use of it.

Best Regards, Hanks


2017-10-31 17:49 GMT+08:00 Adam Feng :

> +1
>
> The playground in Weex repo should be a simple “Weex browser”,  a Weex
> examples viewer that lets you navigate to Weex experiences just like
> websites.
>
> Thanks.
> Adam Feng
>
> On 30 Oct 2017, 10:13 PM +0800, xing zhang ,
> wrote:
> > We should update the Playground App in App Store both on Android and iOS
> > frequently, so the developers can use it to preview their page using the
> > new feature, and we can fix the emergency bug at the same time.
> >
> > 2017-10-30 21:59 GMT+08:00 Jonathan Dong  >:
> >
> > > Hi Weex folks,
> > >
> > > I’m thinking of moving Playground and Examples out of Weex repo to
> > > simplify our code base, I hope we can fully discuss if it is necessary
> to
> > > make this move.
> > >
> > > Playground is a good entry to fiddle with the features of basic
> components
> > > and debug your pages, but it is kind of heavy if we take it as a demo
> in
> > > the Weex repo. As many of the Weex developers tend to create their own
> > > applications based on the Playground project, I suppose it is
> necessary to
> > > create a simpler one, say AppShell, which only contains QR Scan and
> page
> > > load functions, it would be sufficient for users to test their Weex
> pages,
> > > and much easier for them to take it as an application template to
> create
> > > their own project. Playground should be maintained in a separate repo
> in
> > > WeexTeam, which can be maintained and distributed separately.
> > >
> > > Same things should also happens to examples directory, I suppose what
> we
> > > really need is one or few simplified example to demonstrate the usage
> of
> > > the main components and the way of implementing app using Weex in the
> > > simplest way, not to keep those detailed example for each components in
> > > Weex repo. Instead I think it is a good practice to move them into
> WeexTeam
> > > and maintains as a separate repo, and replace the .we implementation
> with
> > > .vue as well.
> > >
> > > Any thought? I hope we can fully discuss it and bring out a proposal to
> > > make it happen asap.
> > >
> > > Cheers,
> > > Jonathan Dong
> > >
> > >
>

[jira] [Created] (WEEX-161) DURATION lost should not throw exception when toast

[codefurture (JIRA)]

codefurture created WEEX-161:


 Summary: DURATION lost should not throw exception when toast
 Key: WEEX-161
 URL: https://issues.apache.org/jira/browse/WEEX-161
 Project: Weex
  Issue Type: Improvement
Reporter: codefurture
Assignee: Adam Feng


DURATION lost should not throw exception when toast



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (WEEX-160) Weex Transition Improvement for high frequency

[codefurture (JIRA)]

codefurture created WEEX-160:


 Summary: Weex Transition Improvement for high frequency 
 Key: WEEX-160
 URL: https://issues.apache.org/jira/browse/WEEX-160
 Project: Weex
  Issue Type: Improvement
Reporter: codefurture
Assignee: Adam Feng


Weex Transition Improvement for high frequency 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (WEEX-159) Weex Support Style Diff when update, exclude un effect layout params,

[codefurture (JIRA)]

codefurture created WEEX-159:


 Summary: Weex Support Style Diff when update, exclude un effect  
layout params,
 Key: WEEX-159
 URL: https://issues.apache.org/jira/browse/WEEX-159
 Project: Weex
  Issue Type: Improvement
Reporter: codefurture
Assignee: Adam Feng


Weex Support Style Diff when update, exclude un effect  layout params,



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Support HIGH-Frequency calls

[谷宝剑(剑白)]

javascriptcore and v8 has poor performance on string  concat.   steven have an 
test, which show use  json combine has amost 5 faster(101ms) then string 
concat(522ms).  for improve g-canvas fps. three steps should be done. 1,use 
json combine  instead of string concat for sending command2,new thread timer, 
maybe c++ timer is better3,support arraybuffer on android platform, avoid 
base64 encoding/decoding, which has  an great performance improvement  on ios 
platform. 
after the three step,   g-canvas fps will be better.

--From:GU 
Baojian Time:2017 Dec 5 (Tue) 15:57To:dev 
Subject:回复：Support HIGH-Frequency calls

yeah， we found the same problem,  a different thread for hight frequency 
message is one soluation.  please join my dingding jianbai.gbj for detail 
discussation
--发件人：SteveYTX 
发送时间：2017年12月5日(星期二) 11:51收件人：dev 
主　题：Support HIGH-Frequency calls
Hi, Weex Dev Team
 I am developing a Canvas component based on Weex called G-Canvas.
 My design lists below:

 First, putting some OpenGL-capable views on the screen;
 Secondly, make a js framework which's APIs are as the same as HTML5
canvas and translate each API to my own protocol. Call it as "Drawing
Command" or "Command" for short.
 Thirdly, pass drawing commands to a local rendering engine, parse each
command and then draw each frame on screen.

 It works, but if the page's complicated, the FPS drops rapidly,
especially on Android. The problem is Weex uses a Looper class for message
management on Android, each message goes from Java to Native, and may go up
in some situations (such as DOM update). This message channel is good
enough for normal calls, but may not efficiently for high-frequency calls.
so, if there are any high-frequency caller in a complicated page (such as a
Canvas, 60 calls/second), race conditions comes out, the Looper's message
queue may be blocked for some time. And iOS has the same problem.

I think there are two ways to fix this:
1. If Multi-Context supported, use separated Looper and JS Thread for
high-frequency calls component.
2. Make a different message channel for high-frequency calls component.
Maybe a  C++ timer and looper, to reduce Looper's pressure.

  Please let me know if you have any opinion. Any reply would be
appreciated. Thanks.


BR,

 Steven Xu

[jira] [Commented] (WEEX-86) Reorganize the structure of documents and website

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16278279#comment-16278279
 ] 

ASF GitHub Bot commented on WEEX-86:


GitHub user boboning opened a pull request:

https://github.com/apache/incubator-weex-site/pull/19

 [WEEX-86][doc] update the docs of the scroller component and navigator 
module, make the description more understandable.

* add some examples to show how use some new attributes and event for 
scroller.
* update the example of the navigator module.
* make the description more understandable for above docs.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/boboning/incubator-weex-site master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-weex-site/pull/19.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #19


commit b549fe9e834b86115e212e3f3ccdc570ab6c09f6
Author: boboning 
Date:   2017-12-05T07:51:25Z

[WEEX-86][doc] update the docs of srcroller component and navigator module.

commit ff5c23b065567cea60a5b434455c02ae30dddc7b
Author: boboning 
Date:   2017-12-05T09:30:40Z

[WEEX-86][doc] add the description of 'scrollstart' and 'scrollend' evnet 
in scroller component, besides，give the example.




> Reorganize the structure of documents and website
> -
>
> Key: WEEX-86
> URL: https://issues.apache.org/jira/browse/WEEX-86
> Project: Weex
>  Issue Type: Improvement
>  Components: Project 
>Reporter: Hanks Zhang
>Assignee: zhengshihan
>
> h1. Weex Document Index
> + contributing.md
> + development-process.md
> + who-is-using-weex.md
> + releasenote.md
> + resources.md
> h2. Guide
> + index.md
> + advanced
>   + app-architecture.md
>   + downgrade.md
>   + page-architecture.md
>   + path.md
>   + use-vuex-and-vue-router.md
> + extend-android.md
> + extend-ios.md
> + extend-js-framework.md
> + extend-web-render.md
> + front-end-frameworks.md
> + integrate-devtool-to-android.md
> + integrate-devtool-to-ios.md
> + integrate-to-your-app.md
> + set-up-env.md
> + using-rax.md
> + using-vue.md
> h2.  References
> + index.md
> + android-apis.md
> + ios-apis.md
> + js-framework-apis.md
> + js-service.md
> + weex-variable.md
> h3. Components
> + a.md
> + cell.md
> + div.md
> + image.md
> + indicator.md
> + input.md
> + list.md
> + loading.md
> + refresh.md
> + scroller.md
> + slider.md
> + switch.md
> + text.md
> + textarea.md
> + video.md
> + waterfall.md
> + web.md
> h3. Modules
> + animation.md
> + clipboard.md
> + dom.md
> + globalevent.md
> + meta.md
> + modal.md
> + navigator.md
> + picker.md
> + storage.md
> + stream.md
> + websocket.md
> + webview.md
> h2. WiKi
> + color-names.md
> + common-events.md
> + common-styles.md
> + css-units.md
> + design-principles.md
> + event-bubble.md
> + faq.md
> + gestures.md
> + index.md
> + platform-difference.md
> + text-styles.md
> h2. Tools
> + helpers.md
> + index.md
> + market.md
> + toolkit.md



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] incubator-weex-site pull request #19: [WEEX-86][doc] update the docs of the ...

[boboning]

GitHub user boboning opened a pull request:

https://github.com/apache/incubator-weex-site/pull/19

 [WEEX-86][doc] update the docs of the scroller component and navigator 
module, make the description more understandable.

* add some examples to show how use some new attributes and event for 
scroller.
* update the example of the navigator module.
* make the description more understandable for above docs.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/boboning/incubator-weex-site master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-weex-site/pull/19.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #19


commit b549fe9e834b86115e212e3f3ccdc570ab6c09f6
Author: boboning 
Date:   2017-12-05T07:51:25Z

[WEEX-86][doc] update the docs of srcroller component and navigator module.

commit ff5c23b065567cea60a5b434455c02ae30dddc7b
Author: boboning 
Date:   2017-12-05T09:30:40Z

[WEEX-86][doc] add the description of 'scrollstart' and 'scrollend' evnet 
in scroller component, besides，give the example.




---