I have completed making an IOS app. Now its been final and was ready to upload, but suddenly I was given a task to apply a new thing in the app and that is as Under
When user increases text size From the Settings > Accessibility > Larger Text or from Settings > Display And Brightness > TextSize now my app text appearance must change accordingly.
What I want: As I told you above that app is completed, and as I have used too many UILabels, UIButtons and UITextViews, so I am finding a way to how to change their text size accordingly to newly changed text size by the user. Is it possible to add any extension that increase the text size of app in more generic way. so that I do not have to go to every view in storyboard to make the view of dynamic type.
The process of changing and converting every view or coding in every class will be cumbersome. Is there any short way to handle it while everything is already completed.
Please help thanks.
The process of changing and converting every view or coding in every class will be cumbersome. Is there any short way to handle it while everything is already completed.
I'm sorry to tell you that implementing the Dynamic Type feature in an already existing app is never easy and quick to be done.
It's like making the design, it takes time and requires conception for adapting the ergonomic a11y to provide the best user experience.
Even if many things can be done in the Interface Builder, I prefer to handle everything in code because you can mutualize many properties and methods while it's element by element in the IB.
Among other things, you'll have to:
Use the text styles and activate the adjustsFontForContentSizeCategory properties of your elements to have an automatic update of your system font size.
Listen to the traitCollectionDidChange method that belongs to the UITraitEnvironment informal protocol to be aware of the font size settings changes.
Use dynamic values for adapting all your constraints so as to reorder appropriately every single element and make the containers fit their contents according to the different font size settings.
Adapt and customize every Large Content Viewers to enlarge UI elements when the Dynamic Type can't be applied (only since iOS 13).
There's no magic trick to make an app with the Dynamic Type support: you have to know how it works and then build every element as you do in your daily programming.
Hereunder few links that may help to reach your goal:
A detailed summary of the WWDC video 'Building Apps with Dynamic Type' where every steps are explained with a complete example in the end.
Some code snippets (ObjC + Swift) and illustrations to provide explanations for code implementation.
Few outlines to have in mind when testing a Dynamic Type implementation.
All these information could help you make your app with the Dynamic Type support.
Related
I am trying to implement a font size changer functionality similar to the one provided by the iBooks app in iPhone.
I know how to set the font using Dynamic Type when Text Size changes at the phone level, but the requirement here is to allow the user to change the font size within the app, and update the content as per the new font size.
(I need to change the brightness and the font size only.)
I looked over the net and found this link
This link shows a manual way of doing it. I was wondering if this a common requirement among apps and is there a standard way/cocoa pod to do this?
Thanks in advance.
Been a Java developer for about 8 years, and was used to using the term "library" which I believe didn't make much sense in the iOS world.
I was looking for something that lets me change the font size and the screen brightness in one shot since I thought it would be a common requirement in most of the reading apps. Something like this :
Since I didn't find anything, and like #WTEDST mentioned saying it requires few lines of code, I went ahead and
Added a view(B) on top of my main view(A)
Showed this view(B) only on clicking of the ᴀA button
This view(B) contained the slider component and 2 buttons at the bottom for increasing and decreasing the font size.
I added a method to change screen brightness on moving the slider and another method on each of the increase/decrease font buttons.
Used a UIStackView to arrange the items nicely.
Done.
I have a somewhat customized UIPickerView in my app. Basically I use pickerView:viewForRow:forComponent:reusingView returning a simple UILabel. As I started working on making the app more accessible, I noticed that VoiceOver reads label and adds, say, "3 of 300" (i.e. row number "of" total rows). This is not a desired behavior.
While trying to troubleshoot this, I found that if I use pickerView:titleForRow:forComponent instead of pickerView:viewForRow:forComponent:reusingView, without any other changes, then I get the desired behavior of VoiceOver simply reading the "title" of the selected row. I tested this on iOS 9.
Question is: how do I get UIPickerView back to the "normal" VoiceOver behavior, while still using pickerView:viewForRow:forComponent:reusingView? Thanks for any help!
I asked Apple support for help on this. The official reply was: "Our engineers have reviewed your request and have concluded that there is no supported way to achieve the desired functionality given the currently shipping system configurations". (For posterity - this was when the newest iOS version was 9.4). They suggested to file a request for new functionality, which I may do.
To solve this problem I went with the following workaround.
Created a base class almost identical to the class I had, but implementing only pickerView:titleForRow:forComponent and not pickerView:viewForRow:forComponent:reusingView. This class presents vanilla non-customized picker.
Created a subclass of that base class, now implementing pickerView:viewForRow:forComponent:reusingView. This class presents a fully customized picker.
In my code elsewhere used UIAccessibilityIsVoiceOverRunning() to create an object of base class when VoiceOver is on, and an object of the subclass otherwise
Thus when a user is running VoiceOver, they get a visually ugly picker, but one that is perfectly well-behaved in terms of accessibility (i.e. no row number announcements). Which is a perfectly reasonable "compromise" I think, since the user is basically guaranteed not to care about the visual appearances.
One fix will be to check if voice over is running
UIAccessibilityIsVoiceOverRunning()
If so use titleForRow otherwise use viewForRow. That way you don't degrade normal experience.
For an iOS app i am currently working on, I need to manage the controls displayed on the screen based on the type of device the app is running on.
I will try to explain with a theoretical example (the actual numbers used below are not important, what interests me is best method to achieve the desired result).
Example:
In the case of the app in the screenshots, the button that overlaps the UIImageView should not be displayed at all OR displayed in another place on the screen.
So far I've worked with autolayout , but , from what i could figure, there's no way to say to xcode something like: hey, for a class size "Compact Width / Compact Height" , I want you to hide these buttons...but show them for "Regular Width / Compact Height" .
I also did some googling and saw some people talk about using different storyboards based on the device; I am also thinking, I could add/remove buttons dynamically based on the device type , but I think it's not so pleasant to have to add all of the constraints by hand (programatically that is).
So to resume, I would appreciate a suggestion of a 'best' way to do this , best meaning a combination of 'not so hard' + ' not so long'. Also, some code example (or links) would be highly appreciated.
Thank you all in advance !
I think it all depends how sophisticated it gets what you are doing overall. When you look at developer's code for large app projects very little is actually done in interface builder since the apps are so dynamic it's just too much work in IB.
Using multiple storyboards 'sounds' like a good idea, but often isn't. If you want to update/change one, in most cases you then have to change the other ones as well.
What I think is handy:
Use one storyboard (or multiple but for different parts of you app and not parallel ones) and then put in very 'special' cases multiple ViewControllers of the same class for the different size into the single storyboard. That way you won't forget about updating the second (and third) because they are all right there.
I would only use multiple 'parallel' storyboards for apps that support iPhone and iPad and it makes sense to really split them up..
Also:
I would as fas as possible still use just one representation and derive the other 'versions' from that in code. If you build a structured user interface you can then reuse (or just inherit) the code that 'hides' parts of the first viewController in the next. That way your code AND your IB files won't get cluttered.
Also think about internationalisation (if that is part of your future plans), since multiple IB documents and multiple instances of the same viewController layout really don't help for that ;)
I want to send some log data to the ios app settings menu. I have dynamic text fields that I can change from that app working, but I need a text block now.
What I need to do is have a menu item that has a child view. That part too I have working. You click on View Logs from my app settings menu and it takes me to a blank page right now. How can I add a large dynamic text block? I have tried adding a Group and setting the Key to FooterText which I think is what I need to do. I can specify static text in there right now.
I don't know how to make it dynamic though. Any ideas?
Not exactly clear on what you are trying to do here (maybe clarify?). If you need a large text view then why not consider UITextView. You can jam essentially as much text in there as you want.
Settings is really not meant to serve as a read-write repository in the manner you describe. It is really focused on write infrequently, read many (think LDAP). However, you can make a lot of text data available through settings if that's what you want. Since the fields in settings don't support large quantities of text data, you might consider this approach. Even though it talks about 'licenses and attribution' you could apply this to logfiles as well.
best way to add license section to iOS settings bundle
I'm building an iOS with bilingual content, the user will be able to switch between languages at any point and the content will be updated to the selected language. What is the best way to keep track of all of my UIView components to facilitate the language switch?
The options I see are;
Make each element that could possibly change a property of my ViewController;
Give each element a tag and grab the elements with viewWithTag when required;
Throw out the whole container view and rebuild it from scratch.
To be honest none of these 3 options sound ideal, are there others options I haven't thought of? What is considered the best way to keep track of multiple elements?
Thanks,
Edit 3 Mar 2014
More details.
The app will have two versions of all the dynamic content, French and English. Only one language will be displayed at a time, but the user will be able to switch languages at any time and all of the displayed content should be updated.
App description.
The app is part of an instillation and will be run in kiosk mode with a landscape orientation. The left hand 2/3 of the screen will be a horizontal scroll view though which the the user can page though the content. When the user sees content that they wish to investigate further a vertical scrollview will slide up from the bottom and fill the right hand 1/3 of the screen. The user will then be able to page though details on the content. It is this dynamic detail content that I am currently working on changing according to language.
What I'd do is subclass all "basic" components (UILabel, UIButton and others) and make them respond to a global, custom NSNotification sent by your controllers when the user switches a language, with the use of the global notification center ([NSNotificationCenter defaultCenter]). That way, anyone has a chance to update.
In a recent localisation attempt we just made every visible string an outlet and defined them as NSLocalizedString, then we have plist dictionaries for each language. It takes awhile to get all set up, but is relatively easy to maintain once it's there!
Not saying that's the best way, but that's what we did!
https://developer.apple.com/internationalization/
That link may help you! :)