PDA

View Full Version : Best practices for event driven coding.



milton9480
11 May 2012, 10:04 AM
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!

mitchellsimoens
14 May 2012, 5:48 AM
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.

milton9480
14 May 2012, 7:21 AM
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

milton9480
23 May 2012, 12:11 PM
Hey guys, some time has past since the last post. Any news/hint regarding the issue ?

Thanks in advance,
Milton.

SebasSP
23 May 2012, 1:27 PM
Can it be a PhoneGap issue? Does it run different when you use "sencha app build production" and run it from the browser?

milton9480
23 May 2012, 3:48 PM
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.