I was looking at the presentation from Eric Burke about the work square did with Android which resulted in a really nice UI. He tells about quite a few struggles they had with the Android API which seem to be pretty easy to get around in LWUIT.
Anyway, one of the nicest things they did was the screenshot on the right which features a leather texture with stitches as the UI for the application which is a really nice touch for a wallet application (assuming you aren't a vegan).
Anyway, that took me back a bit... How do you make a UI like that regardless of the platform that will look nice for all resolutions. I came up with the answer but because I suck at Photoshop I wasn't able to achieve anything remotely close to the image on the right... This just goes to show you how valuable professional design can be to a team.
The way to produce an image like that is start with a clean tileable leather texture such as this one which I got from here and scaled down:
I set this as the style of the Form UIID and made it TILE on both axis's. Then I created a simple transparent gradient image, its so transparent you might not even see it but its very important to create the texturized depth to the image above:
I created a container and placed it above the form and gave it a style of Gradient, then I set this image as the scaled background (since this is an alpha mask scaling won't hurt the image quality much).
Last I created a stitch image by using a stitch brush tool I found on the internet and this is the stitch image I was able to make (I set the background to red since the image is barely visible otherwise):
I set the stitches as a 9-piece border which allowed them to grow nicely. However, due to the bad source material the end result doesn't look nearly as polished as the work the guys from square were able to achieve. I'm guessing they have a depression overlay with the stitch layer to create an additional effect and their images are obviously more refined. This is what I ended up with in the resource editor:
Monday, December 12, 2011
Sunday, December 4, 2011
Using EmbeddedContainer
EmbeddedContainer is a class I added to LWUIT 1.5 without much fanfare out of a simple necessity, the problem is that this necessity existed only within the GUI builder and the class makes no sense outside of the context of the GUI builder. How do you document something like that???
The necessity came about due to Triplay's application designs (our original GUI builder beta site), their design was iPhone inspired and so it relied on tabs (iPhone style tabs at the bottom of the screen) where different features of the application are within a different tab.
This didn't mesh well with the LWUIT GUI builder navigation logic and so we needed to rethink some of it. I wanted to reuse GUI as much as possible while still enjoying the advantage of navigation being completely managed for me.
Android does this with Activities and the iPhone itself has a view controller, I don't like both approaches and think they both suck. The problem is that you have what is effectively two incompatible hierarchies to mix and match which is why Android needed to "invent" fragments and Apple can't mix view controllers within a single application.
The Component/Container hierarchy is powerful enough to represent such a UI but we needed a "marker" to indicate to the UIBuilder where a "root" component exists so navigation occurs only within the given "root". Here EmbeddedContainer comes into play, its a simple container that can only contain another GUI from the GUI builder. Nothing else. So we can place it in any form of UI and effectively have the UI change appropriately and navigation would default to "sensible values".
Navigation replaces the content of the embedded container, it finds the embedded container based on the component that broadcast the event. If you want to navigate manually just use the showContainer() method which accepts a component, you can give any component that is under the EmbeddedContainer you want to replace and LWUIT will be smart enough to replace only that component.
You can see an example of building a simple Tab based UI with the GUI builder and embedded container in the video above. The nice part about this is that this UI can be very easily refactored to provide a more traditional form based UI without duplicating effort and can be easily adapted to a more tablet oriented UI (with a side bar) again without much effort.
The necessity came about due to Triplay's application designs (our original GUI builder beta site), their design was iPhone inspired and so it relied on tabs (iPhone style tabs at the bottom of the screen) where different features of the application are within a different tab.
This didn't mesh well with the LWUIT GUI builder navigation logic and so we needed to rethink some of it. I wanted to reuse GUI as much as possible while still enjoying the advantage of navigation being completely managed for me.
Android does this with Activities and the iPhone itself has a view controller, I don't like both approaches and think they both suck. The problem is that you have what is effectively two incompatible hierarchies to mix and match which is why Android needed to "invent" fragments and Apple can't mix view controllers within a single application.
The Component/Container hierarchy is powerful enough to represent such a UI but we needed a "marker" to indicate to the UIBuilder where a "root" component exists so navigation occurs only within the given "root". Here EmbeddedContainer comes into play, its a simple container that can only contain another GUI from the GUI builder. Nothing else. So we can place it in any form of UI and effectively have the UI change appropriately and navigation would default to "sensible values".
Navigation replaces the content of the embedded container, it finds the embedded container based on the component that broadcast the event. If you want to navigate manually just use the showContainer() method which accepts a component, you can give any component that is under the EmbeddedContainer you want to replace and LWUIT will be smart enough to replace only that component.
You can see an example of building a simple Tab based UI with the GUI builder and embedded container in the video above. The nice part about this is that this UI can be very easily refactored to provide a more traditional form based UI without duplicating effort and can be easily adapted to a more tablet oriented UI (with a side bar) again without much effort.
Subscribe to:
Posts (Atom)