In interface builder, there is a option that lets the user clear a TextField when they hit the (x) key. Since I think this option is extremely useful, I want to implement it in as many TextFields as possible.
However, the default implementation of the option is "never appears", and I want to keep as many default values as possible (because I think Apple considers the default interface behavior very well).
So my question is: when should I change the value? And if so, to what should I change it (always, when editing, or unless edition)? Here are some occasions I need to know:
On a table view
when the user enters his account details (email, password, name, etc.).
If you come up with other cases I should consider, please let me know!
Sorry, but I couldn't find any documents about this part of the UI in apple's documentation (which is very good and precise when it deals with standards).
This question is not about how to enable the key. Instead, it is when to enable it. I know it is my app and I can do whatever I want but I know how non-standardized apps feel like. So I want mine to be as standardized as possible so that the user doesn't experience any weird or usual behaviors.
This ABSOLUTELY depends on the you app design. Apple gives you these four options and it's up to you, which behavior fits your needs best, Apple does not care at all.
I personally only use it "while editing". In the past, I only used them for login or sign up forms.
Related
I use Vaadin7 and I develop my application and test it with Edge. When I enter information in my input fields, I remark than Edge store data like this (see screenshot). My question is can we block with Vaadin the message in my input fields ? I don't want change parameter in my browser Edge but I would like to do it in my code.
Best regard.
Thank you
Screenshot
It's a tad complicated.
First of all, there is no standard way of doing this. There is the non-standard attribute autocomplete that, when set to off, seems to work (or at least have worked at some point in time, see Disable browser 'Save Password' functionality) but only in non-edge browsers. One trick seems to be to use some kind of hiding/obfuscation (which I would consider a bad idea and probably leads to accessibility issues) like mentioned here: https://stackoverflow.com/a/2555771/10493440. A current approach is using invalid data: https://stackoverflow.com/a/52608082/10493440
I would not suggest any of that as it might break at any time without warning. Changing your browser's setting is the proper way to go even if that might feel unsatisfactory.
For the Vaadin part: Give your field an ID and then apply any of the suggestion above via JavaScript.execute(...) method.
Problem
I'm trying to provide my users with an alternative to purchasing my iAP by allowing them to share that they're playing the game via facebook.
However, when the composer view controller loads the content is editable by the user. Which, for profitability sake is a bad thing. They could remove the entire message and still receive the perk that they receive for sharing. Thus, ruling out that way of marketing.
I'm curious as to two solutions.
Solution One
Force Read-Only ?
Solution Two
Cancel the sharing and display an error message if the sent message is not equal to the initial text/images.
Also, if it is not possible for them to remove the image and/or url then I don't really have a problem with them adding their own text. However, if they can remove the image/url then there is an issue.
Thank you for reading.
Restricting/enforcing what to share by the user, in any way, is not allowed in the Facebook Platform Policy. See also point 2 of: https://developers.facebook.com/policy#control. You can't make the share dialog read-only and you should not check if they shared the content you have provided.
With the second solution; you might also be hitting a policy restriction. You should not incentivize people to share in order for these kind of promotions. See rule number 5: https://developers.facebook.com/policy#properuse. This might be an more difficult issue though, policy wise.
You can let people share an open graph object; either generated from your app or directly one that you (or FB) is hosting, with an open graph url. For that, see https://developers.facebook.com/docs/sharing/opengraph and https://developers.facebook.com/docs/sharing/best-practices.
I have a Swift application i'm working on that allows a user to save various settings about their profile. Throughout my code, there are times where knowing these settings/preferences are important for the application's business logic. One of them is where the user works (their job, (which is a row in a sqllite database that has an ID as a primary key). The user is allowed to select one (and only one) in the app at any given time. Think of it like a profile - they can work many jobs, but only have one selected.
The following are scenarios where knowing the workplaceid profile is important:
In my sqllite database, retrieving work/shift information based upon the currently selected work ID(so not the ID from the database, but the ID they currently have selected). I'm passing this into my query.
In an NSDate extension function, when I go to determine some things about their starting date, I need to retrieve their currently selected profile, and use that for the calculation.
Within a particular view model when I want to show/hide certain fields.
On an alert view to show something related to their current workplace.
Now I think the quick and dirty way to do this is simply create a wrapper class to your nsuserdefaults in a utility class. Sure, all your info is stored in sqllite, but your currently selected app preferences are in nsuserdefaults since I can change this around (and it will change). This would parallel my other cross-cutting concerns such as logging/error handling, where I could use similar utility classes for all my work.
The fact that I might call this helper/utility class from every single layer of my application seems like a typical red flag you wouldn't do. Whether it's logging, or a user service to get information.
I'm curious to know what other people are doing in scenarios like this. When you need nsuserdefaults from all over your app, is the answer "eh who cares, just make a utility class and call it wherever you need it" ? Or is there a best practice others have followed with well-designed iOS apps? I know AOP is something folks tend to recommend. Does that have a place in iOS?
Thanks so much stackoverflow :)
The user is allowed to select one (and only one) in the app at any given time.
This tells me you want to create a singleton class. Every time you want to change the profile, you hit the singleton class and set it. That class encapsulates all the logic to get/set whatever you need, and the accessor functions. That's what I've been doing in my ObjC code for many years, and it has served me well. It's extremely easy to debug, and the rest of the code needs to know nothing about profile management (unless it's the UI part where you choose a profile).
I'm using Settings.bundle for few configuration settings for my app.
Now I'm searching for a solution to hide all, or even better, some configuration parts for the casual users. Only a 'admin' should see and edit these fields.
Is it possible to check for a password before showing the settings-properties?
If not, what could be a suitable solution? (new view controller with secret gesture or button?)
Thx in advance!
You won't be able to do anything special in the settings bundle. It's static, whatever you compile is what all users will see. If you want special behavior, there are two ways to do it:
Put it in the app itself and only allow the user access if they have the right credentials. A secret gesture could work too, but is a little dangerous because users may accidentally find out about it.
Use a different target/scheme or compile-time conditionals (using #if) to build two different versions of the app, one that does include the special configuration and one that doesn't. Personally, I would go for this option, but it may be a little harder initially.
I am developing an iOS app in which I need a UIControl that allows the user to select between 2 options and 2 options only.
For example, assume I am displaying a form in my app in which the user fills up his personal information like Name, gender, hobbies etc. Here, gender is a possible field for which there are only 2 options (other options are possible, but let's say we don't want it in our app).
I thought it will be nice to use a customized version of the UISwitch for such a case.
But then, I am beginning to think that the UISwitch is applicable only in the context where something is enabled or disabled. Can it also be used in the context where user selects one of 2 choices? Does this go against Apple's design guidelines? If yes, then what other UIControl could I use for this? (I want to use something other than a plain dropdown)
UISegmentedControl is your choice.
You can feel free to use other controls (with customized look & feel) in your app, as long as it does not confuse users.
I'd suggest a UISegmentedControl, which has the behavior you require.