Lately I have been building a mobile phone application using Sproutcore20 and now Ember.JS.
This works great on my iPhone (3GS) though it stutters on many android devices.
The simplest thing, like switching from main menu item, and thus loading in a different view feels all but native.
Currently it makes use of template views which are appended and removed in a statechart. Each main menu item has a main state in which the corresponding views are appended (and removed on exit).
This method seems optimal to me but it does not function optimal, so I am wondering if an alternative approach like appending all views on load (deferred) and visibility toggling would improve performance (1)? It would make the DOM larger and thus operations on the DOM slower.
What is an optimal Ember.js code structure for building a mobile application, and what considerations need to be taken into account when building for mobile devices(2)?
It really depends on your application. In general, limiting the number of DOM elements and the number of DOM changes helps performance. Deciding whether to leave elements in the DOM and hide/show them, or to create/destroy elements on demand depends on the usage patterns of the app. If you expect the user to move quickly back and forth between views, hide/show can make sense.
Related
this question could be a duplicate but I have a specific use case.
The app is a single page Django app. The user can choose from several options in a drop-down box. Depending on the choice, a few input boxes will need to be rendered. As an example, if the user chooses to order a pizza, the options in another drop-down menu should be related to the toppings whereas an order for drinks should provide options related to the type or brands. The resulting number of input boxes could be 5 with one option or 10 with a different option.
I can think of rendering the page using JS or by using Python in the back-end. Because this app will be a commercial one, I do not need SEO as users need to log into the app first. I also want to minimize the amount of code that a competitor can 're-use' from my work.
Will client-side rendering open up security problems? If not, is client-side the better way to go?
This question is more of a theoretical/opinion-based nature than technical, but let me provide some answers.
Will client-side rendering open up security problems?
Generally, web application security is a server-side concern, not client-side. You can do things like input validation on the client-side, but the minimum practice for security is to sanitize, validate, and authenticate all request data anyway, so the client-side checks are more of for convenience and improved user experience than security. I'm not saying that there are no such things as client-side security concerns, but it's something I don't think is generally a cause of worry. Client-side rendering specifically and especially doesn't sound like something to be careful about: regardless of what your client-side code does, whatever <form> and <input> markup it generates, your server-side code should always handle the submitted data as if it could be malicious.
Is client-side the better way to go?
There are so many more factors to consider in order to answer this, so it's largely a matter of opinion. But since you're asking about Django, then you might want to reduce overall development friction by maximizing Django's features and design—and Django, in my view, is largely a static markup-first framework, meaning minimal use (at first, at least) of client-side JavaScript. Django Forms and Class-Based Views (CBV), for example, work well together to allow rapid development of non-single-page applications.
Your specific use case of an initial drop-down choice determining the main form to be presented could be developed very rapidly in the traditional Django way by giving up your single-page-application requirement, and just providing some initial menu page that will lead to the different views and forms (pizza vs. drinks, etc.), the latter of which you could build rapidly with the help of CBVs. (By the way, your specific use case doesn't seem too unique, actually. It's just the fundamental issue of complexity for which we have programming concepts such as polymorphism and inheritance in object-oriented programming—hence the appropriateness of CBVs.)
I know that single-page applications are nice, and is the fashionable thing nowadays, but I think people underestimate the speed of old-fashioned HTML applications. And by speed I mean not just the user's client-side experience (HTML pages load rather rapidly with HTTP2 and CDNs and all the other modern Web infrastructure tech these days), but also development time.
Besides, you can always just add single-page-like experiences in a progressive manner. Django is particularly suited to an agile-style development strategy where you'd build initial functionality rapidly without much client-side JS, and then just add rich client-side experiences (using React or Vue or something similar) where it will add the most value for users.
I also want to minimize the amount of code that a competitor can 're-use' from my work.
I don't know the full context, but generally I wouldn't worry about this. If you won't do much client-side rendering, then there won't be much client-side code to ‘steal’. But even if you do, unless you specifically write your client-side code in a way that maximizes reusability (either for yourself or for others), I think coders tend anyway to write highly-coupled code, which is to say, your client-side code will tend to be highly dependent on your server-side code's specifics, which means poor reusability. Your competitors could copy your client-side code all they want, but the cost of making it work with their own back-end will be so high that it wouldn't be worth it, they'll just want to write their own.
I'm using Ember JS 2.3.0, Ember Data 2.3.3 and jQuery 2.1.4 and I'm having an issue when trying to transition away from a page with a HTML table component on it. The table component is populated with data from this Ember Data call:
this.store.query('log', {filter: {
created_at_from: moment().subtract(1, 'month').format('DD/MM/YYYY'),
created_at_to: moment().format('DD/MM/YYYY'),
object: 'IsoApplication'
}})
which having looked in the developer tools "Timeline" and "Network" tabs is resolving in good time. It has no special jQuery events etc attached to it and is simply a plain HTML table made dynamic with Ember.
However, when clicking a "link-to" helper that transitions away from the page with the component on it there is a huge 10 second delay before the destination page renders. During this time nothing seems to happen and having used the developer tools "Timeline" and drilled down it seems that the delay occurs when the "removeFromListeners" function is being called (see attached timeline screenshot). No asynchronous stuff is happening at this point and therefore no loader appears but it seems that tearing down the table is the problem because if I remove the table component from the template the issue disappears. Without the table component the page transitions almost instantly.
I have attached the timeline screenshot to see if anyone can help to pinpoint the possible cause of this problem.
Any suggestions would be welcome.
Thanks.
Ok, after significantly reducing the number of rows in my table I discovered that the issue went away. #runspired provided a detailed and very helpful description of why my issue occurred, which I have posted below to inform others who may have similar issues:
there's a number of things going on here
I've given a few talks on this (including two podcasts on Ember Weekend (episodes 38 and 39))
I wish I had my chicago-ember talk on it recorded but I don't
but basically, comes down to three things as to why this is slow
and none of it is actually because "dom is slow", that argument masks the truth of the matter
1.) don't render the universe, render the scene
easiest analogy is take any video game you can think of, especially one in which you can "pivot" the camera view quickly
that pivot is a lot like scroll
you really only want to render what's visible at the moment, and prepare content that's closer to the camera's view
but it makes no sense to prepare content that's far out of view
this is a lesson that every native SDK and game SDK has baked in, but which no JS framework has yet realized
when people say DOM is slow, it's really because they are trying to render far more things than they ought to
2.) is a bug in most browsers
memory allocated for DOM is always retained by the tab that allocated it
this allocation persists beyond the lifecycle of your page
it's a true leak that hopefully Chrome etc. will fix soon
or basically, the allocation heap size made for DOM can only ever grow
you can reuse allocated memory, but you can't shrink it
this means that if you generate a huge amount of DOM nodes, even once you tear them down there's a high memory overhead for that tab
which causes performance issues in other areas because less memory is available for JS allocations etc.
this problem is bigger on mobile, especially android, than on desktop. But it can affect desktop too.
Something going hand in hand with 1 and 2
is there's a definite limit to how many DOM nodes you can render before the browser starts chugging
I've found that limit to be roughly 40k DOM nodes, varies from as low as 20k on older android devices to > 100k on Safari
but 40k seems to be a limit which if held to as a target works well for all platforms
if you have 700-2000 table rows, and each row has maybe 3 TDs, and each TD has just one link or span or other element, and then in that you have some text
6,300 - 18,000 nodes
or basically, you're dealing with half of your max budget with that setup
just as the content of the rows
so 7002 - 20,002 nodes counting the rows
and it's likely that 9 nodes per row is a very low estimate
if we double that
you're exceeding that max
and 18 nodes sounds more likely
3.) GC events stop the world
[9:28]
even though the memory allocated by the tab is retained
the allocation IS cleaned up
(so it can be reused for more DOM later)(edited)
so you're releasing the memory for at LEAST your max DOM size (likely larger) all at once
that's a lot for the browser to clean up on
it's also likely a lot of arrays and array observers are being torn down in this time.
#runspired is also the author of
https://github.com/runspired/smoke-and-mirrors which is a project that:
focuses on improving initial and re-render performance in high-stress situations by providing components and primitives for performant lists and svelte renders to match a core belief: Don't render the universe, render the scene.
I have a Windows Phone 7 app that (currently) calls an OData service to get data, and throws the data into a listbox. It is horribly slow right now. The first thing I can think of is because OData returns way more data than I actually need.
What are some suggestions/best practices for speeding up the fetching of data in a Windows Phone 7 app? Anything I could be doing in the app to speed up the retrieval of data and putting into in front of the user faster?
Sounds like you've already got some clues about what to chase.
Some basic things I'd try are:
Make your HTTP requests as small as possible - if possible, only fetch the entities and fields you absolutely need.
Consider using multiple HTTP requests to fetch the data incrementally instead of fetching everything in one go (this can, of course, actually make the app slower, but generally makes the app feel faster)
For large text transfers, make sure that the content is being zipped for transfer (this should happen at the HTTP level)
Be careful that the XAML rendering the data isn't too bloated - large XAML structure repeated in a list can cause slowness.
When optimising, never assume you know where the speed problem is - always measure first!
Be careful when inserting images into a list - the MS MarketPlace app often seems to stutter on my phone - and I think this is caused by the image fetch and render process.
In addition to Stuart's great list, also consider the format of the data that's sent.
Check out this blog post by Rob Tiffany. It discusses performance based on data formats. It was written specifically with WCF in mind but the points still apply.
As an extension to the Stuart's list:
In fact there are 3 areas - communication, parsing, UI. Measure them separately:
Do just the communication with the processing switched off.
Measure parsing of fixed ODATA-formatted string.
Whether you believe or not it can be also the UI.
For example a bad usage of ProgressBar can result in dramatical decrease of the processing speed. (In general you should not use any UI animations as explained here.)
Also, make sure that the UI processing does not block the data communication.
At my company we develop prefabricated web applications. While our applications work as-is in many cases, often we receive complex customization requests. We are having a problem in trying to perform this in a structured way. Generic functionality should not be influenced by customizations. At the moment we are looking into Spring Web Flow and it looks like it can handle a part of what we need.
For example, we have an Online Shopping and we have a request from a client that in a moment of checking out the Shopping Basket order has to be written to a proprietary logging system.
With SWF, it is possible to inherit our Generic Checkout Flow with ClientX Checkout Flow and to extend it with states necessary to perform a custom log write. This scenario seems to be handled well. This means we can keep our Generic Checkout Flow as is and extend it with custom functionality, according to Open/Closed principle. Our team in time can add functionality to the Generic Checkout Flow and this can be distributed to a client without modifying the extension.
However, sometimes clients request our pages to be customized. For example, in our Online Shopping app a client requests a multiple currencies feature. In this case, you need to modify the View as well as the Flow (Controller). Is there a technology that would let me extend the Generic View and not modify it? So far, only two solutions with majority of template-based views (JSP, Struts, Velocity etc.) seems to be
to have a specific version of view for each client. This obviously leads to implementation explosion
to make application configurable depending on parameter (if multipleCurrency then) that leads to code explosion - a number of configuration conditions that have to be checked in each page
What would be the best solution in this case? There are probably some other customization cases I am not able to recall. Is there maybe a component based view technology that would let me extend certain base view and does that makes sense.
What are typical solutions to a problem of configurable web applications?
each customization point implies some level of conditionality.
Where possible folks tend to use style sheets to control some aspects. For example display of a currency selector perhaps could be done like that.
Another thought for that currency example: 1 is the limiting case of many. So the model provides the list of currencies. The view displays a selector if there are many, and a fixed field if only one. Quite well-defined behaviour - easy to test reusable for other scenarios.
Why should I choose to use one instead of the other and in which cases?
I mainly focus on desktop applications and personally speaking I do find the humble dialog box more easy and natural to use.
In MVC, you would still use your "humble" dialog. Except all the business logic for it would be farmed off to another class somewhere else.
http://en.wikipedia.org/wiki/Model-view-controller
You need to weight up whether the investment in MVC will be worth it - especially if you're only working with a single simple dialog.
One of the best discussions I've found regarding the advantages and disadvantages of the model view controller/presenter patterns was written by Martin Fowler: http://martinfowler.com/eaaDev/uiArchs.html
In short, by choosing to use a MVC variant you are increasing the testability of your view (dialog). Keeping all of your logic in your dialog class on the other hand, can be fine if you do not expect that dialog to be very complex, however as the complexity increases, the benefit of testable code increases.
It really is a judgement call.
"Humble" dialogs themselves are already MVC. You have:
M, The content of the dialog's message.
V, The window and widgets the user can see.
C, How the dialog is displayed and how it responds to user activity.
Your GUI framework or wrapper library can provide MVC for you seamlessly without you having to think about it, but it's still MVC.
There is no simple answer.
You should use whatever will make your life easier.
If dialog is really simple, and you know for sure it is going to stay that way, go with humble dialog.
If you have something more complex, like multiple view presentations of the same data, or you know your simple dialog will become more complex over time, then, by all means, use MVC.
You can also take a look ant MVP pattern as an alternative to MVC.