Tags

, , , ,

Last month I wrote a post on LinkedIn about about a Proposed Model For Dynamic UI in Standalone Apps. I am continuously working on this and this has been a major research for me for couple of years.

We are living in a web centered world, all development tools providers focus on delivering their tools based on a web based stack. Think now we have built an app with dynamic user interface where UI is generated from a script pulled from a server and initially users of our app, what they see is a delay on launch of the app or, a ring something similar to this

But you know this is the same thing we get in browsers, so there seems no actual difference between our app and a browser based app, both loads a webpage and its obvious. Still we know the computations are native in app and only UI logic is coming from sever but the users of the app won’t get satisfied on this behavior.

We can overcome this issue by caching. Caching has been a great methodology for a while now. So the idea, simply is, we store previous UI we got from the server and load it on first launch of the app and if there is a new UI script available, lazy load it.

Why lazy load here?

The idea of Lazy load is, it delays the loading of resources in web related (mainly images in websites). And those images, or resources out of view port wont load until user scrolls there. In this way, we can render the cached UI and on scroll down or any kind of UI invocation, we can give a quick response to user with the new UI. Even we can use on touch event of screen. Again we have to make sure, we are not loading the entire new UI script here, instead we load the necessary part to render the initial view.

s4-flat

Where does the cached script goes?

This is a great question, we have several types of memories in our devices, from internal memories to cloud storage. But for the scenario and for the quick load time, we have to choose “App in memory”. All platforms support this memory and this is very quick to retrieve data. But this has a limitation on loading long scripts, and that’s why again we need to employ lazy load methodology here. If the cached code is way bigger, developers can consider compressing it, but think about compression and decompression time and do compression only if necessary.

That’s all I would like to share with you guys, regarding the caching. Hope to meet you soon with another post on this subject. Its about seeking the best data structure.. (for what??)

Stay thirsty.. Happy coding 🙂

Advertisements