I was asked by a client to make a "skinnable" app and I don't really know what that means.
I googled like crazy and I didn't found a clear answer or an example.
If anyone has a clue about this, any tip would be appreciated.
Thanks.
Generally this means the app will allow the user to choose different looks for the UI, each of which will have a different color scheme, feel, etc.
What I actually did with my project. I decided to use multiple storyboards to give me greater control over the entire UI and UX of each theme. I programmatically link them all together via a master storyboard that links them all together. That's what I did, and it works very very well. Performance is great, while still maintaining high level of fine grain control over each theme. You can even keep your Header and Implementation files the same for individual view controllers, just so as you keep the names the same on the storyboard.
So for instance, one of my apps that I'm working on called Jam-mout (A music player) has multiple high quality themes. (Image attached). Each theme has it's own storyboard.
For iPhone apps, where the majority of the GUI design is provided by the operating system, you could do it by setting custom Navigation bar background images, custom button graphics, and different fonts/sizes/weights and whitespace. Make sure you're working with a designer who's familiar with the iPhone GUI (if you're not working closely with a designer this is going to be a nightmare).
I recently put together an app for a client who wanted a heavily customised GUI: http://itunes.apple.com/us/app/gogoparis/id428497937?mt=8. A 'skinnable' app would have several sets like this, so the user could choose between several different overall styles. (I hope your client has an enormous design budget!)
my post here should help you get started:
What is the recommended method of styling an iOS app?
if you need live theme changes, each theme in this example could post notifications when the user selects another theme (or skin) - then you can update either the theme instance itself.
alternatively, you can create identifiers for themes which are mapped (NSCFDictionary) to a central theme factory. an example identifier for a specific view for use with the theme factory could be a string MONImageSelectorTableCellThemeIdentifier.
an example manager/factory which handles all theme loading and vends references to themes:
#interface MONThemeManager : NSObject
//...
- (MONTheme *)themeForCurrentlySelectedSkinForViewWithIdentifier:(NSString *)identifier;
//...
#end
beyond that, it's hard to answer your question in more detail without knowing your requirements. the implementation of skinning an app can range from very simple to very very complex. good luck.
Already some good answer here, but I'd add that if you use a ui toolkit such as Three20
you can skin everything using CSS as you might for web pages.
I do realise this is an old post, but I thought I'd share my penny on the matter:)
To make any Cocoa app skinnable you need you think of 3 aspects of the app:
1) Uniformity: By this I mean that on all windows, views (including buttons, text inputs etc...) you want to have a 'standard' that will apply throughout the app. This is the first thing you need to look at. Although iOS and OS X alike already have 'themes' as to put it i.e. Apples default way of shading and laying things out, you can override these (refer to the individual view / window etc... documentation.
2) Performance: With skinning etc... performance is always an issue when it comes to writing your own drawRect etc... methods. The code apple have in place for the 'default' is already optimised, so you need to keep a close eye on the performance of the app whilst you are doing this. Good examples are: Do I use an image with a gradient, or do I use NSGradient? Both of which have performance issues when it comes to rendering them, but it's a question of which is the better of the two
3) userDefaults: This is generally the area where you'd be getting your 'skin settings' pulled from. userDefaults is basically where you store all of the information which you generally set in a preference pane.
If I were you I'd look into the class reference of it:
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/
Furthermore, here's a nifty example of using userDefaults:
http://mobile.tutsplus.com/tutorials/iphone/nsuserdefaults_iphone-sdk/
Hope this helps!
Related
I'd like to offer my app users a couple of different skins to use for the app, a default black skin and then say a white skin. Maybe allow them to set fonts and / or font color site wide for headers or whatever.
What would be the best approach to do this? Obviously I don't want this to affect the speed of my application.
You basically have 3 options.
HTML5 + CSS in UIWebView
Depending on your needs, the most flexible way would be to provide part of the user interface via UIWebView as HTML5 and CSS, and let the users (or theme makers) create different CSS based styles. This is what most applications do; IM+ or Colloquy for instance.
Modifying the native controls by subclassing them
Apple might reject apps that modify the native controls and views. So that is not a secure option if you want to submit your app to the App Store.
Create your own UIView subclasses and implement their behavior
Option three would be to draw your own controls using subclasses of UIView, but that might be more work than it's worth. You find this in many games on iOS.
For storing and accessing properties like colors and other parameters that make up the user interface, I'd suggest using something simple.
In some of my apps I use a JSON file (or alternatively XML - but that's more work to parse). There is TouchJSON (github.com/schwa/TouchJSON) which does an excellent job in simply converting a file into an NSDictionary, which is easily accessible. You could, for instance, store colors and font names and sizes in such a file and read one of them at launch time.
I'm the programmatic guy, and I simply don't want to use Interface Builder. I feel out of control, and besides that my GUI is about 90% custom all the time.
Literally every book does everything in Interface Builder and claims that this is the one and only great way to have real MVC going on.
Example: One of those books mentions that programmatically creating an UINavigationController with an Root View Controller and everything else that belongs in there is a big mess and won't be reusable when porting to the iPad, while doing this in XIB is a clever decision. Then the port to iPad using UISplitViewController will be a simple task.
So when I make iPhone apps and want to port those to the iPad too, what strategies work to reuse as much code as possible? I'd like to learn more about how to separate my code and achieve a better overall architectural design without using Interface Builder.
For those who want to tell me I must go with IB: Again, I do a lot of custom UI where IB is often just in the way. And not to mention all the animations. I really have my reasons. For people who make default UI IB is really fine - but please, I don't want to start a fight for IB vs programmatical UI or default UI vs custom UI! It's all about how to achieve great reusable code when doing everything programmatically, and both have their pros and cons.
Although you did not ask for it, I feel compelled to make the case for why people in general (perhaps not you) should consider IB, and then address the issue of custom components.
I use a lot of animations and custom components. And I love to use IB...
The key is to use IB for its strengths, and then decide what to do with the rest from there. What then are the strongest points of IB? Connections, placement, auto-resizing and customizations.
Connections are linking aspects of views and controllers together. It's faster in IB to drag out a few connections to delegates or references, than it is to write the code that forms the connections. And, it's a quick place to review all links to the UI you are building.
Placement IB also does well at. There's a fair amount of code involved in setting up any GGRect correctly. Not only is it easier to enter and review coordinate and size details in IB, but the tool automatically sizes a lot of elements properly for the container and the control, and offers many guides to help things line up properly - that kind of thing can take a lot of repeated testing to get right.
Related is auto-resizing. Although I don't feel that many screens can actually have auto-reiszing rules that rotate the screen and come out the other side looking just right (I almost always do rotated views as a separate XIB file), there still are a lot of shifts that can occur in the course of running your application that make it really useful to have these defined just right. The best example of this is the enlarged status bar while you are on a call.
Lastly comes customization. This again can be a lot of tedious code to write; try setting up all of the properties on a UILabel manually and it'll have you yearning for quick changes in IB.
With all that said, what is a good approach to custom components? I like to use UIViews in IB screens, with the class type set to a custom UIView that then fills out the display at runtime. But at least IB helps me get composition, placement and auto-resizing just right with minimum fuss, and also wire aspects of that custom view into a controller.
The one thing that would really lend IB to use with custom components is if it would simply let me set values for any simple properties the custom view had - then I could adjust parameters like a corner radius or whatever else I had going on.
I urge you to think on IB a little more, as it's a huge productivity boost when used correctly. There should be nothing about IB that gets in the way, it's there to boost your output.
One book I really liked was Erica Sadun's iPhone Cookbook 1st edition. It did everything programmatically.
Unfortunately the second edition is bloated.
If you reuse lots of your custom UI objects, it would make sense to write a code which
reads a plist (or a more general XML file) specifying how the custom UI objects should be placed / animated
and then creates your custom UI objects accordingly.
It's like writing a mini-xib file format tailored to your UI objects; you can also feel that you're in control of everything, as an added bonus.
I've seen many people saying it's easier to code your UI directly than to manipulate them in IB.
I know how to create UI objects from code but it just seems unnecessarily complicated, especially when you have 10+ subviews/controllers in one view(screen).
1. How do you visualize the UI layout when you create UI from code?
2. How do you make sure you are following the apple guidelines when placing the UI objects? (IB shows the blue dashed line to suggest you the correct(i guess) positions)
3. How do you manage to separate the UI creation part and the UI placement part in code? (maybe to figure out the UI layout easily)
and so on..
I wish there was a tutorial or example that can answer the above questions but hard to google.
Thank you for any suggestion.
I am creating my UIs from code with config files.
I have a test iPhone app that reads a config file and displays the UI, so i can tweak it.
First: No, none of the content should be loaded from the web. All content parts are shipped with the main bundle.
I have n images and mass of text (including lists). Instead of building all view parts programmatically in objective-c if was thinking of using an UIWebView and build "only" the HTML dynamically.
Does anything speaks against it?
How does UIWebView work with local content?
Links and resources welcome.
Thanks
I would not recommend using the WebView for building application UIs. It introduces many elements that may cripple the user experience. Well, it basically depends on the complexity of the UI.
I created an App UI in WebView myself, using JavaScript and all that advanced CSS animations/transforms that WebKit has to offer, but in the end it was not good for the consumer. My goal was to make the app skinnable, but if something goes wrong - for example in JS - the WebView is stuck, except you spend the time into building a WebView wrapper for your app that deals with this.
That said I, i don't know how complex your UI is going to be, but I would say using IB or building the UI in code with cocoa is still more efficient.
Regards, Erik
I've thought about using web views in these situations sometimes, but then decided against it. 99% of the time, it's better to design the screen in Interface Builder. That will be as fast as or faster than creating an HTML page, and will give you all the benefits of elements functioning as expected (text input for example) and the possibility of customizing things programmatically. But of course, in many scenarios a web view might be the way to go (in fact, several standard UI elements have underlying web views).
my app asks the user yes-no questions, user replies using a uiswitch on screen. i've been thinking about creating a custom version of the switch that would display yes/no instead of on/off and would use a green/red background as an indicator of the value. after creating a mock up i'm not so sure this is the way to go. using the default switch doesn't feel right but so does changing it too much. what do you think?
It really depends; some custom applications have extremely custom UIs (such as ConvertBot, for example) and it works great for them. The risk is sometimes worth the effort. In other scenarios, custom widgets result in breaking usability. I don't think that changing 'ON/OFF' to 'YES/NO' is groundbreaking, if you do it right you can pull it off no problem.
I think if your mockup was better done (the slider should be divided into two to have YES AND NO of equal length with equal padding on both sides) it would look a little better.
From a user interface perspective, this is a bad idea. People have already learned the default switch, so why change it now?
Additionally, you run the risk of adding another source of bugs to your application that was not present before.
Depending on the app, this can be very valid. Sure people are used to the default controls, but changing the text or colors is not going to break the user's understanding of these controls. Its still the same switch underneath.
In your example you color both the Yes/No. That is the only concern I would have that you did change how the core switch works. Typically, it works with a highlighted color and a grey color. So, having it stay colored on both options could potentially be confusing.
Regardless, if you want to build your app this way, you should. Just because the iPhone offers great default controls doesn't mean developers shouldn't innovate and add their own or take the default controls to the next level.
Take a look at the custom UISwitch control that I built to allow me to change the background color of the control. You could use the same method to change the text, the font, or the text color very easily.
http://www.homick.com/posts/custom-uiswitch-control
The code is available on Github and includes a PSD that is used to build three different png files that the control uses. You can modify the contents of the psd to recreate the png files in whatever format you like. Swap those into the control and away you go.