1. #1
    Sencha User
    Join Date
    Nov 2009
    Location
    Uruguay
    Posts
    49
    Vote Rating
    1
    milton9480 is on a distinguished road

      0  

    Default Best practices for event driven coding.

    Best practices for event driven coding.


    Hi guys!
    I've an application in ST1, recently migrated to ST2. I can make it work just in a browser. When I try to deploy in a mobile, the mobile memory explode. I don't know the reason for that, and I'm doing some research.
    I've left only the home page in the app, and I was able to see the page working in the mobile, but is a bit slower than the full application in ST1.
    Now, the question: As dispatchers are no longer the way to send messages to controllers, I've replaced it for events. I fire all the events at application level (MyApp.app.fireEvent('myevent', params)).
    I'd like to know about best practices for event driven coding, mainly, if fire events at application level, impacts in the application performance.


    Thanks for your time!

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    37,541
    Vote Rating
    872
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    It shouldn't affect performance, performance more gets noticed from how the DOM is and the CSS.

    I would fire events on the view instead of the application though.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  3. #3
    Sencha User
    Join Date
    Nov 2009
    Location
    Uruguay
    Posts
    49
    Vote Rating
    1
    milton9480 is on a distinguished road

      0  

    Default


    Great Mitchel, tks for the response. So, events shouldn't be an issue in performance, that's good and bad at the same time
    Regarding CSS:
    I've updated my custom styles, given that in some cases, ST2 creates different dom, and use different style names. Anyway, I've removed the inclusion of my custom styles, and application performance remains poor.


    Regarding DOM:
    In my ST1 application, I was very careful with dom elements. I've created my own tabview component that implements a stack to retain controller/action string, and action parameters. When tab fires cardswitch event, the component place the new view, and removes the old one from dom. When the user press back button, application takes the controller/action and parameters from the stack, and place the previews view. These behavior was transparent for the user, and keeps the dom elements very clean, making application runs well.
    Now, in ST2, I've replaced my own tabview, by the new navigation bar. I know that old views remains there, and views are removed only when the user press back, but I guess that this behavior takes care of the dom elements as well.


    Deployment process:
    I was reviewing the deployment process, and I've tried with different approaches. I've used the "sencha app build native" command line, and I got an app.js file with almost 500k, is that ok ?
    In the process, I've noticed things like:
    * I need to include all js files in requires arrays in order to give the sdk tool to get the full dependency chain, so, there is no chance to get js files loaded dynamically.
    * Is almost mandatory to have one file per class (rather than recomendable). I had a js file with extended components, and I had to separate it in different files because was unreachable after concatenate and minify.


    So.. now, I think that the performance issues are in other things rather than DOM and CSS, and this may be in the deployment process, or something else. BTW, my application runs wrapped in PhoneGap, given that I need to access to gps.


    Any hint or help will be very helpful Mitchel!


    Thanks,
    Milton

  4. #4
    Sencha User
    Join Date
    Nov 2009
    Location
    Uruguay
    Posts
    49
    Vote Rating
    1
    milton9480 is on a distinguished road

      0  

    Default Any news on that?

    Any news on that?


    Hey guys, some time has past since the last post. Any news/hint regarding the issue ?

    Thanks in advance,
    Milton.

  5. #5
    Sencha User
    Join Date
    Mar 2012
    Location
    The Netherlands
    Posts
    75
    Vote Rating
    4
    SebasSP is on a distinguished road

      0  

    Default


    Can it be a PhoneGap issue? Does it run different when you use "sencha app build production" and run it from the browser?

  6. #6
    Sencha User
    Join Date
    Nov 2009
    Location
    Uruguay
    Posts
    49
    Vote Rating
    1
    milton9480 is on a distinguished road

      0  

    Default


    Quote Originally Posted by SebasSP View Post
    Can it be a PhoneGap issue? Does it run different when you use "sencha app build production" and run it from the browser?

    I'm using same version of phonegap in both (1.3), the performance is quite different in ST1 and ST2.
    I've used both deployment approaches and also a mix of that.


    1.- Using ST build with ST wrapper.
    2.- Using ST build to minimize the app.js and then use the app.js in another project structure.
    3.- Using the old build way (many files in ST sdk folder may cause the preformance issue).


    Any of those approaches result in an application with a very poor performance.
    BTW, I had to increase the load timeout, given that the default value results in timeout of index.html request.


    I really want to know if there is a hint of performance issue with ST. I haven't found anything about performance issues, and I think that could be something wrong in the components that we select to perform the migration.

Thread Participants: 2