I have developed the application in ios. It is working fine. I have converted it as a framework(library) so that My codebase remain same.
I have multiple clients for this app. So I need to change the following things
Colors (As it will change the background colors, text colors etc)
Strings (Like headings and labels in some views)
Some files like Images etc
What I want:
As I am android developer, So in that I can create another color file in my client app with same color name, that replaces the color value in Library. and this it just require only one file to be replace and it automatically overrides in library. Same was the case with the String.xml and image files
Looking for something like that as I have described above.
What I searched and found so far:
After searching alot I have found that I need to make outlets public and then I can give them color by accessing them. But What If I have a 1000 of views and 1000s of outlets to make to use this technique, Isnt it better to use it as same way as in android I described above.
Confusions:
Is there anyway in IOS to declare color in a file and to use them in IB and code as well. Well I read about Color.xcassets but that is for ios 11 I think
How to make strings file and to use them in IB and in code. Like strings.xml file in android?
So I short, I want to updated colors,Strings and file per client wise and I do not know how to do it and what is a best way of doing this??
Please help and thanks in advance. Please share your views.
You should configure your framework to read from predefined files in .plist file. this will require only changing the files content in the client application.
Easy way to handle colors and theme using SkinKit. This is too old code. You just reuse idea or create custom themes configuration file(plist,JSON),Strings and images as .bundle read all color and customization from that bundle. So easy to change Colors, Strings and Images assert for various clients.
You seem to have a misconception about what IB is — in particular, what a nib is, and what it means to edit a nib, which is what Interface Builder does. A nib is a file expressing potential instances, typically views. You edit it on your computer using Xcode (IB). When your app runs, the nib is loaded and the views are actually instantiated. That is the only thing you can do with a nib when the app runs. You cannot modify the nib in some way when the app runs; all you can do is load the nib and get the instances.
So, if you want to change all the titles of buttons or all the colors of views when your app runs in accordance with some configuration file, you can do that, but that has nothing to do with nibs or IB. You would just load the nib as usual to get the views, and then change them all, one by one, in code. You could use tags or some other identification mechanism to help you find each view, but that would be entirely up to you to work out.
Related
So a few weeks ago I got into Swift and before that I learned a bit Web dev. When learning web development there was always a certain structure to follow for any project. Like specifying where to get the stylesheet from, where to get the JS and that information was put into the head of an html. It is not easy to put my question into words, but is there a general structure for iOS projects? So far I realized that there is always an "import" for example at the beginning of any file to add a framework and then a class. But there is always just one class and all the code goes into that class, why? What else stays always the same for iOS projects?
There are a couple of ways you can approach developing an iOS project. But generally this is what you need to know.
All your UI related designs can be implemented in Main.storyboard file in your project. Here you can create a View Controller and add various UI elements to them like button, labels etc.
To make sure your views look the same across all device screen sizes, you need to use autolayouts which is the process of setting constraints to the UI elements so that they can be resized according to the screen size of the device they are being displayed on.
For each View Controller created you have to assign a class file which is a .swift file. In this class file you have a function by default called viewDidLoad(). This method is executed when the view is displayed on the screen after running the code.
For each UI element in a View Controller you can add IBOutlets and IBAction to their respective class file.
Here are a few links that can help you more:
Tutorial for autolayouts: https://www.raywenderlich.com/443-auto-layout-tutorial-in-ios-11-getting-started
Tutorial for Swift programming: https://www.raywenderlich.com/6338-swift-tutorial-part-1-expressions-variables-and-constants
Get started with iOS: https://codewithchris.com/how-to-make-an-iphone-app/
Some other useful links:
https://medium.com/ios-os-x-development/7-things-you-must-absolutely-do-before-writing-an-ios-app-a8bacf710c57
https://www.raywenderlich.com/477-design-patterns-on-ios-using-swift-part-1-2
I am going to implement Alert feature in my application.
When user taps an alert button my application is about to change all orange (default) colors to red (Navigation bar, switches, Tab bar, Buttons, views and other stuff).
I want to implement it using "css" files also known as stylesheets.
I've found two libraries: Motif and NUI.
The most important problem is to dynamically change theme inside application. Motif can do this but I want to do it more simple.
Also I learned that NUI can change the app theme too but I can't to change it dynamically.
P.S. I am using storyboard and XIB-files. I need to add runtime attribute for object's key-path. This attribute will go to my stylesheet file and apply styles. It's the most simple way I think.
Can I do it simply and without any libraries?
P.S.S. NUI is more simple for me. Maybe you know how to change styles when application runs.
There are ways of making this work, but not very simply. So your options are either to construct your own solution, or use a library.
If you are looking for something that feels easier and more native than NUI or Motif, and which also lets you assign styles and see them rendered live inside your storyboards, take a look at my library for this: https://github.com/daniel-hall/Stylish
Here is a demonstration of changing the "stylesheet" (which can be created either in code, or in an external JSON file) at runtime:
In Android, you lay out a view with an AXML file, where you specify the hierarchy of sub views and their relationships, and the OS loads this file and renders the view.
In iOS, there's a NIB file, which is similar in concept, but it's completely human unreadable (in my opinion). You can create this file with the WYSIWYG editor in Xcode, but you can't just type it by hand, because it's immensely complex and impossible to get right.
I find the WYSIWYG editor unwieldy for any but the most trivial layout, and so I'm also finding that in iOS, it's easier to build the control tree in code than to use the NIB file. But the AXML approach seems much easier still.
So, I'm wondering if there's any iOS library that would let me lay out the code in a declarative way (that is, not with a designer), and then create a view from that, with automatic resizing and other conveniences.
The .storyboard format is a simpler format to read, use that instead of XIB files.
It seem like you are coming in iOS development from Android.
But Editing background XML (Back Source) view file is not style of iOS.
Yes you can see that file but Apple want that you design your app by using this two approach only.
How I can say that? Because apple have not provided any document for how to do that (At least I have not come across any).
Design in visual editor (XIB Or Storyboard)
By Using code (Create view and controls and addSubview)
Mostly we use mix approach we use top level and simple design by first one and use detail and complex design by second one.
Storyboard is new and very good one try to use that.
I'm working on 2 iOS apps using the "multiple nib files method".
I came across storyboards not long ago and this seems really great in terms of efficiency.
Any reason not to switch to storyboards (for quite simple applications) ?
Are there any stuff that were possible in the old methods that are not more possible now ?
The answer is... it depends. Storyboards are all fine and dandy, but there are circumstances where multiple nibs are still beneficial. For example, if you are using a scroll view to swap multiple subviews on and off screen then it's far easier to design each subview in its own NIB, then load and add them programatically.
I have found a comfortable compromise: I use a storyboard for the main app screen and any major state transitions (e.g. a 'main' mode to a 'config' mode), but I still use separate NIBs for subviews which are off-screen to start with (e.g. dynamically created popovers not tied to a fixed UI element.) I get the ease and efficiency of storyboards for big stuff which could be a bit tricky in the past, but I get full flexibility for designing very dynamic UIs using separate NIBs.
Anecdotally, I have heard that storyboards are a particular pain for people developing in teams of any significant size. They are extremely hard to share, and they make dividing up responsibilities for separate areas almost impossible. Separate NIBs work perfectly in those cases.
They're another tool, nothing more. They're certainly not a complete replacement (at least, not yet.)
The main reason you might stick with NIBs and programmatic transitions rather than a storyboard is to retain compatibility with iOS 4 and below. Once you're supporting iOS 5 only there's going to be very little reason for using NIBs, however they'll still be useful for any occasion when you want to be able to load a resource on demand, possibly several times.
So, off the top of my head, I'd still expect to use NIBs to design UITableViewCells and other similar content, and as a way to store graphical-type data in a way that's visually editable.
I'm not sure how common a practice it is, but often when I want, say, for the palette used by a program to vary from target to target or by locale, I find it more manageable to create a NIB with a bunch of views set to the relevant palette colours and to programmatically load the NIB and pull the colours out. I find that to be a good solution because you set the visual properties of the thing through a visual editor, built right into the IDE.
I like storyboards over "multiple nib files method". Only difficult part i encounter in storyboards is Control object. Messaging between two views are little difficult but once you understand it will be very easy. All the stuff is possible which you can achieve by multiple nib files method. I will recommend you to use storyboards over multiple nib files.
I'm learning the basics steps to internationalize an app and I have a question about localizing interface NIB files... I've seen that in Xcode you can click on a AppViewController.xib interface file and click on the + in the Localization section of the inspector window to add another language along with the default English one (I add Italian for example)... This allows me to translate the interface in Italian... but then how do you maintain future evolution of the App? If you need to add a button, for example, you have to add it by hand to all the localized versions of your interface NIB file? Documentation says also
Objects in a nib file typically have connections between them that should not be broken. Make sure you lock all connections before handing your nibs off to translation. For information on how to lock down your nib file, see “Localization” in Interface Builder User Guide.
Can you explain me this concept? I've seen the Localization Locking section within the inspector which allows you to lock Properties, Localizable Properties or Un-localizable Properties, but I don't understand very well what it does.
So, to sum up a bit, I'd like you to suggest me what is the workflow to design localized versions of your interface and maintain the multiple NIB files when the interface evolves.
EDIT: any idea and/or link that can help me?
iLocalize provides an easy way of localising an app and updating translated nibs. If you'd rather use ibtool, --localize-incremental, which will handle the changes in a nib and copy them to the translated nibs, is explained well here.
Alternatively, you could use NSLocalizedStrings and one nib which is useful in some instances. Set each control's title in code and you need only worry about making the controls wide enough for the longest translation.