I have an app which has quite a lot of activities, and all of the activities' layout have lots of views (TextViews, to display different kind of data in different styles, ImageViews etc).
When the activities load, they take too much time to load the layout/UI (more than a second).
Ques: Is there a way to reduce the time it takes to load the activity, because the activity takes too long to load the UI?
A short description of what I have:
All the layouts have at least 30-35 views
I am using Relative Layout
I am not nesting layouts, most of the views are parallel to each other, and the overdraw is at max 2x
All of the text views are custom, setting a custom font for them
The UI is being loaded in onCreate() of the activity
I am thinking of doing either of the following things:
Converting the app into Fragments in a way there are less number of activities, and more number of fragments. For example, there is one Home Activity which loads the first fragment, and further interactions with the app keep loading/switching between fragments for different purposes via Fragment Transactions. I would spawn a new activity only when I am hitting a limitation of Fragments.
Will it help improve the speed?
Disintegrate the UI in a way were the most basic UI is loaded in the view once the activity starts, and all the other UI elements are inflated in a background thread (AsyncTask) and are then added to the root of the current view.
In different opinions, which approach would be better?
Is there a better or standard way of solving this problem?
Appreciating all the inputs. Thanks in advance!
Here are some more suggestions to what you've already going to do.
If you inject views in onCreate() method, make sure you use design-time injection frameworks (Bufferknife or AndroidAnnotations) and not runtime ones (Guice, RoboGuice). Runtime frameworks definitely slow startup time down.
If you have views, which are not visible to the user initially, you can use ViewStub and load them on demand.
I'm in the concept phase of a Mac application that should let the user easily select and layout images for printing. It's a document-based app and a document can have multiple pages with lots of pictures in different sizes and rotations on it. The UI would kind of be like the UI of Pages.app.
Those pictures can possibly be large hi-res images. The user should also be able to print them in the best quality that the images offer.
I have re-watched some WWDC sessions about Quartz, 2D drawing optimization and NSView.
I know that there are a few different ways of accomplishing what I want to do, namely:
Use a custom view for a "page" and draw the images in drawRect: with Core Graphics/Quartz. Use CG transforms to rotate and scale images.
Also use a custom view for a "page", but use NSImageView-subviews to display the images. Use Core Animation and layer transforms to scale/rotate images.
What is the best practice for this? Drawing with Core Graphics or using NSViews? Why?
Thank you so much!
Johannes
Depends on how interactive these pages should be. If there is a lot of mouse interaction, e.g. dragging, selecting etc. I'd go with views. If you want fluid animations I'd even use plain CALayers with their content set to one image. This would also let you zPosition the images in case they overlap. A view based solution makes z-ordering hard.
The drawRect method should be fastest but you have hard times integrating user interaction and you must z-order manually.
This is a reply I got from opening one of my two Apple Technical Support Incidents:
Hi Johannes,
Thanks for contacting Apple DTS regarding your question about printing
and the different ways to construct your applications general UI (with
views).
There is a trend toward using layer-backed views in OS X (utilizing
Core Animation layers) which is motivated by the ability to easily
animate your application's user interface, with little work, when
needed. However in terms of printing, you would be better off to
implement drawRect for custom views so that the view contents can be
drawn at "full resolution" when rendered into the context for
printing.
If instead you use layer backed views at as those layers to
"renderInContext" the layer contents would be used to render, which
commonly will not be set to the full resolution of your source
documents/images. This is because layer backed views take additional
memory to store those bitmaps (cached layer contents), and because of
that, they are recommended to be sized appropriately for the screen
(which may not necessarily be sized appropriately for the printed
page).
Does this help guide your application architecture? Please let me
know.
So basically this means that using layer-backed views might result in sub-optimal printing quality. I've replied with some follow-up questions ("How setting wantsLayer = NO on the rootView right before printing help?") and will post the answers as soon as I get them.
All three approaches should work. Since you should be using scaled-down representations of large images anyway, I don't think there will be much difference. Do what you feel most comfortable doing.
My guess is just using layer-backed NSViews (one par draggable image) will probably work best for starters. If you find performance lacking, you can always micro-optimize. Note that you may have to make your views a tad larger than the images so you can draw the selection handles outside them.
This is all assuming that you will never want to do a more complex drawing.
I'm creating a library of UI elements, and I want the graphics to be custom. At first, I was going to draw everything with code, and take properties such as "background-base-color", "background-gradient-color", etc. I was concerned that the user would need to modify too many properties and might get confused. I eventually talked myself into using external graphics, such as button_top_left_over.png and etc. Now I'm back and forth. I want people to easily be able to change the skin, so my options are, have them create external graphic libraries, or have them update properties in a front end that would write to XML, such as background-base-color, background-base-highlight,etc. Anyone have experience with this, and can offer advise?
You may "guess" gradients by a given single color, and it should fit in the most of the cases. Here is an algorithm: ColorUtil.as
Customizing components is a common problem. The user shouldn't need to step that deep into the implementation but we sill want a maximum of flexibility. For that, I have created a CSS framework: Jakute Styling Engine. Using Jakute you may set up your component using states.
Instead of declaring tons of properties for each state:
Button top_left_over: red.png
Button top_left_down: blue.png
Button top_left_disabled_over: grey.png
With Jakute you may specify stateful rules:
Button:over top_left: red.png
Button:down top_left: blue.png
Button:disabled:over top_left: blue.png
In this case the user only needs to know the list of button states and the single property "top_left". The styles can be loaded from an external style sheet or directly set to the component.
Finally, here is an example that shows you how to create a stateful styleable component: States Example. Even if you are not plan to incorporate Jakute, you might get an idea of how others create such components. :-)
I have a DSL containing two main domain classes: Area and Entity. Areas are represented visually by a GeometryShape, whereas entities are represented by a CompartmentShape. Entities can be embedded in an Area, or not (in this case they are embedded in the root object, which is a kind of Area). There may be relationships between entities, including between entities in different areas. Areas cannot be embedded inside of other areas, nor entities embedded inside of other entities.
My problem is that I cannot get the behavior I want from the diagram. The embedding of entities in areas works perfectly well at the model level, but the visual representation behaves erratically. For example, if I drag an entity that was created in an area outside of that area, it no longer responds to mouse clicks (I have code that performs the re-parenting, but somehow the diagram side of things is broken).
I have searched high and low for samples of how to do this, and come up empty. Every example I've found on the web simulates nesting via "references" relationships, whereas I am performing true embedding of the domain classes (and therefore of their associated shape classes).
Does anyone have an example of how to do this?
While I'm venting, am I the only one who thinks the diagram/shape classes are massively under-documented?
I believe there's an example of this in Domain-Specific Development with Visual Studio DSL Tools. Also, you might want to ask on the Visual Studio Extensibility forum.
Is there some standard way to make my applications skinnable?
By "skinnable" I mean the ability of the application to support multiple skins.
I am not targeting any particular platform here. Just want to know if there are any general guidelines for making applications skinnable.
It looks like skinning web applications is relatively easy. What about desktop applications?
Skins are just Yet Another Level Of Abstraction (YALOA!).
If you read up on the MVC design pattern then you'll understand many of the principles needed.
The presentation layer (or skin) only has to do a few things:
Show the interface
When certain actions are taken (clicking, entering text in a box, etc) then it triggers actions
It has to receive notices from the model and controller when it needs to change
In a normal program this abstraction is done by having code which connects the text boxes to the methods and objects they are related to, and having code which changes the display based on the program commands.
If you want to add skinning you need to take that ability and make it so that can be done without compiling the code again.
Check out, for instance, XUL and see how it's done there. You'll find a lot of skinning projects use XML to describe the various 'faces' of the skin (it playing music, or organizing the library for an MP3 player skin), and then where each control is located and what data and methods it should be attached to in the program.
It can seem hard until you do it, then you realize it's just like any other level of abstraction you've dealt with before (from a program with gotos, to control structures, to functions, to structures, to classes and objects, to JIT compilers, etc).
The initial learning curve isn't trivial, but do a few projects and you'll find it's not hard.
-Adam
Keep all your styles in a separate CSS file(s)
Stay away from any inline styling
It really depends on how "skinnable" you want your apps to be. Letting the user configure colors and images is going to be a lot easier than letting them hide/remove components or even write their own components.
For most cases, you can probably get away with writing some kind of Resource Provider that serves up colors and images instead of hardcoding them in your source file. So, this:
Color backgroundColor = Color.BLUE;
Would become something like:
Color backgroundColor = ResourceManager.getColor("form.background");
Then, all you have to do is change the mappings in your ResourceManager class and all clients will be consistent. If you want to do this in real-time, changing any of the ResourceManager's mappings will probably send out an event to its clients and notify them that something has changed. Then the clients can redraw their components if they want to.
Implementation varies by platform, but here are a few general cross-platform considerations:
It is good to have an established overall layout into which visual elements can be "plugged." It's harder (but still possible) to support completely different general layouts through skinning.
Develop a well-documented naming convention for the assets (images, HTML fragments, etc.) that comprise a skin.
Design a clean way to "discover" existing skins and add new ones. For example: Winamp uses a ZIP file format to store all the images for its skins. All the skin files reside in a well-known folder off the application folder.
Be aware of scaling issues. Not everyone uses the same screen resolution.
Are you going to allow third-party skin development? This will affect your design.
Architecturally, the Model-View-Controller pattern lends itself to skinning.
These are just a few things to be aware of. Your implementation will vary between web and fat client, and by your feature requirements. HTH.
The basic principle is that used by CSS in web pages.
Rather than ever specifying the formatting (colour / font / layout[to some extent]) of your content, you simply describe what kind of content it is.
To give a web example, in the content for a blog page you might mark different sections as being an:
Title
Blog Entry
Archive Pane
etc.
The Entry might be made of severl subsections such as "heading", "body" and "timestamp".
Then, elsewhere you have a stylesheet which specifies all the properties of each kind of element, size, alignment, colour, background, font etc. When rendering the page or srawing / initialising the componatns in your UI you always consult the current stylesheet to look up these properties.
Then, skinning, and indeed editing your design, becomes MUCH easier. You simple create a different stylesheet and tweak the values to your heat's content.
Edit:
One key point to remember is the distinction between a general style (like classes in CSS) and a specific style (like ID's in CSS). You want to be able to uniquely identify some items in your layout, such as the heading, as being a single identifiable item that you can apply a unique style to, whereas other items (such as an entry in a blog, or a field in a database view) will all want to have the same style.
It's different for each platform/technology.
For WPF, take a look at what Josh Smith calls structural skinning: http://www.codeproject.com/KB/WPF/podder2.aspx
This should be relatively easy, follow these steps:
Strip out all styling for your entire web application or website
Use css to change the way your app looks.
For more information visit css zen garden for ideas.
You shouldn't. Or at least you should ask yourself if it's really the right decision.
Skinning breaks the UI design guidelines. It "jars" the user because your skinned app operates and looks totally different from all the other apps their using. Things like command shortcut keys won't be consistent and they'll lose productivity. It will be less handicapped accessible because screen readers will have a harder time understanding it.
There are a ton of reasons NOT to skin. If you just want to make your application visually distinct, that's a poor reason in my opinion. You will make your app harder to use and less likely that people will ever go beyond the trial period.
Having said all that, there are some classes of apps where skinning is basically expected, such as media players and imersive full screen games. But if your app isn't in a class where skinning is largely mandated, I would seriously consider finding other ways to make your app better than your competition.
Depending on how deep you wish to dig, you can opt to use a 'formatting' framework (e.g. Java's PLAF, the web's CSS), or an entirely decoupled multiple tier architecture.
If you want to define a pluggable skin, you need to consider that from the very beginning. The presentation layer knows nothing about the business logic but it's API and vice versa.
It seems most of the people here refer to CSS, as if its the only skinning option.
Windows Media Player (and Winamp, AFAIR) use XML as well as images (if neccesary) to define a skin.
The XML references hooks, events, etc. and handles how things look and react. I'm not sure about how they handle the back end, but loading a given skin is really as simply as locating the appropriate XML file, loading the images then placing them where they need to go.
XML also gives you far more control over what you can do (i.e. create new components, change component sizes, etc.).
XML combined with CSS could give wonderful results for a skinning engine of a desktop or web application.